The buffer handling is compleatly different in those two situations.
> As I said fork() is not the problem here its the bad control over system
> resources that brings down the system. And its possible that those
> system that you tested where configured against FORK bomb,but it does
> not make them immune against other attacks of the same kind(memory
> eating.)I heard of new Sun's HARD kernel,that protects memory very good,
> have look in it.
Oh if you are just after a user who is eating out much of systems
resource
then I have the following advice: man ulimits. (Actually you will find
it in man ksh or in the inferior man bash)
> About buffer overloading: i check some times securityfocus.com one of
> the most common of bugs under any OS is buffer overloading,and
> Linux/unix is not exeption. Mistakes do happen,this is why pencils got
I think you not the first guy out there with this wonderfull idea.
But in fact proper system protection does incorporate complete hardware
*virtualization*. This is something that isn't supported by many very
common
CPU designs out there. (IA32 for example) Yes it *can* be done like in
vmware,
but the perforamce penalty for this stuff is HUGE and doesn't justyfy
the gain
of security for the average user. (Guess what: only a minority of
computers is and allways will be on the internet!)
> erraysers. That example you showed me exec() it calls that function from
> c libraries ,c libraries ask KERNEL to execute the program. Because
> KERNEL is the boss,KERNEL controls everything thats going on. And i'm
> sure its possible to make kernel check. It would of be just very cool,
> if linux could do it,and any other OS couldn't.
Then think about why Sun made the HARD kernel an option and not the
default...
-- Marcin Dalecki- 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/