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
| ||
|
Date: Mon, 17 Apr 2017 12:40:26 -0400 From: Jamal Hadi Salim <jhs@...atatu.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: Jiri Pirko <jiri@...nulli.us>, davem@...emloft.net, netdev@...r.kernel.org, xiyou.wangcong@...il.com Subject: Re: [PATCH net-next 1/1] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch On 17-04-17 10:58 AM, Eric Dumazet wrote: [..] > Very often, pads are there because of ABI constraints. > > We 'name' them to make clear to developers that they are there, > and avoid security issues, because of say few bytes from kernel stack > are copied to user space. > > struct foo { > __u32 a; > __u16 b; > }; > > > Note that the 16bit padding is there, even if you do not name it. > Agreed. But note netlink is defined as "a wire protocol" which has explicit requirement to pad/align to 32 bit boundary. Therefore we _always_ explicitly name the pads. > Once this structure had been exported to some include file and in a > kernel, there is little point trying to 'reuse' the padding, unless for > very specific cases. > > If you name paddings, then developers might think about it. > We always name them for netlink. The challenge is a few months later we are not allowed to use the fields we name. I see these netlink struct pads in the same manner as say reserved packet header fields. cheers, jamal
Powered by blists - more mailing lists