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] [day] [month] [year] [list]
Date:	Wed, 21 Jul 2010 11:09:12 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Peter Crosthwaite <peter.crosthwaite@...alogix.com>
Cc:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	hjk@...utronix.de, Michal Simek <michal.simek@...alogix.com>,
	John Williams <john.williams@...alogix.com>
Subject: Re: UIO: munmap bug for boot time allocated memory

On Wed, Jul 21, 2010 at 05:17:17PM +1000, Peter Crosthwaite wrote:
> Hi Greg,
> 
> Thanks for your reply on the mmunmap issue. Sorry about the delay on
> this correspondance.
> 
> I have looked into this bug in more detail. The
> alloc_bootmem_low_pages() call is falling back to a call to kzalloc(),
> so the address passed to UIO when used in UIO_MEM_LOGICAL is a return
> from kmalloc(). So my first question is, is kmalloc'ed memory
> supported by UIO?

Yes, of course. UIO_MEM_LOGICAL is the correct memtype for that. But
that applies only to memory you get _directly_ from kmalloc().
For example, dma_alloc_coherent() on ARM internally gets its memory from
kmalloc, too. But it needs a completely different mapping routine,
trying to map it using UIO_MEM_LOGICAL will fail.

> 
> With regards to the copying the data from the buffer to file, yes it
> is showing the correct data.
> 
> I have since resolved the BUG() by manually modifying the usage
> counters for the buffer pages from kernel space. i.e. Once the memory
> is kmalloc'ed the driver will iterate through all the pages and
> increment the _count field of the struct page. This will cause the
> pages to have a user count of 2 when mmaped (by user space) which
> reverts to 1 when unmapped. Now this fixes the bug, but should this
> manual increment be necessary? Is there a cleaner way in the kernel
> API for kernel space to mark itself as a user of a memory range or
> user space VMA?
> 
> You mentioned linking you up with the source code for my driver. Im
> trying to put together a minimal driver that replicates this bug, but
> it seems UIO enforces the need for a parent device when initialised.
> Considering this bug requires no actual hardware to replicate, is
> there a way to get a UIO device without a physical device to be able
> to test this behaviour in isolation?

There once was the uio_dummy driver. It maps some kmalloc'ed memory
to userspace and uses a timer to simulate interrupts. Just google
for "uio_dummy" and you'll find it. It's quite old (2.6.23), so it
will need some fixing. But it should give you the idea.

Thanks,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ