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@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. Ok, got it applied back to 4.9 now, thanks. greg k-h
