linux-kernel - Re: [PATCH] arm64: Add ARM64_HAS

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] [day] [month] [year] [list]

Message-ID: <Ztr-FHF5MG1YvLse@J2N7QTR9R3.cambridge.arm.com>
Date: Fri, 6 Sep 2024 14:05:57 +0100
From: Mark Rutland <mark.rutland@....com>
To: "tiantao (H)" <tiantao6@...ilicon.com>
Cc: catalin.marinas@....com, will@...nel.org, jonathan.cameron@...wei.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linuxarm@...wei.com
Subject: Re: [PATCH] arm64: Add ARM64_HAS_LSE2 CPU capability

On Fri, Sep 06, 2024 at 08:20:19PM +0800, tiantao (H) wrote:
> 
> 在 2024/9/6 19:42, Mark Rutland 写道:
> > On Fri, Sep 06, 2024 at 06:58:19PM +0800, tiantao (H) wrote:
> > > 在 2024/9/6 17:44, Mark Rutland 写道:
> > > > On Fri, Sep 06, 2024 at 05:08:12PM +0800, Tian Tao wrote:
> > > I've come across a situation where the simplified code is as follows:
> > > 
> > >   long  address = (long) mmap(NULL,1024*1024*2,PROT_READ|PROT_WRITE,
> > > MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
> > > 
> > > long new_address = address + 9;
> > > 
> > >   long *p = (long*) new_address;
> > >   long v = -1;
> > > 
> > >   __atomic_store(p, &v, __ATOMIC_RELEASE);
> > Hold on; looking at the ARM ARM (ARM DDI 0487K.a), the example and the
> > patch are both bogus. NAK to this patch, explanation below.
> > 
> > Per section B2.2.1.1 "Changes to single-copy atomicity in Armv8.4", all of the
> > LSE2 relaxations on alignment require:
> > 
> > | all bytes being accessed are within a 16-byte quantity that is aligned
> > | to 16 bytes
> > 
> > In your example you perform an 8-byte access at an offset of 9 bytes,
> > which means the access is *not* contained within 16 bytes, and is *not*
> > guaranteed to be atomic. That code simply has to be fixed, the kernel
> > cannot magically make it safe.
> > 
> > Regardless of that, the nAA bit *only* causes an alignment fault for
> > accesses which cannot be atomic. If a CPU has LSE2 and SCTLR_ELx.nAA=0,
> > an unaligned access within 16 bytes (which would be atomic) does not
> > cause an alignment fault. That's pretty clear from the description of
> > nAA and the AArch64.UnalignedAccessFaults() pseudocode:
> 
> Sorry, this example is just for verifying nnA, it's not an example of a real
> scenario,
> 
> we have scenarios that don't require atomicity to be guaranteed, they just
> require that coredump doesn't occur when non-aligned

Please give a concrete explanation of such a scenario, with an
explanation of why atomicity is not required.

Mark.