Re: [RFC]: mm,power: introduce MADV_WIPEONSUSPEND

[Alexander Graf <graf@amazon.com>]

On 04.07.20 13:48, Pavel Machek wrote:
> Hi!
> 
>>>> Cryptographic libraries carry pseudo random number generators to
>>>> quickly provide randomness when needed. If such a random pool gets
>>>> cloned, secrets may get revealed, as the same random number may get
>>>> used multiple times. For fork, this was fixed using the WIPEONFORK
>>>> madvise flag [1].
>>>
>>>> Unfortunately, the same problem surfaces when a virtual machine gets
>>>> cloned. The existing flag does not help there. This patch introduces a
>>>> new flag to automatically clear memory contents on VM suspend/resume,
>>>> which will allow random number generators to reseed when virtual
>>>> machines get cloned.
>>>
>>> Umm. If this is real problem, should kernel provide such rng in the
>>> vsdo page using vsyscalls? Kernel can have special interface to its
>>> vsyscalls, but we may not want to offer this functionality to rest of
>>> userland...
>>
>> And then the kernel would just need to maintain a sequence
>> number in the vDSO data page that gets bumped on suspen
> 
> Yes, something like that would work. Plus, we'd be free to change the
> mechanism in future.

So if we keep treading along that train of thought, a simple vsyscall 
that returns an epoch (incremented by every [VM] resume) would be good 
enough, as user space could in its own logic determine whether it's 
still living inside the same epoch.

The beauty of the clearing is that the checks on it are almost free and 
that we can avoid to store secrets on disk in the first place.

The latter I think is impossible to model with the epoch, but that might 
be ok.

Performance wise, I don't think we can make the vsyscall as cheap as a 
memory compare. Keep in mind that we need to check for the epoch in a 
pretty hot path. How bad would it really be? I'm not sure. It might be 
good enough.

My main concern however is around fragmentation of mechanisms. We 
already have the WIPEONFORK semantic in place in user space 
applications. Do we really want to introduce yet another check for 
what's almost the same semantic? With WIPEONSUSPEND, the hot path check 
between fork and suspend are identical. With an epoch, we have to check 
for zeros and the epoch in addition.

Unless we create a vsyscall that returns both the PID as well as the 
epoch and thus handles fork *and* suspend. I need to think about this a 
bit more :).


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879