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).
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.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
Matthew Wilcox <[email protected]> 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?
Matthew Wilcox <[email protected]> wrote:
>> 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).
On Wed, Sep 01, 2004 at 11:19:11AM -0700, Andrew Morton wrote:
> It requires 32GB's worth of pte's.
> So yeah, it might be possible on a 64GB ia32 box.
This only requires approximately 10922.666666666666 processes, which
has surprisingly been done in practice.
-- wli