1

There doesn't appear to be synchronization between establishing/removing callbacks (e.g. kauth_unlisten_scope) and the callbacks themselves (in the xnu codebase, yes, I know, it's dated). This puts the burden of tracking/draining callbacks and synchronizing with calls on the extension itself. But this is problematic as well in that there is a window in noting that a thread has exited the callback AND actually returning out of the extension code.

Is there any pattern that gives a correct avoidance of this race? Or, is there any documentation from Apple that indicates they've synchronized this correctly?

MJZ
  • 1,074
  • 6
  • 12

1 Answers1

1

As far as I'm aware there's no 100% reliable way of preventing kauth callback deregistration race conditions; the API is just badly designed. Apple themselves implement/recommend a simple atomic counter based mechanism, which you can see in the Kauth-O-Rama example. Search for gActivationCount in the KauthORama.c source file. There's still a small chance that a thread is running code before the increment or after the decrement in the callback, but I have never seen a crash caused by this.

pmdj
  • 22,018
  • 3
  • 52
  • 103
  • Thank you! I'm aware of the kauth-o-rama example, but adding in that one-second-delay that still has a race bugs me. In my experience "you never saw it" means my customers will hit it on day zero. Murphy Gone Wild. – MJZ Jun 29 '16 at 16:17
  • Yeah, it bugs me too, but if you look at the example, the comment in there basically admits you can't do it cleanly given the existing API, and it's just broken. You can file a radar. I guess the question is also how often you're planning to unload the kext in production. If it happens all the time, then yeah, people might hit it. In practice, it's usually pretty rare to unload a kext like that. – pmdj Jun 29 '16 at 19:12
  • Yes, it is rare, but I'm of the "if it can happen, then I should fix it", persuasion... – MJZ Jul 04 '16 at 15:28
  • Let us know if you do find a way. I wouldn't lose sleep over it though - quoting the Apple engineer who wrote the Kauth-O-Rama example: `"[…] However, there's no way to close this race because of the weak concurrency guarantee for kauth_unlisten_scope."`. If anything, file a radar for it. – pmdj Jul 07 '16 at 11:47