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. It
might not be entirely practical though and might be better off done from a
separate work item.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
