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 <>
To:     Matthew Wilcox <>
Cc:     Christoph Hellwig <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Paolo Abeni <>, Du Cheng <>,
        Christophe JAILLET <>,
        Vlastimil Babka <>,
        William Kucharski <>,
        Arnd Bergmann <>,
        Nathan Chancellor <>,,,,
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. :)


Kees Cook

Powered by blists - more mailing lists