From: Matthew Wilcox <willy@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Christoph Hellwig <hch@infradead.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Du Cheng <ducheng2@gmail.com>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Vlastimil Babka <vbabka@suse.cz>,
William Kucharski <william.kucharski@oracle.com>,
Arnd Bergmann <arnd@arndb.de>,
Nathan Chancellor <nathan@kernel.org>,
netdev@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] niu: Add "overloaded" struct page union member
Date: Tue, 10 May 2022 18:27:41 +0100 [thread overview]
Message-ID: <YnqgjVoMDu5v9PNG@casper.infradead.org> (raw)
In-Reply-To: <202205100849.58D2C81@keescook>
On Tue, May 10, 2022 at 08:50:47AM -0700, Kees Cook wrote:
> On Tue, May 10, 2022 at 12:27:53AM -0700, Christoph Hellwig wrote:
> > On Mon, May 09, 2022 at 03:23:33PM -0700, Kees Cook wrote:
> > > The randstruct GCC plugin gets upset when it sees struct addresspace
> > > (which is randomized) being assigned to a struct page (which is not
> > > randomized):
> >
> > Well, the right fix here is to remove this abuse from the driver, not
> > to legitimize it as part of a "driver" patch touching a core mm header
>
> Right, I didn't expect anyone to like the new "overloaded" member.
> Mainly I'd just like to understand how niu _should_ be fixed. Is using
> the "private" member the correct thing here?
Well ... no. We're not entirely set up yet to go to the good answer
that means we don't have to touch this driver again, and yet we're also
in a situation where we'll need to touch this driver at some point in
order to get rid of the way it abuses struct page before we can get to
our good place.
The eventual good answer is that we declare a driver-private memdesc
variant that has a ->link, ->base ->refcount and ->pfn (maybe it has more
than that; I'd have to really understand this driver to be completely
certain about what it needs). Or perhaps there's a better way to handle
driver-allocated memory for this kind of networking card that this driver
should be converted to use.
I haven't looked into this case deeply enough to have strong thoughts
about how we should handle it, both now and in the glorious future.
next prev parent reply other threads:[~2022-05-10 17:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 22:23 [PATCH] niu: Add "overloaded" struct page union member Kees Cook
2022-05-10 7:27 ` Christoph Hellwig
2022-05-10 15:50 ` Kees Cook
2022-05-10 17:27 ` Matthew Wilcox [this message]
2022-05-10 20:20 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YnqgjVoMDu5v9PNG@casper.infradead.org \
--to=willy@infradead.org \
--cc=arnd@arndb.de \
--cc=christophe.jaillet@wanadoo.fr \
--cc=davem@davemloft.net \
--cc=ducheng2@gmail.com \
--cc=hch@infradead.org \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vbabka@suse.cz \
--cc=william.kucharski@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).