|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5 |
|
| #
9b4bb822 |
| 25-Oct-2024 |
Matthew Wilcox (Oracle) <[email protected]> |
ecryptfs: Pass the folio index to crypt_extent()
We need to pass pages, not folios, to crypt_extent() as we may be working with a plain page rather than a folio. But we need to know the index in th
ecryptfs: Pass the folio index to crypt_extent()
We need to pass pages, not folios, to crypt_extent() as we may be working with a plain page rather than a folio. But we need to know the index in the file, so pass it in from the caller.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
| #
bf64913d |
| 25-Oct-2024 |
Matthew Wilcox (Oracle) <[email protected]> |
ecryptfs: Convert lower_offset_for_page() to take a folio
Both callers have a folio, so pass it in and use folio->index instead of page->index.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infrade
ecryptfs: Convert lower_offset_for_page() to take a folio
Both callers have a folio, so pass it in and use folio->index instead of page->index.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
| #
c15b8146 |
| 25-Oct-2024 |
Matthew Wilcox (Oracle) <[email protected]> |
ecryptfs: Convert ecryptfs_decrypt_page() to take a folio
Both callers have a folio, so pass it in and use it throughout.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://
ecryptfs: Convert ecryptfs_decrypt_page() to take a folio
Both callers have a folio, so pass it in and use it throughout.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
| #
6b9c0e81 |
| 25-Oct-2024 |
Matthew Wilcox (Oracle) <[email protected]> |
ecryptfs: Convert ecryptfs_encrypt_page() to take a folio
All three callers have a folio, so pass it in and use it throughout.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: htt
ecryptfs: Convert ecryptfs_encrypt_page() to take a folio
All three callers have a folio, so pass it in and use it throughout.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.12-rc4, v6.12-rc3, v6.12-rc2 |
|
| #
5f60d5f6 |
| 01-Oct-2024 |
Al Viro <[email protected]> |
move asm/unaligned.h to linux/unaligned.h
asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-
move asm/unaligned.h to linux/unaligned.h
asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
show more ...
|
|
Revision tags: v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1 |
|
| #
f700b719 |
| 21-Mar-2024 |
Justin Stitt <[email protected]> |
fs: ecryptfs: replace deprecated strncpy with strscpy
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string int
fs: ecryptfs: replace deprecated strncpy with strscpy
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. A good alternative is strscpy() as it guarantees NUL-termination on the destination buffer.
In crypto.c: We expect cipher_name to be NUL-terminated based on its use with the C-string format specifier %s and with other string apis like strlen(): | printk(KERN_ERR "Error attempting to initialize key TFM " | "cipher with name = [%s]; rc = [%d]\n", | tmp_tfm->cipher_name, rc); and | int cipher_name_len = strlen(cipher_name);
In main.c: We can remove the manual NUL-byte assignments as well as the pointers to destinations (which I assume only existed to trim down on line length?) in favor of directly using the destination buffer which allows the compiler to get size information -- enabling the usage of the new 2-argument strscpy().
Note that this patch relies on the _new_ 2-argument versions of strscpy() and strscpy_pad() introduced in Commit e6584c3964f2f ("string: Allow 2-argument strscpy()").
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: <[email protected]> Signed-off-by: Justin Stitt <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/20240321-strncpy-fs-ecryptfs-crypto-c-v1-1-d78b74c214ac@google.com Signed-off-by: Kees Cook <[email protected]>
show more ...
|
|
Revision tags: v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8 |
|
| #
42c3732f |
| 31-Dec-2023 |
Chuck Lever <[email protected]> |
fs: Create a generic is_dot_dotdot() utility
De-duplicate the same functionality in several places by hoisting the is_dot_dotdot() utility function into linux/fs.h.
Suggested-by: Amir Goldstein <am
fs: Create a generic is_dot_dotdot() utility
De-duplicate the same functionality in several places by hoisting the is_dot_dotdot() utility function into linux/fs.h.
Suggested-by: Amir Goldstein <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Reviewed-by: Amir Goldstein <[email protected]> Acked-by: Christian Brauner <[email protected]> Signed-off-by: Chuck Lever <[email protected]>
show more ...
|
|
Revision tags: v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1 |
|
| #
8b70deb8 |
| 26-Apr-2023 |
Fabio M. De Francesco <[email protected]> |
fs/ecryptfs: Replace kmap() with kmap_local_page()
kmap() has been deprecated in favor of kmap_local_page().
Therefore, replace kmap() with kmap_local_page() in fs/ecryptfs.
There are two main pro
fs/ecryptfs: Replace kmap() with kmap_local_page()
kmap() has been deprecated in favor of kmap_local_page().
Therefore, replace kmap() with kmap_local_page() in fs/ecryptfs.
There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. The tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid.
Obviously, thread locality implies that the kernel virtual addresses returned by kmap_local_page() are only valid in the context of the callers (i.e., they cannot be handed to other threads).
The use of kmap_local_page() in fs/ecryptfs does not break the above-mentioned assumption, so it is allowed and preferred.
Tested in a QEMU/KVM x86_32 VM, 6GB RAM, booting a kernel with HIGHMEM64GB enabled.
Suggested-by: Ira Weiny <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Signed-off-by: "Fabio M. De Francesco" <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8 |
|
| #
20066bf7 |
| 06-Feb-2023 |
Herbert Xu <[email protected]> |
fs: ecryptfs: Use crypto_wait_req
This patch replaces the custom crypto completion function with crypto_req_done.
Signed-off-by: Herbert Xu <[email protected]> Acked-by: Jarkko Sakkinen <
fs: ecryptfs: Use crypto_wait_req
This patch replaces the custom crypto completion function with crypto_req_done.
Signed-off-by: Herbert Xu <[email protected]> Acked-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
show more ...
|
|
Revision tags: v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4 |
|
| #
39f60c1c |
| 13-Jan-2023 |
Christian Brauner <[email protected]> |
fs: port xattr to mnt_idmap
Convert to struct mnt_idmap.
Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conver
fs: port xattr to mnt_idmap
Convert to struct mnt_idmap.
Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap.
Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs.
Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap.
Acked-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Christian Brauner (Microsoft) <[email protected]>
show more ...
|
|
Revision tags: v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1 |
|
| #
c6052f09 |
| 03-May-2021 |
Phillip Potter <[email protected]> |
fs: ecryptfs: remove BUG_ON from crypt_scatterlist
crypt_stat memory itself is allocated when inode is created, in ecryptfs_alloc_inode, which returns NULL on failure and is handled by callers, whic
fs: ecryptfs: remove BUG_ON from crypt_scatterlist
crypt_stat memory itself is allocated when inode is created, in ecryptfs_alloc_inode, which returns NULL on failure and is handled by callers, which would prevent us getting to this point. It then calls ecryptfs_init_crypt_stat which allocates crypt_stat->tfm checking for and likewise handling allocation failure. Finally, crypt_stat->flags has ECRYPTFS_STRUCT_INITIALIZED merged into it in ecryptfs_init_crypt_stat as well.
Simply put, the conditions that the BUG_ON checks for will never be triggered, as to even get to this function, the relevant conditions will have already been fulfilled (or the inode allocation would fail in the first place and thus no call to this function or those above it).
Cc: Tyler Hicks <[email protected]> Signed-off-by: Phillip Potter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| #
e1436df2 |
| 03-May-2021 |
Greg Kroah-Hartman <[email protected]> |
Revert "ecryptfs: replace BUG_ON with error handling code"
This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72.
Because of recent interactions with developers from @umn.edu, all commits fr
Revert "ecryptfs: replace BUG_ON with error handling code"
This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72.
Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.
Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.
The original commit log for this change was incorrect, no "error handling code" was added, things will blow up just as badly as before if any of these cases ever were true. As this BUG_ON() never fired, and most of these checks are "obviously" never going to be true, let's just revert to the original code for now until this gets unwound to be done correctly in the future.
Cc: Aditya Pakki <[email protected]> Fixes: 2c2a7552dd64 ("ecryptfs: replace BUG_ON with error handling code") Cc: stable <[email protected]> Acked-by: Tyler Hicks <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse |
|
| #
1abbe110 |
| 24-Feb-2021 |
Sascha Hauer <[email protected]> |
ecryptfs: Fix typo in message
ecryptfs_decrypt_page() issues a warning "Error encrypting extent". This should be "Error decrypting extent" instead.
Fixes: 0216f7f79217 ("eCryptfs: replace encrypt,
ecryptfs: Fix typo in message
ecryptfs_decrypt_page() issues a warning "Error encrypting extent". This should be "Error decrypting extent" instead.
Fixes: 0216f7f79217 ("eCryptfs: replace encrypt, decrypt, and inode size write") Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Tyler Hicks <[email protected]>
show more ...
|
| #
5da877ea |
| 30-Mar-2021 |
Lee Jones <[email protected]> |
ecryptfs: crypto: Supply some missing param descriptions and demote abuses
Fixes the following W=1 kernel build warning(s):
fs/ecryptfs/crypto.c:29: warning: expecting prototype for eCryptfs(). Pr
ecryptfs: crypto: Supply some missing param descriptions and demote abuses
Fixes the following W=1 kernel build warning(s):
fs/ecryptfs/crypto.c:29: warning: expecting prototype for eCryptfs(). Prototype was for DECRYPT() instead fs/ecryptfs/crypto.c:360: warning: Function parameter or member 'crypt_stat' not described in 'lower_offset_for_page' fs/ecryptfs/crypto.c:360: warning: Function parameter or member 'page' not described in 'lower_offset_for_page' fs/ecryptfs/crypto.c:637: warning: Function parameter or member 'crypt_stat' not described in 'ecryptfs_compute_root_iv' fs/ecryptfs/crypto.c:1386: warning: Function parameter or member 'ecryptfs_dentry' not described in 'ecryptfs_read_metadata' fs/ecryptfs/crypto.c:1463: warning: Function parameter or member 'filename' not described in 'ecryptfs_encrypt_filename' fs/ecryptfs/crypto.c:1463: warning: Function parameter or member 'mount_crypt_stat' not described in 'ecryptfs_encrypt_filename' fs/ecryptfs/crypto.c:1897: warning: Function parameter or member 'encoded_name_size' not described in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Function parameter or member 'mount_crypt_stat' not described in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Function parameter or member 'name_size' not described in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Excess function parameter 'crypt_stat' description in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Excess function parameter 'length' description in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:2006: warning: Function parameter or member 'sb' not described in 'ecryptfs_decode_and_decrypt_filename' fs/ecryptfs/crypto.c:2006: warning: Excess function parameter 'ecryptfs_dir_dentry' description in 'ecryptfs_decode_and_decrypt_filename'
Cc: Tyler Hicks <[email protected]> Cc: Eric Biggers <[email protected]> Cc: "Michael A. Halcrow" <[email protected]> Cc: "Michael C. Thompson" <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> [tyhicks: Fix typo in ecryptfs_encrypt_and_encode_filename() func docs] Signed-off-by: Tyler Hicks <[email protected]>
show more ...
|
|
Revision tags: v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1 |
|
| #
902af369 |
| 24-Dec-2020 |
Zheng Yongjun <[email protected]> |
ecryptfs: use DEFINE_MUTEX() for mutex lock
mutex lock can be initialized automatically with DEFINE_MUTEX() rather than explicitly calling mutex_init().
Signed-off-by: Zheng Yongjun <zhengyongjun3@
ecryptfs: use DEFINE_MUTEX() for mutex lock
mutex lock can be initialized automatically with DEFINE_MUTEX() rather than explicitly calling mutex_init().
Signed-off-by: Zheng Yongjun <[email protected]> Signed-off-by: Tyler Hicks <[email protected]>
show more ...
|
| #
c7c7a1a1 |
| 21-Jan-2021 |
Tycho Andersen <[email protected]> |
xattr: handle idmapped mounts
When interacting with extended attributes the vfs verifies that the caller is privileged over the inode with which the extended attribute is associated. For posix acces
xattr: handle idmapped mounts
When interacting with extended attributes the vfs verifies that the caller is privileged over the inode with which the extended attribute is associated. For posix access and posix default extended attributes a uid or gid can be stored on-disk. Let the functions handle posix extended attributes on idmapped mounts. If the inode is accessed through an idmapped mount we need to map it according to the mount's user namespace. Afterwards the checks are identical to non-idmapped mounts. This has no effect for e.g. security xattrs since they don't store uids or gids and don't perform permission checks on them like posix acls do.
Link: https://lore.kernel.org/r/[email protected] Cc: Christoph Hellwig <[email protected]> Cc: David Howells <[email protected]> Cc: Al Viro <[email protected]> Cc: [email protected] Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: James Morris <[email protected]> Signed-off-by: Tycho Andersen <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4 |
|
| #
19798113 |
| 02-May-2020 |
Eric Biggers <[email protected]> |
ecryptfs: use crypto_shash_tfm_digest()
Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_
ecryptfs: use crypto_shash_tfm_digest()
Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us.
Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
show more ...
|
|
Revision tags: v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2 |
|
| #
2c2a7552 |
| 14-Feb-2020 |
Aditya Pakki <[email protected]> |
ecryptfs: replace BUG_ON with error handling code
In crypt_scatterlist, if the crypt_stat argument is not set up correctly, the kernel crashes. Instead, by returning an error code upstream, the erro
ecryptfs: replace BUG_ON with error handling code
In crypt_scatterlist, if the crypt_stat argument is not set up correctly, the kernel crashes. Instead, by returning an error code upstream, the error is handled safely.
The issue is detected via a static analysis tool written by us.
Fixes: 237fead619984 (ecryptfs: fs/Makefile and fs/Kconfig) Signed-off-by: Aditya Pakki <[email protected]> Signed-off-by: Tyler Hicks <[email protected]>
show more ...
|
|
Revision tags: v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1 |
|
| #
9ac0d136 |
| 29-Nov-2019 |
Eric Biggers <[email protected]> |
crypto: skcipher - remove crypto_skcipher::keysize
Due to the removal of the blkcipher and ablkcipher algorithm types, crypto_skcipher::keysize is now redundant since it always equals crypto_skciphe
crypto: skcipher - remove crypto_skcipher::keysize
Due to the removal of the blkcipher and ablkcipher algorithm types, crypto_skcipher::keysize is now redundant since it always equals crypto_skcipher_alg(tfm)->max_keysize.
Remove it and update crypto_skcipher_default_keysize() accordingly.
Also rename crypto_skcipher_default_keysize() to crypto_skcipher_max_keysize() to clarify that it specifically returns the maximum key size, not some unspecified "default".
Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
show more ...
|
|
Revision tags: v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2 |
|
| #
7451c54a |
| 02-Jul-2019 |
Hariprasad Kelam <[email protected]> |
ecryptfs: Change return type of ecryptfs_process_flags
Change return type of ecryptfs_process_flags from int to void as it never fails.
fixes below issue reported by coccicheck
s/ecryptfs/crypto.c
ecryptfs: Change return type of ecryptfs_process_flags
Change return type of ecryptfs_process_flags from int to void as it never fails.
fixes below issue reported by coccicheck
s/ecryptfs/crypto.c:870:5-7: Unneeded variable: "rc". Return "0" on line 883
Signed-off-by: Hariprasad Kelam <[email protected]> [tyhicks: Remove the return value line from the function documentation] Signed-off-by: Tyler Hicks <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3 |
|
| #
1a59d1b8 |
| 27-May-2019 |
Thomas Gleixner <[email protected]> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1334 file(s).
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Allison Randal <[email protected]> Reviewed-by: Richard Fontana <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6 |
|
| #
877b5691 |
| 15-Apr-2019 |
Eric Biggers <[email protected]> |
crypto: shash - remove shash_desc::flags
The flags field in 'struct shash_desc' never actually does anything. The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP. However, no shash algori
crypto: shash - remove shash_desc::flags
The flags field in 'struct shash_desc' never actually does anything. The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP. However, no shash algorithm ever sleeps, making this flag a no-op.
With this being the case, inevitably some users who can't sleep wrongly pass MAY_SLEEP. These would all need to be fixed if any shash algorithm actually started sleeping. For example, the shash_ahash_*() functions, which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP from the ahash API to the shash API. However, the shash functions are called under kmap_atomic(), so actually they're assumed to never sleep.
Even if it turns out that some users do need preemption points while hashing large buffers, we could easily provide a helper function crypto_shash_update_large() which divides the data into smaller chunks and calls crypto_shash_update() and cond_resched() for each chunk. It's not necessary to have a flag in 'struct shash_desc', nor is it necessary to make individual shash algorithms aware of this at all.
Therefore, remove shash_desc::flags, and document that the crypto_shash_*() functions can be called from any context.
Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
show more ...
|
|
Revision tags: v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1, v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1 |
|
| #
d43388de |
| 21-Aug-2018 |
Robbie Ko <[email protected]> |
eCryptfs: fix permission denied with ecryptfs_xattr mount option when create readonly file
When the ecryptfs_xattr mount option is turned on, the ecryptfs metadata will be written to xattr via vfs_s
eCryptfs: fix permission denied with ecryptfs_xattr mount option when create readonly file
When the ecryptfs_xattr mount option is turned on, the ecryptfs metadata will be written to xattr via vfs_setxattr, which will check the WRITE permissions.
However, this will cause denial of permission when creating a file withoug write permission.
So fix this by calling __vfs_setxattr directly to skip permission check.
Signed-off-by: Robbie Ko <[email protected]> [tyhicks: Copy up lower inode attributes when successful] Signed-off-by: Tyler Hicks <[email protected]>
show more ...
|
|
Revision tags: v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4 |
|
| #
0bdf8a82 |
| 04-Jul-2018 |
Dan Carpenter <[email protected]> |
eCryptfs: fix a couple type promotion bugs
ECRYPTFS_SIZE_AND_MARKER_BYTES is type size_t, so if "rc" is negative that gets type promoted to a high positive value and treated as success.
Fixes: 778a
eCryptfs: fix a couple type promotion bugs
ECRYPTFS_SIZE_AND_MARKER_BYTES is type size_t, so if "rc" is negative that gets type promoted to a high positive value and treated as success.
Fixes: 778aeb42a708 ("eCryptfs: Cleanup and optimize ecryptfs_lookup_interpose()") Signed-off-by: Dan Carpenter <[email protected]> [tyhicks: Use "if/else if" rather than "if/if"] Cc: [email protected] Signed-off-by: Tyler Hicks <[email protected]>
show more ...
|
| #
231baecd |
| 19-Jan-2019 |
Eric Biggers <[email protected]> |
crypto: clarify name of WEAK_KEY request flag
CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak k
crypto: clarify name of WEAK_KEY request flag
CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak keys be forbidden (for algorithms that have the notion of "weak keys"; currently only DES and XTS do).
Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which it can be easily confused. (This in fact happened in the UX500 driver, though just in some debugging messages.)
Therefore, make the intent clear by renaming it to CRYPTO_TFM_REQ_FORBID_WEAK_KEYS.
Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
show more ...
|