linux-kernel - Re: [GIT PULL] bcachefs

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]

Date:   Wed, 6 Sep 2023 20:46:14 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     dsterba@...e.cz, Kent Overstreet <kent.overstreet@...ux.dev>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-bcachefs@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs

Em Wed, Sep 06, 2023 at 04:34:32PM -0700, Linus Torvalds escreveu:
> On Wed, 6 Sept 2023 at 16:20, David Sterba <dsterba@...e.cz> wrote:
> >     I think I've always seen an int for enums, unless it was
> > explicitly narrowed in the structure (:8) or by __packed attribute in
> > the enum definition.

> 'int' is definitely the default (and traditional) behavior.
 
> But exactly because enums can act very differently depending on
> compiler options (and some of those may have different defaults on
> different architectures), we should never ever have a bare 'enum' as
> part of a structure in any UAPI.
 
> In fact, having an enum as a bitfield is much better for that case.
 
> Doing a quick grep shows that sadly people haven't realized that.
 
> Now: using -fshort-enum can break a _lot_ of libraries exactly for
> this kind of reason, so the kernel isn't unusual, and I don't know of
> anybody who actually uses -fshort-enum. I'm mentioning -fshort-enum
> not because it's likely to be used, but mainly because it's an easy
> way to show some issues.
 
> You can get very similar issues by just having unusual enum values.  Doing
> 
>    enum mynum { val = 0x80000000 };
 
> does something special too.
 
> I leave it to the reader to figure out, but as a hint it's basically
> exactly the same issue as I was trying to show with my crazy
> -fshort-enum example.

Two extra hints:

⬢[acme@...lbox perf-tools-next]$ grep KIND_ENUM64 include/uapi/linux/btf.h
	BTF_KIND_ENUM64		= 19,	/* Enumeration up to 64-bit values */
/* BTF_KIND_ENUM64 is followed by multiple "struct btf_enum64".
⬢[acme@...lbox perf-tools-next]$

⬢[acme@...lbox perf-tools-next]$ pahole --help |& grep enum
      --skip_encoding_btf_enum64   Do not encode ENUM64s in BTF.
⬢[acme@...lbox perf-tools-next]$

:-)

- Arnaldo