linux-kernel - Re: [PATCH v2 1/4] lib: test copy_{to,from}

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: <ZCFr3I36Te2D0ZuQ@arm.com>
Date:   Mon, 27 Mar 2023 11:11:40 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     David Laight <David.Laight@...lab.com>
Cc:     'Mark Rutland' <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
        "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
        "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "will@...nel.org" <will@...nel.org>
Subject: Re: [PATCH v2 1/4] lib: test copy_{to,from}_user()

On Thu, Mar 23, 2023 at 10:16:12PM +0000, David Laight wrote:
> From: Mark Rutland
> > Sent: 22 March 2023 14:05
> ....
> > > IIUC, in such tests you only vary the destination offset. Our copy
> > > routines in general try to align the source and leave the destination
> > > unaligned for performance. It would be interesting to add some variation
> > > on the source offset as well to spot potential issues with that part of
> > > the memcpy routines.
> > 
> > I have that on my TODO list; I had intended to drop that into the
> > usercopy_params. The only problem is that the cross product of size,
> > src_offset, and dst_offset gets quite large.
> 
> I thought that is was better to align the writes and do misaligned reads.

We inherited the memcpy/memset routines from the optimised cortex
strings library (fine-tuned by the toolchain people for various Arm
microarchitectures). For some CPUs with less aggressive prefetching it's
probably marginally faster to align the reads instead of writes (as
multiple unaligned writes are usually combined in the write buffer
somewhere).

Also, IIRC for some small copies (less than 16 bytes), our routines
don't bother with any alignment at all.

> Although maybe copy_to/from_user() would be best aligning the user address
> (to avoid page faults part way through a misaligned access).

In theory only copy_to_user() needs the write aligned if we want strict
guarantees of what was written. For copy_from_user() we can work around
by falling back to a byte read.

> OTOH, on x86, is it even worth bothering at all.
> I have measured a performance drop for misaligned reads, but it
> was less than 1 clock per cache line in a test that was doing
> 2 misaligned reads in at least some of the clock cycles.
> I think the memory read path can do two AVX reads each clock.
> So doing two misaligned 64bit reads isn't stressing it.

I think that's what Mark found as well in his testing, though I'm sure
one can build a very specific benchmark that shows a small degradation.

-- 
Catalin