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: <YJGdDHLcYuRajhsb@gmail.com>
Date:   Tue, 4 May 2021 12:14:20 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     harshad shirwadkar <harshadshirwadkar@...il.com>
Cc:     Theodore Ts'o <tytso@....edu>, 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 10:55:44AM -0700, harshad shirwadkar wrote:
> > However, wouldn't it be easier to just add __attribute__((packed)) to the
> > definition of struct journal_block_tag_t?
> While we know that journal_block_tag_t can be unaligned, our code
> should still ensure that we are reading this struct in an
> alignment-safe way (like Ted's patch does). IIUC, using
> __attribute__((packed)) might result in us keeping the door open for
> unaligned accesses in future. If someone tries to read 4 bytes
> starting at &journal_block_tag_t->t_flags, with attribute packed,
> UBSAN won't complain but this may still cause issues on some
> architectures.

I don't understand your concern here.  Accesses to a packed struct are assumed
to be unaligned -- that's why I suggested it.  The packed attribute is pretty
widely used to implement unaligned accesses in C (as an alternative to memcpy()
or explicit byte-by-byte accesses, both of which also work, though the latter
seems to run into an UBSAN bug in this case).

- Eric