[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXEQetR-4PtjDPaHV4EcYnJyQu1TCTN=YunCnn4MU5CH5g@mail.gmail.com>
Date: Thu, 16 May 2024 19:22:10 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: "Chaney, Ben" <bchaney@...mai.com>
Cc: Kees Cook <kees@...nel.org>, Kees Cook <keescook@...omium.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "Tottenham, Max" <mtottenh@...mai.com>,
"Hunt, Joshua" <johunt@...mai.com>, "Galaxy, Michael" <mgalaxy@...mai.com>
Subject: Re: Regression in 6.1.81: Missing memory in pmem device
On Thu, 16 May 2024 at 16:59, Chaney, Ben <bchaney@...mai.com> wrote:
>
> The 'nokaslr' flag does work around this issue, but using it has a few downsides.
>
> First, we would like the security benefit provided be ASLR.
We wouldn't need to disable virtual KASLR only physical KASLR.
> Also, this imposes a restriction on what memmaps are possible. It would then be required to have them offset from the beginning of the memory.
>
Relying on the KASLR code to move the kernel away from the base of RAM
is rather risky - even when KASLR is in effect, the logic will fall
back to placement at the base of memory if physical randomization is
not possible for any reason.
> I also think there are a few other features that may be impacted by this, that were not addressed by the patch. crashkernel and pstore both probably need physical kaslr disabled as well.
>
Please reply to the patch if you have any comments on it. Thanks.
Powered by blists - more mailing lists