linux-kernel - Re: [PATCH AUTOSEL 5.18 147/159] ARM: 9201/1: spectre-bhb: rely on linker to emit cross-section literal loads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXGO-1ccxaK_GnE+d2yc0XkF5y9ZawXXC3ypeGAanv9VtA@mail.gmail.com>
Date:   Mon, 30 May 2022 17:56:09 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Russell King <rmk+kernel@...linux.org.uk>
Cc:     Sasha Levin <sashal@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "# 3.4.x" <stable@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Nicolas Pitre <nico@...xnic.net>,
        Keith Packard <keithpac@...zon.com>,
        Arnd Bergmann <arnd@...db.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH AUTOSEL 5.18 147/159] ARM: 9201/1: spectre-bhb: rely on
 linker to emit cross-section literal loads

On Mon, 30 May 2022 at 17:25, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Mon, May 30, 2022 at 03:32:47PM +0200, Ard Biesheuvel wrote:
> > AUTONAK
> >
> > As discussed before, please disregard all patches authored by me when
> > running the bot.
>
> Ok, but why wasn't this spectre-bhb commit asked to be backported to
> stable in the first place?

Because it doesn't belong in -stable. Hence the lack of cc:stable or
fixes: tags.

> Do older kernels not need these types of
> fixes?
>

This commit was part of a series of six, two of which were bug fixes
and had fixes: tags. They do not have cc:stable tags because the
'fixed' patches had not been backported yet when they were sent out.

So those are clear candidates for -stable, and as far as I can tell,
they have already been backported.

This patch does not fix a bug. It makes the asm code more resilient to
potential bugs introduced inadvertently by future changes, which will
be harder to detect now that we have three different versions of the
exception vector table. (Any given system will only exercise one of
the three, depending on whether and which Spectre-BHB workaround it
requires)

I build and boot test my patches carefully, and so I consciously
decided that the regression risk of backporting this patch outweighs
the benefits. This is why I did not add a cc:stable or fixes: tag. If
a tag existed that said 'do not backport this unless explicitly
requested', I would have added it.

I would expect anyone that proposes this patch for -stable to be as
diligent in ensuring that the patch is safe for backporting, which
includes building the code with older GCC versions that those stable
kernels still support, and boot testing the result on actual hardware.

If this is part of the AUTOSEL workflow, then I stand corrected. But
even then, this does not mean that the patch *belongs* in -stable. As
you know, I enjoy throwing stable-kernel-rules.rst in your face, and I
am pretty sure that using a bot to find patches that apply cleanly and
happen not to cause build breakage is not covered by the criteria
defined by that document by any stretch of the imagination.

On top of that, I feel that 'saving' precious stable maintainer's time
by using a bot to offload this burden to the community uninvited is
really not ok. We work very hard to keep highly heterogeneous
architectures such as ARM working across all supported platforms, and
this is work enough as it is without all the bogus patches that
AUTOSEL digs up without *any* justification beyond 'hey, it applies!'