Re: CVS commit: src/sys/arch

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 27/11/2016 à 15:22, Joerg Sonnenberger a écrit :
> On Sun, Nov 27, 2016 at 12:21:48PM +0100, Maxime Villard wrote:
> > Le 26/11/2016 à 07:43, David Holland a écrit :
> > > On Thu, Nov 24, 2016 at 10:28:56PM +0900, Masanobu SAITOH wrote:
> > >  > > Put a one-page redzone between userland and the PTE space on amd64 and
> > >  > > i386.
> > >  > >
> > >  > > The PTE space is a critical region that maps the page tree, and bugs have
> > >  > > been found in both amd64 and i386 where the kernel would wrongly overflow
> > >  > > userland data on this area. This kind of bug is terrible, since it allows
> > >  > > userland to overwrite some entries of the page tree, which makes it easy
> > >  > > to patch the kernel text and get ring0 privileges.
> > >  >
> > >  > My emacs dumps core with change.
> > >  >
> > >  > What should we do?
> > >
> > > Make maxv clean up his mess, or rebuild emacs. It seems that the stack
> > > location gets baked in somehow when emacs dumps, although I don't
> > > really see exactly how (see PR 51654) and this causes existing emacs
> > > binaries to stop working.
> >
> > The real "mess" was having a critical x86 region sitting right next to
> > userland. I just fixed it.
>
> You "fixed" it by changing the VM layout. That's wrong. The correct
> approach would have been to shift the PTE by one page.

You cannot shift the PTE area by one page. This area is recursively
mapped by a single L4 entry. The smallest shift you can apply is 512GB,
which obviously collides with VM_MIN_KERNEL_ADDRESS.

If you have a better solution feel free, but to me reducing the VM
space by one page at the top is strictly the only solution.