| Message ID | 20161127044155.23022-4-tytso@mit.edu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/fscrypto.h b/include/linux/fscrypto.h index 71e8a20711ec..42ef82d60790 100644 --- a/include/linux/fscrypto.h +++ b/include/linux/fscrypto.h @@ -18,20 +18,6 @@ #include <crypto/skcipher.h> #include <uapi/linux/fs.h> -#define FS_POLICY_FLAGS_PAD_4 0x00 -#define FS_POLICY_FLAGS_PAD_8 0x01 -#define FS_POLICY_FLAGS_PAD_16 0x02 -#define FS_POLICY_FLAGS_PAD_32 0x03 -#define FS_POLICY_FLAGS_PAD_MASK 0x03 -#define FS_POLICY_FLAGS_VALID 0x03 - -/* Encryption algorithms */ -#define FS_ENCRYPTION_MODE_INVALID 0 -#define FS_ENCRYPTION_MODE_AES_256_XTS 1 -#define FS_ENCRYPTION_MODE_AES_256_GCM 2 -#define FS_ENCRYPTION_MODE_AES_256_CBC 3 -#define FS_ENCRYPTION_MODE_AES_256_CTS 4 - #define FS_CRYPTO_BLOCK_SIZE 16 struct fscrypt_info; diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index acb2b6152ba0..0496d37abe28 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -254,6 +254,20 @@ struct fsxattr { /* Policy provided via an ioctl on the topmost directory */ #define FS_KEY_DESCRIPTOR_SIZE 8 +#define FS_POLICY_FLAGS_PAD_4 0x00 +#define FS_POLICY_FLAGS_PAD_8 0x01 +#define FS_POLICY_FLAGS_PAD_16 0x02 +#define FS_POLICY_FLAGS_PAD_32 0x03 +#define FS_POLICY_FLAGS_PAD_MASK 0x03 +#define FS_POLICY_FLAGS_VALID 0x03 + +/* Encryption algorithms */ +#define FS_ENCRYPTION_MODE_INVALID 0 +#define FS_ENCRYPTION_MODE_AES_256_XTS 1 +#define FS_ENCRYPTION_MODE_AES_256_GCM 2 +#define FS_ENCRYPTION_MODE_AES_256_CBC 3 +#define FS_ENCRYPTION_MODE_AES_256_CTS 4 + struct fscrypt_policy { __u8 version; __u8 contents_encryption_mode;
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(-)