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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 1 Apr 2015 21:15:38 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Kirill A. Shutemov" <kirill@...temov.name>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [RFC] iov_iter_get_pages() semantics

On Wed, Apr 01, 2015 at 11:34:12AM -0700, Linus Torvalds wrote:
> with kernel mappings. But vmalloc space is at least better than random
> "just kernel addresses" which is even worse, since they could be stack
> pages or SLAB pages or whatever.
> 
> And slab allocations, for example, do *not* honor the page count, even
> though such pages do have page counts. The slab allocations can be
> reused for other things freely, completely regardless of whether
> somebody incremented the page count or not.
> 
> And yes, people do things like "kernel_read()" on just normal
> kmalloc() allocations. So no, I do *not* think that it's ok to "just
> make zero-copy kernel_read() work on kernel addresses by turning them
> into 'struct page' and then do whop-the-hell-knows-what random things
> with such a 'struct page').

Umm...  Tangentially related question - do we have any IO codepaths where
a pointer to page might stick around indefinitely?  AFAICS, for AIO it's
enough to wait for request to complete, but that's available to caller.
Do we have anything where one would really have to do e.g. freeing (or
dropping refcount, etc.) in a callback one can't conveniently wait for?
sg_table with pointers to pages of kmalloc'ed objects are really common in
e.g. crypto/*...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ