Mailing List Archive

linux memory DOS
Hello,
Recently, when playing with memory managment on linux I've found funny
DOS, based on lazy memory allocation in linux kernel.
Namely, let's take following simple code:
______________________________________________
#include <stdlib.h>
#include <stdio.h>
main(){
char* ptr;
long int count,i;
count = 150000000;
printf ("I'll alloc %ld bytes\n",count);
ptr = (char *) malloc(count);
if (ptr) printf("OK\n");
else {
printf("failed\n"); return;
}
for (i=0; i < count; i++) ptr[i] = i % 255;
}
________________________________________
on linux box with 200Mb of total(RAM+swap) memory (tested on 2.2.5 and
2.0.36).
Run it, and you'll see, with /usr/bin/top for example, that size of memory
for this process is growing, when you're writing to the memory.
All other *nix I've tested (Solaris, FreeBSD) behaves in another manner.
They allocate all memory when malloc'ing.
That's OK, lazy memory allocation and new technologies in action :).
But now, let's run 2 programs like this. Both mallocs will be succesfull,
but when memory will over, your linux became very unusable. You can't
start new processes, and some of existing processes will die. You should
reboot it, or run all needed from console (inetd, sshd will die too).
I think this is very nasty DOS, which can appear even in real life (
i.e. as result of working usual userspace programs, not this "exploit").
Please reply to me directly, as I not on the list.
Nikolay.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
On Thu, 2 Sep 1999, Nikolay N. Igotti wrote:
> Recently, when playing with memory managment on linux I've found funny
> DOS, based on lazy memory allocation in linux kernel.
[snip overcommit nasties]
I've prepared part of the solution to this, a selection algorithm
which almost always kills 'the bad guy' when memory runs out.
People are using it and it Works For Them(tm).
However, every time I proposed it on this list it has gone down
in a salvo of flames. And I have enough disk for swap now so I
don't really care enough any more to fight that kind of resistance
again.
You can get the patch from my home page and I'm even willing to
help port it to 2.3 *IF* there's a good chance that it'll get
integrated. I'm just too busy to waste my time again...
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--
work at: http://www.reseau.nl/
home at: http://www.nl.linux.org/~riel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
On Thu, 2 Sep 1999, Nikolay N. Igotti wrote:
>I think this is very nasty DOS, which can appear even in real life (
>i.e. as result of working usual userspace programs, not this "exploit").
All 2.2.x kernels have also a potential deadlock condition in the
swapin-code. It spotted it down some month ago. You can trigger it only
going OOM (causing GFP to fail).
At first I fixed it in the page-fault generic code, but Linus suggested me
to do the right thing and to fix it in the core of the page-fault handler
code (as he did in 2.3.x). This change broken the handle_mm_fault
interface and so all archs will need to be updated (i386 and Alpha are
just updated with only my patch applyed). BTW, Alpha was not sending the
SIGBUS accessing a shared mapping beyond the end of the file (I fixed such
bug too in the patch).
Also in i386 now the kernel send a SIGTERM and not a SIGKILL if a process
running in iopl() > 0 goes OOM (so X won't be able to screw-up your
display anymore only by going OOM).
With this patch applyed you can still forbid the admin to alloc the memory
to run `kill`, but at least the machine won't deadlock.
ftp://ftp.suse.com/pub/people/andrea/kernel-patches/my-2.2.12/oom-2.2.11-H
But before to try again I suggest you to apply also this performance
patch and you'll get at least some more performance while the hard-disk
trashes ;).
ftp://ftp.suse.com/pub/people/andrea/kernel-patches/my-2.2.12/trashing-mem-2.2.10-A
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
> However, every time I proposed it on this list it has gone down
> in a salvo of flames. And I have enough disk for swap now so I
> don't really care enough any more to fight that kind of resistance
> again.
I'm all for it going into the main kernel tree, for what its worth.
Rene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
> > However, every time I proposed it on this list it has gone down
> > in a salvo of flames. And I have enough disk for swap now so I
> > don't really care enough any more to fight that kind of resistance
> > again.
>
> I'm all for it going into the main kernel tree, for what its worth.
I don't think its the Right answer, but its certain a right answer. Lets
see if we can get the Beancounter work Andrey Savochkin has been doing
into 2.4.
(ftp://ftp.nc.orc.ru/pub/Linux/people/saw/kernel/userbean.5)
Thats putting hard per user limits on stuff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: I vote for updated RAID and KNFSD [ In reply to ]
On Thu, 2 Sep 1999, David Woodhouse wrote:
> > I have no problem with the updating of tools... if I didn't want to
> > upgrade tools, I don't have to upgrade kernels either, right?
>
> > I say, do the updates.
>
> Anyone who has refused to upgrade their userspace tools since installation is
> almost certainly running daemons with known security exploits in them.
>
> What are these people whinging about, and why are we bothering to listen to
> them?
>
> Tools change. Bugs are found and fixed, and sometimes you have to upgrade.
> Get used to it - it's not going to stop happening.
i second that. We use linux for school here and i'm almost getting used to
patching stock kernels to get nfs, smp or somethink like that to work
>
> If people want a system where they don't have to upgrade their tools to fix
> known bugs, then they should opt for something commercial which doesn't
> actually bother to fix such bugs under the next 'service pack'.
>
>
win nt ?????? ;-)
--
Robbert Muller
mjrider@writeme dot com | Never let a luser on your console.
uin: 9659330 | Because that means they're in your room.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
Just for the record, my computer went down because it ran out of memory
today. I guess it killed a few things before it chanced on X (which killed
pico, which was what had used the remaining 15 megs..) , because logging
in again froze up the machine.. thats no good.
Rene
On Thu, 2 Sep 1999, Rik van Riel wrote:
> On Thu, 2 Sep 1999, Alan Cox wrote:
>
> > > > However, every time I proposed it on this list it has gone down
> > > > in a salvo of flames. And I have enough disk for swap now so I
> > > > don't really care enough any more to fight that kind of resistance
> > > > again.
> > >
> > > I'm all for it going into the main kernel tree, for what its worth.
> >
> > I don't think its the Right answer, but its certain a right
> > answer. Lets see if we can get the Beancounter work Andrey
> > Savochkin has been doing into 2.4.
>
> We probably want both in. The beancounter stuff can prevent
> a lot of DoS emergency situations and the program killer is
> able to get the machine back to work with minimal damage in
> the rare situations that it gets out of hand.
>
> Rik
> --
> The Internet is not a network of computers. It is a network
> of people. That is its real strength.
> --
> work at: http://www.reseau.nl/
> home at: http://www.nl.linux.org/~riel/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
For the record, this same thing happened to me two days ago. X->pico. Maybe
my fault for pico(ing) a 120M file (bash autocomplete mishap).
Matthew
On Thu, 02 Sep 1999, Rene Chaddock wrote:
> Just for the record, my computer went down because it ran out of memory
> today. I guess it killed a few things before it chanced on X (which killed
> pico, which was what had used the remaining 15 megs..) , because logging
> in again froze up the machine.. thats no good.
>
> Rene
>
> On Thu, 2 Sep 1999, Rik van Riel wrote:
>
> > On Thu, 2 Sep 1999, Alan Cox wrote:
> >
> > > > > However, every time I proposed it on this list it has gone down
> > > > > in a salvo of flames. And I have enough disk for swap now so I
> > > > > don't really care enough any more to fight that kind of resistance
> > > > > again.
> > > >
> > > > I'm all for it going into the main kernel tree, for what its worth.
> > >
> > > I don't think its the Right answer, but its certain a right
> > > answer. Lets see if we can get the Beancounter work Andrey
> > > Savochkin has been doing into 2.4.
> >
> > We probably want both in. The beancounter stuff can prevent
> > a lot of DoS emergency situations and the program killer is
> > able to get the machine back to work with minimal damage in
> > the rare situations that it gets out of hand.
> >
> > Rik
> > --
> > The Internet is not a network of computers. It is a network
> > of people. That is its real strength.
> > --
> > work at: http://www.reseau.nl/
> > home at: http://www.nl.linux.org/~riel/
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
--
To segfault is human, to blue screen is moronic...
~~~~~~~~~~~~
Matthew
matthew@mattshouse.com
http://www.mattshouse.com
--
To segfault is human, to blue screen is moronic...
~~~~~~~~~~~~
Matthew
matthew@mattshouse.com
http://www.mattshouse.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
Followup to: <Pine.LNX.4.10.9909022224480.18610-100000@zorro.pangea.ca>
By author: Rene Chaddock <renec@zorro.adsl.pangea.ca>
In newsgroup: linux.dev.kernel
>
> Just for the record, my computer went down because it ran out of memory
> today. I guess it killed a few things before it chanced on X (which killed
> pico, which was what had used the remaining 15 megs..) , because logging
> in again froze up the machine.. thats no good.
>
> Rene
>
Heuristic #1 should be that any process with IOPL should be dead last
in kill priority. Perhaps root-owned processes should be allowed to
set a "don't kill me no matter what" flag, too.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: linux memory DOS [ In reply to ]
I think that this problem seems to be theoretical, and can't be solved
with different "program killers", as criteria to kill is _very_ heuristic.
The problems is:
1. should we allow succesfully allocate more memory, that we can really
give, in hope that we'll have it in the future.
2. if answer to 1. is true, then we should _correctly_ handle cases when
application will be out of memory not when malloc'ing, but when
reading/writing. Maybe send signal, or message box:
"You program/kernel performed illegal operation.." ;))
Anyway, current situation is completly unacceptable for me.
Thanks,
Nikolay.
On Thu, 2 Sep 1999, Rene Chaddock wrote:
> Just for the record, my computer went down because it ran out of memory
> today. I guess it killed a few things before it chanced on X (which killed
> pico, which was what had used the remaining 15 megs..) , because logging
> in again froze up the machine.. thats no good.
>
> Rene
>
> On Thu, 2 Sep 1999, Rik van Riel wrote:
>
> > On Thu, 2 Sep 1999, Alan Cox wrote:
> >
> > > > > However, every time I proposed it on this list it has gone down
> > > > > in a salvo of flames. And I have enough disk for swap now so I
> > > > > don't really care enough any more to fight that kind of resistance
> > > > > again.
> > > >
> > > > I'm all for it going into the main kernel tree, for what its worth.
> > >
> > > I don't think its the Right answer, but its certain a right
> > > answer. Lets see if we can get the Beancounter work Andrey
> > > Savochkin has been doing into 2.4.
> >
> > We probably want both in. The beancounter stuff can prevent
> > a lot of DoS emergency situations and the program killer is
> > able to get the machine back to work with minimal damage in
> > the rare situations that it gets out of hand.
> >
> > Rik
> > --
> > The Internet is not a network of computers. It is a network
> > of people. That is its real strength.
> > --
> > work at: http://www.reseau.nl/
> > home at: http://www.nl.linux.org/~riel/
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/