Re: [RFC] keyctl {clear,revoke} serialization with key-users

[Dmitry Monakhov <dmonakhov@openvz.org>]

[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]

David Howells <dhowells@redhat.com> writes:

> Dmitry Monakhov <dmonakhov@openvz.org> wrote:
>
>> But currently there is not synchronization between 'keyctl clear' and dirty
>> page buffers write-back, which result in data loss(because key no longer
>> available).
>
> The way fs/afs/ deals with this is to attach the key to the pending writeback
> record.  However, this would also benefit from writeback being triggered at
> key invalidation.
>
>> But currently there is not synchronization between 'keyctl clear' and dirty
>> page buffers write-back, which result in data loss(because key no longer
>> available).
>>
>> There are several ways to synchronize key-management with key-usage
>> 1) ext4 specific way via userspace
>>    add 'del_key' command to e4crypto which will do:
>>        ioctl(ext4_del_key)          # sync and invalidate all inodes which referees given key
>>        keyctl(KEYCTL_INVALIDATE,..) # wipe key from kernel
>
> I'm not keen on this because it's too easy to bypass half the process and miss
> the ioctl.
>
>> 2) Generic keyring way:
>>    Add kernel API to register event listeners for a key so any subsystem
>>    may listen for such events and performs necessary actions once it happen.
>>    For example:
>>    key = request_key(....)
>>    notify_changes_key(key, event_mask, my_callback)
>> 
>> 
>>    keyring_clear() {
>>    for_each_listener{
>>         notify_key(callback, KEY_CLEAR)
>>    }
>>    
>> First one is easy and clean also it preserves original keyring management
>> assumptions, but second one is more generic (since other fs will likely to
>> implement encryption in near future), the only visible changes of second
>> option is that callbacks must be synchronous so 'keyctl clear @s' may takes
>> long time. IMHO such implicit synchronization is good for 99% use-cases, the
>> only exception is 'emergency key clear' case where we do not care about data
>> consistency but do care about key to be wiped ASAP.
>> 
>> I would like to implement second option. Please rise your objections if any.
>
> I agree that the second is the best option.  It's something I thought about
> originally for keys that are tied to some sort of removable hardware but I
> never actually implemented.
>
> I would suggest that you consider driving the notification from the
> gc.
AFAIU it is too late to perform notifications from GS because key is
already tagged as INVALIDATED or DEAD so key_validate() will fail.

BTW: I try to find synchronous way to clear a key the one which
explicitly wait for scheduled gc work to complete. But I can not find it.
Please guide me.
>It might not be entirely practical though and might be better off done from a
> separate work item.
I'll try to implement this case.
>
> David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]