From: Eric Biggers
Make fscrypt no longer use Crypto API drivers for non-inline crypto
accelerators, even when the Crypto API prioritizes them over CPU-based
code (which unfortunately it often does). These drivers tend to be
really problematic, especially for fscrypt's synchronous wor
On Fri, Jun 13, 2025 at 11:01:03AM +0200, Maxime MERE wrote:
> Hello,
>
> On 6/11/25 22:58, Eric Biggers wrote:
> > To protect users from these buggy and seemingly unhelpful drivers that I
> > have no way of testing, let's make fscrypt not use them. Unfortunately
>
On Thu, Jun 12, 2025 at 03:57:43PM +, Eric Biggers wrote:
> On Thu, Jun 12, 2025 at 09:50:26AM +0100, Giovanni Cabiddu wrote:
> > On Wed, Jun 11, 2025 at 11:25:21PM -0700, Eric Biggers wrote:
> >
> > ...
> >
> > > FWIW, here's what happens if
On Thu, Jun 12, 2025 at 09:50:26AM +0100, Giovanni Cabiddu wrote:
> On Wed, Jun 11, 2025 at 11:25:21PM -0700, Eric Biggers wrote:
>
> ...
>
> > FWIW, here's what happens if you try to use the Intel QAT driver with
> > dm-crypt:
> >
On Thu, Jun 12, 2025 at 12:59:14AM +, Eric Biggers wrote:
> On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 6/12/25 05:58, Eric Biggers wrote:
> >
> > > But
> > > otherwise this style of hardware offload is basica
On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote:
> Hi,
>
> On 6/12/25 05:58, Eric Biggers wrote:
>
> > But
> > otherwise this style of hardware offload is basically obsolete and has
> > been superseded by hardware-accelerated crypto instructions dire
From: Eric Biggers
fscrypt has never properly supported the old-school Crypto API hardware
offload drivers, as it processes each request synchronously. There was
one report of someone successfully using such a driver 8 years ago. But
otherwise this style of hardware offload is basically
642 | .iv = "\xca\xfe\xba\xbe\xfa\xce\xdb\xad"
> | ^~
>
> Signed-off-by: Kees Cook
> ---
> Cc: Herbert Xu
> Cc: Eric Biggers
> Cc: Ard Biesheuvel
> Cc: "David S.
[+Kees and linux-hardening]
On Wed, May 28, 2025 at 01:15:05PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> by this commit, the config has below diff:
>
> ---
> /pkg/linux/x86_64-randconfig-101-20250522/clang-20/d469eaed223fa485eabebd3bcd05ddd3c891f54e/.config
> 2025-05-23 23:44:56.78171
On Mon, Apr 28, 2025 at 12:19:50PM -0700, Dave Hansen wrote:
> On 4/28/25 11:38, Eric Biggers wrote:
> > -static int sgx_get_key_hash(const void *modulus, void *hash)
> > -{
> > - struct crypto_shash *tfm;
> > - int ret;
> > -
> > - tfm = crypto_al
From: Eric Biggers
This user of SHA-256 does not support any other algorithm, so the
crypto_shash abstraction provides no value. Just use the SHA-256
library API instead, which is much simpler and easier to use.
Signed-off-by: Eric Biggers
---
This patch is targeting the x86 tree for 6.16
From: Eric Biggers
This mostly reverts commit a0fc20333ee4bac1147c4cf75dea098c26671a2f.
Keep the relevant parts of the comment added by that commit.
The problem with that commit is that it allowed people to create broken
configurations that enabled FS_ENCRYPTION but not the mandatory
algorithms
On Mon, Aug 05, 2024 at 07:52:38PM +0200, Thorsten Blum wrote:
> struct poly_req {
> @@ -611,8 +611,8 @@ static int chachapoly_create(struct crypto_template
> *tmpl, struct rtattr **tb,
> poly->base.cra_priority) / 2;
> inst->alg.base.cra_blocksize = 1;
On Fri, May 17, 2024 at 07:48:48PM +0300, Jarkko Sakkinen wrote:
> On Fri May 17, 2024 at 7:22 PM EEST, Nícolas F. R. A. Prado wrote:
> > On Fri, May 17, 2024 at 07:25:40AM -0700, James Bottomley wrote:
> > > On Fri, 2024-05-17 at 15:43 +0200, Ard Biesheuvel wrote:
> > > > On Fri, 17 May 2024 at 15
On Mon, Apr 22, 2024 at 04:05:34PM +0800, kernel test robot wrote:
> [ 235.998172][T1] Kernel panic - not syncing: Certs selftest 0:
> pkcs7_verify() = -65
Thanks! The problem is that CONFIG_FIPS_SIGNATURE_SELFTEST is missing
dependencies on the algorithms it uses.
https://lore.kernel.org/r
On Thu, Mar 14, 2024 at 04:52:47AM -0700, James Prestwood wrote:
> IWD uses AF_ALG/keyctl for _all_ its crypto, cipher, and checksum needs.
> Anything that wifi requires as far as crypto goes IWD uses the kernel,
> except ECC is the only exception. The entire list of crypto requirements
> (for full
On Wed, Mar 13, 2024 at 04:06:11PM -0700, Eric Biggers wrote:
> On Wed, Mar 13, 2024 at 03:51:10PM -0700, Jeff Johnson wrote:
> > On 3/13/2024 3:10 PM, Eric Biggers wrote:
> > > On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> > >> Hi,
> >
On Wed, Mar 13, 2024 at 03:51:10PM -0700, Jeff Johnson wrote:
> On 3/13/2024 3:10 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> >> Hi,
> >>
> >> On 3/13/24 1:22 PM, Eric Biggers wrote:
> >>> On Wed, M
On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 1:22 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
> > > Hi,
> > >
> > > On 3/13/24 12:44 PM, Eric Biggers wrote:
> &
On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 12:44 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
> > > Hi,
> > >
> > > On 3/13/24 1:56 AM, Johannes Berg wrote:
&g
On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 1:56 AM, Johannes Berg wrote:
> > Not sure why you're CC'ing the world, but I guess adding a few more
> > doesn't hurt ...
> >
> > On Wed, 2024-03-13 at 09:50 +0100, Karel Balej wrote:
> > > and I use iwd
> >
On Mon, Jan 22, 2024 at 04:27:21PM -0800, Kees Cook wrote:
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> N
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
itted even if SHA-256 is being used.
> + imply CRYPTO_SHA256
> help
> This option enables fs-verity. fs-verity is the dm-verity
> mechanism implemented at the file level. On supported
Looks fine,
Acked-by: Eric Biggers
- Eric
On Fri, Apr 16, 2021 at 06:06:41PM +0200, Ard Biesheuvel wrote:
> Even if FS encryption has strict functional dependencies on various
> crypto algorithms and chaining modes. those dependencies could potentially
> be satisified by other implementations than the generic ones, and no link
> time depen
On Mon, Apr 19, 2021 at 04:16:13AM +, Mothershead, Hailey wrote:
> Hello,
>
> The patch quoted below causes the kernel to panic when fips is enabled with:
>
>alg: ecdh: test failed on vector 2, err=-14
>Kernel panic - not syncing: alg: self-tests for ecdh-generic (ecd
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 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 Thu, Apr 08, 2021 at 07:58:08PM +0800, Hangbin Liu wrote:
> On Thu, Apr 08, 2021 at 09:06:52AM +0800, Hangbin Liu wrote:
> > > Also, couldn't you just consider WireGuard to be outside your FIPS module
> > > boundary, which would remove it from the scope of the certification?
> > >
> > > And how
On Wed, Apr 07, 2021 at 07:39:20PM +0800, Hangbin Liu wrote:
> As the cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
> FIPS certified, the WireGuard module should be disabled in FIPS mode.
>
> Signed-off-by: Hangbin Liu
I think you mean "FIPS allowed", not "FIPS certified"?
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 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
-crypto@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 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
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 Mon, Mar 22, 2021 at 08:45:22AM +0300, Dan Carpenter wrote:
> On Sun, Mar 21, 2021 at 10:07:48PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > crypto_stats_get() is a no-op when the kernel is compiled without
> > CONFIG_CRYPTO_STATS, so pai
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-crypto@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-crypto@vger.ker
From: Eric Biggers
crypto_stats_get() is a no-op when the kernel is compiled without
CONFIG_CRYPTO_STATS, so pairing it with crypto_alg_put() unconditionally
(as crypto_rng_reset() does) is wrong.
Fix this by moving the call to crypto_stats_get() to just before the
actual algorithm operation
From: Eric Biggers
The new ARM BLAKE2s code doesn't work correctly (fails the self-tests)
in big endian kernel builds because it doesn't swap the endianness of
the message words when loading them. Fix this.
Fixes: 5172d322d34c ("crypto: arm/blake2s - add ARM scalar optimized B
t; Reviewed-by: Nicolas Pitre
> Reviewed-by: Geert Uytterhoeven
> Reviewed-by: Linus Walleij
Reviewed-by: Eric Biggers
Although likewise, shouldn't the commit title say "rev_l" instead of "rev_32"?
- Eric
Walleij
Reviewed-by: Eric Biggers
Although shouldn't the commit title say "rev_l" instead of "rev_32"?
- Eric
ash(struct crypto_ahash *tfm)
> {
You missed crypto_free_shash().
Otherwise this looks good, feel free to add:
Reviewed-by: Eric Biggers
- Eric
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 Sun, Feb 28, 2021 at 01:28:24PM +0100, Ard Biesheuvel wrote:
> Given that crypto_alloc_tfm() may return ERR pointers, and to avoid
> crashes on obscure error paths where such pointers are presented to
> crypto_destroy_tfm() (such as [0]), add an ERR_PTR check there
> before dereferencing the sec
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
From: Eric Biggers
Neither crypto_unregister_shashes() nor the module_exit function return
a value, so the explicit 'return' is unnecessary.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/blake2b-neon-glue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
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,
crypto/testmgr.c | 6 -
> crypto/testmgr.h | 79
> crypto/twofish_generic.c | 11 +-
> 12 files changed, 90 insertions(+), 303 deletions(-)
Thanks for fixing this up! These patches all look good to me, and all the
self-tests still pass. You can add:
Reviewed-by: Eric Biggers
- Eric
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-crypto@vger.kernel.org
> Cc: Andy Lutomirski
>
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 Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
> Salsa20 is not used anywhere in the kernel, is not suitable for disk
> encryption, and widely considered to have been superseded by ChaCha20.
> So let's remove it.
>
> Signed-off-by: Ard Biesheuvel
> ---
> Documentation/admin-guid
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 Sat, Jan 16, 2021 at 08:59:50AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> master
> head: b3a3cbdec55b090d22a09f75efb7c7d34cb97f25
> commit: 28dcca4cc0c01e2467549a36b1b0eacfdb01236c [952/3956] crypto: blake2b -
> sync with
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
On Fri, Jan 15, 2021 at 06:17:43PM +0100, Jason A. Donenfeld wrote:
> users are unable to load the module after use.
It should say "unload".
- Eric
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-crypto@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
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-crypto@vger.kernel.org
Cc: Andy
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-crypto@vger.ker
particular,
> whether synchronize_rcu_tasks() is sufficient to ensure that a module
> providing the target of a static call can be unloaded safely.
>
> Cc: "Martin K. Petersen"
> Cc: Eric Biggers
> Cc: Peter Zijlstra
>
> Ard Biesheuvel (7):
> crypto: crc-t1
+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 Fri, Jan 08, 2021 at 06:17:06PM +0100, Ard Biesheuvel wrote:
> diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
> index 6a733b171a5d..aa133dc3bf39 100644
> --- a/include/crypto/skcipher.h
> +++ b/include/crypto/skcipher.h
> @@ -128,7 +128,7 @@ struct skcipher_alg {
>
On Thu, Jan 07, 2021 at 01:41:28PM +0100, Ard Biesheuvel wrote:
> Unlike many other structure types defined in the crypto API, the
> 'shash_desc' structure is permitted to live on the stack, which
> implies its contents may not be accessed by DMA masters. (This is
> due to the fact that the stack m
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:
> >
| 2 +-
> 12 files changed, 8 insertions(+), 8 deletions(-)
Acked-by: Eric Biggers
| 6 -
> include/crypto/internal/skcipher.h| 1 -
> 6 files changed, 243 deletions(-)
Acked-by: Eric Biggers
h_avx_glue.c | 73 +-
> arch/x86/crypto/twofish_glue_3way.c | 80 ++--
> crypto/Kconfig | 2 -
> 3 files changed, 44 insertions(+), 111 deletions(-)
Acked-by: Eric Biggers
t6_avx_glue.c | 61 ++--
> crypto/Kconfig | 1 -
> 2 files changed, 17 insertions(+), 45 deletions(-)
Acked-by: Eric Biggers
5_avx_glue.c | 184 ++--
> 1 file changed, 17 insertions(+), 167 deletions(-)
Acked-by: Eric Biggers
1 - 100 of 1661 matches
Mail list logo
