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:   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