Jump to content



Member Since 13 Aug 2005
Offline Last Active Jul 26 2016 04:52 AM

Posts I've Made

In Topic: [AMD] OS X El Capitan (10.11) FX Kernel Task Force

31 March 2016 - 06:08 PM

Hi folks, could one of you prepare a post with a list of CPU models that fail?? That would help me greatly.

-- Sinetek


Edit by spakk:

Hi Sinetek, I have placed your post here, I think that here is the right place for your request,


In Topic: [AMD] OS X El Capitan (10.11) FX Kernel Task Force

21 March 2016 - 06:44 AM

I don't know :(
I have no AMD machine to reproduce the bug.

In Topic: [AMD] OS X El Capitan (10.11) FX Kernel Task Force

11 March 2016 - 03:18 AM

anyway it sounds like a cache writeback issue

In Topic: [AMD] OS X El Capitan (10.11) FX Kernel Task Force

10 March 2016 - 08:46 AM

hmm.. I don't have an AMD CPU to test

In Topic: [AMD] OS X El Capitan (10.11) FX Kernel Task Force

24 February 2016 - 09:45 PM

Hey guys. It just dawns on me that the whole opcode emulation thing is not the only way to go.
You could have the Kernel detect any dynamic loading of libSystem and redirect the offending SSE-optimized string functions (memset/memmove et ali) to either safe functions in the comm-page or another newly mapped area in the process' memory. Well, there could be a few ways to go about this, but the general idea is the same.
This would be a metric bajillion times faster than going thru the kernel call on every single offending instruction.

hmmmmm I'm kinda sorta curious about it now.




Hell, we even have the source code to the system dynamic loader, so we could stuff the $amd symboled versioning in there and do all the re-routing even in ring3 space there. This is the less barbaric way but that would require lots of reversing and coffee.

Plus the names won't change much, this is all POSIX stuff.. AFAIK

Similarly the kernel also has a dynamic loader, for Kext purposes, and the crypto stuff that uses SSE primitives could be forcefully re-routed on a case-by-case basis to safer versions somewhere. That's the easier of the two, i believe. Apart from the long debugging hours, that is!

Edit #499305: As I recall one of the problems I had with this approach before writing the opemu is that the dynamic linker itself used a private version of these optimized libc functions. So it was a circular problem. We could EITHER bootstrap this at first using the fallback in-kernel opemu or throw the towel in and try to build a custom dynamic linkers ourselves from the sources, which might cause us to lose some OS X features, not entirely sure on that. It should be legal though to distribute the binary?

Edit #499306: AFAIK the graphical frameworks like Aqua inline their memcopy/memmove operations to make sure image blitting is as fast as possible, that's a big problem- and possibly the source of graphical corruption here. Who knows, it's been a while now.

© 2016 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy