linux-kernel - Re: [PATCH v1] arm64/mm: Fix Boot panic on Ampere Altra

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: <CAMj1kXHJGC9aYCwwb2XTWfhAjH6GDKQptNdLwO+hfv6hazivHQ@mail.gmail.com>
Date: Wed, 26 Feb 2025 09:33:40 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Will Deacon <will@...nel.org>, Catalin Marinas <catalin.marinas@....com>, 
	Mark Rutland <mark.rutland@....com>, Luiz Capitulino <luizcap@...hat.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] arm64/mm: Fix Boot panic on Ampere Altra

On Wed, 26 Feb 2025 at 09:07, Ryan Roberts <ryan.roberts@....com> wrote:
>
> On 26/02/2025 06:59, Ard Biesheuvel wrote:
> > On Wed, 26 Feb 2025 at 01:10, Will Deacon <will@...nel.org> wrote:
> >>
> >> On Tue, Feb 25, 2025 at 07:05:35PM +0100, Ard Biesheuvel wrote:
> >>> Apologies for the breakage, and thanks for the fix.
> >>>
> >>> I have to admit that I was a bit overzealous here: there is no point
> >>> yet in using the sanitised value, given that we don't actually
> >>> override the PA range in the first place.
>
> But unless I've misunderstood something, parange is overridden; Commit
> 62cffa496aac (the same one we are fixing) adds an override to force parange to
> 48 bits when arm64.nolva is specified for LPA2 systems (see mmfr2_varange_filter()).
>
> I thought it would be preferable to honour that override, hence my use of
> arm64_apply_feature_override() in the fix. Are you saying we don't need to worry
> about that case?
>

I wouldn't think so (but I'm glad you brought it up because this
didn't occur to me at all tbh)

With arm64.nolva, both the VA and PA ranges will be reduced, and so
the range of the linear map will be 47 bits. So if the PA range is
being reduced from 52 to 48, it will still exceed the size of the
linear map, and so it should make no difference in this particular
case.

The use case I had in mind was to allow the PA range to be reduced to
a value that is substantially less than the range of the linear map,
e.g, 40 bits on a 48-bit VA kernel. On the Android side, the issue of
the missing linear map randomization has come up a couple of times,
but there is no clear direction at this point, so adding this feature
here was premature (mea culpa)