[ofw] RE: [PATCH] NDProvider: Use private heap for memory allocations

[Fab Tillier]

>> The kernel driver is what secures the memory.  If you want to be able
>> to use the SecureMemoryCacheCallback functionality provided by the OS,
>> you must abide by the rules for the callback: you can't touch the heap
>> for which memory is being freed.  If you don't want to play by those OS
>> rules, you can't cache memory registrations.
>
> I'm not sure I understand this correctly.  The problem is that the
> library doing the caching is trying to deregister the memory from within
> the callback, correct?

Correct.

> Would moving the deregister to a different thread solve the problem?

No, you'd have to block the callback thread since it expect the memory to be unsecured by the time it returns, and then the other thread would deadlock on the heap since the heap lock is held by the callback thread (taken at a higher level, before the low level memory deallocation call is made that invokes the callback).

I won't claim that the implementation is easy to use.  Given the low percentage of systems with drivers that make use of this functionality however, the extra burden on those drivers was preferable over making significant changes to memory management.

If you can avoid creating a user-mode structure for the MR (like only using the KEY_PAIR or whatever the structure is called in WinVerbs), you avoid this issue altogether (since the KEY_PAIR is allocated and owned by the caller.)  There are no issues with making an IOCTL call and having the kernel driver free memory, this is only in the user-mode heap management (and malloc/free use the default process heap.)

-Fab