| 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
| ||
|
Message-ID: <ZPkQ+whuhTT6JtKN@kernel.org>
Date: Wed, 6 Sep 2023 20:53:31 -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 08:46:14PM -0300, Arnaldo Carvalho de Melo escreveu:
> 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]$
> :-)
Some examples:
[root@...e perf-tools-next]# bpftool btf dump file /sys/kernel/btf/vmlinux | grep -w ENUM64
[2954] ENUM64 '(anon)' encoding=SIGNED size=8 vlen=28
[6519] ENUM64 'blake2b_iv' encoding=UNSIGNED size=8 vlen=8
[12990] ENUM64 '(anon)' encoding=UNSIGNED size=8 vlen=3
[16283] ENUM64 'netdev_priv_flags' encoding=UNSIGNED size=8 vlen=33
[21717] ENUM64 '(anon)' encoding=UNSIGNED size=8 vlen=11
[28247] ENUM64 'ib_uverbs_device_cap_flags' encoding=UNSIGNED size=8 vlen=28
[34836] ENUM64 'perf_callchain_context' encoding=UNSIGNED size=8 vlen=7
[48851] ENUM64 '(anon)' encoding=UNSIGNED size=8 vlen=9
[54703] ENUM64 'hmm_pfn_flags' encoding=UNSIGNED size=8 vlen=7
[root@...e perf-tools-next]# pahole netdev_priv_flags
enum netdev_priv_flags {
IFF_802_1Q_VLAN = 1,
IFF_EBRIDGE = 2,
IFF_BONDING = 4,
IFF_ISATAP = 8,
IFF_WAN_HDLC = 16,
IFF_XMIT_DST_RELEASE = 32,
IFF_DONT_BRIDGE = 64,
IFF_DISABLE_NETPOLL = 128,
IFF_MACVLAN_PORT = 256,
IFF_BRIDGE_PORT = 512,
IFF_OVS_DATAPATH = 1024,
IFF_TX_SKB_SHARING = 2048,
IFF_UNICAST_FLT = 4096,
IFF_TEAM_PORT = 8192,
IFF_SUPP_NOFCS = 16384,
IFF_LIVE_ADDR_CHANGE = 32768,
IFF_MACVLAN = 65536,
IFF_XMIT_DST_RELEASE_PERM = 131072,
IFF_L3MDEV_MASTER = 262144,
IFF_NO_QUEUE = 524288,
IFF_OPENVSWITCH = 1048576,
IFF_L3MDEV_SLAVE = 2097152,
IFF_TEAM = 4194304,
IFF_RXFH_CONFIGURED = 8388608,
IFF_PHONY_HEADROOM = 16777216,
IFF_MACSEC = 33554432,
IFF_NO_RX_HANDLER = 67108864,
IFF_FAILOVER = 134217728,
IFF_FAILOVER_SLAVE = 268435456,
IFF_L3MDEV_RX_HANDLER = 536870912,
IFF_NO_ADDRCONF = 1073741824,
IFF_TX_SKB_NO_LINEAR = 2147483648,
IFF_CHANGE_PROTO_DOWN = 4294967296,
}
[root@...e perf-tools-next]# pahole --hex ib_uverbs_device_cap_flags
enum ib_uverbs_device_cap_flags {
IB_UVERBS_DEVICE_RESIZE_MAX_WR = 0x1,
IB_UVERBS_DEVICE_BAD_PKEY_CNTR = 0x2,
IB_UVERBS_DEVICE_BAD_QKEY_CNTR = 0x4,
IB_UVERBS_DEVICE_RAW_MULTI = 0x8,
IB_UVERBS_DEVICE_AUTO_PATH_MIG = 0x10,
IB_UVERBS_DEVICE_CHANGE_PHY_PORT = 0x20,
IB_UVERBS_DEVICE_UD_AV_PORT_ENFORCE = 0x40,
IB_UVERBS_DEVICE_CURR_QP_STATE_MOD = 0x80,
IB_UVERBS_DEVICE_SHUTDOWN_PORT = 0x100,
IB_UVERBS_DEVICE_PORT_ACTIVE_EVENT = 0x400,
IB_UVERBS_DEVICE_SYS_IMAGE_GUID = 0x800,
IB_UVERBS_DEVICE_RC_RNR_NAK_GEN = 0x1000,
IB_UVERBS_DEVICE_SRQ_RESIZE = 0x2000,
IB_UVERBS_DEVICE_N_NOTIFY_CQ = 0x4000,
IB_UVERBS_DEVICE_MEM_WINDOW = 0x20000,
IB_UVERBS_DEVICE_UD_IP_CSUM = 0x40000,
IB_UVERBS_DEVICE_XRC = 0x100000,
IB_UVERBS_DEVICE_MEM_MGT_EXTENSIONS = 0x200000,
IB_UVERBS_DEVICE_MEM_WINDOW_TYPE_2A = 0x800000,
IB_UVERBS_DEVICE_MEM_WINDOW_TYPE_2B = 0x1000000,
IB_UVERBS_DEVICE_RC_IP_CSUM = 0x2000000,
IB_UVERBS_DEVICE_RAW_IP_CSUM = 0x4000000,
IB_UVERBS_DEVICE_MANAGED_FLOW_STEERING = 0x20000000,
IB_UVERBS_DEVICE_RAW_SCATTER_FCS = 0x400000000,
IB_UVERBS_DEVICE_PCI_WRITE_END_PADDING = 0x1000000000,
IB_UVERBS_DEVICE_FLUSH_GLOBAL = 0x4000000000,
IB_UVERBS_DEVICE_FLUSH_PERSISTENT = 0x8000000000,
IB_UVERBS_DEVICE_ATOMIC_WRITE = 0x10000000000,
}
[root@...e perf-tools-next]#
Powered by blists - more mailing lists