[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202506021057.3AB03F705@keescook>
Date: Mon, 2 Jun 2025 11:03:18 -0700
From: Kees Cook <kees@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Pranav Tyagi <pranav.tyagi03@...il.com>, andrew+netdev@...n.ch,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, horms@...nel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
linux-kernel-mentees@...ts.linux.dev
Subject: Re: [PATCH] net: randomize layout of struct net_device
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
Powered by blists - more mailing lists