> On Jun 18, 2019, at 9:22 AM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 6/18/19 9:15 AM, Kirill A. Shutemov wrote: >>> 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. >> I see a problem with the scheme: if we don't have a way to decide if the >> key is right for the file, user without access to the right key is able to >> prevent legitimate user from accessing the file. Attacker just need read >> access to the encrypted file to prevent any legitimate use to access it. > > I think you're bringing up a separate issue. > > We were talking about how you resolve a conflict when someone attempts > to use two *different* keyids to decrypt the data in the API and what > the resulting API interaction looks like. > > You're describing the situation where one of those is the wrong *key* > (not keyid). That's a subtly different scenario and requires different > handling (or no handling IMNHO). I think we’re quibbling over details before we look at the big questions: Should MKTME+DAX encrypt the entire volume or should it encrypt individual files? Or both? If it encrypts individual files, should the fs be involved at all? Should there be metadata that can check whether a given key is the correct key? If it encrypts individual files, is it even conceptually possible to avoid corruption if the fs is not involved? After all, many filesystems think that they can move data blocks, compute checksums, journal data, etc. I think Dave is right that there should at least be a somewhat credible proposal for how this could fit together.
