linux-ext4 - Re: [PATCH] e2fsck: fix portability problems caused by unaligned accesses

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: <YJTh9T3sgdFFE7fM@sol.localdomain>
Date:   Thu, 6 May 2021 23:45:09 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Theodore Ts'o <tytso@....edu>
Cc:     harshad shirwadkar <harshadshirwadkar@...il.com>,
        Andreas Dilger <adilger@...ger.ca>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Harshad Shirwadkar <harshads@...gle.com>
Subject: Re: [PATCH] e2fsck: fix portability problems caused by unaligned
 accesses

On Tue, May 04, 2021 at 02:30:50PM -0700, Eric Biggers wrote:
> > So maybe the memcpy to a local copy is the better way to go, and
> > hopefully the C compiler will optimize away the local copy on
> > architectures where it is safe to do so.  And in the unlikely case
> > that it is a performance bottleneck, we could add a -DUBSAN when
> > configure --enable-ubsan is in force, which switches in the memcpy
> > when only when ubsan is enabled.
> 
> These days the memcpy() approach does get optimized properly.  armv6 and armv7
> with gcc used to be a notable exception, but it got fixed in gcc 6
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366).
> 

Just to be clear (looking at the latest patches on the list which are copying
whole structs), by "the memcpy() approach does get optimized properly", I meant
that it gets optimized properly in implementations of get_unaligned_le16(),
get_unaligned_le32(), put_unaligned_le32(), etc., where a single word (or less
than a word) is loaded or stored.  I don't know how reliably the compilers will
optimize out the copy if you memcpy() a whole struct instead of a single word.

Even if they don't optimize it out, I don't expect that it would be a
performance problem in this context, so it's probably still fine to solve the
problem.  But I just wanted to clarify what I meant here.

- Eric