Changes in Makefile

5fee3609 - fscrypt: add inline encryption support

Thu, 02 Jul 2020 01:56:05 +0000

fscrypt: add inline encryption supportAdd support for inline encryption to fs/crypto/. With "inlineencryption", the block layer handles the decryption/encryption as partof the bio, instead of the filesystem doing the crypto itself viaLinux's crypto API. This model is needed in order to take advantage ofthe inline encryption hardware present on most modern mobile SoCs.To use inline encryption, the filesystem needs to be mounted with'-o inlinecrypt'. Blk-crypto will then be used instead of the traditionalfilesystem-layer crypto whenever possible to encrypt the contentsof any encrypted files in that filesystem. Fscrypt still provides the keyand IV to use, and the actual ciphertext on-disk is still the same;therefore it's testable using the existing fscrypt ciphertext verificationtests.Note that since blk-crypto has a fallback to Linux's crypto API, andalso supports all the encryption modes currently supported by fscrypt,this feature is usable and testable even without actual inlineencryption hardware.Per-filesystem changes will be needed to set encryption contexts whensubmitting bios and to implement the 'inlinecrypt' mount option. Thispatch just adds the common code.Signed-off-by: Satya Tangirala Reviewed-by: Jaegeuk Kim Reviewed-by: Eric Biggers Reviewed-by: Theodore Ts'o Link: https://lore.kernel.org/r/20200702015607.1215430-3-satyat@google.comCo-developed-by: Eric Biggers Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Makefile

c1144c9b - fscrypt: add an HKDF-SHA512 implementation

Mon, 05 Aug 2019 02:35:47 +0000

fscrypt: add an HKDF-SHA512 implementationAdd an implementation of HKDF (RFC 5869) to fscrypt, for the purpose ofderiving additional key material from the fscrypt master keys for v2encryption policies. HKDF is a key derivation function built on top ofHMAC. We choose SHA-512 for the underlying unkeyed hash, and use an"hmac(sha512)" transform allocated from the crypto API.We'll be using this to replace the AES-ECB based KDF currently used toderive the per-file encryption keys. While the AES-ECB based KDF isbelieved to meet the original security requirements, it is nonstandardand has problems that don't exist in modern KDFs such as HKDF:1. It's reversible. Given a derived key and nonce, an attacker can easily compute the master key. This is okay if the master key and derived keys are equally hard to compromise, but now we'd like to be more robust against threats such as a derived key being compromised through a timing attack, or a derived key for an in-use file being compromised after the master key has already been removed.2. It doesn't evenly distribute the entropy from the master key; each 16 input bytes only affects the corresponding 16 output bytes.3. It isn't easily extensible to deriving other values or keys, such as a public hash for securely identifying the key, or per-mode keys. Per-mode keys will be immediately useful for Adiantum encryption, for which fscrypt currently uses the master key directly, introducing unnecessary usage constraints. Per-mode keys will also be useful for hardware inline encryption, which is currently being worked on.HKDF solves all the above problems.Reviewed-by: Paul Crowley Reviewed-by: Theodore Ts'o Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Makefile

22d94f49 - fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl

Mon, 05 Aug 2019 02:35:46 +0000

fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctlAdd a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds anencryption key to the filesystem's fscrypt keyring ->s_master_keys,making any files encrypted with that key appear "unlocked".Why we need this~~~~~~~~~~~~~~~~The main problem is that the "locked/unlocked" (ciphertext/plaintext)status of encrypted files is global, but the fscrypt keys are not.fscrypt only looks for keys in the keyring(s) the process accessing thefilesystem is subscribed to: the thread keyring, process keyring, andsession keyring, where the session keyring may contain the user keyring.Therefore, userspace has to put fscrypt keys in the keyrings forindividual users or sessions. But this means that when a process with adifferent keyring tries to access encrypted files, whether they appear"unlocked" or not is nondeterministic. This is because it depends onwhether the files are currently present in the inode cache.Fixing this by consistently providing each process its own view of thefilesystem depending on whether it has the key or not isn't feasible dueto how the VFS caches work. Furthermore, while sometimes users expectthis behavior, it is misguided for two reasons. First, it would be anOS-level access control mechanism largely redundant with existing accesscontrol mechanisms such as UNIX file permissions, ACLs, LSMs, etc.Encryption is actually for protecting the data at rest.Second, almost all users of fscrypt actually do need the keys to beglobal. The largest users of fscrypt, Android and Chromium OS, achievethis by having PID 1 create a "session keyring" that is inherited byevery process. This works, but it isn't scalable because it preventssession keyrings from being used for any other purpose.On general-purpose Linux distros, the 'fscrypt' userspace tool [1] can'tsimilarly abuse the session keyring, so to make 'sudo' work on allsystems it has to link all the user keyrings into root's user keyring[2]. This is ugly and raises security concerns. Moreover it can't makethe keys available to system services, such as sshd trying to access theuser's '~/.ssh' directory (see [3], [4]) or NetworkManager trying toread certificates from the user's home directory (see [5]); or to Dockercontainers (see [6], [7]).By having an API to add a key to the *filesystem* we'll be able to fixthe above bugs, remove userspace workarounds, and clearly express theintended semantics: the locked/unlocked status of an encrypted directoryis global, and encryption is orthogonal to OS-level access control.Why not use the add_key() syscall~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~We use an ioctl for this API rather than the existing add_key() systemcall because the ioctl gives us the flexibility needed to implementfscrypt-specific semantics that will be introduced in later patches:- Supporting key removal with the semantics such that the secret is removed immediately and any unused inodes using the key are evicted; also, the eviction of any in-use inodes can be retried.- Calculating a key-dependent cryptographic identifier and returning it to userspace.- Allowing keys to be added and removed by non-root users, but only keys for v2 encryption policies; and to prevent denial-of-service attacks, users can only remove keys they themselves have added, and a key is only really removed after all users who added it have removed it.Trying to shoehorn these semantics into the keyrings syscalls would bevery difficult, whereas the ioctls make things much easier.However, to reuse code the implementation still uses the keyringsservice internally. Thus we get lockless RCU-mode key lookups withouthaving to re-implement it, and the keys automatically show up in/proc/keys for debugging purposes.References: [1] https://github.com/google/fscrypt [2] https://goo.gl/55cCrI#heading=h.vf09isp98isb [3] https://github.com/google/fscrypt/issues/111#issuecomment-444347939 [4] https://github.com/google/fscrypt/issues/116 [5] https://bugs.launchpad.net/ubuntu/+source/fscrypt/+bug/1770715 [6] https://github.com/google/fscrypt/issues/128 [7] https://askubuntu.com/questions/1130306/cannot-run-docker-on-an-encrypted-filesystemReviewed-by: Theodore Ts'o Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Makefile

feed8258 - fscrypt: rename keyinfo.c to keysetup.c

Mon, 05 Aug 2019 02:35:45 +0000

fscrypt: rename keyinfo.c to keysetup.cRename keyinfo.c to keysetup.c since this better describes what the filedoes (sets up the key), and it matches the new file keysetup_v1.c.Reviewed-by: Theodore Ts'o Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Makefile

0109ce76 - fscrypt: move v1 policy key setup to keysetup_v1.c

Mon, 05 Aug 2019 02:35:45 +0000

fscrypt: move v1 policy key setup to keysetup_v1.cIn preparation for introducing v2 encryption policies which will findand derive encryption keys differently from the current v1 encryptionpolicies, move the v1 policy-specific key setup code from keyinfo.c intokeysetup_v1.c.Reviewed-by: Theodore Ts'o Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Makefile

ec8f24b7 - treewide: Add SPDX license identifier - Makefile/Kconfig

Sun, 19 May 2019 12:07:45 +0000

treewide: Add SPDX license identifier - Makefile/KconfigAdd SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any formThese files fall under the project license, GPL v2 only. The resulting SPDXlicense identifier is: GPL-2.0-onlySigned-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/fs/crypto/Makefile

efcc7ae2 - fscrypt: new helper function - fscrypt_file_open()

Mon, 09 Oct 2017 19:15:40 +0000

fscrypt: new helper function - fscrypt_file_open()Add a helper function which prepares to open a regular file which may beencrypted. It handles setting up the file's encryption key, thenchecking that the file's encryption policy matches that of its parentdirectory (if the parent directory is encrypted). It may be set as the->open() method or it can be called from another ->open() method.Acked-by: Dave Chinner Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o List of files: /linux-6.15/fs/crypto/Makefile

58ae7468 - fscrypt: factor out bio specific functions

Mon, 19 Dec 2016 11:25:32 +0000

fscrypt: factor out bio specific functionsThat way we can get rid of the direct dependency on CONFIG_BLOCK.Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")Reported-by: Arnd Bergmann Reported-by: Randy Dunlap Reviewed-by: Eric Biggers Reviewed-by: Christoph Hellwig Reviewed-by: David Gstir Signed-off-by: Richard Weinberger Signed-off-by: Theodore Ts'o List of files: /linux-6.15/fs/crypto/Makefile

0b81d077 - fs crypto: move per-file encryption from f2fs tree to fs/crypto

Fri, 15 May 2015 23:26:10 +0000

fs crypto: move per-file encryption from f2fs tree to fs/cryptoThis patch adds the renamed functions moved from the f2fs crypto files.1. definitions for per-file encryption used by ext4 and f2fs.2. crypto.c for encrypt/decrypt functions a. IO preparation: - fscrypt_get_ctx / fscrypt_release_ctx b. before IOs: - fscrypt_encrypt_page - fscrypt_decrypt_page - fscrypt_zeroout_range c. after IOs: - fscrypt_decrypt_bio_pages - fscrypt_pullback_bio_page - fscrypt_restore_control_page3. policy.c supporting context management. a. For ioctls: - fscrypt_process_policy - fscrypt_get_policy b. For context permission - fscrypt_has_permitted_context - fscrypt_inherit_context4. keyinfo.c to handle permissions - fscrypt_get_encryption_info - fscrypt_free_encryption_info5. fname.c to support filename encryption a. general wrapper functions - fscrypt_fname_disk_to_usr - fscrypt_fname_usr_to_disk - fscrypt_setup_filename - fscrypt_free_filename b. specific filename handling functions - fscrypt_fname_alloc_buffer - fscrypt_fname_free_buffer6. Makefile and KconfigCc: Al Viro Signed-off-by: Michael Halcrow Signed-off-by: Ildar Muslukhov Signed-off-by: Uday Savagaonkar Signed-off-by: Theodore Ts'o Signed-off-by: Arnd Bergmann Signed-off-by: Jaegeuk Kim List of files: /linux-6.15/fs/crypto/Makefile