On 6/18/19 2:12 AM, Peter Zijlstra wrote: > On Tue, Jun 18, 2019 at 02:23:31PM +1200, Kai Huang wrote: >> Assuming I am understanding the context correctly, yes from this perspective it seems having >> sys_encrypt is annoying, and having ENCRYPT_ME should be better. But Dave said "nobody is going to >> do what you suggest in the ptr1/ptr2 example"? > > You have to phrase that as: 'nobody who knows what he's doing is going > to do that', which leaves lots of people and fuzzers. > > Murphy states that if it is possible, someone _will_ do it. And this > being something that causes severe data corruption on persistent > storage,... I actually think it's not a big deal at all to avoid the corruption that would occur if it were allowed. But, if you're even asking to map the same data with two different keys, you're *asking* for data corruption. What we're doing here is continuing to preserve cache coherency and ensuring an early failure. We'd need two rules: 1. A page must not be faulted into a VMA if the page's page_keyid() is not consistent with the VMA's 2. Upon changing the VMA's KeyID, all underlying PTEs must either be checked or zapped. If the rules are broken, we SIGBUS. Andy's suggestion has the same basic requirements. But, with his scheme, the error can be to the ioctl() instead of in the form of a SIGBUS. I guess that makes the fuzzers' lives a bit easier. BTW, note that we don't have any problems with the current anonymous implementation and fork() because we zap at the encryption syscall.
