linux-hardening - Re: [PATCH] niu: Add "overloaded" struct page union member

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 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 10 May 2022 13:20:48 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Du Cheng <ducheng2@...il.com>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Vlastimil Babka <vbabka@...e.cz>,
        William Kucharski <william.kucharski@...cle.com>,
        Arnd Bergmann <arnd@...db.de>,
        Nathan Chancellor <nathan@...nel.org>, netdev@...r.kernel.org,
        linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH] niu: Add "overloaded" struct page union member

On Tue, May 10, 2022 at 06:27:41PM +0100, Matthew Wilcox wrote:
> 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.

Okay, in the meantime, I'll just add a casting wrapper with a big
comment to explain what I understand about it with some pointers back to
this and prior threads. :)

Thanks!

-- 
Kees Cook