Re: UVM and the NULL page

On Tue, Dec 27, 2016 at 02:12:59PM +0100, Wolfgang Solfrank wrote: > Hi, > > >Any cpu that doesn't require special instructions for copyin/out > >is susceptible to user processes mapping code to address 0 and > >converting a kernel 'jump through unset pointer' from a panic > >into a massive

Re: UVM and the NULL page

>> Depends on the architecture. For example, on the VAX, I would say >> c000 and e000 would be prime candidates, because the high >> quarter of the possible address space is permanently reserved. > Then the bit encoding for null should obviously be 0xdeadbeef :-) Indeed! I don't know

re: UVM and the NULL page

> There was a bunch of fuss before about being able to "fool" UVM into > mapping at address 0 in spite of this supposedly being disabled; for > some reason the "fix" was to bodge around it rather than to fix UVM to > honor its specification, which I don't understand. If you can fool UVM > into

Re: UVM and the NULL page

On Tue, Dec 27, 2016 at 11:15:59AM -0500, Mouse wrote: > >> Perhaps it's time to implement null pointers as something other than > >> all-bits-zero? > > Wouldn't help much; the next obvious (probably only viable) candidate > > is all-bits-1 and then you just need a slightly larger offset from

Re: UVM and the NULL page

On Tue, Dec 27, 2016 at 03:26:04PM +, David Holland wrote: > Userspace memory shouldn't have supervisor execute permission anyway, > although I suppose x86 can't represent that. > Not all x86, but newer CPUs have SMEP/SMAP which do that.

Re: UVM and the NULL page

On Mon, Dec 26, 2016 at 04:40:16PM -0500, Mouse wrote: > > The only reason I know for mapping address zero [...] > > > Anyway mmap() without MAP_FIXED should never return NULL. > > Perhaps it's time to implement null pointers as something other than > all-bits-zero? Wouldn't help much;

Re: UVM and the NULL page

Hi, Any cpu that doesn't require special instructions for copyin/out is susceptible to user processes mapping code to address 0 and converting a kernel 'jump through unset pointer' from a panic into a massive security hole (executing process code with the 'supervisor' bit set). Only if you do

Re: UVM and the NULL page

> The only reason I know for mapping address zero [...] > Anyway mmap() without MAP_FIXED should never return NULL. Perhaps it's time to implement null pointers as something other than all-bits-zero? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML

Re: UVM and the NULL page

This wine argument is mostly hypothetical. It can run plenty of programs with the disable in place. I know because I've used it since the change. See the following: http://web.archive.org/web/20150324113601/http://wiki.winehq.org/PreloaderPageZeroProblem On Mon, Dec 26, 2016 at 09:22:29PM +,

Re: UVM and the NULL page

On Mon, Aug 01, 2016 at 03:56:01PM +, Eduardo Horvath wrote: > On Sat, 30 Jul 2016, Thor Lancelot Simon wrote: > > > 1) amd64 partially shares VA space between the kernel and userland. It > >is not unique in this but most architectures do not. > > FWIW all the pmaps I worked on have

Re: UVM and the NULL page

On Mon, 1 Aug 2016, Joerg Sonnenberger wrote: > On Mon, Aug 01, 2016 at 04:46:34PM +, Eduardo Horvath wrote: > > > > I don't understand. If you can't enter the mapping into the TLB, who > > cares what UVM does? > > If UVM tries [0, n] and could have picked [1, n+1] as page numbers as >

Re: UVM and the NULL page

On Mon, Aug 01, 2016 at 04:46:34PM +, Eduardo Horvath wrote: > On Mon, 1 Aug 2016, Joerg Sonnenberger wrote: > > > I disagree. While it is nice to assert this property in the pmap, it is > > the wrong place. First of all, all pmaps need to be audited, at least on > > platforms with shared

Re: UVM and the NULL page

On Mon, 1 Aug 2016, Joerg Sonnenberger wrote: > I disagree. While it is nice to assert this property in the pmap, it is > the wrong place. First of all, all pmaps need to be audited, at least on > platforms with shared address space. It's not specific to x86. Second, > part of the problem is that

Re: UVM and the NULL page

On Mon, Aug 01, 2016 at 03:30:37PM +, Eduardo Horvath wrote: > On Sat, 30 Jul 2016, Joerg Sonnenberger wrote: > > > For what it is worth, I do believe that the handling of the 0 page > > should be part of UVM and not pmap. I am only objection to forcing it > > unconditionally. > > I

Re: UVM and the NULL page

On Sat, 30 Jul 2016, Thor Lancelot Simon wrote: > 1) amd64 partially shares VA space between the kernel and userland. It >is not unique in this but most architectures do not. FWIW all the pmaps I worked on have split user/kernel address spaces and do not share this vulnerability. Eduardo

Re: UVM and the NULL page

On Sat, 30 Jul 2016, Joerg Sonnenberger wrote: > For what it is worth, I do believe that the handling of the 0 page > should be part of UVM and not pmap. I am only objection to forcing it > unconditionally. I disagree. Based on the number of files you need to touch it's much better to

Re: UVM and the NULL page

In article <29bc17a0-924a-9eb3-ea57-196853642...@m00nbsd.net>, Maxime Villard wrote: >Le 31/07/2016 à 15:39, Christos Zoulas a écrit : >> In article <311df12c-d620-1c09-92f5-72783f392...@m00nbsd.net>, >> Maxime Villard wrote: >>> >>> My first proposion did

Re: UVM and the NULL page

In article <311df12c-d620-1c09-92f5-72783f392...@m00nbsd.net>, Maxime Villard wrote: > >My first proposion did not take care of the sysctl, because I didn't think it >was relevant. My last one does. Here is a patch for it. I believe it is safe >then to remove the va0_disable

Re: UVM and the NULL page

Le 30/07/2016 à 19:35, Thor Lancelot Simon a écrit : On Sat, Jul 30, 2016 at 07:12:31PM +0200, Joerg Sonnenberger wrote: For what it is worth, I do believe that the handling of the 0 page should be part of UVM and not pmap. I am only objection to forcing it unconditionally. Perhaps I

Re: UVM and the NULL page

On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote: > >IIRC some software relies on this feature, like emulators/wine. If > >really so then something like a sysctl to allow it again would be helpful. > > I thought about that. The only emulator-related problem I found is [1], >

Re: UVM and the NULL page

On Sat, Jul 30, 2016 at 07:12:31PM +0200, Joerg Sonnenberger wrote: > > For what it is worth, I do believe that the handling of the 0 page > should be part of UVM and not pmap. I am only objection to forcing it > unconditionally. Perhaps I misunderstood, but I thought we were all already agreed

Re: UVM and the NULL page

On Sat, Jul 30, 2016 at 11:52:59AM +0200, Maxime Villard wrote: > Le 30/07/2016 ? 01:35, Wolfgang Solfrank a ?crit : > > Actually, if this nonsense is committed, I will stop contributing > > to NetBSD! > > > > ? Leave, then. This is way, way out of line. Wolfgang has made many important

Re: UVM and the NULL page

On Sat, Jul 30, 2016 at 11:12:57AM +0200, Maxime Villard wrote: > This is something you generally don't need to remind people of, but I guess > I'll > have to here: you are neither my boss, nor my manager, nor my father, nor > whoever. You don't get to tell me "find a different solution" with

Re: UVM and the NULL page

Le 30/07/2016 à 12:54, Martin Husemann a écrit : On Sat, Jul 30, 2016 at 11:12:57AM +0200, Maxime Villard wrote: You know - as well as I do - that NULL pointer dereferences are quite common, and that it is the main way to execute malicious code in kernel mode. Sorry, but you are not making

Re: UVM and the NULL page

Le 30/07/2016 à 01:35, Wolfgang Solfrank a écrit : Actually, if this nonsense is committed, I will stop contributing to NetBSD! ? Leave, then.

Re: UVM and the NULL page

Le 29/07/2016 à 18:27, Eduardo Horvath a écrit : On Fri, 29 Jul 2016, Maxime Villard wrote: Anyway, the only thing I'm suggesting is doing it in amd64, so this is a little off-topic. Yes, and if it's for amd64 it should be done in the pmap layer, not polluting the UVM layer all other

Re: UVM and the NULL page

On Sat, Jul 30, 2016 at 11:12:57AM +0200, Maxime Villard wrote: > You know - as well as I do - that NULL pointer dereferences are quite > common, > and that it is the main way to execute malicious code in kernel mode. Sorry, but you are not making your point very clear, please try to explain in

Re: UVM and the NULL page

Maxime Villard wrote: > ... > You know - as well as I do - that NULL pointer dereferences are quite common, > and that it is the main way to execute malicious code in kernel mode. Allowing > NULL is a huge problem on architectures like amd64. The way you are talking > about compatibility sounds

Re: UVM and the NULL page

Le 29/07/2016 à 22:42, Joerg Sonnenberger a écrit : On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote: It is not possible to keep a sysctl, since VM_MIN_ADDRESS is a constant used in assembly, so it won't be turned to a variable. So find a different solution to fix the bugs.

Re: UVM and the NULL page

Hi all, Paul Goyette schrieb: On Fri, 29 Jul 2016, Joerg Sonnenberger wrote: On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote: It is not possible to keep a sysctl, since VM_MIN_ADDRESS is a constant used in assembly, so it won't be turned to a variable. So find a different

Re: UVM and the NULL page

On Fri, 29 Jul 2016, Joerg Sonnenberger wrote: On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote: It is not possible to keep a sysctl, since VM_MIN_ADDRESS is a constant used in assembly, so it won't be turned to a variable. So find a different solution to fix the bugs. Now,

Re: UVM and the NULL page

On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote: > It is not possible to keep a sysctl, since VM_MIN_ADDRESS is a constant > used in assembly, so it won't be turned to a variable. So find a different solution to fix the bugs. > > Now, it is a little hard to know how many

Re: UVM and the NULL page

On Fri, 29 Jul 2016, Maxime Villard wrote: > Anyway, the only thing I'm suggesting is doing it in amd64, so this is a > little off-topic. Yes, and if it's for amd64 it should be done in the pmap layer, not polluting the UVM layer all other architectures also use. Eduardo

Re: UVM and the NULL page

Le 28/07/2016 à 20:48, Pierre Pronchery a écrit : On 07/28/16 18:57, Maxime Villard wrote: Currently, there is no real way to make sure a userland process won't be able to allocate the NULL page. There is this attempt [1], but it has two major issues. [...] IIRC some software relies on this

Re: UVM and the NULL page

Le 29/07/2016 à 05:59, Matt Thomas a écrit : That is not true. Older ARM processors use a vector page located at 0 which has to be mapped into each processes address space. Now while the VA is mapped but it does not need to be writeable. You didn't understand what I said. The fact is that

Re: UVM and the NULL page

On Thu, Jul 28, 2016 at 08:48:51PM +0200, Pierre Pronchery wrote: > IIRC some software relies on this feature, like emulators/wine. If > really so then something like a sysctl to allow it again would be helpful. Yes, we have that (and it defaults to disabled everywhere, I think):

Re: UVM and the NULL page

> On Jul 28, 2016, at 12:21 PM, Maxime Villard wrote: > > Le 28/07/2016 à 19:45, Eduardo Horvath a écrit : >> On Thu, 28 Jul 2016, Maxime Villard wrote: >> >>> Currently, there is no real way to make sure a userland process won't be >>> able to allocate the NULL page. There

Re: UVM and the NULL page

Le 28/07/2016 à 19:45, Eduardo Horvath a écrit : On Thu, 28 Jul 2016, Maxime Villard wrote: Currently, there is no real way to make sure a userland process won't be able to allocate the NULL page. There is this attempt [1], but it has two major issues. I don't think this is a good idea. You

Re: UVM and the NULL page

On Thu, Jul 28, 2016 at 08:43:54PM +0200, Wolfgang Solfrank wrote: > Hi, > > > Currently, there is no real way to make sure a userland process won't be > > able to allocate the NULL page. > > Why should this be restricted? It matters on architectures with shared user/kernel VA. If you can map

Re: UVM and the NULL page

Hi, Currently, there is no real way to make sure a userland process won't be able to allocate the NULL page. Why should this be restricted? Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank

Re: UVM and the NULL page

On Thu, 28 Jul 2016, Maxime Villard wrote: > Currently, there is no real way to make sure a userland process won't be > able to allocate the NULL page. There is this attempt [1], but it has two > major issues. I don't think this is a good idea. You should leave this to the pmap layer rather

UVM and the NULL page

Currently, there is no real way to make sure a userland process won't be able to allocate the NULL page. There is this attempt [1], but it has two major issues. First, it is easy to bypass ([2]). The combination of parameters in the code makes sure this branch [3] is not taken, then [4] is