lkml.org 
[lkml]   [2019]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME
    From
    Date
    On 6/18/19 9:36 AM, Andy Lutomirski wrote:
    > Should MKTME+DAX encrypt the entire volume or should it encrypt individual files? Or both?

    Our current thought is that there should be two modes: One for entire
    DAX namespaces and one for filesystem DAX that would allow it to be at
    the file level. More likely, we would mirror fscrypt and do it at the
    directory level.

    > 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?
    FWIW, this is a question for the fs guys. Their guidance so far has
    been "do what fscrypt does", and fscrypt does not protect against
    incorrect keys being specified. See:

    https://www.kernel.org/doc/html/v5.1/filesystems/fscrypt.html

    Which says:

    > Currently, fscrypt does not prevent a user from maliciously providing
    > an incorrect key for another user’s existing encrypted files. A
    > protection against this is planned.

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

    Yes, exactly. Thankfully, fscrypt has thought about this already and
    has infrastructure for this. For instance:

    > Online defragmentation of encrypted files is not supported. The
    > EXT4_IOC_MOVE_EXT and F2FS_IOC_MOVE_RANGE ioctls will fail with
    > EOPNOTSUPP.

    \
     
     \ /
      Last update: 2019-06-18 18:49    [W:4.107 / U:0.340 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site