Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #68776 > unrolled thread

Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config

Back to article view | Back to linux.debian.kernel

Contents

  Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config Ard Biesheuvel <ardb@kernel.org> - 2020-12-06 09:40 +0100
    Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config Diederik de Haas <didi.debian@cknow.org> - 2020-12-11 12:30 +0100
      Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config Ard Biesheuvel <ardb@kernel.org> - 2020-12-11 12:40 +0100
        Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config Diederik de Haas <didi.debian@cknow.org> - 2020-12-11 13:30 +0100
    Bug#976635: marked as done (linux-image-arm64: Accelerated crypto  modules missing from kernel config) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-12-13 12:10 +0100

#68776 — Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config

Package: linux-image-arm64
Version: 5.9.6-1~bpo10+1
Severity: important

Dear Maintainer,

Currently, arm64 kernel packages are built with the following Kconfig symbols unset:

# CONFIG_CRYPTO_SHA512_ARM64 is not set
# CONFIG_CRYPTO_SHA512_ARM64_CE is not set
# CONFIG_CRYPTO_SHA3_ARM64 is not set
# CONFIG_CRYPTO_SM3_ARM64_CE is not set
# CONFIG_CRYPTO_SM4_ARM64_CE is not set
# CONFIG_CRYPTO_CRCT10DIF_ARM64_CE is not set
# CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set
# CONFIG_CRYPTO_AES_ARM64_BS is not set

Please consider enabling these as modules. The latter two are especially relevant, given that scalar AES is susceptible to known-plaintext attacks on the key due to the fact that it is not time invariant. While most arm64 SoCs implement the AES instructions and therefore don't rely on these modules, notable SoCs such as the Raspberry Pi 3 and 4 can only use the NEON version which is not enabled here. (And on these platforms, these are substantially faster too)

-- System Information:
Debian Release: 10.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.9.0-0.bpo.2-arm64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-arm64 depends on:
ii  linux-image-5.9.0-0.bpo.2-arm64  5.9.6-1~bpo10+1

linux-image-arm64 recommends no packages.

linux-image-arm64 suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#68811

[Multipart message — attachments visible in raw view] — view raw

On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> Currently, arm64 kernel packages are built with the following Kconfig symbols 
unset:
> 
> # CONFIG_CRYPTO_SHA512_ARM64 is not set
> # CONFIG_CRYPTO_SHA512_ARM64_CE is not set
> # CONFIG_CRYPTO_SHA3_ARM64 is not set
> # CONFIG_CRYPTO_SM3_ARM64_CE is not set
> # CONFIG_CRYPTO_SM4_ARM64_CE is not set
> # CONFIG_CRYPTO_CRCT10DIF_ARM64_CE is not set
> # CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set
> # CONFIG_CRYPTO_AES_ARM64_BS is not set
> 
> Please consider enabling these as modules. The latter two are especially 
relevant, given that scalar AES is susceptible to known-plaintext attacks on 
the key due to the fact that it is not time invariant. While most arm64 SoCs 
implement the AES instructions and therefore don't rely on these modules, 
notable SoCs such as the Raspberry Pi 3 and 4 can only use the NEON version 
which is not enabled here. (And on these platforms, these are substantially 
faster too)

Are you the same Ard Biesheuvel that 'Signed-off-by' the patch in:
https://salsa.debian.org/kernel-team/linux/-/commit/
8332600d1188a6d88881fc835dfcd392a20f6bfc

In that commit a bunch of crypto modules got enabled, but (explicitly) not 
CONFIG_CRYPTO_AES_ARM64_NEON_BLK. Do you recall why that happened? (I realize 
it's from 2014)
There's an important difference between an 'oversight' and explicitly disabling 
a module and I'd like to have a clarification wrt that.

Cheers,
  Diederik

[toc] | [prev] | [next] | [standalone]

#68812

Hello Diederik,


On Fri, 11 Dec 2020 at 12:21, Diederik de Haas <didi.debian@cknow.org> wrote:
>
> On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> > Currently, arm64 kernel packages are built with the following Kconfig symbols
> unset:
> >
> > # CONFIG_CRYPTO_SHA512_ARM64 is not set
> > # CONFIG_CRYPTO_SHA512_ARM64_CE is not set
> > # CONFIG_CRYPTO_SHA3_ARM64 is not set
> > # CONFIG_CRYPTO_SM3_ARM64_CE is not set
> > # CONFIG_CRYPTO_SM4_ARM64_CE is not set
> > # CONFIG_CRYPTO_CRCT10DIF_ARM64_CE is not set
> > # CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set
> > # CONFIG_CRYPTO_AES_ARM64_BS is not set
> >
> > Please consider enabling these as modules. The latter two are especially
> relevant, given that scalar AES is susceptible to known-plaintext attacks on
> the key due to the fact that it is not time invariant. While most arm64 SoCs
> implement the AES instructions and therefore don't rely on these modules,
> notable SoCs such as the Raspberry Pi 3 and 4 can only use the NEON version
> which is not enabled here. (And on these platforms, these are substantially
> faster too)
>
> Are you the same Ard Biesheuvel that 'Signed-off-by' the patch in:
> https://salsa.debian.org/kernel-team/linux/-/commit/
> 8332600d1188a6d88881fc835dfcd392a20f6bfc
>

Presumably, yes. But I cannot access that link.

> In that commit a bunch of crypto modules got enabled, but (explicitly) not
> CONFIG_CRYPTO_AES_ARM64_NEON_BLK. Do you recall why that happened? (I realize
> it's from 2014)
> There's an important difference between an 'oversight' and explicitly disabling
> a module and I'd like to have a clarification wrt that.
>

This code was written before any hardware existed, and at the time, it
was not obvious whether it would perform well enough.

Six years later, we know that this code works fine, and is faster (and
safer!) than any of the non-NEON alternatives. (On Raspberry Pi 3, the
non-NEON AES takes 31.5 cycles per byte, whereas the NEON code takes
around 22 cycles per byte)

[toc] | [prev] | [next] | [standalone]

#68815

[Multipart message — attachments visible in raw view] — view raw

Hi Ard,

On vrijdag 11 december 2020 12:26:43 CET Ard Biesheuvel wrote:
> > Are you the same Ard Biesheuvel that 'Signed-off-by' the patch in:
> > https://salsa.debian.org/kernel-team/linux/-/commit/
> > 8332600d1188a6d88881fc835dfcd392a20f6bfc
> 
> Presumably, yes. But I cannot access that link.

https://salsa.debian.org/kernel-team/linux/-/commit/8332600d1188a6d88881fc835dfcd392a20f6bfc
Mail client wrapped the link previously. AFAIK it should be public for all.

> > In that commit a bunch of crypto modules got enabled, but (explicitly) not
> > CONFIG_CRYPTO_AES_ARM64_NEON_BLK. Do you recall why that happened? (I
> > realize it's from 2014)
> > There's an important difference between an 'oversight' and explicitly
> > disabling a module and I'd like to have a clarification wrt that.
> 
> This code was written before any hardware existed, and at the time, it
> was not obvious whether it would perform well enough.
> 
> Six years later, we know that this code works fine, and is faster (and
> safer!) than any of the non-NEON alternatives. (On Raspberry Pi 3, the
> non-NEON AES takes 31.5 cycles per byte, whereas the NEON code takes
> around 22 cycles per byte)

Thanks for the clarification :)

[toc] | [prev] | [next] | [standalone]

#68825 — Bug#976635: marked as done (linux-image-arm64: Accelerated crypto modules missing from kernel config)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Sun, 13 Dec 2020 11:00:10 +0000
with message-id <E1koP6o-0005Z8-AO@fasolo.debian.org>
and subject line Bug#976635: fixed in linux 5.10~rc7-1~exp1
has caused the Debian Bug report #976635,
regarding linux-image-arm64: Accelerated crypto modules missing from kernel config
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
976635: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976635
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web