VoodooI2CHID leads to a kernel panic with OpenCorePkg

[anonymous-writer]

Hello developers,
With Clover the Kext still works as a dream. Thanks to your very good work.

Now I have tried to use the Kext under OC.
https://github.com/acidanthera/OpenCorePkg

I know that's all still in development but I would like to post the result, since the I2C Kext is the only one which leads to a kernel panic with OC. The kernel panic always occurs only by reboot oder shutdown of the laptop.
Maybe someone would like to look at the bug report and have any idea why this kernel panic happens.

Here are some more information:

GPIO is not possible with my Zenbook UX330UAK. Asus BIOS is buggy und CPU frequency is going up du max level with GPIO.
Therefore, for my ASUS only polling is possible.

VoodooI2C + VoodooI2CHID not injected > Laptop works perfect.

Only VoodooI2C is installed > Laptop works perfect.

VoodooI2C + VoodooI2CHID are installed to /L/E > Not possible with OC since the SIP is fully activated. Must be deactivated by boot in the recovery mode and I did not want to do that .

Kernelpanik also happen with the official version from mojave 10.14.4.

debug_30391.zip

[stevezhengshiqi]

Exactly the same problem here.

[vit9696]

Hello,

Fritz asked me to do a brief check on this, and here is the details I can provide. The kernel panic happens due to a use-after-free in IOHIDEventService in IOHIDFamily:

void IOHIDEventService::close(IOService *forClient, IOOptionBits options)
{
    _commandGate->runAction(OSMemberFunctionCast(IOCommandGate::Action, this, &IOHIDEventService::closeGated), forClient, &options);
}

_commandGate is a macro pointing to _reserved→commandGate, and given the kernel panic _reserved was actually freed. The only method that does this is IOHIDEventService::free().

I am not sure how exactly this can happen, but it seems to be a race condition during driver unloading in either IOHIDFamily itself, or perhaps VoodooI2CHID. While it is strange that it reproduces reliably with our kext injector, we checked the code on our side, and OpenCore itself cannot be any relevant: the bug must have existed long before, and it just became more visible.

If I were to theorise, the reason for Clover's implementation to more frequently win the race condition may be due to booter-based kext injection and additional patches disabling debug data jettison. For Clover the latter is a necessity that prevents XNU memory corruption at the cost of slightly slower operation. Either way regardless of the cause itself the fix can only land in kernelspace. Perhaps some retain() or lock is missing somewhere.

Hope this helps,
Vit

[alexandred]

@vit9696 Thank you for the detailed analysis of the situation. I have not had the time to fully investigate the issue inside VoodooI2CHID myself but I will find some free time at some point in the near future (hopefully in time for the full release of OpenCore).

[gongzhenjeef]

Interestingly, this issue seems to have disappeared in 10.15 and VoodooI2C runs flawlessly. Maybe Apple made some modification to the driver for features like iPad input integration. Hopefully pen pressure might be back with iPad Pen support? ;)

[kprinssu]

Interestingly, this issue seems to have disappeared in 10.15 and VoodooI2C runs flawlessly. Maybe Apple made some modification to the driver for features like iPad input integration. Hopefully pen pressure might be back with iPad Pen support? ;)

As @vit9696 mentioned it's a race condition, something in deallocation routine changed in Catalina. The issue is still present and needs to be addressed.

Edit:

This seems to be a use-after free. I added a retain on the work loop but this does not fix the issue to the VoodooI2CMultitouchHIDEventDriver, it kernel panics when VoodooI2CHIDDevice is loaded. I am still investigating the root cause of the panic.

[kprinssu]

I believe that I fixed the issue with https://github.com/kprinssu/VoodooI2CHID/commit/4ef0ac5cf6c52f7e89c6cae28cc22e60ccd2aef0.

The issue was indeed a race condition and my fix was to retain the opened IOService clients and wait until all of them to close to then release them. With the above fix, I no longer have a kernel panic with OpenCore.

I would like to validate the fix with more devices.

[gongzhenjeef]

I believe that I fixed the issue with kprinssu/VoodooI2CHID@4ef0ac5.

The issue was indeed a race condition and my fix was to retain the opened IOService clients and wait until all of them to close to then release them. With the above fix, I no longer have a kernel panic with OpenCore.

I would like to validate the fix with more devices.

I just compiled and tested it on Mojave. Current released binary lead to panic while loading from OpenCore and your commit fixes.

I will later try it on Catalina and see if it will also fix the random loading failure there. (Not sure if it suffered from the same race condition and haven't opened this issue for the preview build)

[kprinssu]

@gongzhenjeef Can you attach a copy of the panic log and compiled kexts?

Edit: I may have misread your comment. Do you mean that my commit fixes the kernel panic on shutdown?

[gongzhenjeef]

@gongzhenjeef Can you attach a copy of the panic log and compiled kexts?

Edit: I may have misread your comment. Do you mean that my commit fixes the kernel panic on shutdown?

I'm sorry for the confusion. Your commit fixes that panic on shutdown.

I just tried it several times on Catalina and both new and old kext have the same issue. Only the VoodooI2CHID.kext won't load the first time I switched to it (I installed Catalina on another drive) and IOReg shows VoodooI2C attached successfully. Then VoodooI2CHID.kext will load after a reboot.

I'm not sure if they result from the same issue. But it's a preview build and document seems not ready.

[kprinssu]

Good to hear that my commit fixes the issue. In regards to the kext not loading, I am not sure what maybe cause it.

[Sniki]

@kprinssu can you upload prebuilt release kexts with all your recent commits on the Pull Request #195
and the latest commits on VoodooI2CELAN

For some reasons i still can't manage to successfully build this kext and satellites from Xcode.

[kprinssu]

@Snikii Please contact me on https://gitter.im/alexandred/VoodooI2CDev . I suspect that it is probably one of the build phases, but I'd like to take it to Gitter to prevent cluttering up this Github issue.

I'd also like to avoid uploading an "unofficial" version of the kext (to prevent confusion and I do not want to provide support on non-official versions of VoodooI2C).

[onemanosx]

Good to hear that my commit fixes the issue.

Thank you for the panic fix in OC!

[ben9923]

Can we close this issue, as the v2.3 release includes @kprinssu 's changes?