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:	Thu, 2 Nov 2006 12:04:12 -0800
From:	Andrew Morton <akpm@...l.org>
To:	"Miguel Ojeda" <maxextreme@...il.com>
Cc:	Franck <vagabon.xyz@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH update6] drivers: add LCD support

On Thu, 2 Nov 2006 19:33:48 +0000
"Miguel Ojeda" <maxextreme@...il.com> wrote:

> May 2.6.18-new vmalloc
> related functions help correlating userspace & kernel addresses? I
> will try them and come with an answer tomorrow.
> 
> Quoting http://lwn.net/Articles/2.6-kernel-api/
> 
> "Some functions have been added to make it easy for kernel code to
> allocate a buffer with vmalloc() and map it into user space. They are:
> 
>      void *vmalloc_user(unsigned long size);
>      void *vmalloc_32_user(unsigned long size);
>      int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
>                              unsigned long pgoff);
> 
> The first two functions are a form of vmalloc() which obtain memory
> intended to be mapped into user space; among other things, they zero
> the entire range to avoid leaking data. vmalloc_32_user() allocates
> low memory only. A call to remap_vmalloc_range() will complete the
> job; it will refuse, however, to remap memory which has not been
> allocated with one of the two functions above."

No, it doesn't look like those helper functions are designed to handle this.

I'm really not the person to be asking about this.  I can poke around in
arch/sparc64/kernel/sys_sparc.c:arch_get_unmapped_area() as well as the
next guy, and it seems to be doing the right thing for MAP_FIXED, but
how/whether it handles !MAP_FIXED I do not know.  Ask davem ;)
-
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