Re: page fault scalability patch final : i386 tested, x86_64support added

[Andrew Morton]

Matthew Wilcox <willy@xxxxxxxxxx> wrote:
>
> On Fri, Aug 27, 2004 at 10:39:54PM -0700, Andrew Morton wrote:
> > And we need larger atomic types _anyway_ for page->_count.  An unprivileged
> > app can mmap the same page 4G times and can then munmap it once.  Do it on
> > purpose and it's a security hole.  Due it by accident and it's a crash.
> 
> Sure, but the same kind of app can also do this on 32-bit architectures.
> Assuming there's only 2.5GB of address space available per process,
> you'd need 1638 cooperating processes to do it.  OK, that's a lot but
> the lowest limit I can spy on a quick poll of multiuser boxes I have a
> login on is 3064.  Most are above 10,000 (poll sample includes Debian,
> RHAS and Fedora).

It requires 32GB's worth of pte's.

So yeah, it might be possible on a 64GB ia32 box.

> I think it would be better to check for overflow of the atomic_t (atomic_t
> is signed) in the mmap routines.  Then kill the process that caused the
> overflow.  OK, this is a local denial-of-service if someone does it to
> glibc, but at least the admin should be able to reboot the box.

The overflow can happen in any get_page(), anywhere.  If we wanted to check
for it in this manner I guess we could do

	if (page_count(page) > (unsigned)-1000)
		barf();

in the pagefault handler.

But I don't think it's a serious issue on 32-bit machines, and on 64 bit
machines the 64-bit counter kinda makes sense?

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