From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Peter Jones <pjones@redhat.com>, "# 3.4.x" <stable@vger.kernel.org>
Subject: Re: WTF: patch "[PATCH] efi: Make it possible to disable efivar_ssdt entirely" was seriously submitted to be applied to the 5.7-stable tree?
Date: Tue, 7 Jul 2020 16:10:31 +0200 [thread overview]
Message-ID: <20200707141031.GD4064836@kroah.com> (raw)
In-Reply-To: <CAMj1kXFFPO=csSXhxJ5gEpbzKi4r5q2XeLEJvvTfxFh37PhJDQ@mail.gmail.com>
On Mon, Jun 29, 2020 at 08:30:21PM +0200, Ard Biesheuvel wrote:
> On Mon, 29 Jun 2020 at 17:48, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Jun 29, 2020 at 05:18:08PM +0200, Ard Biesheuvel wrote:
> > > On Mon, 29 Jun 2020 at 11:32, <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > The patch below was submitted to be applied to the 5.7-stable tree.
> > > >
> > > > I fail to see how this patch meets the stable kernel rules as found at
> > > > Documentation/process/stable-kernel-rules.rst.
> > > >
> > > > I could be totally wrong, and if so, please respond to
> > > > <stable@vger.kernel.org> and let me know why this patch should be
> > > > applied. Otherwise, it is now dropped from my patch queues, never to be
> > > > seen again.
> > > >
> > >
> > > Without this patch, there is no way to disable sideloading of SSDTs
> > > via EFI variables, which is a security hole. The fact that this is not
> > > governed by the existing ACPI_TABLE_UPGRADE Kconfig option was an
> > > oversight, and so distros currently have this functionality enabled
> > > inadvertently (although most of them have the lockdown check
> > > incorporated as well)
> > >
> > > SSDTs can manipulate any memory (even kernel memory that has been
> > > mapped read-only) by using SystemMemory OpRegions in _INI AML methods,
> > > and setting an EFI variable once will make this persist across
> > > reboots.
> >
> > All of this was not in the description of the patch at all, how were we
> > supposed to know this?
> >
>
> Good point. This patch was the result of same off-list discussion, so
> it was obvious to those involved but not for anyone else.
>
> > And this really looks like a new feature now that you are supporting
> > something that we previously could not do. To know that this is a "fix"
> > is not obvious :(
> >
> > I'll go queue it up, but how far back should it go?
> >
>
> The feature was added in v4.8, so as close as we can get to that please.
Ok, got it applied back to 4.9 now, thanks.
greg k-h
next prev parent reply other threads:[~2020-07-07 14:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 9:23 WTF: patch "[PATCH] efi: Make it possible to disable efivar_ssdt entirely" was seriously submitted to be applied to the 5.7-stable tree? gregkh
2020-06-29 15:18 ` Ard Biesheuvel
2020-06-29 15:48 ` Greg Kroah-Hartman
2020-06-29 18:30 ` Ard Biesheuvel
2020-07-07 14:10 ` Greg Kroah-Hartman [this message]
2020-07-07 14:21 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200707141031.GD4064836@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=ardb@kernel.org \
--cc=pjones@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.