linux-kernel - Re: [PATCH] arm64: Clear the initial ID map correctly before remapping

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]

Date: Sun, 23 Jun 2024 22:20:29 +0800
From: Zenghui Yu <zenghui.yu@...ux.dev>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Zenghui Yu <yuzenghui@...wei.com>, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, catalin.marinas@....com, will@...nel.org,
 wanghaibin.wang@...wei.com
Subject: Re: [PATCH] arm64: Clear the initial ID map correctly before
 remapping

On 2024/6/21 17:52, Ard Biesheuvel wrote:
> On Fri, 21 Jun 2024 at 11:28, Zenghui Yu <yuzenghui@...wei.com> wrote:
> >
> > In the attempt to clear and recreate the initial ID map for LPA2, we
> > wrongly use 'start - end' as the map size and make the memset() almost a
> > nop.
> >
> > Fix it by passing the correct map size.
> >
> > Fixes: 9684ec186f8f ("arm64: Enable LPA2 at boot if supported by the system")
> > Signed-off-by: Zenghui Yu <yuzenghui@...wei.com>
> > ---
> >
> > Found by code inspection (don't have the appropriate HW to test it).
> >
> 
> Good catch!
> 
> Even though memset() takes an unsigned size_t, the zeroing path in
> arm64's memset.S does a signed compare on the provided size, and will
> zero at most 63 bytes if the size has the sign bit set. So in the end,
> it does not clear anything.

Yup! It took me a while to figure out why memset() with a VERY large
size doesn't corrupt the memory. ;-)

> Note that in this particular case, that
> doesn't actually matter - the memory is reused immediately to create
> another copy of the ID map, and any unused regions containing garbage
> will just be ignored.

Agreed. I can fold it into the commit message if Will/Catalin ask for a
respin. And it looks like an alternate "fix" would be just removing the
memset().

> Nonetheless,
> 
> Reviewed-by: Ard Biesheuvel <ardb@...nel.org>

Thanks!

Zenghui