Re: [PATCH] net: randomize layout of struct net_device

[Kees Cook]

On Mon, Jun 02, 2025 at 04:46:14PM +0200, Andrew Lunn wrote:
> On Mon, Jun 02, 2025 at 07:29:32PM +0530, Pranav Tyagi wrote:
> > Add __randomize_layout to struct net_device to support structure layout
> > randomization if CONFIG_RANDSTRUCT is enabled else the macro expands to
> > do nothing. This enhances kernel protection by making it harder to
> > predict the memory layout of this structure.
> > 
> > Link: https://github.com/KSPP/linux/issues/188

I would note that the TODO item in this Issue is "evaluate struct
net_device".

> A dumb question i hope.
> 
> As you can see from this comment, some time and effort has been put
> into the order of members in this structure so that those which are
> accessed on the TX fast path are in the same cache line, and those on
> the RX fast path are in the same cache line, and RX and TX fast paths
> are in different cache lines, etc.

This is pretty well exactly one of the right questions to ask, and
should be detailed in the commit message. Mainly: a) how do we know it
will not break anything? b) why is net_device a struct that is likely
to be targeted by an attacker?

> Does CONFIG_RANDSTRUCT understand this? It is safe to move members
> around within a cache line. And it is safe to move whole cache lines
> around. But it would be bad if the randomisation moved members between
> cache lines, mixing up RX and TX fast path members, or spreading fast
> path members over more cache lines, etc.

No, it'll move stuff all around. It's very much a security vs
performance trade-off, but the systems being built with it are happy to
take the hit.

Anything that must stay ordered due to invisible assumptions would need
a distinct anonymous array to keep them together.

> Is there documentation somewhere about what __randomize_layout
> actually does? Given you are posting to a networking mailing list, you
> should not assume the developers here are deep into how the compiler
> works, and want to include a link to documentation, so we can see this
> is actually safe to do.

The basic details are in security/Kconfig.hardening in the "choice" following
the CC_HAS_RANDSTRUCT entry.

-- 
Kees Cook