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@xxxxxxx> > --- > 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@xxxxxxxxxx> Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
