Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

On Tue, 23 Nov 2021 at 06:12, Salvatore Bonaccorso wrote: > > Hi Vincent, > > On Fri, Nov 19, 2021 at 10:04:57PM +0100, Vincent Blut wrote: > > Hi, > > > > Le 2021-10-26 17:33, Zameer Manji a écrit : > > > On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut > > > wrote: > > > > > > > Control: reassign

Re: [PATCH] builddeb: Support signing kernels with a Machine Owner Key

the change itself Acked-by: Ard Biesheuvel although I'd suggest to fix the subject not to refer to Machine Owner Keys, as I don't see anything shim related here (i.e., if you sign using a key that is listed in db, it should also work) > --- > scripts/package/builddeb | 10 +++

Re: [PATCH] builddeb: Support signing kernels with a Machine Owner Key

(+ Peter) On Thu, 6 May 2021 at 15:37, Matthew Wilcox wrote: > > On Thu, May 06, 2021 at 02:01:53PM +0200, Ard Biesheuvel wrote: > > On Thu, 6 May 2021 at 14:00, Matthew Wilcox (Oracle) > > wrote: > > > > > > If the config file specifies a signing key

Re: [PATCH] builddeb: Support signing kernels with a Machine Owner Key

On Thu, 6 May 2021 at 14:00, Matthew Wilcox (Oracle) wrote: > > If the config file specifies a signing key, use it to sign > the kernel so that machines with SecureBoot enabled can boot. > See https://wiki.debian.org/SecureBoot > > Signed-off-by: Matthew Wilcox (Oracle) > --- >

Re: please consider disabling obsolete crypto in 5.10 and later

On Wed, 10 Mar 2021 at 14:38, Salvatore Bonaccorso wrote: > > Hi Ard, > > On Tue, Mar 09, 2021 at 05:45:01PM +0100, Ard Biesheuvel wrote: > > On Thu, 25 Feb 2021 at 12:06, Ard Biesheuvel wrote: > > > > > > On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso

Re: please consider disabling obsolete crypto in 5.10 and later

On Thu, 25 Feb 2021 at 12:06, Ard Biesheuvel wrote: > > On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso wrote: > > > > Hi Ard, > > > > On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote: > > > Hi Ard, > > > > > > On Sa

Re: please consider disabling obsolete crypto in 5.10 and later

On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso wrote: > > Hi Ard, > > On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote: > > Hi Ard, > > > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote: > > > L.S., > > &g

Re: please consider disabling obsolete crypto in 5.10 and later

On Mon, 1 Feb 2021 at 22:21, Salvatore Bonaccorso wrote: > > Hi Ard, > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote: > > L.S., > > > > This is a request to consider disabling obsolete crypto in 5.10 and > > later Debian builds of

please consider disabling obsolete crypto in 5.10 and later

L.S., This is a request to consider disabling obsolete crypto in 5.10 and later Debian builds of the Linux kernel on any architecture. We are all familiar with the rigid rules when it comes to not breaking userspace by making changes to the kernel, but this rule only takes effect when anybody

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel wrote: > > On Sat, 16 Jan 2021 at 18:24, Diederik de Haas wrote: > > > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote: > > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds &g

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

On Sat, 16 Jan 2021 at 18:24, Diederik de Haas wrote: > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote: > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds > > Is there a reason why it shouldn't be included in armhf builds? If not, then

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

Package: src:linux Version: 5.10.4-1 Severity: normal Dear Maintainer, Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds of the Linux kernel. This allows platforms that do not support AES instructions (such as Raspberry Pi 3/4) to enable efficient block device encryption,

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

Hello Diederik, On Fri, 11 Dec 2020 at 12:21, Diederik de Haas wrote: > > On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel wrote: > > Currently, arm64 kernel packages are built with the following Kconfig > > symbols > unset: > > > > # CONF

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

Bug#948285: linux-image-4.19.0-6-arm64: please enable CONFIG_TCG_TIS for TPM support

Package: src:linux Version: 4.19.67-2+deb10u2 Severity: wishlist Dear Maintainer, The current buster kernel for arm64 lacks the TPM TIS module, which means it cannot use TPM based disk encryption using MMIO based TPM2 modules, which is for instance what QEMU emulates, and what TPM enabled

Bug#923723: Acknowledgement (linux: amdgpu/radeon driver optimization is broken on ARM/arm64)

The patch has been backported, and was released as part of v4.19.29

Bug#924456: linux-image-4.19.0-2-arm64: please enable accelerated arm64 crypto drivers

Package: src:linux Version: 4.19.16-1 Severity: normal Dear Maintainer, Please consider enabling the following Kconfig options for arm64 kernels CONFIG_CRYPTO_SHA256_ARM64=m CONFIG_CRYPTO_SHA512_ARM64=m CONFIG_CRYPTO_SHA512_ARM64_CE=m CONFIG_CRYPTO_SHA3_ARM64=m CONFIG_CRYPTO_SM3_ARM64_CE=m

Bug#924453: linux-image-4.19.0-2-arm64: please enable driver for AMD Seattle RNG

Package: src:linux Version: 4.19.16-1 Severity: normal Dear Maintainer, Please enable the following Kconfig options in the arm64 kernels: CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=m CONFIG_CRYPTO_DEV_SP_CCP=y CONFIG_CRYPTO_DEV_CCP_CRYPTO=m This is needed to gain access to the crypto

Bug#922204: linux-image-4.19.0-3-armmp-lpae: Kernel mode NEON support should be enabled

Package: linux-image-4.19.0-3-armmp-lpae Severity: important Dear Maintainer, Currently, the 32-bit ARM kernels are built without support for kernel mode NEON, which means that none of the modules that depend on it are built either. This mostly affects crypto drivers, as well as RAID6 and XOR.

Bug#920866: linux-source-4.19: arm64 kernel should have workaround for ARM Cortex-A53 erratum 843419 enabled

Package: linux-source-4.19 Severity: important Dear Maintainer, Currently, the linux-image-arm64 kernel is built with CONFIG_ARM64_ERRATUM_843419 explicitly disabled, while it defaults to on in the Kconfig definition. The GCC toolchain enables a link time workaround for this erratum, and so all

Bug#917608: linux-image-4.19.0-1-armmp-lpae: Please enable kernel-mode NEON

Package: src:linux Version: 4.19.12-1 Severity: important Dear Maintainer, Please enable CONFIG_KERNEL_MODE_NEON, at least for the LPAE version. This will automatically enable code paths for the XOR and RAID drivers, and permit the various accelerated crypto drivers in arch/arm/crypto to be

Bug#891787: linux-image-4.15.0-1-arm64: Socionext SynQuacer support not enabled

On 28 February 2018 at 20:43, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > Package: src:linux > Version: 4.15.4-1 > Severity: normal > > Dear Maintainer, > > Support for Socionext SynQuacer based platforms (a 24 core arm64 SoC) has > landed in v4.15 mainline.

Bug#891787: linux-image-4.15.0-1-arm64: Socionext SynQuacer support not enabled

Package: src:linux Version: 4.15.4-1 Severity: normal Dear Maintainer, Support for Socionext SynQuacer based platforms (a 24 core arm64 SoC) has landed in v4.15 mainline. Please enable this support in the Debian kernel as well: CONFIG_ARCH_SYNQUACER=y CONFIG_SNI_NETSEC=m

Bug#870071: linux-image-4.9.0-3-arm64: Kconfig option for console on frame buffer device is missing

Package: src:linux Version: 4.9.30-2+deb9u2 Severity: normal Dear Maintainer, Please enable CONFIG_FRAMEBUFFER_CONSOLE (preferably as a builtin) in the arm64's kernel image configuration so that systems with a graphics card installed can get a console on the frame buffer rather than only via

Bug#867611: linux-image-4.9.0-3-arm64: snd-hda-intel.ko module missing

Package: src:linux Version: 4.9.30-2+deb9u2 Severity: normal Dear Maintainer, Please consider adding CONFIG_SND_HDA_INTEL=m to the arm64 kernel config. -- Package-specific info: ** Version: Linux version 4.9.0-3-arm64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian

Bug#834505: arm64 boot failure with large physical memory range

On Sun, 21 Aug 2016 01:11:15 +0100 Ben Hutchings wrote: > On Fri, 2016-08-19 at 13:42 +0100, Leif Lindholm wrote: > > On Fri, Aug 19, 2016 at 12:50:49PM +0100, Ben Hutchings wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > everything