linux-kernel - Re: [PATCH] Protection for exploiting null dereference using mmap

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]

Message-ID:  <loom.20070620T212046-804@post.gmane.org>
Date:	Wed, 20 Jun 2007 19:48:03 +0000 (UTC)
From:	Adam Jackson <ajackson@...hat.com>
To:	linux-kernel@...r.kernel.org
Subject:  Re: [PATCH] Protection for exploiting null dereference using mmap

Eric Paris <eparis <at> redhat.com> writes:
> On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > > This should be an unsigned long.
> > > 
> > > I wonder if the default should be for this value to be zero (i.e. preserve 
> > > existing behavior).  It could break binaries, albeit potentially insecure 
> > 
> > Agreed - DOSemu type apps and lrmi need to map at zero for vm86
> 
> And so it shall be!

X also needs to be able to map at zero for vm86, which makes this a lot less
useful.  In particular, the interrupt vectors need to point to the right place
within the VBIOS we're calling into, so we have to be able to map the zero page.
(And often write to it, if we're posting a non-primary card.)  Obviously this
isn't so much an issue for non-x86, where you have to use the emulator anyway.
And I'm pretty convinced that calling vm86 in a SMP environment is just suicide
so you _ought_ to use the emulator even on real x86.

We've already got the infrastructure in place to completely fake the real mode
address space for the emulator.  IWBNI we had some way of presenting a set of
virtual-address-space pages as contiguous to the vm86 task, since if we had that
we could just malloc 1M, copy in the bits we need, and go.  I don't know if vm86
mode supports that in silicon; it certainly isn't exposed in the API.  Anyone
know?

Actually it's a little worse than that.  Some chips have an escape hatch where
they remap banks of registers into the 64k VGA aperture, and the BIOS relies on
this.  So some of the pages need to be backed by device mappings, and some by
plain memory.  You'd really need either an array of pointers to userspace pages,
or a trap handler like how vm86 handles I/O cycles.  Again, I don't know offhand
whether vm86 can do this, but if it does then fixing X to take advantage of it
is pretty easy.

- ajax

-
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/