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

[Ard Biesheuvel]

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 -1 src:linux
> > > >
> > > > Hi,
> > > >
> > > > Le 2021-10-26 20:44, Zameer Manji a écrit :
> > > > > Package: linux-image-arm64
> > > > > Version: 5.14.9-2
> > > > > Severity: important
> > > > >
> > > > > Dear Maintainer,
> > > > >
> > > > > In bullseye, version 5.10.70-1 has the
> > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > > > > kernel configuration set to 'y'. In bookworm it is unset which disable
> > > > this feature.
> > > > >
> > > > > This kernel configuration parameter allows for the EFI stub of the
> > > > kernel to
> > > > > parse and use a 'initrd=' parameter to set up an initrd when booting
> > > > from EFI.
> > > > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if
> > > > configured
> > > > > to pass an initrd. If the kernel configuration parameter is unset, the
> > > > > `initrd=` paramater is ignored, and can result in an unbootable system
> > > > because
> > > > > the initrd has not setup the root filesystem.
> > > > >
> > > > > Without the kernel configuaration set, it is not possible to use
> > > > 'systemd-boot'
> > > > > or 'refind' on arm64 as both of these bootloaders assume the kernel 
> > > > > will
> > > > > handle the 'initrd=' flag and setup the initrd.
> > > > >
> > > > > Please consider enabling 
> > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> > > > > arm64 so using 'systemd-boot' or 'refind' can continue to work. Until
> > > > these
> > > > > bootloaders have been updated to use an alternative method of passing 
> > > > > the
> > > > > initrd to the EFI stub, it is not possible to have a booting system.
> > > >
> > > > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer 
> > > > enabled
> > > > by
> > > > default. Please see [1] for some details.
> > > >
> > > > Cheers,
> > > > Vincent
> > > >
> > > > [1]
> > > > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
> > > >
> > >
> > > Hello Vincent,
> > >
> > > I see and understand the rationale of upstream to deprecate this
> > > functionality.
> > > >From the commit you linked I see another commit [0] which says:
> > >
> > > > Loading an initrd passed via the kernel command line is deprecated: it
> > > > is limited to files that reside in the same volume as the one the kernel
> > > > itself was loaded from, and we have more flexible ways to achieve the
> > > > same. So make it configurable so new architectures can decide not to
> > > > enable it.
> > >
> > > I assume the 'more flexible ways' to do the same is referencing this
> > > feature [1]
> > > which is indeed more flexible. The problem is that the firmware/bootloader
> > > must
> > > support this new functionality, by populating the right EFI file with the
> > > right GUID.
> > >
> > > As far as I can see on arm64 there are three EFI bootloaders:
> > > * GRUB2
> > > * systemd-boot
> > > * refind
> > >
> > > Both systemd-boot and refind do not yet support this new mechanism,
> > > although I see
> > > that systemd has some unreleased code [2] to support the new way. I have
> > > not been
> > > able to test GRUB2 but my understanding is that this new method is still
> > > under active
> > > development [3].
> > >
> > > The problem is that upstream has deprecated this functionality by assuming
> > > the only
> > > active use was x86, but was completely possible to use it on arm64 (it
> > > works fine for me
> > > on bullseye). Since EFI bootloaders have not yet implemented the new way,
> > > and still
> > > rely on this deprecated method on all architectures, it results in
> > > unbootable systems
> > > on arm64.
> > >
> > > I would 100% think this should remain disabled on arm64 if most EFI
> > > bootloaders
> > > supported the new way, but unfortunately they do not.
> > >
> > > I hope you would consider enabling this kernel configuration for arm64
> > > until EFI
> > > bootloaders catch up to the recommended way.
> > >
> > >
> > > [0]
> > > https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
> > > [1]
> > > https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c
> > > [2]
> > > https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a
> > > [3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html
> >
> > Salvatore, I tend to agree with Zameer. I think we should explicitly enable
> > EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER until the support for loading initrd
> > from a device path is widespread among bootloaders.
>
> Yeah I guess it makes sense and understand. Before doing the switch
> and re-enabling it 

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

[Ard Biesheuvel]

On Wed, 13 Oct 2021 at 22:07, 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) 

For 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 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 91a502bb97e8..4fa6ff2b5cac 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -147,7 +147,15 @@ else
> cp System.map "$tmpdir/boot/System.map-$version"
> cp $KCONFIG_CONFIG "$tmpdir/boot/config-$version"
>  fi
> -cp "$($MAKE -s -f $srctree/Makefile image_name)" 
> "$tmpdir/$installed_image_path"
> +
> +vmlinux=$($MAKE -s -f $srctree/Makefile image_name)
> +if is_enabled CONFIG_MODULE_SIG; then
> +   cert=$srctree/$(grep ^CONFIG_MODULE_SIG_KEY= include/config/auto.conf 
> | cut -d\" -f2)
> +   key=${cert%pem}priv
> +   sbsign --key $key --cert $cert "$vmlinux" --output 
> "$tmpdir/$installed_image_path"
> +else
> +   cp "$vmlinux" "$tmpdir/$installed_image_path"
> +fi
>
>  if is_enabled CONFIG_OF_EARLY_FLATTREE; then
> # Only some architectures with OF support have this target
> --
> 2.32.0
>

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

[Ard Biesheuvel]

(+ 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, 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) 
> > > ---
> > >  scripts/package/builddeb | 10 +-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> > > index 91a502bb97e8..4fa6ff2b5cac 100755
> > > --- a/scripts/package/builddeb
> > > +++ b/scripts/package/builddeb
> > > @@ -147,7 +147,15 @@ else
> > > cp System.map "$tmpdir/boot/System.map-$version"
> > > cp $KCONFIG_CONFIG "$tmpdir/boot/config-$version"
> > >  fi
> > > -cp "$($MAKE -s -f $srctree/Makefile image_name)" 
> > > "$tmpdir/$installed_image_path"
> > > +
> > > +vmlinux=$($MAKE -s -f $srctree/Makefile image_name)
> > > +if is_enabled CONFIG_MODULE_SIG; then
> >
> > Shouldn't this be conditional on CONFIG_EFI as well?
>
> Maybe!  We're a long way outside my area of expertise.  I'm just chuffed
> I thought of using cut -d\" -f2.
>
> There should probably also be something conditional on sbsign actually
> being in $PATH, I guess?
>
> And I wasn't sure about putting all of this in builddeb -- does make
> rpm-pkg already have its own way of doing the same thing, or should this
> be somewhere more generic?
>

No, sbsign is Debian/Ubuntu specific. Fedora/Redhat uses something
else IIRC. But yes, it obviously helps if the tool exists.


> > > +   cert=$srctree/$(grep ^CONFIG_MODULE_SIG_KEY= 
> > > include/config/auto.conf | cut -d\" -f2)
> > > +   key=${cert%pem}priv
> > > +   sbsign --key $key --cert $cert "$vmlinux" --output 
> > > "$tmpdir/$installed_image_path"
> > > +else
> > > +   cp "$vmlinux" "$tmpdir/$installed_image_path"
> > > +fi
> > >
> > >  if is_enabled CONFIG_OF_EARLY_FLATTREE; then
> > > # Only some architectures with OF support have this target
> > > --
> > > 2.30.2
> > >

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

[Ard Biesheuvel]

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) 
> ---
>  scripts/package/builddeb | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 91a502bb97e8..4fa6ff2b5cac 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -147,7 +147,15 @@ else
> cp System.map "$tmpdir/boot/System.map-$version"
> cp $KCONFIG_CONFIG "$tmpdir/boot/config-$version"
>  fi
> -cp "$($MAKE -s -f $srctree/Makefile image_name)" 
> "$tmpdir/$installed_image_path"
> +
> +vmlinux=$($MAKE -s -f $srctree/Makefile image_name)
> +if is_enabled CONFIG_MODULE_SIG; then

Shouldn't this be conditional on CONFIG_EFI as well?

> +   cert=$srctree/$(grep ^CONFIG_MODULE_SIG_KEY= include/config/auto.conf 
> | cut -d\" -f2)
> +   key=${cert%pem}priv
> +   sbsign --key $key --cert $cert "$vmlinux" --output 
> "$tmpdir/$installed_image_path"
> +else
> +   cp "$vmlinux" "$tmpdir/$installed_image_path"
> +fi
>
>  if is_enabled CONFIG_OF_EARLY_FLATTREE; then
> # Only some architectures with OF support have this target
> --
> 2.30.2
>

Re: please consider disabling obsolete crypto in 5.10 and later

[Ard Biesheuvel]

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  
> > > 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.,
> > > > > >
> > > > > > 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 notices, and so I am proposing disabling some 
> > > > > > code
> > > > > > downstream before removing it entirely.
> > > > > >
> > > > > > 5.10 introduces a new Kconfig symbol
> > > > > >
> > > > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > > > > >
> > > > > > which is enabled by default, but depends on support for the AF_ALG
> > > > > > socket API being enabled. In turn, block ciphers that are obsolete 
> > > > > > and
> > > > > > unlikely to be used anywhere have been made to depend on this new
> > > > > > symbol.
> > > > > >
> > > > > > This means that these obsolete block ciphers will disappear entirely
> > > > > > when the AF_ALG socket API is omitted, but we can get rid of these
> > > > > > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > > > > > adding
> > > > > >
> > > > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > > > > >
> > > > > > to the kernel configs. Note that Fedora have already done so in 
> > > > > > release 33 [0]
> > > > > >
> > > > > > The block ciphers in question are RC4, Khazad, SEED, and
> > > > > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > > > > > to be used via the socket API (although a change was applied to
> > > > > > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > > > > > has already been pulled into bullseye afaik)
> > > > > >
> > > > > > Note that this is not a statement on whether these algorithms are
> > > > > > secure or not -there is simply no point in carrying and shipping 
> > > > > > code
> > > > > > that nobody uses or audits, but which can be autoloaded and 
> > > > > > exercised
> > > > > > via an unprivileged interface.
> > > > >
> > > > > FTR (posteriori), we tried that in
> > > > > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> > > > > (and is in the 5.10.12-1 upload to unstable).
> > > >
> > > > There were two reports which might be in the end related to that
> > > > change:
> > > >
> > > > https://bugs.debian.org/979764
> > > > https://bugs.debian.org/983508
> > > >
> > > > We have long that nfs-utils need to be updated, but the version was so
> > > > outdated, that progress on updating to a newer version stalled, and
> > > > could not be done in time for bulleye. Once bullseye is released I
> > > > guess this really needs to be prioritzed in some way.
> > > >
> > > > Ard, have you any insight in the above, so, should we revert the above
> > > > change for bullseye again?
> > > >
> > >
> > > Hello Salvatore,
> > >
> > > I think the issue is the patch below. Having something that requires
> > > RC4 and MD5 for security is an absolute joke in 2021, so I won't
> > > recommend you reverting it. Instead, you should really fix nfs-utils
> > > with priority.
> > >
> >
> > Any updates on this?
>
> Apologies for not replying earlier. I agree with you.
>
> Debian's nfs-utils situation is quite bad. As you might know we still
> ship 1.3.4, which at best is ancient with respect to upstream.  Worse,
> we cannot update it at this stage of the freeze (cf.
> https://release.debian.org/#release-dates).
>
> So I guess the only two options we have now is either to revert the
> above commit you think is the cause of the issues reported, or if this
> is feasible apply the needed changes for nfs-utils (if they can be
> determined and can be applied to the old version).
>

Reverting the patch in question in the distro kernel seems reasonable,
but please keep it as a downstream change only. Note that you will
also need to revert the CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE change,
or re-enable the ecb(arc4) driver in another way, because the NFS code
relies on RC4.

> After the Debian bullseye release it defintively needs to be a
> priority for nfs-utils to be rebased to 2.5.3 and later (and then in
> particular keep up with rebasing it, and not fall into the same issue
> again).
>

Re: please consider disabling obsolete crypto in 5.10 and later

[Ard Biesheuvel]

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 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 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 notices, and so I am proposing disabling some code
> > > > downstream before removing it entirely.
> > > >
> > > > 5.10 introduces a new Kconfig symbol
> > > >
> > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > > >
> > > > which is enabled by default, but depends on support for the AF_ALG
> > > > socket API being enabled. In turn, block ciphers that are obsolete and
> > > > unlikely to be used anywhere have been made to depend on this new
> > > > symbol.
> > > >
> > > > This means that these obsolete block ciphers will disappear entirely
> > > > when the AF_ALG socket API is omitted, but we can get rid of these
> > > > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > > > adding
> > > >
> > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > > >
> > > > to the kernel configs. Note that Fedora have already done so in release 
> > > > 33 [0]
> > > >
> > > > The block ciphers in question are RC4, Khazad, SEED, and
> > > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > > > to be used via the socket API (although a change was applied to
> > > > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > > > has already been pulled into bullseye afaik)
> > > >
> > > > Note that this is not a statement on whether these algorithms are
> > > > secure or not -there is simply no point in carrying and shipping code
> > > > that nobody uses or audits, but which can be autoloaded and exercised
> > > > via an unprivileged interface.
> > >
> > > FTR (posteriori), we tried that in
> > > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> > > (and is in the 5.10.12-1 upload to unstable).
> >
> > There were two reports which might be in the end related to that
> > change:
> >
> > https://bugs.debian.org/979764
> > https://bugs.debian.org/983508
> >
> > We have long that nfs-utils need to be updated, but the version was so
> > outdated, that progress on updating to a newer version stalled, and
> > could not be done in time for bulleye. Once bullseye is released I
> > guess this really needs to be prioritzed in some way.
> >
> > Ard, have you any insight in the above, so, should we revert the above
> > change for bullseye again?
> >
>
> Hello Salvatore,
>
> I think the issue is the patch below. Having something that requires
> RC4 and MD5 for security is an absolute joke in 2021, so I won't
> recommend you reverting it. Instead, you should really fix nfs-utils
> with priority.
>

Any updates on this?

Re: please consider disabling obsolete crypto in 5.10 and later

[Ard Biesheuvel]

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.,
> > >
> > > 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 notices, and so I am proposing disabling some code
> > > downstream before removing it entirely.
> > >
> > > 5.10 introduces a new Kconfig symbol
> > >
> > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > >
> > > which is enabled by default, but depends on support for the AF_ALG
> > > socket API being enabled. In turn, block ciphers that are obsolete and
> > > unlikely to be used anywhere have been made to depend on this new
> > > symbol.
> > >
> > > This means that these obsolete block ciphers will disappear entirely
> > > when the AF_ALG socket API is omitted, but we can get rid of these
> > > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > > adding
> > >
> > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > >
> > > to the kernel configs. Note that Fedora have already done so in release 
> > > 33 [0]
> > >
> > > The block ciphers in question are RC4, Khazad, SEED, and
> > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > > to be used via the socket API (although a change was applied to
> > > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > > has already been pulled into bullseye afaik)
> > >
> > > Note that this is not a statement on whether these algorithms are
> > > secure or not -there is simply no point in carrying and shipping code
> > > that nobody uses or audits, but which can be autoloaded and exercised
> > > via an unprivileged interface.
> >
> > FTR (posteriori), we tried that in
> > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> > (and is in the 5.10.12-1 upload to unstable).
>
> There were two reports which might be in the end related to that
> change:
>
> https://bugs.debian.org/979764
> https://bugs.debian.org/983508
>
> We have long that nfs-utils need to be updated, but the version was so
> outdated, that progress on updating to a newer version stalled, and
> could not be done in time for bulleye. Once bullseye is released I
> guess this really needs to be prioritzed in some way.
>
> Ard, have you any insight in the above, so, should we revert the above
> change for bullseye again?
>

Hello Salvatore,

I think the issue is the patch below. Having something that requires
RC4 and MD5 for security is an absolute joke in 2021, so I won't
recommend you reverting it. Instead, you should really fix nfs-utils
with priority.

-- 
Ard.




commit e33d2a7b3041d7f8cd1f0a2a4ca42a5bc112b14e
Author: Ard Biesheuvel 
Date:   Mon Aug 31 18:16:45 2020 +0300

SUNRPC: remove RC4-HMAC-MD5 support from KerberosV

The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
was specifically issued for interoperability with Windows 2000, but was
never intended to receive the same level of support. The RFC says

  The IETF Kerberos community supports publishing this specification as
  an informational document in order to describe this widely
  implemented technology.  However, while these encryption types
  provide the operations necessary to implement the base Kerberos
  specification [RFC4120], they do not provide all the required
  operations in the Kerberos cryptography framework [RFC3961].  As a
  result, it is not generally possible to implement potential
  extensions to Kerberos using these encryption types.  The Kerberos
  encryption type negotiation mechanism [RFC4537] provides one approach
  for using such extensions even when a Kerberos infrastructure uses
  long-term RC4 keys.  Because this specification does not implement
  operations required by RFC 3961 and because of security concerns with
  the use of RC4 and MD4 discussed in Section 8, this specification is
  not appropriate for publication on the standards track.

  The RC4-HMAC encryption types are used to ease upgrade of existing
  Windows NT environments, provide strong cryptography (128-bit key
 

Re: please consider disabling obsolete crypto in 5.10 and later

[Ard Biesheuvel]

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 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 notices, and so I am proposing disabling some code
> > downstream before removing it entirely.
> >
> > 5.10 introduces a new Kconfig symbol
> >
> > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> >
> > which is enabled by default, but depends on support for the AF_ALG
> > socket API being enabled. In turn, block ciphers that are obsolete and
> > unlikely to be used anywhere have been made to depend on this new
> > symbol.
> >
> > This means that these obsolete block ciphers will disappear entirely
> > when the AF_ALG socket API is omitted, but we can get rid of these
> > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > adding
> >
> > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> >
> > to the kernel configs. Note that Fedora have already done so in release 33 
> > [0]
> >
> > The block ciphers in question are RC4, Khazad, SEED, and
> > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > to be used via the socket API (although a change was applied to
> > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > has already been pulled into bullseye afaik)
> >
> > Note that this is not a statement on whether these algorithms are
> > secure or not -there is simply no point in carrying and shipping code
> > that nobody uses or audits, but which can be autoloaded and exercised
> > via an unprivileged interface.
>
> FTR (posteriori), we tried that in
> https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> (and is in the 5.10.12-1 upload to unstable).
>

Confirmed, thanks.

please consider disabling obsolete crypto in 5.10 and later

[Ard Biesheuvel]

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 notices, and so I am proposing disabling some code
downstream before removing it entirely.

5.10 introduces a new Kconfig symbol

CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE

which is enabled by default, but depends on support for the AF_ALG
socket API being enabled. In turn, block ciphers that are obsolete and
unlikely to be used anywhere have been made to depend on this new
symbol.

This means that these obsolete block ciphers will disappear entirely
when the AF_ALG socket API is omitted, but we can get rid of these
block ciphers explicitly too, by not setting the new symbol. I.e.,
adding

# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set

to the kernel configs. Note that Fedora have already done so in release 33 [0]

The block ciphers in question are RC4, Khazad, SEED, and
TEA/XTEA/XETA, none of which are used by the kernel itself, or known
to be used via the socket API (although a change was applied to
iwd/libell recently to get rid of an occurrence of RC4 - this change
has already been pulled into bullseye afaik)

Note that this is not a statement on whether these algorithms are
secure or not -there is simply no point in carrying and shipping code
that nobody uses or audits, but which can be autoloaded and exercised
via an unprivileged interface.

--
Ard.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=f33

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

[Ard Biesheuvel]

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
> >
> > Is there a reason why it shouldn't be included in armhf builds? If not, then
> > I'd like to see it enabled there too.
> > (And possibly in linux-image-rpi on armel as well?)
>
> Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled
> on those platforms too. For armel, it depends on whether kernel mode
> NEON is already enabled in the first place.

This is enabled now for armhf but not for arm64:

linux-signed-arm64 (5.10.9+1) unstable; urgency=medium
...
* [arm] Enable CRYPTO_NHPOLY1305_NEON. (closes: #980214)

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

[Ard Biesheuvel]

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
> I'd like to see it enabled there too.
> (And possibly in linux-image-rpi on armel as well?)

Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled
on those platforms too. For armel, it depends on whether kernel mode
NEON is already enabled in the first place.

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

[Ard Biesheuvel]

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, using
the 'adiantum' template.

Kind regards,
Ard.


-- Package-specific info:
** Version:
Linux version 5.10.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 
10.2.1-3) 10.2.1 20201224, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.10.4-1 (2020-12-31)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-1-arm64 
root=UUID=62fa7565-f531-4b0f-9311-59cb70ba2c93 ro quiet

** Not tainted

** Kernel log:
[3.87] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, 
bcdDevice= 5.10
[3.822239] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[3.822247] usb usb1: Product: xHCI Host Controller
[3.822254] usb usb1: Manufacturer: Linux 5.10.0-1-arm64 xhci-hcd
[3.822261] usb usb1: SerialNumber: PNP0D10:00
[3.822910] hub 1-0:1.0: USB hub found
[3.822979] hub 1-0:1.0: 1 port detected
[3.823542] xhci-hcd PNP0D10:00: xHCI Host Controller
[3.823572] xhci-hcd PNP0D10:00: new USB bus registered, assigned bus number 
2
[3.823591] xhci-hcd PNP0D10:00: Host supports USB 3.0 SuperSpeed
[3.823752] usb usb2: We don't know the algorithms for LPM for this host, 
disabling LPM.
[3.823936] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, 
bcdDevice= 5.10
[3.823945] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[3.823953] usb usb2: Product: xHCI Host Controller
[3.823960] usb usb2: Manufacturer: Linux 5.10.0-1-arm64 xhci-hcd
[3.823966] usb usb2: SerialNumber: PNP0D10:00
[3.824623] hub 2-0:1.0: USB hub found
[3.824677] hub 2-0:1.0: 4 ports detected
[3.838859] bcmgenet BCM6E4E:00 enabcm6e4ei0: renamed from eth0
[4.157943] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[4.312580] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, 
bcdDevice= 4.21
[4.312595] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[4.312603] usb 1-1: Product: USB2.0 Hub
[4.314265] hub 1-1:1.0: USB hub found
[4.314540] hub 1-1:1.0: 4 ports detected
[4.438232] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[4.460809] usb 2-2: New USB device found, idVendor=18a5, idProduct=0237, 
bcdDevice= 5.10
[4.460819] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4.460827] usb 2-2: Product: Portable USB 3.0 Drive
[4.460835] usb 2-2: Manufacturer: Verbatim
[4.460842] usb 2-2: SerialNumber: 1407010003245394
[4.498931] SCSI subsystem initialized
[4.513467] usb-storage 2-2:1.0: USB Mass Storage device detected
[4.514813] scsi host0: usb-storage 2-2:1.0
[4.515356] usbcore: registered new interface driver usb-storage
[4.520563] usbcore: registered new interface driver uas
[4.673929] libphy: bcmgenet MII bus: probed
[4.673945] unimac-mdio unimac-mdio: Broadcom UniMAC MDIO bus
[5.535323] scsi 0:0:0:0: Direct-Access Samsung  SSD 850 PRO  EXM0 
PQ: 0 ANSI: 6
[5.556933] sd 0:0:0:0: [sda] 500118188 512-byte logical blocks: (256 GB/238 
GiB)
[5.557351] sd 0:0:0:0: [sda] Write Protect is off
[5.557362] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[5.557768] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[5.576531]  sda: sda1 sda2
[5.578991] sd 0:0:0:0: [sda] Attached SCSI disk
[5.612373] random: fast init done
[6.084383] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
(null)
[6.358453] Not activating Mandatory Access Control as /sbin/tomoyo-init 
does not exist.
[6.530927] systemd[1]: Inserted module 'autofs4'
[6.593403] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[6.594215] systemd[1]: Detected architecture arm64.
[6.622998] systemd[1]: Set hostname to .
[7.062138] random: systemd: uninitialized urandom read (16 bytes read)
[7.067659] random: systemd: uninitialized urandom read (16 bytes read)
[7.071927] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[7.072502] random: systemd: uninitialized urandom read (16 bytes read)
[7.072985] systemd[1]: Listening on Journal Audit Socket.
[7.073615] systemd[1]: Listening on Journal Socket (/dev/log).
[7.075141] systemd[1]: Created slice system-serial\x2dgetty.slice.
[7.076570] systemd[1]: Created slice User and Session Slice.
[7.076698] systemd[1]: Reached target Slices.
[7.077261] systemd[1]: Listening on udev Kernel Socket.
[7.230826] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[

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

[Ard Biesheuvel]

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:
> >
> > # 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/
> 8332600d1188a6d1fc835dfcd392a20f6bfc
>

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)

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

[Ard Biesheuvel]

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

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

[Ard Biesheuvel]

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 versions of the SynQuacer
platform implement.

So please consider enabling CONFIG_TCG_TIS as a module for upcoming builds of
the arm64 buster kernel.

Thanks,
Ard.




-- Package-specific info:
** Version:
Linux version 4.19.0-6-arm64 (debian-kernel@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-arm64 
root=UUID=dc66b395-cdab-4e57-bf1f-a47424c22356 ro quiet

** Not tainted

** Kernel log:
[6.369402] EFI Variables Facility v0.08 2004-May-17
[6.369556] sbsa-gwdt sbsa-gwdt.0: Initialized with 10s timeout @ 25000 
Hz, action=0.
[6.371101] iommu: Adding device AMDI8001:00 to group 3
[6.372295] amd-xgbe AMDI8001:00 eth0: net device enabled
[6.372372] iommu: Adding device AMDI8001:01 to group 4
[6.373313] amd-xgbe AMDI8001:01 eth1: net device enabled
[6.375529] input: Apple Inc. Apple Keyboard as 
/devices/pci:00/:00:02.1/:01:00.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:024F.0002/input/input1
[6.376687] pstore: Using compression: deflate
[6.376937] amd-xgbe AMDI8001:01 enaamdi8001i1: renamed from eth1
[6.379768] pstore: Registered efi as persistent store backend
[6.394731] cryptd: max_cpu_qlen set to 1000
[6.402817] iommu: Adding device :02:00.1 to group 0
[6.402964] snd_hda_intel :02:00.1: enabling device ( -> 0002)
[6.402971] snd_hda_intel :02:00.1: Force to snoop mode by module option
[6.408829] amd-xgbe AMDI8001:00 enaamdi8001i0: renamed from eth0
[6.424808] input: HDA ATI HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.2/:02:00.1/sound/card0/input2
[6.436839] apple 0003:05AC:024F.0002: input,hidraw1: USB HID v1.11 Keyboard 
[Apple Inc. Apple Keyboard] on usb-:01:00.0-1.2/input0
[6.437222] input: Apple Inc. Apple Keyboard as 
/devices/pci:00/:00:02.1/:01:00.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:024F.0003/input/input3
[6.496678] apple 0003:05AC:024F.0003: input,hidraw2: USB HID v1.11 Device 
[Apple Inc. Apple Keyboard] on usb-:01:00.0-1.2/input1
[6.521677] Adding 781308k swap on /dev/sda3.  Priority:-2 extents:1 
across:781308k SSFS
[6.575867] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[6.655568] audit: type=1400 audit(1578038684.964:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=500 comm="apparmor_parser"
[6.656045] audit: type=1400 audit(1578038684.964:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=495 comm="apparmor_parser"
[6.656505] audit: type=1400 audit(1578038684.964:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=497 comm="apparmor_parser"
[6.656634] audit: type=1400 audit(1578038684.968:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=501 
comm="apparmor_parser"
[6.656640] audit: type=1400 audit(1578038684.968:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=501 comm="apparmor_parser"
[6.658207] audit: type=1400 audit(1578038684.968:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=502 comm="apparmor_parser"
[6.659469] audit: type=1400 audit(1578038684.968:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=504 
comm="apparmor_parser"
[6.659474] audit: type=1400 audit(1578038684.968:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=504 
comm="apparmor_parser"
[6.659478] audit: type=1400 audit(1578038684.968:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=504 
comm="apparmor_parser"
[6.660845] audit: type=1400 audit(1578038684.972:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=498 comm="apparmor_parser"
[7.364023] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i0: link is not ready
[7.406593] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i0: link is not ready
[7.411687] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i1: link is not ready
[7.449215] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i1: link is not ready
[8.420522] amd-xgbe AMDI8001:00 enaamdi8001i0: Link is Up - 1Gbps/Full - 
flow control off
[8.420540] IPv6: ADDRCONF(NETDEV_CHANGE): enaamdi8001i0: link becomes ready
[   13.456021] random: crng init done
[   13.456025] random: 7 urandom warning(s) missed due to ratelimiting
[   46.811694] fuse init 

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

[Ard Biesheuvel]

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

[Ard Biesheuvel]

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
CONFIG_CRYPTO_SM4_ARM64_CE=m
CONFIG_CRYPTO_AES_ARM64=m
CONFIG_CRYPTO_AES_ARM64_NEON_BLK=m
CONFIG_CRYPTO_CHACHA20_NEON=m
CONFIG_CRYPTO_NHPOLY1305_NEON=m
CONFIG_CRYPTO_AES_ARM64_BS=m

and if appropriate

CONFIG_CRYPTO_CRCT10DIF_ARM64_CE=m

(which depends on whether T10DIF support is enabled)

Note that in the case of AES, this is not just a matter of performance - NEON
and bit sliced AES routines implement the AES cipher in a time invariant
matter, and so without them, arm64 CPUs that do not implement the crypto
extensions (such as the Raspberry Pi3) are forced to fall back on the generic,
table based C implementation.




-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.0.1+ (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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)

Versions of packages linux-image-4.19.0-2-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod26-1
ii  linux-base  4.5

Versions of packages linux-image-4.19.0-2-arm64 recommends:
ii  apparmor 2.13.2-9
pn  firmware-linux-free  
pn  irqbalance   

Versions of packages linux-image-4.19.0-2-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-2-arm64 is related to:
ii  firmware-amd-graphics 20190114-1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

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

[Ard Biesheuvel]

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 accelerator in the ARM Seattle
arm64 SoC, which also implements the platform's random number generator. Since
the platform does not have any other entropy sources, the lack of access to the
on-SoC RNG causes boot delays, SSH logins that time out etc etc



-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.0.1+ (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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)

Versions of packages linux-image-4.19.0-2-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod26-1
ii  linux-base  4.5

Versions of packages linux-image-4.19.0-2-arm64 recommends:
ii  apparmor 2.13.2-9
pn  firmware-linux-free  
pn  irqbalance   

Versions of packages linux-image-4.19.0-2-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-2-arm64 is related to:
ii  firmware-amd-graphics 20190114-1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

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

[Ard Biesheuvel]

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. This is mostly a
performance problem, although the fact that the non-NEON AES is not time
invariant implies that systems may be susceptible to cache timing attacks
needlessly.

Note that there is also a runtime check, so even with
CONFIG_KERNEL_MODE_NEON=y, systems without a NEON implementation will still run
as before.

The XOR and RAID6 code will automatically be built with NEON support once the
CONFIG_KERNEL_MODE_NEON option is set. For the crypto part, the following ones
should be set to =m as well. (The CE ones rely on ARMv8 crypto instructions so
they are not as relevant, but they can easily be enabled at the same time)

config CRYPTO_SHA1_ARM_NEON
config CRYPTO_AES_ARM_BS
config CRYPTO_CHACHA20_NEON

config CRYPTO_SHA1_ARM_CE
config CRYPTO_SHA2_ARM_CE
config CRYPTO_AES_ARM_CE
config CRYPTO_GHASH_ARM_CE
config CRYPTO_CRCT10DIF_ARM_CE
config CRYPTO_CRC32_ARM_CE

Note that this applies equally to the non-LPAE configuration.



-- System Information:
Debian Release: 9.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.0.0-rc6+ (SMP w/24 CPU cores; PREEMPT)
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 /bin/dash
Init: systemd (via /run/systemd/system)

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

[Ard Biesheuvel]

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 fully linked binaries such as userland executables and shared
libraries, as well as the core kernel (vmlinux), are built with
mitigations that prevent this erratum from being triggered. However,
kernel modules are not fully linked binaries (they are partially linked
object files), and so without this CONFIG option enabled, the resulting
modules may trigger the erratum and crash or corrupt data (or both).

Note that the Cortex-A53 used in the Raspberry Pi 3 is affected by this
erratum.

So please enable CONFIG_ARM64_ERRATUM_843419.

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

Kernel: Linux 5.0.0-rc4+ (SMP w/24 CPU cores; PREEMPT)
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-source-4.19 depends on:
ii  binutils  2.28-5
ii  xz-utils  5.2.2-1.2+b1

Versions of packages linux-source-4.19 recommends:
ii  bc1.06.95-9+b3
ii  gcc   4:6.3.0-4
ii  libc6-dev [libc-dev]  2.24-11+deb9u3
pn  linux-config-4.19 
ii  make  4.1-9.1

Versions of packages linux-source-4.19 suggests:
ii  libncurses5-dev [ncurses-dev]  6.0+20161126-1+deb9u2
pn  libqt4-dev 
ii  pkg-config 0.29-4+b1

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

[Ard Biesheuvel]

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 enabled as well, including the ones that use special crypto
instructions, which are typically 5x - 20x faster (depending on the
particular algorithm)

-- Package-specific info:
** Version:
Linux version 4.19.0-1-armmp-lpae (debian-kernel@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-12)) #1 SMP Debian 4.19.12-1 (2018-12-22)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-armmp-lpae 
root=UUID=aaabcf58-4f83-485b-9461-15abd2fd4437 ro quiet

** Not tainted

** Kernel log:

** Model information
[6.007886] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[6.007890] usb usb2: Product: xHCI Host Controller
[6.007895] usb usb2: Manufacturer: Linux 4.19.0-1-armmp-lpae xhci-hcd
[6.007900] usb usb2: SerialNumber: :00:01.0
[6.008357] hub 2-0:1.0: USB hub found
[6.008447] hub 2-0:1.0: 4 ports detected
[6.061319] virtio_blk virtio0: [vda] 67108864 512-byte logical blocks (34.4 
GB/32.0 GiB)
[6.063807]  vda: vda1 vda2
[6.066318] virtio_net virtio1 enp0s3: renamed from eth0
[6.289595] EXT4-fs (vda2): mounted filesystem with ordered data mode. Opts: 
(null)
[6.349208] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[6.466139] random: fast init done
[6.499430] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, 
bcdDevice= 0.00
[6.499439] usb 1-1: New USB device strings: Mfr=1, Product=4, SerialNumber=5
[6.499444] usb 1-1: Product: QEMU USB Keyboard
[6.499449] usb 1-1: Manufacturer: QEMU
[6.499453] usb 1-1: SerialNumber: 42
[6.629264] usb 1-2: new high-speed USB device number 3 using xhci_hcd
[6.629836] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[6.629941] systemd[1]: Detected virtualization kvm.
[6.629960] systemd[1]: Detected architecture arm.
[6.641065] systemd[1]: Set hostname to .
[6.778423] usb 1-2: New USB device found, idVendor=0627, idProduct=0001, 
bcdDevice= 0.00
[6.778432] usb 1-2: New USB device strings: Mfr=1, Product=3, SerialNumber=5
[6.778437] usb 1-2: Product: QEMU USB Tablet
[6.778441] usb 1-2: Manufacturer: QEMU
[6.778446] usb 1-2: SerialNumber: 42
[7.017476] random: systemd: uninitialized urandom read (16 bytes read)
[7.021828] systemd[1]: Created slice User and Session Slice.
[7.022272] random: systemd: uninitialized urandom read (16 bytes read)
[7.022799] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[7.022920] random: systemd: uninitialized urandom read (16 bytes read)
[7.023111] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[7.025094] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[7.025279] systemd[1]: Reached target Swap.
[7.025918] systemd[1]: Listening on Journal Audit Socket.
[7.127876] EXT4-fs (vda2): re-mounted. Opts: errors=remount-ro
[7.238072] systemd-journald[211]: Received request to flush runtime journal 
from PID 1
[7.745992] EFI Variables Facility v0.08 2004-May-17
[7.765948] random: crng init done
[7.765957] random: 7 urandom warning(s) missed due to ratelimiting
[7.889152] hidraw: raw HID events driver (C) Jiri Kosina
[7.891705] [drm] pci: virtio-gpu-pci detected at :00:05.0
[7.894015] [drm] virgl 3d acceleration enabled
[7.897229] [TTM] Zone  kernel: Available graphics memory: 362162 kiB
[7.897235] [TTM] Zone highmem: Available graphics memory: 2526942 kiB
[7.897254] [TTM] Initializing pool allocator
[7.897302] [TTM] Initializing DMA pool allocator
[7.897397] [drm] number of scanouts: 1
[7.897413] [drm] number of cap sets: 1
[7.935766] [drm] cap set 0: id 1, max-version 1, max-size 308
[7.941395] usbcore: registered new interface driver usbhid
[7.941400] usbhid: USB HID core driver
[7.960197] Console: switching to colour frame buffer device 128x48
[8.031802] input: QEMU QEMU USB Keyboard as 
/devices/platform/3f00.pcie/pci:00/:00:01.0/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input1
[8.041530] virtio_gpu virtio3: fb0: virtiodrmfb frame buffer device
[8.077273] [drm] Initialized virtio_gpu 0.0.1 0 for virtio3 on minor 0
[8.115421] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v1.11 
Keyboard [QEMU QEMU USB Keyboard] on usb-:00:01.0-1/input0
[8.116205] input: QEMU QEMU USB Tablet as 
/devices/platform/3f00.pcie/pci:00/:00:01.0/usb1/1-2/1-2:1.0/0003:0627:0001.0002/input/input2
[8.116919] 

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

[Ard Biesheuvel]

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.
>
> Please enable this support in the Debian kernel as well:
> CONFIG_ARCH_SYNQUACER=y
> CONFIG_SNI_NETSEC=m
> CONFIG_MMC_SDHCI_F_SDH30=m
> CONFIG_GPIO_MB86S7X=m
>

Actually, NETSEC support did not make it into v4.15 after all but was
pulled into v4.16 instead.

The SoC has PCIe support, so it can be used with PCIe NICs instead,
and so it would still be useful to enable the other pieces.

Thanks,
Ard.

>
> -- Package-specific info:
> ** Version:
> Linux version 4.15.0-1-arm64 (debian-kernel@lists.debian.org) (gcc version 
> 7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18)
>
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.15.0-1-arm64 
> root=UUID=4e4cd64e-fe66-44c6-ae59-4c8f8fada27d ro earlycon
>
> ** Tainted: O (4096)
>  * Out-of-tree module has been loaded.
>
> ** Kernel log:
> [2.572430] pci 0001:00:00.0: BAR 0: assigned [mem 
> 0x3f-0x3f3fff 64bit]
> [2.580576] vgaarb: loaded
> [2.583622] EDAC MC: Ver: 3.0.0
> [2.587045] dmi: Firmware registration failed.
> [2.591498] Registered efivars operations
> [2.597581] clocksource: Switched to clocksource arch_sys_counter
> [2.647787] VFS: Disk quotas dquot_6.6.0
> [2.651808] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [2.659117] AppArmor: AppArmor Filesystem Enabled
> [2.663943] pnp: PnP ACPI init
> [2.710945] system 00:00: [mem 0x7000-0x77ef] could not be reserved
> [2.717930] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
> [2.717941] pnp: PnP ACPI: found 1 devices
> [2.728872] NET: Registered protocol family 2
> [2.733841] TCP established hash table entries: 32768 (order: 6, 262144 
> bytes)
> [2.741430] TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
> [2.748510] TCP: Hash tables configured (established 32768 bind 32768)
> [2.755274] UDP hash table entries: 2048 (order: 4, 65536 bytes)
> [2.761390] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
> [2.768200] NET: Registered protocol family 1
> [2.772594] PCI: CLS 0 bytes, default 128
> [2.772776] Unpacking initramfs...
> [3.775379] Freeing initrd memory: 18460K
> [3.781356] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 
> counters available
> [3.789398] kvm [1]: 8-bit VMID
> [3.792543] kvm [1]: IDMAP page: 808b2000
> [3.796551] kvm [1]: HYP VA range: 8000:
> [3.803083] kvm [1]: vgic-v2@2c02
> [3.806800] kvm [1]: GIC system register CPU interface enabled
> [3.813166] kvm [1]: vgic interrupt IRQ1
> [3.817109] kvm [1]: virtual timer IRQ3
> [3.821557] kvm [1]: Hyp mode initialized successfully
> [3.830044] Initialise system trusted keyrings
> [3.834634] workingset: timestamp_bits=44 max_order=20 bucket_order=0
> [3.845934] zbud: loaded
> [5.139407] Key type asymmetric registered
> [5.143515] Asymmetric key parser 'x509' registered
> [5.148554] Block layer SCSI generic (bsg) driver version 0.4 loaded 
> (major 246)
> [5.156157] io scheduler noop registered
> [5.160090] io scheduler deadline registered
> [5.164583] io scheduler cfq registered (default)
> [5.169289] io scheduler mq-deadline registered
> [5.177066] ACPI GTDT: found 1 SBSA generic Watchdog(s).
> [5.183192] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [5.190393] Serial: AMBA driver
> [5.193625] msm_serial: driver initialized
> [5.198236] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [5.204767] mousedev: PS/2 mouse device common for all mice
> [5.211741] ledtrig-cpu: registered to indicate activity on CPUs
> [5.217772] dmi-sysfs: dmi entry is absent.
> [5.222849] NET: Registered protocol family 10
> [5.240755] Segment Routing with IPv6
> [5.244479] mip6: Mobile IPv6
> [5.247452] NET: Registered protocol family 17
> [5.251904] mpls_gso: MPLS GSO support
> [5.256247] registered taskstats version 1
> [5.260351] Loading compiled-in X.509 certificates
> [5.426174] Loaded X.509 cert 'Debian Project: Ben Hutchings: 
> 008a018dca80932630'
> [5.433813] zswap: loaded using pool lzo/zbud
> [5.438349] AppArmor: AppArmor sha1 policy hashing enabled
> [5.443843] ima: No TPM chip found, activating TPM-bypass! (rc=-19)
> [5.450360] hctosys: unable to open rtc device (rtc0)
> [5.466502] Freeing unused kernel memory: 454

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

[Ard Biesheuvel]

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
CONFIG_MMC_SDHCI_F_SDH30=m
CONFIG_GPIO_MB86S7X=m


-- Package-specific info:
** Version:
Linux version 4.15.0-1-arm64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0-1-arm64 
root=UUID=4e4cd64e-fe66-44c6-ae59-4c8f8fada27d ro earlycon

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[2.572430] pci 0001:00:00.0: BAR 0: assigned [mem 0x3f-0x3f3fff 
64bit]
[2.580576] vgaarb: loaded
[2.583622] EDAC MC: Ver: 3.0.0
[2.587045] dmi: Firmware registration failed.
[2.591498] Registered efivars operations
[2.597581] clocksource: Switched to clocksource arch_sys_counter
[2.647787] VFS: Disk quotas dquot_6.6.0
[2.651808] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[2.659117] AppArmor: AppArmor Filesystem Enabled
[2.663943] pnp: PnP ACPI init
[2.710945] system 00:00: [mem 0x7000-0x77ef] could not be reserved
[2.717930] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[2.717941] pnp: PnP ACPI: found 1 devices
[2.728872] NET: Registered protocol family 2
[2.733841] TCP established hash table entries: 32768 (order: 6, 262144 
bytes)
[2.741430] TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
[2.748510] TCP: Hash tables configured (established 32768 bind 32768)
[2.755274] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[2.761390] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[2.768200] NET: Registered protocol family 1
[2.772594] PCI: CLS 0 bytes, default 128
[2.772776] Unpacking initramfs...
[3.775379] Freeing initrd memory: 18460K
[3.781356] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters 
available
[3.789398] kvm [1]: 8-bit VMID
[3.792543] kvm [1]: IDMAP page: 808b2000
[3.796551] kvm [1]: HYP VA range: 8000:
[3.803083] kvm [1]: vgic-v2@2c02
[3.806800] kvm [1]: GIC system register CPU interface enabled
[3.813166] kvm [1]: vgic interrupt IRQ1
[3.817109] kvm [1]: virtual timer IRQ3
[3.821557] kvm [1]: Hyp mode initialized successfully
[3.830044] Initialise system trusted keyrings
[3.834634] workingset: timestamp_bits=44 max_order=20 bucket_order=0
[3.845934] zbud: loaded
[5.139407] Key type asymmetric registered
[5.143515] Asymmetric key parser 'x509' registered
[5.148554] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
246)
[5.156157] io scheduler noop registered
[5.160090] io scheduler deadline registered
[5.164583] io scheduler cfq registered (default)
[5.169289] io scheduler mq-deadline registered
[5.177066] ACPI GTDT: found 1 SBSA generic Watchdog(s).
[5.183192] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[5.190393] Serial: AMBA driver
[5.193625] msm_serial: driver initialized
[5.198236] cacheinfo: Unable to detect cache hierarchy for CPU 0
[5.204767] mousedev: PS/2 mouse device common for all mice
[5.211741] ledtrig-cpu: registered to indicate activity on CPUs
[5.217772] dmi-sysfs: dmi entry is absent.
[5.222849] NET: Registered protocol family 10
[5.240755] Segment Routing with IPv6
[5.244479] mip6: Mobile IPv6
[5.247452] NET: Registered protocol family 17
[5.251904] mpls_gso: MPLS GSO support
[5.256247] registered taskstats version 1
[5.260351] Loading compiled-in X.509 certificates
[5.426174] Loaded X.509 cert 'Debian Project: Ben Hutchings: 
008a018dca80932630'
[5.433813] zswap: loaded using pool lzo/zbud
[5.438349] AppArmor: AppArmor sha1 policy hashing enabled
[5.443843] ima: No TPM chip found, activating TPM-bypass! (rc=-19)
[5.450360] hctosys: unable to open rtc device (rtc0)
[5.466502] Freeing unused kernel memory: 4544K
[5.608443] nvme nvme0: pci function 0001:00:00.0
[5.871879] blk_queue_max_hw_sectors: set to minimum 8
[5.890416] blk_queue_max_hw_sectors: set to minimum 8
[5.905751]  nvme0n1: p1 p2 p3 p4
[6.706212] PM: Starting manual resume from disk
[6.711061] PM: Image not found (code -22)
[6.842702] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. 
Opts: (null)
[7.020882] systemd[1]: System time before build time, advancing clock.
[7.045997] ip_tables: (C) 2000-2006 Netfilter Core Team
[7.071928] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[7.090621] systemd[1]: Detected architecture arm64.
[

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

[Ard Biesheuvel]

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 serial.

-- Package-specific info:
** Version:
Linux version 4.9.0-3-arm64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-arm64 
root=UUID=f3b7c265-d79f-4dce-8c44-d6120d9111e7 ro console=ttyAMA0 console=tty0

** Not tainted

** Kernel log:
[2.477111] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[2.631395] usb 1-1: New USB device found, idVendor=05ac, idProduct=1006
[2.638097] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2.645227] usb 1-1: Product: Keyboard Hub
[2.649319] usb 1-1: Manufacturer: Apple, Inc.
[2.653757] usb 1-1: SerialNumber: 
[2.660074] hub 1-1:1.0: USB hub found
[2.664135] hub 1-1:1.0: 3 ports detected
[2.783268] ata2: SATA link down (SStatus 0 SControl 300)
[2.957106] usb 1-1.1: new low-speed USB device number 3 using xhci_hcd
[3.072863] usb 1-1.1: New USB device found, idVendor=413c, idProduct=3012
[3.079735] usb 1-1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[3.087042] usb 1-1.1: Product: Dell USB Optical Mouse
[3.092175] usb 1-1.1: Manufacturer: Dell
[3.100842] hidraw: raw HID events driver (C) Jiri Kosina
[3.103266] ata3: SATA link down (SStatus 0 SControl 300)
[3.115764] usbcore: registered new interface driver usbhid
[3.121341] usbhid: USB HID core driver
[3.125960] input: Dell Dell USB Optical Mouse as 
/devices/platform/smb/f000.pcie/pci:00/:00:02.2/:02:00.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:413C:3012.0001/input/input0
[3.142168] hid-generic 0003:413C:3012.0001: input,hidraw0: USB HID v1.11 
Mouse [Dell Dell USB Optical Mouse] on usb-:02:00.0-1.1/input0
[3.177110] usb 1-1.2: new low-speed USB device number 4 using xhci_hcd
[3.294036] usb 1-1.2: New USB device found, idVendor=05ac, idProduct=024f
[3.300910] usb 1-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[3.308217] usb 1-1.2: Product: Apple Keyboard
[3.312656] usb 1-1.2: Manufacturer: Apple Inc.
[3.327778] input: Apple Inc. Apple Keyboard as 
/devices/platform/smb/f000.pcie/pci:00/:00:02.2/:02:00.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:024F.0002/input/input1
[3.401366] apple 0003:05AC:024F.0002: input,hidraw1: USB HID v1.11 Keyboard 
[Apple Inc. Apple Keyboard] on usb-:02:00.0-1.2/input0
[3.414198] input: Apple Inc. Apple Keyboard as 
/devices/platform/smb/f000.pcie/pci:00/:00:02.2/:02:00.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:024F.0003/input/input2
[3.415263] ata4: SATA link down (SStatus 0 SControl 300)
[3.493164] apple 0003:05AC:024F.0003: input,hidraw2: USB HID v1.11 Device 
[Apple Inc. Apple Keyboard] on usb-:02:00.0-1.2/input1
[3.727269] ata5: SATA link down (SStatus 0 SControl 300)
[4.209110] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[4.216467] ata6.00: ATA-9: SanDisk Ultra II 240GB, X41200RL, max UDMA/133
[4.223345] ata6.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32)
[4.231248] ata6.00: configured for UDMA/133
[4.235759] scsi 5:0:0:0: Direct-Access ATA  SanDisk Ultra II 00RL 
PQ: 0 ANSI: 5
[4.587265] ata7: SATA link down (SStatus 0 SControl 300)
[4.907267] ata8: SATA link down (SStatus 0 SControl 300)
[4.920097] sd 5:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 
GiB)
[4.927659] sd 5:0:0:0: [sda] Write Protect is off
[4.932451] sd 5:0:0:0: [sda] Mode Sense: 00 3a 00 00
[4.932474] sd 5:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[4.948846]  sda: sda1 sda2 sda3 sda4
[4.953073] sd 5:0:0:0: [sda] Attached SCSI disk
[4.994067] PM: Starting manual resume from disk
[4.998724] PM: Hibernation image partition 8:3 present
[4.998726] PM: Looking for hibernation image.
[4.998871] random: fast init done
[5.002349] PM: Image not found (code -22)
[5.002351] PM: Hibernation image not present or could not be loaded.
[5.053585] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
(null)
[5.158112] ip_tables: (C) 2000-2006 Netfilter Core Team
[5.171529] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[5.189751] systemd[1]: Detected architecture arm64.
[5.196476] systemd[1]: Set hostname to .
[5.210572] uart-pl011 e101.serial: no DMA platform data
[5.253903] systemd[1]: Listening on Journal Socket (/dev/log).
[5.260032] 

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

[Ard Biesheuvel]

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 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-arm64 
root=UUID=f3b7c265-d79f-4dce-8c44-d6120d9111e7 ro earlycon

** Tainted: WI (2560)
 * Taint on warning.
 * Working around severe firmware bug.

** Kernel log:
[6.089313] systemd[1]: Listening on Journal Socket (/dev/log).
[6.109283] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[6.129535] systemd[1]: Created slice System Slice.
[6.145453] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[6.165443] systemd[1]: Created slice system-serial\x2dgetty.slice.
[6.185365] systemd[1]: Listening on Journal Audit Socket.
[6.435663] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[6.744776] EFI Variables Facility v0.08 2004-May-17
[6.749803] efi_call_virt_check_flags: 268 callbacks suppressed
[6.755747] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.765128] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.768835] alg: No test for __ecb-aes-ce (__driver-ecb-aes-ce)
[6.768967] sd 4:0:0:0: Attached scsi generic sg0 type 0
[6.780236] alg: No test for __ecb-aes-ce (cryptd(__driver-ecb-aes-ce))
[6.784251] systemd-journald[214]: Received request to flush runtime journal 
from PID 1
[6.800167] [drm] Initialized
[6.803346] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.803380] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.803410] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.803438] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.803465] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.803493] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.803520] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.803547] efi: [Firmware Bug]: IRQ flags corrupted 
(0x0140=>0x0100) by EFI get_next_variable
[6.813510] pstore: using zlib compression
[6.816906] pstore: Registered efi as persistent store backend
[6.926537] nouveau :01:00.0: NVIDIA GT218 (0a8280b1)
[7.038991] Adding 976892k swap on /dev/sda3.  Priority:-1 extents:1 
across:976892k SSFS
[7.166280] nouveau :01:00.0: bios: version 70.18.8a.00.06
[7.167145] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at 
usb-:02:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 50:3f:56:00:23:f5
[7.167203] usbcore: registered new interface driver ax88179_178a
[7.171345] ax88179_178a 2-1:1.0 enx503f560023f5: renamed from eth0
[7.254405] nouveau :01:00.0: fb: 1024 MiB DDR3
[7.280057] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[7.834658] IPv6: ADDRCONF(NETDEV_UP): enx503f560023f5: link is not ready
[8.561510] [TTM] Zone  kernel: Available graphics memory: 8190650 kiB
[8.568041] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[8.574569] [TTM] Initializing pool allocator
[8.578937] [TTM] Initializing DMA pool allocator
[8.583669] nouveau :01:00.0: DRM: VRAM: 1024 MiB
[8.588719] nouveau :01:00.0: DRM: GART: 1048576 MiB
[8.594040] nouveau :01:00.0: DRM: TMDS table version 2.0
[8.599789] nouveau :01:00.0: DRM: DCB version 4.0
[8.604929] nouveau :01:00.0: DRM: DCB outp 00: 02000300 
[8.611370] nouveau :01:00.0: DRM: DCB outp 01: 01000302 00020030
[8.617811] nouveau :01:00.0: DRM: DCB outp 02: 02021362 00020010
[8.624253] nouveau :01:00.0: DRM: DCB outp 04: 01032310 
[8.630699] nouveau :01:00.0: DRM: DCB conn 00: 1030
[8.636358] nouveau :01:00.0: DRM: DCB conn 01: 2161
[8.642017] nouveau :01:00.0: DRM: DCB conn 02: 0200
[8.657437] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[8.664052] [drm] Driver supports precise vblank timestamp query.
[8.699486] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
[8.729230] nouveau :01:00.0: No connectors reported connected with modes
[8.736366] [drm] Cannot find any crtc or sizes - going 1024x768
[8.746063] nouveau :01:00.0: DRM: allocated 1024x768 fb: 0x7, bo 
8c556ae7ec00
[8.754469] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[8.777201] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on 
minor 0
[   

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

[Ard Biesheuvel]

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 using mozilla-js).
> > > > > [...]
> > > > >
> > > > > Could we possibly work around that by reducing
> > > > > CONFIG_ARCH_MMAP_RND_BITS_MAX? Â (That's not directly configurable; it
> > > > > requires patching arch/arm64/Kconfig.)
> > > >
> > > > I think this would be opening up a real can of worms. Not all sizes
> > > > are supported by the architecture, and only certain VA_BITS/pagesize
> > > > combinations work in the kernel.
> > > >
> > > > We could switch to 42-bit VA, but that would require switching to 64K
> > > > pagesize, which would be an even huger can.
> > >
> > > I'm not suggesting using any unusual page table configuration. Just
> > > reducing the ASLR range that is currently implied by a 48-bit VA.
> >
> > But would that help anything?
> > Even if you don't allocate to the top bits, if they're used for
> > tagging, you'll still segfault.
>
> I seem to remember that AArch64 has the ill-advised rule that VA bits
> outside the range of the current page table format are ignored, so
> presumably you're concerned that the code relies on this. Â But since
> other 64-bit architectures (at least x86, PowerPC and SPARC) behave
> otherwise, I would expect semi-portable code to mask out the tag bits.
>

Indeed. The most likely failure mode (but we'd need to check to be
sure) is that the JITs 'clean up' the addresses before dereferencing
them by masking bits that have a special meaning to them, and
inadvertently clear upper address bits in the process.

My concern with changing CONFIG_ARCH_MMAP_RND_BITS_MAX is that it is
not a guarantee that mmap() will not be called with explicit addr
values in the problematic range. (In some cases, munmap() is used to
detect the VA range, given that munmap() turns out to succeed for
non-existent mappings unless the address value exceeds the VA size).
It's unlikely that an affected JIT would do both things at the same
time, i.e., steal upper address bits and perform mmap() allocations in
the problematic range, but we'd need to confirm it nonetheless.

-- 
Ard.