linux-kernel - Re: [PATCH AUTOSEL 4.19 133/191] efi: honour memory reservations passed via a linux specific config table

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: <20191110132726.GN4787@sasha-vm>
Date:   Sun, 10 Nov 2019 08:27:26 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Jeremy Linton <jeremy.linton@....com>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [PATCH AUTOSEL 4.19 133/191] efi: honour memory reservations
 passed via a linux specific config table

On Sun, Nov 10, 2019 at 08:33:47AM +0100, Ard Biesheuvel wrote:
>On Sun, 10 Nov 2019 at 03:44, Sasha Levin <sashal@...nel.org> wrote:
>>
>> From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>>
>> [ Upstream commit 71e0940d52e107748b270213a01d3b1546657d74 ]
>>
>> In order to allow the OS to reserve memory persistently across a
>> kexec, introduce a Linux-specific UEFI configuration table that
>> points to the head of a linked list in memory, allowing each kernel
>> to add list items describing memory regions that the next kernel
>> should treat as reserved.
>>
>> This is useful, e.g., for GICv3 based ARM systems that cannot disable
>> DMA access to the LPI tables, forcing them to reuse the same memory
>> region again after a kexec reboot.
>>
>> Tested-by: Jeremy Linton <jeremy.linton@....com>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>> Signed-off-by: Sasha Levin <sashal@...nel.org>
>
>NAK
>
>This doesn't belong in -stable, and I'd be interested in understanding
>how this got autoselected, and how I can prevent this from happening
>again in the future.

It was selected because it's part of a fix for a real issue reported by
users:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806766

Besides ubuntu, it is also carried by:

SUSE: https://www.suse.com/support/update/announcement/2019/suse-su-20191530-1/
CentOS: https://koji.mbox.centos.org/koji/buildinfo?buildID=4558

As a way to resolve the reported bug.

Any reason this *shouldn't* be in stable? I'm aware that there might be
dependencies that are not obvious to me, but the solution here is to
take those dependencies as well rather than ignore the process
completely.

-- 
Thanks,
Sasha