On Mon, 29 Jun 2020 at 17:48, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 29, 2020 at 05:18:08PM +0200, Ard Biesheuvel wrote: > > On Mon, 29 Jun 2020 at 11:32, <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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. Thanks, Ard.
