keyctl {clear,revoke} serialization with key-users

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).

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

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.

Quoted 3 lines · Dmitry Monakhov

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.

Quoted 9 lines

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.

Quoted 21 lines

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.

Quoted 1 line

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.

It might not be entirely practical though and might be better off done from a separate work item.

David