From: Eric Biggers <ebiggers@google.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Linux Filesystem Development List <linux-fsdevel@vger.kernel.org>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
jaegeuk@kernel.org, Michael Halcrow <mhalcrow@google.com>
Subject: Re: [PATCH 4/4] fscrypt: move the policy flags and encryption mode definitions to uapi header
Date: Tue, 29 Nov 2016 13:30:33 -0800 [thread overview]
Message-ID: <20161129213033.GD52769@google.com> (raw)
In-Reply-To: <20161127044155.23022-4-tytso@mit.edu>
On Sat, Nov 26, 2016 at 11:41:55PM -0500, Theodore Ts'o wrote:
> These constants are part of the UAPI, so they belong in
> include/uapi/linux/fs.h instead of include/linux/fscrypto.h
>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
> include/linux/fscrypto.h | 14 --------------
> include/uapi/linux/fs.h | 14 ++++++++++++++
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
This looks fine to me. I had wanted to do this a while back, but there was some
talk about exposing the modes under names that hide the specific algorithms,
like "CRYPT_SW_V1", with the assumption being that users shouldn't have to know
about any specific modes but rather simply choose the modes with the highest
version numbers, which would also be the most secure. But I wasn't really
convinced by that argument because people might add or use specific modes for
reasons other than security, such as hardware support on a certain platform.
And I think a better solution to the "use the most secure mode the kernel knows
about" problem would be to implement a special mode like
FS_ENCRYPTION_MODE_MOST_SECURE which the kernel would translate into its
preferred mode when setting an encryption policy.
Mike, do you have a different opinion?
I should also mention that the UAPI header is also missing struct fscrypt_key
and its the definitions FS_MAX_KEY_SIZE, FS_KEY_DESC_PREFIX, and
FS_KEY_DESC_PREFIX_SIZE. I think those should be moved to the UAPI header too,
though that can be a separate patch.
Reviewed-by: Eric Biggers <ebiggers@google.com>
Eric
next prev parent reply other threads:[~2016-11-29 21:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-27 4:41 [PATCH 1/4] fscrypt: rename get_crypt_info() to fscrypt_get_crypt_info() Theodore Ts'o
2016-11-27 4:41 ` [PATCH 2/4] fscrypt: unexport fscrypt_initialize() Theodore Ts'o
2016-11-29 21:01 ` Eric Biggers
2016-11-27 4:41 ` [PATCH 3/4] fscrypt: move non-public structures and constants to fscrypt_private.h Theodore Ts'o
2016-11-27 4:41 ` Theodore Ts'o
2016-11-29 21:06 ` Eric Biggers
2016-11-27 4:41 ` [PATCH 4/4] fscrypt: move the policy flags and encryption mode definitions to uapi header Theodore Ts'o
2016-11-29 21:30 ` Eric Biggers [this message]
2016-11-29 21:00 ` [PATCH 1/4] fscrypt: rename get_crypt_info() to fscrypt_get_crypt_info() Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161129213033.GD52769@google.com \
--to=ebiggers@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mhalcrow@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.