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: <19f05d6a-7b96-472a-919d-56292596e8bb@linux.dev>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ