he "Fixes" line shouldn't be line-wrapped.
Otherwise this looks fine. The explanation in the commit message still isn't
great, but it's much better than it was before.
You can add:
Reviewed-by: Eric Biggers
- Eric
On Thu, Apr 15, 2021 at 03:46:46PM -0400, Chris von Recklinghausen wrote:
> Hibernation fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> This patch changes the integrity check algorithm from md5 to crc32.
The second par
On Thu, Mar 25, 2021 at 09:26:09PM +, Satya Tangirala wrote:
> The number of sectors passed to bio_split() should be aligned to
> bio_required_sector_alignment(). All callers (other than bounce.c) have
> been updated to ensure this, so add a WARN() if the number of sectors is
> not aligned. (bo
On Thu, Mar 25, 2021 at 09:26:07PM +, Satya Tangirala wrote:
> Not all crypto data unit sizes might be supported by the block layer due to
> certain queue limits. This new function checks the queue limits and
> appropriately modifies the keyslot manager to reflect only the supported
> crypto da
On Thu, Mar 25, 2021 at 09:26:06PM +, Satya Tangirala wrote:
> Make blk_crypto_split_bio_if_needed() respect
> bio_required_sector_alignment() when calling bio_split().
>
A bit more explanation would be helpful here. Does this fix something, and if
so what is it and under what circumstances?
On Thu, Mar 25, 2021 at 09:26:05PM +, Satya Tangirala wrote:
> This function returns the required alignment for the number of sectors in
> a bio. In particular, the number of sectors passed to bio_split() must be
> aligned to this value.
>
> Signed-off-by: Satya Tangirala
> ---
> block/blk.h
On Tue, Mar 30, 2021 at 07:06:53PM +0100, Christoph Hellwig wrote:
> On Thu, Mar 25, 2021 at 09:26:05PM +, Satya Tangirala wrote:
> > +/*
> > + * The required sector alignment for a bio. The number of sectors in any
> > bio
> > + * that's constructed/split must be aligned to this value.
> > +
On Thu, Mar 25, 2021 at 09:26:04PM +, Satya Tangirala wrote:
> The size of any bio must be aligned to the data unit size of the bio crypt
> context (if it exists) of that bio. This must also be ensured whenever a
> bio is split. Introduce blk_crypto_bio_sectors_alignment() that returns
> the re
On Thu, Mar 25, 2021 at 09:26:03PM +, Satya Tangirala wrote:
> Handle any error from blk_ksm_register() in the callers. Previously,
> the callers ignored the return value because blk_ksm_register() wouldn't
> fail as long as the request_queue didn't have integrity support too, but
> as this is
On Thu, Mar 25, 2021 at 09:26:02PM +, Satya Tangirala wrote:
> This function checks if a given keyslot manager supports any encryption
> mode/data unit size combination (and returns true if there is no such
> supported combination). Helps clean up code a little.
>
> Signed-off-by: Satya Tangir
On Wed, Apr 14, 2021 at 11:53:51AM -0700, Nick Terrell wrote:
> On Wed, Apr 14, 2021 at 11:35 AM Eric Biggers wrote:
> >
> > On Wed, Apr 14, 2021 at 11:01:29AM -0700, Nick Terrell wrote:
> > > Hi all,
> > >
> > > I would really like to make some prog
On Wed, Apr 14, 2021 at 11:01:29AM -0700, Nick Terrell wrote:
> Hi all,
>
> I would really like to make some progress on this and get it merged.
> This patchset offsers:
> * 15-30% better decompression speed
> * 3 years of zstd bug fixes and code improvements
> * Allows us to import zstd directly
On Tue, Apr 13, 2021 at 12:13:30PM -0400, Chris von Recklinghausen wrote:
> Suspend fails on a system in fips mode because md5 is used for the e820
Suspend to disk (hibernation), or any suspend?
> struct restore_data_record {
> unsigned long jump_address;
> unsigned long jump_address
On Tue, Apr 13, 2021 at 12:13:30PM -0400, Chris von Recklinghausen wrote:
> +static inline void get_e820_crc32(struct e820_table *table, void *buf)
> {
This should just return the CRC-32 value as a u32. There's no need for the
'void *buf' argument.
Also like I said, compute_e820_crc32() would b
On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote:
> On 4/12/21 1:45 PM, Eric Biggers wrote:
> > On Mon, Apr 12, 2021 at 10:09:32AM -0400, Chris von Recklinghausen wrote:
> > > Suspend fails on a system in fips mode because md5 is used for the e820
> &g
t; v2
>bump up RESTORE_MAGIC
> v2 -> v3
>move embelishment from cover letter to commit comments (no code change)
> v3 -> v4
>add note to comments that md5 isn't used for encryption here.
> v4 -> v5
>reword comment per Simo's suggestion
> v5
On Thu, Apr 08, 2021 at 11:53:59AM -0400, Chris von Recklinghausen wrote:
> On 4/8/21 11:30 AM, Eric Biggers wrote:
> > On Thu, Apr 08, 2021 at 09:15:06AM -0400, Chris von Recklinghausen wrote:
> > > Suspend fails on a system in fips mode because md5 is used for the e820
> &g
On Thu, Apr 08, 2021 at 09:15:06AM -0400, Chris von Recklinghausen wrote:
> Suspend fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> This patch changes the integrity check algorithm from md5 to
> crc32. This integrity ch
On Thu, Apr 08, 2021 at 03:32:38PM +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 8, 2021 at 3:15 PM Chris von Recklinghausen
> wrote:
> >
> > Suspend fails on a system in fips mode because md5 is used for the e820
> > integrity check and is not available. Use crc32 instead.
> >
> > This patch chan
On Wed, Apr 07, 2021 at 08:18:45PM +0530, Shreeya Patel wrote:
> diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
> index 2c27b9a5cd6c..0c69800a2a37 100644
> --- a/fs/unicode/Kconfig
> +++ b/fs/unicode/Kconfig
> @@ -2,13 +2,31 @@
> #
> # UTF-8 normalization
> #
> +# CONFIG_UNICODE will be au
On Wed, Apr 07, 2021 at 08:18:42PM +0530, Shreeya Patel wrote:
> The -Wstringop-truncation warning highlights the unintended
> uses of the strncpy function that truncate the terminating NULL
> character from the source string.
> Unlike strncpy(), strscpy() always null-terminates the destination str
On Wed, Apr 07, 2021 at 06:04:21AM -0400, Chris von Recklinghausen wrote:
> Suspend fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> Prior to this patch, MD5 is used only to create a digest to ensure integrity
> of
> th
On Mon, Apr 05, 2021 at 11:04:38AM -0400, Julian Braha wrote:
> Currently, when a config option selects a
> CRYPTO_LIB_* option while CRYPTO is disabled,
> Kbuild gives an unmet dependency. However,
> these config options do not actually need to
> depend on CRYPTO.
>
> Signed-off-by: Julian Braha
On Thu, Apr 01, 2021 at 02:37:51AM +0530, Shreeya Patel wrote:
> +# utf8data.h_shipped has a large database table which is an auto-generated
> +# decodification trie for the unicode normalization functions and it is not
> +# necessary to carry this large table in the kernel.
> +# Enabling UNICODE_U
On Thu, Apr 01, 2021 at 06:19:57PM +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 3:59 PM Ard Biesheuvel wrote:
> >
> > On Thu, 1 Apr 2021 at 15:34, Rafael J. Wysocki wrote:
> > >
> > > On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
> > > wrote:
> > > >
> > > > Suspend fails o
On Thu, Apr 01, 2021 at 09:54:21AM -0400, Chris von Recklinghausen wrote:
> On 4/1/21 9:38 AM, Rafael J. Wysocki wrote:
> > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> > > On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> > > > On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
On Thu, Apr 01, 2021 at 08:50:05AM +0300, Jarkko Sakkinen wrote:
> On Thu, Apr 01, 2021 at 12:11:32PM +1100, Herbert Xu wrote:
> > On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote:
> > > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote:
> > > &
On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote:
>
> It's a bummer but uapi is the god in the end. Since TPM does not do it
> today, that behaviour must be supported forever. That's why a boot option
> AND a warning would be the best compromise.
>
It's not UAPI if there is no way
On Tue, Mar 30, 2021 at 09:38:55AM -0700, Randy Dunlap wrote:
> On 3/29/21 10:29 PM, Eric Biggers wrote:
> > On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote:
> >> Having just seen a report of using "fips=1" on the kernel command line,
> >> I coul
On Sun, Mar 28, 2021 at 11:37:23PM +0300, Jarkko Sakkinen wrote:
>
> Unfortunately, TPM trusted keys started this bad security practice, and
> obviously it cannot be fixed without breaking uapi backwards compatibility.
>
The whole point of a randomness source is that it is random. So userspace
On Mon, Mar 29, 2021 at 10:16:57PM -0400, Gabriel Krisman Bertazi wrote:
> Eric Biggers writes:
>
> > On Tue, Mar 30, 2021 at 02:12:40AM +0530, Shreeya Patel wrote:
> >> diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
> >> index 2c27b9a5cd6c..ad4b837f2eb
-cry...@vger.kernel.org
> Cc: Eric Biggers
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> ---
> Updates/corrections welcome.
>
> v2: drop comment that "fips_enabled can cause some tests to be
On Tue, Mar 30, 2021 at 02:12:40AM +0530, Shreeya Patel wrote:
> diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
> index 2c27b9a5cd6c..ad4b837f2eb2 100644
> --- a/fs/unicode/Kconfig
> +++ b/fs/unicode/Kconfig
> @@ -2,13 +2,26 @@
> #
> # UTF-8 normalization
> #
> +# CONFIG_UNICODE will be au
On Tue, Mar 30, 2021 at 02:12:38AM +0530, Shreeya Patel wrote:
> utf8data.h_shipped has a large database table which is an auto-generated
> decodification trie for the unicode normalization functions and it is not
> necessary to carry this large table in the kernel.
> Goal is to make UTF-8 encoding
On Sun, Mar 28, 2021 at 11:43:54AM -0300, André Almeida wrote:
> For directories with negative dentries that are becoming case-insensitive
> dirs, we need to remove all those negative dentries, otherwise they will
> become dangling dentries. During the creation of a new file, if a d_hash
> collisio
On Mon, Mar 29, 2021 at 09:56:18PM +, Dexuan Cui wrote:
> Hi all,
> The v5.12.0-rc5 kernel (1e43c377a79f) panics with fips=1.
>
> Please refer to the below panic call-trace. The kernel config file and
> the full kernel messages are also attached.
>
> Is this a known issue?
>
> Thanks,
> -- D
On Thu, Mar 25, 2021 at 03:31:42PM -0400, Gabriel Krisman Bertazi wrote:
> Eric Biggers writes:
>
> > On Thu, Mar 25, 2021 at 05:38:08AM +0530, Shreeya Patel wrote:
> >> utf8_unload is being called if CONFIG_UNICODE is enabled.
> >> The ifdef block doesn't che
On Thu, Mar 25, 2021 at 05:38:11AM +0530, Shreeya Patel wrote:
> Also, indirect calls using function pointers are easily exploitable by
> speculative execution attacks, hence use static_call() in unicode.h and
> unicode-core.c files inorder to prevent these attacks by making direct
> calls and also
On Thu, Mar 25, 2021 at 05:38:09AM +0530, Shreeya Patel wrote:
> Rename the function names from utf8 to unicode for taking the first step
> towards the transformation of utf8-core file into the unicode subsystem
> layer file.
>
> Reviewed-by: Gabriel Krisman Bertazi
> Signed-off-by: Shreeya Patel
On Thu, Mar 25, 2021 at 05:38:08AM +0530, Shreeya Patel wrote:
> utf8_unload is being called if CONFIG_UNICODE is enabled.
> The ifdef block doesn't check if utf8 encoding has been loaded
> or not before calling the utf8_unload() function.
> This is not the expected behavior since it would sometime
On Tue, Mar 23, 2021 at 03:51:44PM -0400, Gabriel Krisman Bertazi wrote:
> > -int unicode_validate(const struct unicode_map *um, const struct qstr *str)
> > -{
> > - const struct utf8data *data = utf8nfdi(um->version);
> > -
> > - if (utf8nlen(data, str->name, str->len) < 0)
> > - ret
On Mon, Mar 22, 2021 at 12:57:26PM +0300, Andrey Ryabinin wrote:
> keyctl_read_key() has a strange code which allows possessor to read
> key's payload regardless of READ permission status:
>
> $ keyctl add user test test @u
> 196773443
> $ keyctl print 196773443
> test
> $ keyctl describe 19677344
me key".
So that's why there's a mix of 16 and 32 byte "keys".
The naming "POLY1305_KEY_SIZE" assumes the second convention, which is a bit
confusing; it really should be called something like POLY1305_ONETIME_KEY_SIZE.
I guess the idea was that the one-time key convention is the more common one.
Anyway, the patch seems to be fine, as it uses the correct length in each
location. You can add:
Reviewed-by: Eric Biggers
- Eric
On Wed, Feb 03, 2021 at 01:41:01PM +0100, Miklos Szeredi wrote:
> @@ -3071,123 +3012,54 @@ static int f2fs_ioc_setproject(struct file *filp,
> __u32 projid)
> }
> #endif
>
> -/* FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR support */
> -
> -/*
> - * To make a new on-disk f2fs i_flag gettable via FS
On Wed, Feb 03, 2021 at 01:40:55PM +0100, Miklos Szeredi wrote:
> + * Verifying attributes involves retrieving current attributes with
> + * i_op->miscattr_get(), this also allows initilaizing attributes that have
initilaizing => initializing
> +int vfs_miscattr_set(struct dentry *dentry, struct
On Mon, Mar 22, 2021 at 11:42:07AM -0400, Mimi Zohar wrote:
>
> Reported-by: Dmitry Vyukov
> Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> Signed-off-by: Mimi Zohar
Missing Cc stable?
- Eric
On Mon, Mar 22, 2021 at 11:42:06AM -0400, Mimi Zohar wrote:
> Only after an IMA policy is loaded, check, save, or update the cached
> file's integrity status.
>
> Signed-off-by: Mimi Zohar
This commit message doesn't describe what the actual effect of this change is.
Is it fixing something?
- E
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-cry...@vger.kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
Cc: Theodore Ts'o
Reviewed-by: Andy Lutomirski
Acked-by: Ard Biesheuvel
Sign
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-cry...@vger.ker
On Thu, Mar 18, 2021 at 07:03:05PM +0530, Shreeya Patel wrote:
> +struct unicode_ops {
> + struct module *owner;
> + int (*validate)(const struct unicode_map *um, const struct qstr *str);
> + int (*strncmp)(const struct unicode_map *um, const struct qstr *s1,
> +cons
On Thu, Mar 18, 2021 at 07:03:04PM +0530, Shreeya Patel wrote:
> Following warning was reported by Kernel Test Robot.
>
> In function 'utf8_parse_version',
> inlined from 'utf8_load' at fs/unicode/utf8mod.c:195:7:
> >> fs/unicode/utf8mod.c:175:2: warning: 'strncpy' specified bound 12 equals
> dest
On Tue, Mar 09, 2021 at 01:55:27AM -0800, Jia-Ju Bai wrote:
> When get_task_mm() returns NULL to mm, no error return code of
> proc_map_files_readdir() is assigned.
> To fix this bug, ret is assigned with -ENOENT in this case.
>
> Fixes: f0c3b5093add ("[readdir] convert procfs")
> Reported-by: TOT
On Mon, Mar 01, 2021 at 09:51:56PM +0100, Christoph Böhmwalder wrote:
> > Do you have a specific use case in mind for this information? Normally,
> > users
> > should already know which algorithm they want to use (or set of algorithms
> > they
> > might want to use).
>
> I have a pretty specifi
On Mon, Mar 01, 2021 at 05:59:17PM +0100, Christoph Böhmwalder wrote:
> Currently, it is not apparent for userspace users which hash algorithms
> require a key and which don't. We have /proc/crypto, so add a field
> with this information there.
>
> Signed-off-by: Christoph Böhmwalder
>
> ---
>
On Fri, Feb 26, 2021 at 02:14:41PM -0800, Sarthak Kukreti wrote:
> This allows 32-bit userspace utils to use FS_IOC_FSGETXATTR and
> FS_IOC_FSSETXATTR on a 64-bit kernel.
>
> Signed-off-by: Sarthak Kukreti
> ---
> fs/ext4/ioctl.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/ex
simd)
> crypto_disable_simd_for_test();
> - err = crypto_shash_update(desc, sg_data(&tsgl->sgl[i]),
> + err = crypto_shash_update(desc, sg_virt(&tsgl->sgl[i]),
> tsgl->sgl[i].length);
> if (divs[i]->nosimd)
> crypto_reenable_simd_for_test();
> --
Looks good,
Reviewed-by: Eric Biggers
- Eric
served
somewhere, and the other end wants to do its own fs-verity compatible
verification of the file. See the commit messages for details.
This new ioctl has been tested using new xfstests I've written for it.
Eric Bigge
On Mon, Feb 01, 2021 at 05:10:19AM +, Satya Tangirala wrote:
> dm-linear and dm-flakey obviously can pass through inline crypto support.
>
> Co-developed-by: Eric Biggers
> Signed-off-by: Eric Biggers
> Signed-off-by: Satya Tangirala
> ---
> drivers/md/dm-flakey.c |
ict that key from each device.
>
> Co-developed-by: Eric Biggers
> Signed-off-by: Eric Biggers
> Signed-off-by: Satya Tangirala
This latest version looks good to me. If it's needed despite my
Co-developed-by, feel free to add:
Reviewed-by: Eric Biggers
- Eric
capabilities are a (*not* necessarily strict) superset of the "old" inline
> encryption capabilities. Attempts to make changes to the table that result
> in some inline encryption capability becoming no longer supported will be
> rejected.
>
> For the sake of clarity, key evicti
a previously
> advertised crypto capability must always continue to be supported.
> This function can be used to check that a new ksm is a valid
> replacement for an old ksm.
>
> Signed-off-by: Satya Tangirala
Looks good, you can add:
Reviewed-by: Eric Biggers
On Thu, Feb 04, 2021 at 07:09:53PM -0500, Thara Gopinath wrote:
> > > @@ -260,6 +261,10 @@ static int qce_skcipher_crypt(struct
> > > skcipher_request *req, int encrypt)
> > > rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
> > > keylen = IS_XTS(rctx->flags) ? ctx->enc_keyl
On Thu, Feb 04, 2021 at 04:43:54PM -0500, Thara Gopinath wrote:
> + /*
> + * ECB and CBC algorithms require message lengths to be
> + * multiples of block size.
> + * TODO: The spec says AES CBC mode for certain versions
> + * of crypto engine can handle partial blocks as we
On Thu, Feb 04, 2021 at 04:43:53PM -0500, Thara Gopinath wrote:
> Crypto engine BAM dma does not support 0 length data. Return unsupported
> if zero length messages are passed for transformation.
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/skcipher.c | 5 +
> 1 file changed,
On Tue, Jan 12, 2021 at 11:28:18AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
> doesn't make sense. Reseed it from the input_pool instead.
>
> Fixes: d848e5f8e1eb ("random: add new ioc
On Tue, Jan 12, 2021 at 11:29:27AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> On big endian CPUs, the ChaCha20-based CRNG is using the wrong
> endianness for the ChaCha20 constants.
>
> This doesn't matter cryptographically, but technically it means it's not
On Tue, Jan 12, 2021 at 11:29:38AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove some dead code that was left over following commit 90ea1c6436d2
> ("random: remove the blocking pool").
>
> Cc: linux-cry...@vger.kernel.org
> Cc: Andy Lutomirski
>
On Thu, Dec 17, 2020 at 03:04:35PM +, Satya Tangirala wrote:
> Wire up metadata encryption support with the fscrypt metadata crypt
> additions. Note that this feature relies on the blk-crypto framework
> for encryption, and thus requires either hardware inline encryption
> support or the blk-cr
On Thu, Dec 17, 2020 at 03:04:34PM +, Satya Tangirala wrote:
> Introduces functions that help with metadata encryption.
>
> In particular, we introduce:
>
> fscrypt_setup_metadata_encryption() - filesystems should call this function
> to set up metadata encryption on a super block with the en
On Sun, Jan 24, 2021 at 03:04:50PM +0100, Stephan Müller wrote:
> The clearing of the OKM memory buffer in case of an error is already
> performed by the HKDF implementation crypto_hkdf_expand. Thus, the
> code clearing is not needed any more in the file system code base.
>
> Signed-off-by: Stepha
On Sun, Jan 24, 2021 at 03:04:31PM +0100, Stephan Müller wrote:
> @@ -74,16 +57,14 @@ int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8
> *master_key,
> return PTR_ERR(hmac_tfm);
> }
>
> - if (WARN_ON(crypto_shash_digestsize(hmac_tfm) != sizeof(prk))) {
> + if
Please prefix the commit subject with "fscrypt: " rather than "fs: ".
On Sun, Jan 24, 2021 at 03:04:31PM +0100, Stephan Müller wrote:
> diff --git a/fs/crypto/hkdf.c b/fs/crypto/hkdf.c
> index e0ec21055505..ae236b42b1f0 100644
> --- a/fs/crypto/hkdf.c
> +++ b/fs/crypto/hkdf.c
> @@ -9,7 +9,7 @@
>
On Sun, Jan 24, 2021 at 03:03:28PM +0100, Stephan Müller wrote:
> RFC5869 specifies an extract and expand two-step key derivation
> function. The HKDF implementation is provided as a service function that
> operates on a caller-provided HMAC handle. The caller has to allocate
> the HMAC shash handl
On Tue, Jan 19, 2021 at 08:26:40PM -0500, Sasha Levin wrote:
> From: Anthony Iliopoulos
>
> [ Upstream commit f7b347acb5f6c29d9229bb64893d8b6a2c7949fb ]
>
> The integrity target relies on skcipher for encryption/decryption, but
> certain kernel configurations may not enable CRYPTO_SKCIPHER, lead
On Fri, Jan 15, 2021 at 04:20:44PM -0800, Dave Hansen wrote:
> On 1/15/21 4:14 PM, Dey, Megha wrote:
> > Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
>
> That's true, bit it's also possible that a hypervisor could enumerate
> support for PCLMULQDQ and not AES-NI. In g
On Fri, Jan 15, 2021 at 04:14:40PM -0800, Dey, Megha wrote:
> > Hello Megha,
> >
> > What is the purpose of this separate GHASH module? GHASH is only used
> > in combination with AES-CTR to produce GCM, and this series already
> > contains a GCM driver.
> >
> > Do cores exist that implement PCLMU
From: Eric Biggers
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: Andy
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-cry...@vger.kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
Cc: Theodore Ts'o
Reviewed-by: Andy Lutomirski
Signed-off-by: Eric Biggers
---
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-cry...@vger.ker
;crypto_cap_array);
> out:
> /* Indicate that init failed by clearing UFSHCD_CAP_CRYPTO */
> hba->caps &= ~UFSHCD_CAP_CRYPTO;
Looks fine, feel free to add:
Reviewed-by: Eric Biggers
I think this was here to free the memory in the case where the crypto support
gets disab
On Mon, Jan 11, 2021 at 10:51:20AM -0800, Darrick J. Wong wrote:
> On Sun, Jan 10, 2021 at 07:41:02PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > On Fri 2020-10-09 10:37:32, Theodore Y. Ts'o wrote:
> > > On Thu, Oct 08, 2020 at 03:22:59PM -0700, Josh Triplett wrote:
> > > >
> > > > I wasn't trying
On Sun, Jan 10, 2021 at 01:27:09PM +0800, dinghao@zju.edu.cn wrote:
> > On Sat, Jan 09, 2021 at 07:33:05PM +0800, Dinghao Liu wrote:
> > > When kmalloc() fails, tmp_tfm allocated by
> > > crypto_alloc_shash() has not been freed, which
> > > leads to memleak.
> > >
> > > Fixes: d46eb3699502b ("
+Jason, since this looks WireGuard-related.
On Sat, Jan 09, 2021 at 05:05:24AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_..
> git tree: https://github.com/google/kmsan.git master
> co
On Sat, Jan 09, 2021 at 07:33:05PM +0800, Dinghao Liu wrote:
> When kmalloc() fails, tmp_tfm allocated by
> crypto_alloc_shash() has not been freed, which
> leads to memleak.
>
> Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
> Signed-off-by: Dinghao Liu
> ---
> security/integrity/e
On Thu, Jan 07, 2021 at 10:14:46PM +, Russell King - ARM Linux admin wrote:
> On Thu, Jan 07, 2021 at 10:48:05PM +0100, Arnd Bergmann wrote:
> > On Thu, Jan 7, 2021 at 5:27 PM Theodore Ts'o wrote:
> > >
> > > On Thu, Jan 07, 2021 at 01:37:47PM +, Russell King - ARM Linux admin
> > > wrote
On Thu, Jan 07, 2021 at 10:48:05PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 7, 2021 at 5:27 PM Theodore Ts'o wrote:
> >
> > On Thu, Jan 07, 2021 at 01:37:47PM +, Russell King - ARM Linux admin
> > wrote:
> > > > The gcc bugzilla mentions backports into gcc-linaro, but I do not see
> > > > th
On Thu, Jan 07, 2021 at 08:53:15AM +0100, Stephan Mueller wrote:
> >
> > > RFC5869
> > > allows two optional parameters to be provided to the extract operation:
> > > the salt and additional information. Both are to be provided with the
> > > seed parameter where the salt is the first entry of the
On Thu, Jan 07, 2021 at 08:49:52AM +0100, Stephan Mueller wrote:
> > > -int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key,
> > > +int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, u8 *master_key,
> > > unsigned int master_key_size);
> >
> > It shouldn't be
On Mon, Jan 04, 2021 at 10:49:13PM +0100, Stephan Müller wrote:
> RFC5869 specifies an extract and expand two-step key derivation
> function. The HKDF implementation is provided as a service function that
> operates on a caller-provided HMAC cipher handle.
HMAC isn't a "cipher".
> The extract fun
On Mon, Jan 04, 2021 at 10:50:49PM +0100, Stephan Müller wrote:
> As the kernel crypto API implements HKDF, replace the
> file-system-specific HKDF implementation with the generic HKDF
> implementation.
>
> Signed-off-by: Stephan Mueller
> ---
> fs/crypto/Kconfig | 2 +-
> fs/crypto/
On Wed, Jan 06, 2021 at 10:59:24PM -0800, Eric Biggers wrote:
> On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> > Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> >
On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> > > The HKDF addition is used to replace the implementation in the files
On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> The HKDF addition is used to replace the implementation in the filesystem
> crypto extension. This code was tested by using an EXT4 encrypted file
> system that was created and contains files written to by the current
> implementatio
On Fri, Nov 20, 2020 at 10:52:54AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:54AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:51:45PM -0700, Eric Biggers wrote:
> > > On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> > > >
On Fri, Nov 20, 2020 at 10:52:35AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:34:03AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:58PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> >
On Fri, Nov 20, 2020 at 10:52:14AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:43AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:21PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> >
On Tue, Sep 22, 2020 at 09:44:18AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There's no need for mnt_want_write_file() to increment mnt_writers when
> the file is already open for writing, provided that
> mnt_drop_write_file() is changed to conditionally decrement
gt; can't compute the dirhash when recovering a new dentry in an encrypted +
> casefolded directory. To avoid having to force a checkpoint when a new
> file is fsync'ed, store the dirhash on-disk appended to i_name.
>
> This patch incorporates work by Eric Biggers
> and Jae
hmarked using tcrypt using 1420 byte blocks - full results below)
>
> It also allows us to enable the same driver for i386.
>
> Cc: Megha Dey
> Cc: Eric Biggers
> Cc: Herbert Xu
>
> Ard Biesheuvel (2):
> crypto: x86/aes-ni-xts - use direct calls to and 4-way stri
On Fri, Dec 18, 2020 at 01:10:57PM -0800, Megha Dey wrote:
> Optimize crypto algorithms using VPCLMULQDQ and VAES AVX512 instructions
> (first implemented on Intel's Icelake client and Xeon CPUs).
>
> These algorithms take advantage of the AVX512 registers to keep the CPU
> busy and increase memor
1 - 100 of 1001 matches
Mail list logo
