David Howells <dhowells@xxxxxxxxxx> writes:
> Dmitry Monakhov <dmonakhov@xxxxxxxxxx> 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:
signature.asc
Description: PGP signature
