On Tue, Feb 19, 2019 at 11:18:21PM -0800, Andreas Dilger wrote:
> On Feb 19, 2019, at 10:52 PM, Eric Biggers wrote:
> >
> > Hello,
> >
> > This patchset makes major improvements to how keys are added, removed,
> > and derived in fscrypt, aka ext4/f2fs/ubifs encryption. It does this by
> > addin
On Feb 19, 2019, at 10:52 PM, Eric Biggers wrote:
>
> Hello,
>
> This patchset makes major improvements to how keys are added, removed,
> and derived in fscrypt, aka ext4/f2fs/ubifs encryption. It does this by
> adding new ioctls that add and remove encryption keys directly to/from
> the filesy
From: Eric Biggers
In preparation for introducing v2 encryption policies which will find
and derive encryption keys differently from the current v1 encryption
policies, refactor the v1 policy-specific key setup code from keyinfo.c
into keysetup_legacy.c. Then rename keyinfo.c to keysetup.c.
Not
From: Eric Biggers
Add an ->s_master_keys keyring to 'struct super_block'. New fscrypt
ioctls will allow adding and removing encryption keys from this keyring.
This will enable solving multiple interrelated problems with how fscrypt
keys are provided and managed currently, including:
- Making t
From: Eric Biggers
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption 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/unloc
From: Eric Biggers
Prefix all filesystem encryption UAPI constants except the ioctl numbers
with "FSCRYPT_" rather than with "FS_". This namespaces the constants
more appropriately and makes it clear that they are related specifically
to the filesystem encryption feature, and to the 'fscrypt_*'
From: Eric Biggers
When a filesystem encryption key is removed, we need all files which had
been "unlocked" (had ->i_crypt_info set up) with it to appear "locked"
again. This is most easily done by evicting the inodes. This can
currently be done using 'echo 2 > /proc/sys/vm/drop_caches'; howeve
From: Eric Biggers
By looking up the master keys in a filesystem-level keyring rather than
in the calling processes' key hierarchy, it becomes possible for a user
to set an encryption policy which refers to some key they don't actually
know, then encrypt their files using that key. Cryptographic
From: Eric Biggers
Add an inode back-pointer to 'struct fscrypt_info', such that
inode->i_crypt_info->ci_inode == inode.
This will be useful for:
1. Evicting the inodes when a fscrypt key is removed, since we'll track
the inodes using a given key by linking their fscrypt_infos together,
r
From: Eric Biggers
Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
deriving additional key material from the fscrypt master keys for v2
encryption policies. HKDF is a key derivation function built on top of
HMAC. We choose SHA-512 for the underlying unkeyed hash, and use
From: Eric Biggers
Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
ioctls to be used by non-root users to add and remove encryption keys
from the filesystem-level crypto keyrings, subject to limitations.
Motivation: while privileged fscrypt key management is sufficient for
s
From: Eric Biggers
Update the fscrypt documentation file to catch up to all the latest
changes, including the new ioctls to manage master encryption keys in
the filesystem-level keyring and the support for v2 encryption policies.
Signed-off-by: Eric Biggers
---
Documentation/filesystems/fscryp
From: Eric Biggers
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- The encryption key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
use
From: Eric Biggers
Wire up the new ioctls for adding and removing fscrypt keys to/from the
filesystem, and the new ioctl for retrieving v2 encryption policies.
FS_IOC_REMOVE_ENCRYPTION_KEY also required making ext4_drop_inode() call
fscrypt_drop_inode().
For more details see Documentation/files
From: Eric Biggers
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evi
From: Eric Biggers
Wire up the new ioctls for adding and removing fscrypt keys to/from the
filesystem, and the new ioctl for retrieving v2 encryption policies.
FS_IOC_REMOVE_ENCRYPTION_KEY also required making UBIFS use
fscrypt_drop_inode().
For more details see Documentation/filesystems/fscryp
From: Eric Biggers
Wire up the new ioctls for adding and removing fscrypt keys to/from the
filesystem, and the new ioctl for retrieving v2 encryption policies.
FS_IOC_REMOVE_ENCRYPTION_KEY also required making f2fs_drop_inode() call
fscrypt_drop_inode().
For more details see Documentation/files
From: Eric Biggers
Add a new fscrypt ioctl, FS_IOC_GET_ENCRYPTION_KEY_STATUS. Given a key
specified by 'struct fscrypt_key_specifier' (the same way a key is
specified for the other fscrypt key management ioctls), it returns
status information in a 'struct fscrypt_get_key_status_arg'.
The main m
From: Eric Biggers
Update fs/crypto/ to use the new names for the UAPI constants rather
than the old names, then make the old definitions conditional on
!__KERNEL__.
Signed-off-by: Eric Biggers
---
fs/crypto/crypto.c | 2 +-
fs/crypto/fname.c| 2 +-
fs/crypto/fscrypt_pr
From: Eric Biggers
More fscrypt definitions are being added, and we shouldn't use a
disproportionate amount of space in for fscrypt stuff.
So move the fscrypt definitions to a new header .
For source compatibility with existing userspace programs,
still includes the new header.
Signed-off-by:
Hello,
This patchset makes major improvements to how keys are added, removed,
and derived in fscrypt, aka ext4/f2fs/ubifs encryption. It does this by
adding new ioctls that add and remove encryption keys directly to/from
the filesystem, and by adding a new encryption policy version ("v2")
where t
On 2019/2/20 12:10, Herbert Xu wrote:
> On Sat, Feb 02, 2019 at 10:25:43AM +0800, Zhou Wang wrote:
>>
>> In fact, I planned to register to acomp later.
>>
>> It also makes sense to use scomp if hardware engine is faster than CPU.
>> So how about registering to scomp firstly, then we register this e
On Sat, Feb 02, 2019 at 10:25:43AM +0800, Zhou Wang wrote:
>
> In fact, I planned to register to acomp later.
>
> It also makes sense to use scomp if hardware engine is faster than CPU.
> So how about registering to scomp firstly, then we register this engine to
> acomp later?
Sorry, but the fact
On Wed, Apr 18, 2018 at 07:35:33AM +0200, Steffen Klassert wrote:
>
> Yes sure, I just wanted to know if it is worth to think about
> preventing template recursions. If there is a valid usecase,
> then we don't even need to think in this direction.
>
> While I think each pcrypt instance should ha
On 2/19/19 4:16 AM, Jonas Gorski wrote:
> BCM63XX (MIPS) does not use device tree, so there cannot be any
> of_device_id, causing the driver to fail on probe:
>
> [0.904564] bcm2835-rng: probe of bcm63xx-rng failed with error -22
>
> Fix this by checking for match data only if we are probing
On Tue, 19 Feb 2019 at 17:02, Kamil Konieczny
wrote:
>
> Fix bug "s5p-sss crypto driver doesn't set next AES-CBC IV". While at this,
> fix also AES-CTR mode. Tested on Odroid U3 with Eric Biggers branch
> "iv-out-testing".
>
> Signed-off-by: Kamil Konieczny
> Reported-by: Eric Biggers
> ---
> Ch
Fix bug "s5p-sss crypto driver doesn't set next AES-CBC IV". While at this,
fix also AES-CTR mode. Tested on Odroid U3 with Eric Biggers branch
"iv-out-testing".
Signed-off-by: Kamil Konieczny
Reported-by: Eric Biggers
---
Changes since v1:
- reworded Subject and commit message
- changed code
1-block SSE2 variant of poly1305 stores variables s1..s4 containing key
material on the stack. This commit adds missing zeroing of the stack
memory. Benchmarks show negligible performance hit (tested on i7-3770).
Signed-off-by: Tommi Hirvola
---
Similarly, poly1305_blocks() in crypto/poly1305_gen
This patch set fixes issues uncovered when testing the Job Ring interface
with CONFIG_DMA_API_DEBUG=y.
First patch ("crypto: caam - fix hash context DMA unmap size") has to be
sent to -stable, according to "Fixes" tag.
Franck LENORMAND (1):
crypto: caam - fix hash context DMA unmap size
Horia
From: Franck LENORMAND
When driver started using state->caam_ctxt for storing both running hash
and final hash, it was not updated to handle different DMA unmap
lengths.
Cc: # v4.19+
Fixes: c19650d6ea99 ("crypto: caam - fix DMA mapping of stack memory")
Signed-off-by: Franck LENORMAND
Signed-o
Fix a side effect of adding xcbc support, which leads to DMA mapping the
key twice.
Fixes: 12b8567f6fa4 ("crypto: caam - add support for xcbc(aes)")
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamhash.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto
When generating a split key or hashing the key, DMA mapping the key
buffers coming directly from user is incorrect, since they are
not guaranteed to be DMAable.
Update driver to first copy user-provided key in the output buffer
("key_out") and then use this buffer for in-place computation
(split k
BCM63XX (MIPS) does not use device tree, so there cannot be any
of_device_id, causing the driver to fail on probe:
[0.904564] bcm2835-rng: probe of bcm63xx-rng failed with error -22
Fix this by checking for match data only if we are probing from device
tree.
Fixes: 8705f24f7b57 ("hwrng: bcm2
On Mon, 18 Feb 2019 at 17:01, Kamil Konieczny
wrote:
>
> Fix bug "s5p-sss crypto driver doesn't set next AES-CBC IV". This should
> also fix AES-CTR mode. Tested on Odroid U3 with Eric Biggers branch
> "iv-out-testing".
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/crypto/s5p-sss.c | 8
Replace hard coded AES block size with define.
Signed-off-by: Krzysztof Kozlowski
---
drivers/crypto/s5p-sss.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 0064be0e3941..39fc6942364b 100644
--- a/drivers/crypt
On Tue, 19 Feb 2019 at 10:58, Kamil Konieczny
wrote:
>
> Hi,
>
> On 15.02.2019 19:51, Eric Biggers wrote:
> > Hello,
> >
> > The AES-CBC implementation in the s5p-sss crypto driver is failing the
> > improved
> > crypto self-tests I currently have out for review. The improved tests check
> > tha
Hi,
On 15.02.2019 19:51, Eric Biggers wrote:
> Hello,
>
> The AES-CBC implementation in the s5p-sss crypto driver is failing the
> improved
> crypto self-tests I currently have out for review. The improved tests check
> that all CBC implementations update the IV buffer to be the last ciphertext
37 matches
Mail list logo
