GithubHelp home page GithubHelp logo

polaris22fixup's Introduction

Polaris22 Driver Fixup

This KEXT fixes known graphics issues with Polaris22/VegaM on OSX. Only tested/supported on 10.14+.

  • Framebuffer corruption due to Metal driver bug. The details of the issue and the fix can be found here.
  • On 10.14.5 Beta 2 and newer versions, boot fails with accelerator enabled and ends in a black screen.

Installation

  • You need Lilu 1.3.8 or newer as older versions had incompatibilities
  • Install the KEXT along with Lilu

Implementation

Metal Bug

Userland code injection on 10.14+ is tricky because of various security features designed to prevent malware from taking over system applications. See this article for reasons why various older techniques no longer work.

We do not have to worry about permissions because we have kernel access, but finding when a particular piece of user code is loaded is tricky. OSX does not page in the code until it is needed, so we cannot hook mmap or related functions. Instead we hook cs_validate_range. This function is called after the code is paged in, in order to check the code signature. We put our hook after this call so we can modify the code after the signature check passes. The advantage of placing our hook here is that we do not cause needless paging which reduces performance.

In the hook, we check that the file getting paged in is either AMDMTLBronzeDriver or the shared cache dyld_shared_cache_x86_64h which contains every platform binary on the system. Once that matches, we do a pattern search for the function to patch and fix it.

SMU Loading Bug

Polaris22_UploadSMUFirmwareImageDefault callsPECI_IsEarlySAMUInitEnabled to check if SMU firmware can be loaded directly. PECI_IsEarlySAMUInitEnabled looks at bit 0x160 of CAIL_DDI_CAPS_POLARIS22_A0 which should be 0. But it is 1, leading the firmware to not be loaded. Patching the function to return 0 will fix it.

Before 10.14.5 Beta 2, it worked by chance. AtiAppleCailServices::isAsicCapEnabled did not have CAIL_DDI_CAPS_POLARIS22_A0 and defaulted all bits to 0.

Performance

Because we are hooking on a hot piece of code (code signature checking), we need to make sure we are not adversely impacting performance. The two operations we add are a string compare for the path name (as well as potentially needing to generate the path name) as well as finding the pattern to patch (only if the path name matches first).

Although both operations can be costly, we point out that the path name is at most 1024 bytes which is 1/4 of the minimum size of data (4096) that code signature is checked on. In practice, the path is likely much shorter. In terms of the actual pattern search, we note that right before our hook is called, a SHA hash is computed on the same data. This means the data is already local (in cache) and we have already done Θ(n) work (n bytes). We use a O(n) optimized memmem implementation from musl for the pattern search.

polaris22fixup's People

Contributors

goodbest avatar osy avatar osy86 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

polaris22fixup's Issues

Lilu userspace patching in 11.0

With 11.0 macOS no longer has frameworks and the dyld shared cache now resides in /System without the descriptions of the address ranges in a textual format like before. There will be updates needed to get things working for both this kext and Lilu itself, with likely changes in the entire userspace APIs for Lilu on 11.0 and newer.

I still do not have a good idea what is the best approach here. Since various issues were reported with dyld shared cache patching in the past and since Polaris22Fixup uses an entirely separate way of patching, I wonder if you could suggest something for 11.0? That would benefit all the sides and integrate them better.

My primary concern is doing symbolic patching as I believe doing memory searching for hex-patching is rather slow and error-prone. However, the changes in 11.0 allowed us to avoid reading files from rootfs effectively improving the overall performance. I wonder if it is possible to keep that with userspace patching too.

vfio possible?

I'm running macos via kvm on a hades canyon 8i7hvk
with the VegaM passed through to Osx via vfio,
I can fake the PID and inject ATI and get the Card to display
But I can't get the card to display with just the simple

4GcAAA==
patch...

I try to apply it to PciRoot(0x0)\Pci(0x2,0x0)\Pci(0x0,0x0)
which is the PCID of the Card inside the VM but I can't get it to work.
Also Polaris is the issue I really have, since Faking the ID and injecting ATI seems to work
(with no audio atm, also don't really know why...)

please see my bootlog here:
https://paste.ubuntu.com/p/pT6wR5HK6C/

and the bootlog without injection:
https://paste.ubuntu.com/p/WJHfTjc68Y/

I hope you can give me some insight to this

edit: I got the video patch working now but polaris doesn't seem to get patched, I still see artefacts
edit2: hdmi with audio works fine, had the wrong pci bus set for vfio

everything runs fine, except for the polarisfix :/

Kext compiled with with Xcode 11.4 causes immediate kernel panic

Following Xcode update to 11.4 the kext compiles fine but produces an immediate kernel panic on Catalina 10.15.4 running on a NUC8i7HNK. Here is the report:
`panic(cpu 6 caller 0xffffff8010a4c32a): Kernel trap at 0xffffff7f95c79759, type 13=general protection, registers:
CR0: 0x000000008001003b, CR2: 0xffffff83ae7c6000, CR3: 0x00000001e22a0001, CR4: 0x00000000003626e0
RAX: 0x00e3a791903d00e6, RBX: 0xffffff8050753d00, RCX: 0xffffff80507c2000, RDX: 0x0000000000000000
RSP: 0xffffff83c201b148, RBP: 0xffffff83c201b5d0, RSI: 0x0000000000000000, RDI: 0xffffff8050753d00
R8: 0x0000000000001000, R9: 0xffffff83c201b720, R10: 0x0000000000000480, R11: 0xffffff804b155000
R12: 0xffffff80507c2000, R13: 0x0000000000000000, R14: 0xffffff80507c1360, R15: 0x0000000000001000
RFL: 0x0000000000010286, RIP: 0xffffff7f95c79759, CS: 0x0000000000000008, SS: 0x0000000000000000
Fault CR2: 0xffffff83ae7c6000, Error code: 0x0000000000000000, Fault CPU: 0x6, PL: 0, VF: 0

Backtrace (CPU 6), Frame : Return Address
0xffffff8010754220 : 0xffffff80109215cd mach_kernel : _handle_debugger_trap + 0x49d
0xffffff8010754270 : 0xffffff8010a5a3c5 mach_kernel : _kdp_i386_trap + 0x155
0xffffff80107542b0 : 0xffffff8010a4bf7e mach_kernel : _kernel_trap + 0x4ee
0xffffff8010754300 : 0xffffff80108c7a40 mach_kernel : _return_from_trap + 0xe0
0xffffff8010754320 : 0xffffff8010920c97 mach_kernel : _DebuggerTrapWithState + 0x17
0xffffff8010754420 : 0xffffff8010921087 mach_kernel : _panic_trap_to_debugger + 0x227
0xffffff8010754470 : 0xffffff80110c2c7c mach_kernel : _panic + 0x54
0xffffff80107544e0 : 0xffffff8010a4c32a mach_kernel : _sync_iss_to_iks + 0x2aa
0xffffff8010754660 : 0xffffff8010a4c028 mach_kernel : _kernel_trap + 0x598
0xffffff80107546b0 : 0xffffff80108c7a40 mach_kernel : _return_from_trap + 0xe0
0xffffff80107546d0 : 0xffffff7f95c79759 com.osy86.Polaris22MetalFixup : __ZL17gTrampolineToOrig
0xffffff83c201b5d0 : 0xffffff8010ef77f7 mach_kernel : _load_machfile + 0x1ae7
0xffffff83c201b900 : 0xffffff8010ef5fb9 mach_kernel : _load_machfile + 0x2a9
0xffffff83c201b9c0 : 0xffffff8010e60e03 mach_kernel : _kctl_fill_socketinfo + 0xd03
0xffffff83c201bd70 : 0xffffff8010e68c4e mach_kernel : _posix_spawn + 0x3efe
0xffffff83c201bdf0 : 0xffffff8010e69de2 mach_kernel : ___mac_execve + 0x372
0xffffff83c201be90 : 0xffffff8010e6a37b mach_kernel : _load_init_program + 0x1db
0xffffff83c201bf00 : 0xffffff8010e2f10d mach_kernel : _bsdinit_task + 0x6d
0xffffff83c201bf20 : 0xffffff8010918f29 mach_kernel : _ast_taken_user + 0x119
0xffffff83c201bf60 : 0xffffff80108c7a0c mach_kernel : _return_from_trap + 0xac
Kernel Extensions in backtrace:
com.osy86.Polaris22MetalFixup(1.0)[0E6AF29A-E5AA-39F2-97C8-17BAB86085D9]@0xffffff7f95c78000->0xffffff7f95c7ffff

BSD process name corresponding to current thread: init
Boot args: mbasd=1 alcid=11 shikigva=80 keepsyms=1

Mac OS version:
Not yet set

Kernel version:
Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64
Kernel UUID: AB0AA7EE-3D03-3C21-91AD-5719D79D7AF6
Kernel slide: 0x0000000010600000
Kernel text base: 0xffffff8010800000
__HIB text base: 0xffffff8010700000
System model name: Macmini8,1 (Mac-7BA5B2DFE22DDD8C)
System shutdown begun: NO
Panic diags file available: NO (0xe00002d8)

System uptime in nanoseconds: 825855433`

Happy to help with testing etc.

Something wrong in Polaris22Fixup

Polaris22Fixup do not fix the window bug in Bigsur 11.0.1 when using Polaris22Fixup V131

Also there is some bug here.Double border on the The menu of finder.

Please update it.Thanks very much.

截屏2020-11-14 08 47 40

截屏2020-11-14 08 47 31

Fails to patch PECI_IsEarlySAMUInitEnabled: 0 in Monterey B4

Hi Osy,
Thanks for all the great work you have done over the last 2 years to enable macOS to run on the Hades Canyon NUC. I have been trying to get graphics acceleration working in Monterey Beta 4 using my fork of Polaris22Fixup which can be found here:

https://github.com/dgsga/Polaris22Fixup

All I have done with the fork is to update the code to remove legacy OS support and use the new Lilu API's introduced in version 1.5.1. In Monterey the dyld cache is split into four parts, hence the need to update the repo.

  • Added lilu_os_memmem and lilu_os_memchr APIs
  • Added getSharedCachePath API to obtain current cache path
  • Added LIKELY/UNLIKELY macros.

This fork works fine in BigSur 11.5.1 but in Monterey I get a glitch-free desktop but no graphics acceleration. All relevant kexts show as loaded. I have attached a full Lilu log showing the failure (highlighted in red) to patch PECI_IsEarlySAMUInitEnabled.
Lilu_1.5.6_21.0.rtf.zip.

In the ioreg device tree:
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEG0@1/IOPP/GFX0@0/AMDRadeonX4000_AMDEllesmereGraphicsAccelerator is missing.

13.4 artifacts issue

It looks like this issue is back with version 13.4 - ive attached a screenshot

image

Add support for macOS 13, Ventura - Blackscreen

(NUC8i7HVK, Vega M GH)

The Kernel-Extension seems to be not working with the first Developer Beta of macOS Ventura and needs to be updated.

I was successful to install Ventura on the Hades Canyon with a pre-Alpha OpenCore 0.8.2 build and AvoidRuntimeDefrag enabled but I discovered that it initially went to a black screen after IOConsoleUsers (last line of verbose, related to graphics).
After disabling the Kext and GpuSpoof I could boot at least without graphics acceleration (meaning VESA, 7 MB VRAM).

I'm up for everything if you need a tester.

Incompatible with Lilu user patches

Because we hook cs_validate_range as well as Lilu (when user patches are used), this would cause issues including the order of the hooks and when one plugin decides to remove the hooks.

An ideal solution would be to detect if Lilu is available, make sure to always load after Lilu, and then patch using Lilu when detected.

Add disassembly for more robust patcher

Currently, we do not disassemble the original function. We hard code a "safe" length of code to save ("safe" as in we do not copy half an instruction) and then we copy that code elsewhere and execute it before jumping to the original implementation when attempting to call back into the original function.

This will fail if, in the future, the function changes and the hard coded length is no longer safe. Additionally, if a relative jmp is added to the first couple of bytes in the future, it will also fail.

The likelihood for either case is slim but still a possibility. Ideally we use something like libsubstitute and disassemble the instruction and optionally rewrite relative jumps into absolute jumps.

monterey b4 blackscreen after -v codes finished with only pointer responding

IDK if it has something to do with the kext in this issue. My device is beelinks’s turbo g7 with 8709g. The device works properly at Big Sur 11.2 so I tried to install Monterey b4. I used to successfully install monterey on another laptop(uhd630) but this time it fails after all procedures finished. I can open the install disk, the installation goes well, but after the last reboot and the progress bar runs full, it turns out black screen and only the mouse pointer can move.

Sonoma blackscreen (Potential Fix)

Edit: I was able to get it to boot in safe-mode once with no wallpaper or acceleration but normal mode just says "Check device power" on my monitor or is blank

Not sure if it's this or something else but it seems to be an issue for the NUC8I7HVK with PolarisFixUp 🤔

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.