"loadable library and perl binaries are mismatched" not informative #15861
Comments
From [email protected]Created by [email protected]I have a number of modules which I've installed via 'cpanm'. Sometimes $ some-script-of-mine This message would be more helpful to me if it specified the module Perl Info |
From @jkeenanOn Sat, 04 Feb 2017 23:08:09 GMT, frederik@ofb.net wrote:
Does the discussion in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=124201 help you understand the problem better? Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Sat, 04 Feb 2017 23:08:09 GMT, frederik@ofb.net wrote:
Also, can you supply the output of 'perl -V' for both the version of perl against which your module was originally compiled, as well as that for the perl to which you upgraded (assuming that the 'perl -V' attached to this ticket is neither)? Thank you very much.
-- |
From [email protected]Thank you James. Your link describes the problem but I think I I'm just making a feature request for a better error message. TBH, I I run Arch and I'm attaching 'perl -V' on the old system (same as On Sat, Feb 04, 2017 at 04:27:55PM -0800, James E Keenan via RT wrote:
|
From [email protected]Summary of my perl5 (revision 5 version 24 subversion 0) configuration: Characteristics of this binary (from libperl): |
From [email protected]Summary of my perl5 (revision 5 version 24 subversion 1) configuration: Characteristics of this binary (from libperl): |
From @tonycozOn Sat, 04 Feb 2017 18:06:42 -0800, frederik@ofb.net wrote:
This might be a (conceptual) bug in Perl_xs_handshake(). The XS handshake uses the size of the interpreter structure as part of But maintenance releases *can* safely add members to the end of the interpreter structure, and 2bfbbba does just that. The handshake values in frederick's error message: (got handshake key 0x7ec0080, needed 0x7f00080) extract the structure sizes: got 0x7ec needed 0x7f0 which differ in sizeof(STRLEN) on the 32-bit system in the original -V output. So I think Perl_xs_handshake() should only be checking that the size has not shrunk in maintenance releases. One problem with that is it signifcantly reduces the strength of that check - Perl_xs_handshake() would no longer be detecting the type of problems we want it to detect - differences in sizes of the interpreter structure due to changes to the sizes of it's members (eg use64bitint changes) or due to build options (PERL_HASH_RANDOMIZE_KEYS for example) which may weaken the current interface to near uselessness. Tony |
From @iabynOn Sat, Feb 04, 2017 at 03:08:09PM -0800, via RT wrote:
Leaving aside the discussions elsewhere in this thread about the handshake
XS.c is the name of the src file from which the loadable lib was compiled; $ ./perl -I../perl-5.24.1t/lib -MPerlIO::scalar -e 1 The error is given at the point when a dynamic library is loaded; this while loading MPerlIO::scalar: scalar.c: loadable library and perl binaries are mismatched ... -- |
From [email protected]
That's more or less what I had in mind. Up to you if it's too much I guess one could argue that I should just have a command to recompile Thanks, Frederick |
From @GrinnzOn Mon, Feb 6, 2017 at 12:53 PM, <frederik@ofb.net> wrote:
Generally, the preferred approach is not installing to a package-managed -Dan |
From @LeontOn Mon, Feb 6, 2017 at 12:30 PM, Dave Mitchell <davem@iabyn.com> wrote:
The bootstrap function already received the arguments to Leon |
From @andk
CPAN.pm has a command for that. It's called 'recompile'. -- |
From [email protected]On Mon, Feb 06, 2017 at 07:54:09PM +0100, Andreas Koenig wrote:
I knew about CPAN::recompile but I had thought I would need a eval $(perl -Mlocal::lib=.local) I ran the command perl -MCPAN -e 'recompile()' and after fetching metadata it seems to be doing the recompilation So another possibility for the error message would be to have it Thanks, Frederick |
|
Thank you for this: That was hard to find ... Upgrading to Ubuntu 20.04 from 18.04 wreaked havoc on my Perl setup. |
|
Same problem, but |
|
Found more info. For an offending package: I had to do this for a handful of modules, and then I was fine. If you don't know which module is bad do a find: |
|
I wound up renaming my |
|
Hi! Damn.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xde00080) Also, I was trying to implement the solution mentioned by @princessRTFM. While doing that accidently deleted the perl folder. Thank you. |
|
Just wanted to mention that this problem had me stumped for some time when working through the process of setting up a Lightning Node. It was finally overcome when using the command "sudo ./autogen.sh" as opposed to "./autogen.sh". Obviously there was some permission issue deep in the Perl libraries. This solution may be unique to my Ubuntu setup. It's mentioned as a possible last resort solution. |
|
I think it could be improved by having EU::PXS creating a macro with the module name (as from the MODULE keyword) and combining that with the FILE to supply to Perl_xs_handshake() instead of just FILE. It would require untangling the maze of macros in XSUB.h though to define new macros that accept the new string instead of just supplying FILE. |
|
I get this error when trying to upgrade |
This is a fresh installation: OK This is on a system with previous installations of perl stuff: So, there is a conflict, but the error message does not help tracking down the root cause of it. |
|
I haven't read the rest of the ticket, but your error message says "Encode.c: loadable library and perl binaries are mismatched", so the |
So it seems, according to perldiag: However, I was able to solve the problem by removing collisions, namely uninstalling packages. See fastmail/authentication_milter#161 for a similar example, and related struggle. |
0xeb80 and 0xf280 are sizes of the interp struct/ |
There is a single perl.bin in the whole system. However, this is an updated OS, so perhaps there are old libraries lying around. |
|
As a general note: I find the end-user experience here very poor. As a core perl developer I can justabout guess what's happened, but a more casual end user would have almost no hope at all. I would greatly prefer (for the sake of not confusing users) if the handshake and message had something to say about the Perl version. 99 times in 100, that'll remind people what is going on. I.e. instead of the message: We got To an end-user, that second message is much more useful and much more likely to trigger them into knowing what is going on and how to fix it. |
|
+1000 from me too |
The code to emit that is later on but very unlikely to be reaching b/c previous checks, and if "friendlyness" matters, how do you prevent the even worse message? OS vendor or some 3rd party packer changed 1 random -D or Configure option in perl or added their not-P5P known "security patch". Float/NV length for example. Interp struct size not agreeing is fatal, none of the offsets can be trusted between perl.bin and module.so if interp structs don't agree. I never thought back when I added this feature, that Linux people would hit the error, and that my SEGVs were Win32-unique to me keeping 2 perl.bin libperl.so'es and misc build Checking Perl API string, before check interp size, is API impossible, unless you remove info (module name/package) from the existing message and switch to "Foo.c", b/c module name comes as Line 5624 in f2cb455 It is possible to check Perl API string before interp size, but 1% risky if the arg is explicitly missing by XS module's author's demand since Note for future, |
|
Another question, are OS native missing symbol messages any better than our current
should does Dynloader.xs have a ENV var to trace what .so is actually loaded? is the abs path known of the XS module on all platforms? |
|
My suggestion on p5p list:
|
Both Dynaloader and XSLoader do push the module name onto If we could use APIs we could fetch the last element of XSLoader/DynaLoader could be modified to set some name in the environment, but environment access isn't generally thread-safe. |
I didn't realize the checks were running from the code of the newly loaded module. That makes everything a lot harder. Could the failure of the new module to initialize pass back an error to the Dynaloader code so that the host perl can generate the error message, taking full advantage of the facilities to tell it what paths it was dealing with? Or, is it possible for the host program to look up a string in the .so / .dll before the initialization runs? Then it could do a more intelligent analysis of the .so before running its initializer code. |
No, the checks are done in the perl (or libperl.so) binary, xsubpp generates a call to the dXSBOOTARGSXSAPIVERCHK macro in the boot function of the loadable module, which ends up calling Perl_xs_handshake() in perl/libperl. I suspect the current code doesn't use perl APIs before the signature check out of an abundance of caution, @bulk88 originally wrote that code so I was checking with them.
I don't know how portably we could do data lookups. We could (I suppose) add a That would require xsubpp to be updated and existing binaries wouldn't have the entry. |
The handshake code can only use very basic libc fn calls, and kill the process ASAP. You can't use SV *s/PerlIO/any Perl C APIs. There could be 2 different addresses So the Perl stack That You can't write a hypothetically, Devel::Peek, where ONE .so/XS module, no compiling, no collection of .so fles, ONE. .so can correctly decode SV *s from memory dump file, simultaneously from Perl 5.10-5.40. With no crashes. Challenge issued!
IMO I think a shell ENV var to control dumping the .so paths to console, is needed. ``Dynaloader::``` should read the ENV var once (perf) on perl-proc startup, and save the flag as a bool in PP space or XS/C space, then dump all the paths to STDERR. UI note, many sys admins/power users, can't read Perl script, don't know what a
Other than Dynaloader:: dumping debug info before the fatal handshake it wont work. Remember handshake is instant-fatal incase Perl_sv_setsv() from a 5.24 libperl was injected into libperl 5.40 on ELF with I dont see a API way to get that PP Dynaloader metadata strings across. Long ago, designing -the XSUB's Aka these 2 on POSIX, https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea and https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulehandleexw
How POSIX/spec safe is it ( Can XS Maybe as described above, "bootmeta_Foo" data symbol is needed, which is a C global Data symbol export, from the XS .so to parent perl, and the ,SO's const struct has 3-part Perl API version string. No machine code has run yet from this contaminated .XS .so, so we are still in full control, on the master/root libperl, and the boot XSUB is never executed if the checks fail against the global exported symbol, RO const C struct, data table, if the module's C struct of meta data is 100% incompatible with this perl build. This would be trappable and continue life with no segv risk. Not fatal error we have currently, Simply unload the .so, (which will hopefully unload that 2nd pesky out of place libperl) from OS lib loader,, never running 1 CPU opcode from the .so, and life continues, I think a debug mode/trace for Dynaloader is easier. Than forklifting XSUB to Gen2 XS. Somewhere on my list, I have plants/experiemtnts for perl core or A formal design, on how to pack a XSUB's Perl name, and its protoype, signature, etc, basically C++ name manging for XSUBs, so that 1 Cstring in the linker, has all info for Perl to attach those XSUB fnc ptrs to PP land, has to be spec defined/community API designed. Im going to rewrite the XS Handshake messages RN, for some UI improvement, Always show API ver string mismatch error before interp size mismatch if both failed safety tests. API Ver string mismatch error is very auto-self-resolving, each user will be face with a choice, they has to force reinstall the complete perl from either the
Baby new libperl.so that was accidentally loaded, will SEGV trying to read env vars I think from XS mode. We hook most of libc tokens and route them to perl APIs, but in this case, we have an uninitted libperl.so running, So SEGV time if malloc is used or SV *s are used. With alot of testing perhaps good libperl.so and bad new libperl.so, can communicate through env vars, with no SV areanas, aslong as its 100% pure lib C. I'd rather VARARG bootstrap:: XSUB and get freakiy with ::ParseXS which is the heavy engineering fix, and add a 2nd It seems NClark was working on somekind of solution to this XS .DLL vs Perl.exe version war, but he never finished it, and not enough code or commit comments to explain it. Maybe he can come by and give the API proposal/design proposal from way back then |
Yeah, in hindsight it's obvious a different set of arguments would have been helpful. I can kind of imagine we'd add some
I think that would be probematic on recent Mac OS, but I don't quite know the details. |
|
How about this? (rough draft, for discussion) Built in each XS during compilation: Then this in perl: |
|
The advantage of the above is that now you can also write a tool that scans a directory of perl .so files and pulls the metadata from each of them, for e.g. writing a script to detect outdated modules. Could be very useful for distro maintainers, especially if one of the strings we provide in that metadata is the distro's package name for the module. That could be facilitated by the distro setting an environment variable during compile so that the XS module knows what distro package it belongs to, and could be done without any cooperation by the XS author. |
Thanks, that had slipped my mind. On Linux at least, the loadable objects don't seem to reference the perl executable or libperl.so, for example, for the packaged Imager.so for my system perl, which isn't If I build a so they won't load a foreign libperl as Windows might. As to the choice between the loadable object reporting metadata that DynaLoader checks and an extended xs_handshake, I think I prefer the metadata, since it means we're not giving control to a possibly mismatched bootstrap. Ideally we'd fetch the data pointer directly with dlsym()/GetProcAddress() since it avoids passing control to the loadable object but I'm worried about portability for name decoration ( I expect the exported metadata can be more extensible than a re-worked xs_handshake too. |
|
One problem I do see is loadable modules that are hand-written or are generated without xsubpp (such as with SWIG) won't have the metadata. SWIG's generated |
|
When the new machinery will report a more informative error, please make sure it will also report the files being checked. It is of little use to learn of a mismatch in perl versions when you are still blindfolded and need to find the relevant file to fix. |
In my example, I started with |
I was thinking the same initially, but my suggested getter should be about as safe as you can get. If the .so isn't the right architecture it won't load in the first place, and it does nothing more than copy values into pointers. |
Remember prior insanity P5P dealt with. Win 16, 32b WinCE, Symbian, "shared libraries", yes the ".dll", is a service daemon that lives longer than the process. Yes, the contents of C global vars in the .dll, live longer than the C global vars of the .exe and live longer than the Process ID. Perl.bin and perl PIDs come and go and C globals in perl.bin cone and go and zero fill the normal unix way, but the C global vars in libperl.dll, last forever until the "power button" is used. The only way to wipe zero fill all your C globals, choice 1, keep them in 1 struct contiguous, choice 2, array of void *s to C globals to zero fill. Choice 3, to zero fill your C global vars, reset button, power switch, or unplug power cord from wall. Also, I think P5P supported OSes, where if the perl process, exec() open() the perl.bin disk file again, the OS just calls C "main()" in a new thread in the same process/virtual address space. You can't clear/zero fill the perl C global vars in perl.bin until all perl PIDs exit. IIRC, this is now the weird Perl build configuration of having my_perl pointers args but no ithreads:: and no pseudofork:: and #ifdef away the libperl functions that are used for CGI/apache/nginix/Varnish. Or a weird config of no thread perl keeping " interp struct" as C globals in a tiny disk size perl.bin. with a fat 2-4MB libperl where the real code of The Interpreter lives. Now this is drinks talk but remember that on iPhone and Android the design architecture of a process is identical, to the MSDOS implementation of the process . Both Android and Iphone, are single threaded single process operating systems. I got the idea yesterday, the number one complaint is strace is the only diagnostic tool. And the top four most wanted criminals running from the law, have the street names and pseudonyms of "XS.c", "Class.c", "Base.c", and "Parent.c". If you recognize any of these four felons immediately call the police. My bin analyzer shows "Foo.c" has only one callar which is bootstrap xsub, which xs_handshake() and newXS() actually mandate. Those 2 mandates chain to macro/struct field CvFILE(). What is CvFILE()? Do not copy paste anything from Perl API Pod Perl intern Pod or Perl XS Pod or the .h files in your answer. |
|
When I actually had working Windows CE Pearl 32b port, fun fact you learn very quickly using a live C debugger on Windows Mobile 32b operating system. The hard drive, the free space count, on the hard drive, the concept of a file, and the concept of a directory, are artificial concepts, that are invented and only exist in, inside Microsoft Libc library compiled for Windows Mobile OS. If you use a raw sector hard drive GUI tool on Windows mobile OS. And hunt down perl.bin the file, you'll realize the absolute position, in that hard drive tool, on disc, of perl.bin, bizarrely is the same integer, as C ptr addr, showing in your C debugger, You know where this is going. Windows mobile OS, in the kernel SDK, and in a GUI device manager for the phone, you're not going to find a single driver, object instance, C structure, called "flash disk controller" or "hard drive". Those phones use "static RAM" soldered next to the volatile RAM on the PCB. That OS and those phones do not use SSD flash chips which have sector addresses, and do not have asynchronous IO concept of queuing a read request and then waiting for a CPU interrupt. In the 1990s and 2000s doing this Unix nonsense of a "stream" "file descriptor" allocating and deallocating malloc blocks representing IO requests to a pointless "hard drive controller" was an unacceptable use of battery life CPU time and silicon. Nobody user doing anything on these phones will actually ever notice GUI wise, with their finger, that the "hard drive" is synchronous blocking I/O, on the ram bus of the CPU. The CPU just freezes for microseconds or nanoseconds while The cache Line strobes in on the PCB to the CPU. Even more fun trying to run Perl for Windows CE port, all your developer tricks from hacking Windows 98 and NT-11, from your Desktop don't work on Windows CE. So naturally it's time for me to go attack "kernel32.dll", right? WRONG. WinCE FS is "/" and "/Windows/" and "/Storage Card/". The file browser says "/Windows/System32/kernel32.dll" is a 3KB file, weird but whatever I copy it to my desktop. I open WinCE K32.dll in a Desktop PE tool, these are basic windows programming tools. It reported there is no executable code inside kernel32.dll and all of the fn pointers of exported C symbols are invalid memory addresses pointing outside of the dll. After a lot more research I learned that all the dll files you see in the file browser on Windows CE are only there to keep Desktop Windows developers happy and win 32 API programs happy and to keep end users happy so an end user does not freak out when they buy their new phone at the store. It was assumed the user will freak out and run back to the store when they realize on their new phone the one and only file they can find with the file picker. Is an empty "/home" directory. So the entire Windows mobile phone is a fat packed single compiled C binary .exe produced by visual c. There is no filing system basically. Every entry in the "program files" directory and "windows directory" is faked by "MS libc for WinCE" to keep developers and users happy. All win32 devs got tricked by libc thinking the phone is full of apps and files when there are no apps there are no files at all and the all end users got tricked by the file picker gui. Those fake files, are implemented by RO C global array of structures. Each struct is void * to C symbol/var of the .jpeg/.txt/.wav/.exe, and char * to file name. In another place in libc, in RW Global memory, there is a bit mask of soft delete for those fake files. Once that bit is flipped the fake file is gone from libc forever unless you do a factory reset. And because long tap delete makes the icon disappear in the file picker everyone has been tricked. This keeps win32 API Developers and phone users happy enough and stops the complaints. Nobody picks up on the tiny detail that deleting Microsoft bloat in the windows folder does not change the free hard drive space reported in the file picker at all. They also might notice that if they delete a .jpeg a .gif or a .mpeg, then upload another jpeg to the phone and put it in the same directory as the first jpeg they deleted. The user is trying to change the splash screen they call ugly in a Microsoft Factory app in the phone and looking with the file picker they realized that the ugly splash screen background happens to be in program files as a jpeg file and then thought they will change the ugly logo in the app by changing that file with the file picker with a new jpeg. This is guaranteed to change the splash screen on desktop Windows 32 and it will change the splash screen on a side loaded Windows CE app but it's not going to change the ugly splash screen in a Microsoft Factory app or your cell network branded ugly messaging app that came with the phone (Verizon USA). That jpeg is only in program files for psychological reasons, the app is actually C link time permanently bound to the jpeg. Stdio is never used to read or write that jpeg on the fake file system. App is wrong word, there are no apps on the phone it's a single.exe they are C function calls combined with the c-linker into one static link. So Mr power user to fight the Microsoft Monopoly wants to delete the bloated "Internet Explorer Mobile 6" from his Windows Mobile phone and install Netscape. They go into program files, long tap, delete "iexplore.exe", go into Windows, system 32, long tap, delete "mshtml.dll". This is where things start to go wrong compared to desktop Windows. Mr power user recovered 0 bytes of hard drive space by doing this. MS Outlook for Mobile keeps showing HTML emails like nothing happened. And probably half of your own personal side loaded apps will not start up anymore, with error box about missing dll error. So that's a very interesting operating system that I had a chance to work on and they were very few complaints and almost no developers or end users ever noticed this cuz if they use official Microsoft APIs they would have never figured this out. Very important detail Perl for window CE 32b and all Side loaded personal apps you install, the disk formats, the runtime API begavior, the C struct names and field layouts, the C function symbol names, all of this will be identical to 32b desktop Windows. The most shocking glaring difference is only finding arm 32 machine code instead of Intel x86 lying around in virtual memory and in the disk files , nothing else changed for a side load app, developer experience, C compiled time, and user runtime wise. 90% of fns from desktop Windows 95 kernel32.Dll are available on Windows CE, the last 10% such as current Drive letter are missing symbols and a porting headache. The fat packed fake .exe and fake .dlls problem is only for apps that are factory installed on your Windows mobile phone. Sideload is normal disk files like any OS. Deep secret from Windows CE OS, there is no msvcrt.dll, all lowercase C functions are exported by kernel32.dll. that is not the business of an app developer or an end user to know that. I did ask on a forum how do I hack/patch/replace kernel32.dll on my phone? It's a 3KB file. The answer I got is not pretty. "Syscall VirtualProtect(ptr, PROTECT_RW) does not work if the Addr is 0x60000000-0x80000000, that is the ROM chip, in your phone and that is your 90 MB fat pack OS image. Programming voltage is 7 Volts for 5 minutes to erase the memory cells on that thing. You need a new full OS image available once you have completed the erasing procedure. You cannot change kernel32.dll any other way. You are going to need a pirated copy of "Oak SDK", obviously you're already are a c-developer but you're going to have to run "nmake" and compile the entire OS from .c, although that's the easy part, now this is the hard part you cannot just compile, a pirated copy of Windows mobile, where are you getting the Qualcomm drivers for your phone from? and you already know you can't copy the files from the file picker cuz the drivers .sys are 1 KB big. So here are some links to some warez cracking tools, that hopefully will create real .sys driver files that don't brick your phone, and don't instantly SEGV themselves. I hope you understand the implied extreme difficulty of what you are trying to do and there is no software tool that can perfectly automate recreating the Qualcomm drivers for the SOC on your phone. I suggest you find a new hobby bulk88 and don't try this." So, I'm going to destroy my phone, and a 2nd one, or live not have a cellphone, while single stepping in arm32 machine code, with visual C debugger, for 2 weeks, or maybe a month of time, what pieces of arm machine code were missed, and that are scattered around by the visual c-linker, this closed Source pre GitHub semi-legal tool, the pieces of machine code this tool missed, when trying to recreate standalone win32/window CE kernel drivers .sys files, from a single compiled win32/wince binary. I agree, they are better ways to volunteer time. Sometimes Samsung or HTC or the other vendors of Windows mobile phones made mistakes in the build process and fed an entire .sys file to the makefile that builds the operating system, instead of a .o file, to the OAK sdk makefile. That's an error by someone at Samsung or HTC. The file is a real PE file now sitting in a c array Char8_t array. If the phone vendor makes this mistake and includes the real driver that let hobbyists compile the OS and have a jailbroken Windows mobile phone running a custom ROM but my particular model that mistake was not made and you can't copy paste the drivers out of the phone. Also for some HTC phones HTC made an upgrade install Shield. EXE to upgrade some app on the phone and HTC accidentally included enough new dlls or accidentally included some updates to a factory driver and somehow they included a real full blown PE header driver in that install Shield package and now a hobbyist can recompile the entire OS and change anything they want but those were accidents or sloppy build Scripts and my model did not have that. This is a very educational lesson on how not to bake architectural differences accidentally into software. So does anyone know if Perl 5.40 still works on 286 segmented memory? Remember pointers always were 32 bits on 16-bit processors. You can't reach 640KB of RAM with 16-bit pointers. Also not obvious architecture feature, C89/C99/C23, var arg feature, I hope all developers know that "va_start();" and "va_arg();" macros are actually ring 0 kernel syscalls, outside user mode virtual address space? They are ring 0 kernel system calls from the viewpoint of the ISO C spec. The original reason was to bank switch 65 KB prefixes in segmented memory on your Intel 8086 or 286. The more modern reason is because Solaris on SPARC and Win64 on Itanium supposedly have unbreakable Hardware protection against against all C stack buffer overflows. Call/return assembler commands on SPARC CPUs pop and push the current executing instruction pointer into kernel space memory. Zero overhead, it executes in a fraction of a nanosecond, it's implemented in Hardware. C "longjmp()" either has a SPARC assembler op "rewind_call_frames(size_t layers)" or help from a kernel syscall. The integer addresses of those SPARC call frames are always a secret from user mode even if you can rewind them whenever you want. You can rewind them however much you want until SEGV but you're not allowed to know the integer addresses ahead of time before you issue the rewind op(). So don't mess around/hack/modify, "struct jmp_buf", you really don't want to know what's in that struct, or stick to Intel x86. IA64 took this to the next level, from a document that I read a month ago for IA 64 assembly for Windows Server 2003. I did not have an IA 64 machine so this is just hobby reading. I want to say I was reading a tutorial for IA 64 assembly but this was not a guide for writing IA64 assembly this was a guide for writing IA64 assembly as hexadecimal bytes on paper and pen .The chance of causing C stack corruption, or a C stack security exploit on IA64 in the C language on Server 2003, is the same chance that you have of causing JavaScript stack corruption in Chrome from a .js or Java stack corruption on android from a .class. ZERO. IMPOSSIBLE. On IA64. IA64 successfully converted C99 to use JavaScript memory protection model. So from what I read on Windows Server for IA64, the .exe is always loaded at 0x10000000. Kernel32.dll is loaded at 0x10000000, every DLL in the process is loaded at 0x10000000. So how is that possible? Well Windows for Itanium uses the SysV ELF PLT/GOT, no you are not going to start that binary on Linux for IA64, it's still a PE file header and all the PE flags and PE structs just a little different. First major change, the C stack is fully separated between each C function call, just the way it is fully separated in JavaScript. IA64 assembly, call() op has a mandatory input argument of how much C stack bytes you want to roll back into Kernel space. C auto variables are unreachable between call frames in C. "= &sum_c_auto;" , is implemented in Hardware with an extra C var arg argument, the callee did not know the callee has. Also the return addresses are hidden in kernel space and are secret like on SPARC. The caller fn has full control with hardware help which C Auto variables become visible to the callee and which C auto variables are private hardware protected. A single, 1 wrong extra "va_arg();" is guaranteed to segv on IA 64. Or your accidentally reading the memory address located passed as a size_t * 2 or 4 or 5 arguments to the left in your fn prototype. Which is perfectly safe to do you didn't learn anything new. Yes so the C99 stack has been converted into the JavaScript stack. Next design feature this was quietly killed by Microsoft and died with Server 2008 and died with IA 64. The PLT GOT was removed for Windows 8-11 for ARM. All dlls and the exe, passed control of instruction execution pointer between dll exe boundaries through a wormhole fn through the PLT GOT. Each time you switch dlls or exes through the PLT GOT, map and remap the dll and exe at the exact same 0x10000000 hardware assisted. ~%10 of each dll and exe stays in place at the same address for the rest of the process runtime life, and 90% disappears and reappears each time you cross a dll or exe boundary. " = &static_decl_c_global;" in C99, causes the c-linker, sarcasm ahead to explain to non-technical people. The C linker, make a paper sign that says "free car, steal me", drives to a high crime neighborhood, turns the car off leaves the keys on the driver seat, and walks away and will never see their car again. The C linker put that C Global variable, in a COFF/PE section, at a 4096 sized memory page at a virtual memory address that is frozen forever for the rest of the runtime process life and is read writable no matter what DLL EXE is mapped at 0x10000000. Malloc memory is also Frozen at a fixed address forever ( until "mprotect()" or libc free() call, normal posix), and malloc memory visible to all dlls and the .exe, not mattering what is mapped in at 0x1000,0000. A malicious root kit .dll, in a IA64 Win64 process cannot steal a private key stored in read only const C global memory, of another .dll, in the same process. That malicious rootkit .dll also cannot read as a Char buffer the machine code bytes that make up that other Dll. If the malicious.dll tries to do a memory address read it's just going to attack itself and its own memory mapped disk file and learn nothing new. This design stops all the basic easy security exploits but because all malloc memory is a swimming pool of everyone's (every dll) bacteria, you (malicious dll) could probably find some way to trick openSSL to accidentally copy the private key into a malloc buffer, by manipulating some C struct that happens to be in malloc memory, and exfiltrate the private key and send it to the hacker human. This design was dropped by Microsoft and killed along with itanium, because number one it renders manually parsing the PE header useless because the pointers/0 indexed offets/RVAs that are in the PE header, if you read the PE header, are invalid at all times. Also the only PE header you can ever read is your own .dll PE header, because there can never be two images loaded at any time in the process simultaneously. Each thread and each CPU core is keeping another .dll mapped at 0x1000,0000 while that thread has CPU time and is using electricity. The flips are instant and done in Hardware. Microsoft abandoned this because there were developer complaints "GetProcAddress()" is doing runtime JIT and accused of generating RPC stubs, that are then "making JSON packets" and "using a socket", instead of "GetProcAddress()" obtaining the memory address of a c symbol fn ptr. It's not RPC it's not a socket. There is nothing on msdn api docs, and there is nothing in ISO C that makes this invalid. But the conversation ends with "Microsoft?do you like money? HP, do you like money? do you want money?" The response is "what about security?". Next answer, " the CEO has decided that next year's server purchase is Dell Xeons running Ubuntu click". The zombie corpse of that architecture came back as https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard AMD and Intel did add one or two instructions to x64 because it is Hardware assisted with some pretty crazy but fast enough fallbacks in pure software for older iCore processors, specifically that all .dll and .exe are separated by a contiguous 4GB of invalid memory address space, and AMD x64 assembly only has a command called jump(const signed int32_t) or jump(register signed int64_t), static machine code analysis by the kernel or crypto signing the PE file and static machine code analysis by the c-linker, looking for jump register64, ops, starts to smell like virtual memory process isolation, but not the extreme of swapping All binaries and shared libs In and Out and keeping all of them at the same memory address. The layer of security added on titanium is just useless ultimately because malloc memory is a lot more interesting to an exploit then read only constants in a dll, which can be exploited with normal stdio and a normal read(). Hiding the dlls and they fail file test operator/stat(), couldn't be done. And attempting to keep a private key or password completely as a C Auto in some C call frame sounds impossible the entire process run time. If you do &sum_c_auto, the hardware protection is broken. https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64?view=msvc-170 On win64 for AMD 64 day 1 this was also borrowed from IA64 Windows, but the actual C autos becoming segvs feature is missing. Notice all the information to make C Autos disappear between call frames is actually in that API. |
|
Answer for what is This field had no usage in P5P perl except I can't find ANY non PRINT-STDERR use on CPAN for CV field See 1999 57843af 1999 labeled as dead code b195d48 The introduction of field So, as someone proposed, shouldn't ParseXS just add We might also have a Perl for Linux only problem, or Clang for Linux only or MSVC only problem, my strawberry perl has FULL PACKAGE NAMES like |
Migrated from rt.perl.org#130718 (status was 'open')
Searchable as RT130718$
The text was updated successfully, but these errors were encountered: