Unresolved symbol ___strncpy_chk
mstange opened this issue · comments
I finally wanted to give HookCase a try (after letting 7 months pass by...) but wasn't successful when I tried to install it.
Here's the error I got:
$ sudo kextutil /usr/local/sbin/HookCase.kext
Diagnostics for /usr/local/sbin/HookCase.kext:
Code Signing Failure: not code signed
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/usr/local/sbin/HookCase.kext"
kext signature failure override allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/usr/local/sbin/HookCase.kext"
(kernel) kxld[org.smichaud.HookCase]: The following symbols are unresolved for this kext:
(kernel) kxld[org.smichaud.HookCase]: ___strncpy_chk
(kernel) Can't load kext org.smichaud.HookCase - link failed.
(kernel) Failed to load executable for kext org.smichaud.HookCase.
(kernel) Kext org.smichaud.HookCase failed to load (0xdc008016).
(kernel) Failed to load kext org.smichaud.HookCase (error 0xdc008016).
Failed to load /usr/local/sbin/HookCase.kext - (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).
I'm on macOS 10.12.6.
I can reproduce this error, but only when I build HookCase.kext with XCode 9.1. When I build with XCode 8.3.2 I don't see it. I expect builds made with XCode 8.3.X would work (would load successfully), but those made with XCode 9.X wouldn't -- though I've only tested with 8.3.2 and 9.1.
Please test with XCode 8.3.2 (or 8.3.3) and let us know your results.
You'll probably have noticed that HookCase doesn't yet support the current version (10.13) of macOS. I'm hoping to deal with that over the next few weeks. If this bug only happens building with XCode 9.X, I'll probably only get around to fixing it in the same release.
I just noticed that XCode 9.1 doesn't have a MacOSX10.12.sdk directory -- only a MacOSX10.13.sdk one. This might have something to do with the problem.
I manually changed the SDK to the 10.12 SDK, rebuilt with Xcode 9.1, and now it works! Thanks for the tip!
At least I think that's what I did. Checking the project preferences again, it seems the SDK has reset to the 10.13 SDK. I'm not sure if it actually reset or if I'm seeing an Xcode UI issue.
Any update on 10.13 support @steven-michaud?
It may be a while.
I've been stymied by an Apple bug that seemed to prevent the logging of any "messages" from HookCase.kext (using printf(), IOLog() or os_log()). At first I thought this might be malicious -- that Apple might (effectively) be preventing non-Apple kexts from using printf() and friends. But it's just a bug, and effects any newly compiled kext that's never been loaded.
I discovered the bug also effects current versions of macOS 10.12, so I was able to use HookCase and dtrace to debug it, and to figure out workarounds. (I needed dtrace for its ability to set probes in the kernel itself.) But that means I'm only just now starting my work on getting HookCase ready for 10.13. Currently, I'd guess it'll be done in January or February of 2018.
I'll write up my diagnosis of Apple's bug as an Example for the next release of HookCase.
Alright. I encountered this bug as well when I loaded HookCase on 10.13 and my intentions in fixing it were gone because of this; unlike you, I didn't want to debug Apple's bugs.
You could also describe the bug (or at least the workaround) before the next release so I could fix HookCase for myself. Well, at least I'd appreciate this.
Either way I'm looking forward to the 10.13-compatible release and I appreciate your work!
I'm glad you like HookCase :-)
I'll save writing up the bug for later. The workaround is pretty straightforward, but you need to add a serial port. This is easiest using a virtual machine. I use VMware, which writes the serial port's output to a file on the host machine. Macs haven't included serial ports for ages, but they're still supported both in the kernel and in user mode (though not in both at the same time). To use a serial port from the kernel, use nvram to set boot-args to "debug=0x8", then reboot. A bunch of kernel startup stuff will get logged to the serial port, and so will any of your own kprintf() output.
I've run into another snag, and updating HookCase for 10.13 will not be easy. This time the cause isn't a bug but a feature. Apparently Apple now uses a special value for the CR3 control register in user mode that doesn't map any kernel pages. As a result the interrupt descriptor table (IDT) now lives outside the kernel (but still at a location outside of ordinary user space). And if you replace the "offset" in an IDT entry with a pointer directly into kernel space (or kernel extension space), your machine will panic every time that pointer is dereferenced.
It's frightening to think that, without this new protection, user-mode code might be able to read (or write) kernel memory directly. But that seems to be what Apple is defending against. Interestingly, Apple seems to have introduced this "user-mode CR3" since 10.13 was first released. At least it isn't in the xnu kernel source dump for 10.13 at opensource.apple.com. It's very unusual for Apple to make such a big change between minor releases. This suggests they were defending against a real bug.
I'm glad I waited :-) If I hadn't, this change would have broken HookCase on macOS 10.13.
By the way, two key labels for digging into the new IDT and "user mode CR3" (in a disassembler) are "idt_hndl_table0" and "doublemap_init". Apparently the _HIB segment (where the IDT lives) is now being mapped twice into memory -- once into the kernel, and a second time into a special region where the IDT is actually "live".
"idt_hndl_table0" and "doublemap_init" first appeared in the 10.13.2 kernel, so it seems that this change was made as of the macOS 10.13.2 release.
I suspect the bug that Apple works around using the "_HIB segment double-mapping" trick is the "kernel memory leak" reported here:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
If so, this bug, though fixed in macOS 10.13.2, isn't yet fixed in earlier versions of macOS/OS X. And if Apple backports their workaround to 10.12.6 and 10.11.6, that will break HookCase on those versions of macOS/OS X.
It indeed is, but it's verly unlikely for Apple to backport their patches. So I wouldn't worry too much there. :)
It now seems clear that two processor bugs (or design flaws) are involved here -- Meltdown and Spectre (https://meltdownattack.com/). macOS 10.13.2 contains a workaround for Meltdown. But more fixes are expected in 10.13.3, maybe aimed at Spectre (http://appleinsider.com/articles/18/01/03/apple-has-already-partially-implemented-fix-in-macos-for-kpti-intel-cpu-security-flaw).
I've found a way to make HookCase compatible with Apple's _HIB segment double-mapping, but it isn't yet complete. For example, I haven't yet checked that it doesn't undo Apple's KPTI (Kernel Page Table Isolation). And there's a lot of other work that still needs doing -- for example checking the offsets of a bunch of structure variables in the "regular", development and debug kernels. So, though I'm now reasonably confident that I will be able to create a HighSierra-compatible HookCase, it'll still be a while before I'm done.
In any case I'll wait for macOS 10.13.3 to be released. Though I'm going to test with the 10.13.3 betas, I won't be entirely sure what to expect in the final release.
The new version of HookCase will dynamically detect whether KPTI is in effect. So it shouldn't make any difference whether or not Apple backports _HIB segment double-mapping to 10.12 and 10.11. Either way, the next version of HookCase should still work on older versions of macOS/OS X.
I've finally managed to release version 2.0, which can deal with KPTI support when it's present.
Apple did backport KPTI to Sierra and El Capitan, and did break HookCase 1.0 there. But HookCase 2.0 is once again compatible with the current release of macOS (High Sierra, 10.13.X), plus all prior releases back to OS X Mavericks (10.9.X).
I also fixed a number of bugs in HookCase 2.0, but they don't include this one. I've decided to require a version of XCode that includes an SDK for the version of macOS/OS X on which you're building. So I'm going to close this bug "won't fix".
I forgot to mention, shinvou, that I did include a detailed explanation of Apple's missing log messages bug, as part of my "Kernel logging" example:
https://github.com/steven-michaud/HookCase/blob/master/examples-kernel-logging.md
Awesome work you did there! Can't wait to take a in-depth look at the changes in the next few days!
Thanks! :-) Let me know if you have any questions.