Home | Community | Message Board
You are not signed in.
Sign In New Account
Forum Index Search Posts Trusted Vendors Highlights Galleries FAQ User List Chat Store Random Growery

Magic Mushrooms Zamnesia
This site includes paid links. Please support our sponsors.

General Interest > Science and Technology
Threaded Mode Threaded  Previous topic Previous  View all topics Index  Next topic Next 

Welcome to the Shroomery Message Board! You are experiencing a small sample of what the site has to offer. Please login or register to post messages and view our exclusive members-only content. You'll gain access to additional forums, file attachments, board customizations, encrypted private messages, and much more!

Shop: Myyco.com Golden Teacher Liquid Culture For Sale   Unfolding Nature Unfolding Nature: Being in the Implicate Order

Jump to first unread post Pages: 1
How to crash Linux?
    #13704543 -

I was wondering about the stability of Linux or unix like OS because I recently have some random unrecoverable freezes with Ubuntu 10.10.

Assume we have a stable Linux server. I use one with an uptime of > 250 days. I don't have root permissions.

Can I write a program, or is there a shell command, that will crash the machine?
I certainly don't want to try, but am interested in what stability actually means.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Annom]
    #13704559 -

as far as i know it's near impossible to crash or to have access needed to shutdown the system in normal user env

if quota is disabled you could fill-up the system with garbage that would work.


--------------------
A weekend wasted is never a wasted weekend

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Annom]
    #13704592 -

> Can I write a program, or is there a shell command, that will crash the machine?

I used to use a program called 'crashme' (back in the early 90s) to test Unix machines.  I don't know if it is still maintained or not, but it is a pretty simple concept.  The program uses setjmp/longjmp to recover from sigbus/sigsegv.  It then creates random garbage and passes this garbage as input to random syscalls.  Loop until crash.  You can probably find it archived in comp.sources.unix somewhere.  A good OS will do sanity checks on the arguments being passed in to any syscall.  A bad OS will panic.

There is another version of 'crashme' that tests machine instruction codes.  This is not the same thing, but will also cause crashes (potentially) on computers with buggy microcode.  Rather than attacking the OS, you are attacking the processor the OS runs upon.


--------------------
Just another spore in the wind.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: virus1824]
    #13704615 -

> as far as i know it's near impossible to crash or to have access needed to shutdown the system in normal user env

It is pretty easy to drop a computer to it knees.  Malloc a large chunk of memory, a single page at a time, and store a pointer to each page in an array.  Then write a tight loop that fits within the CPU cache.  Create a handful of threads to run the loop.  In the loop, check to see if the page exists, and if so write a single byte to each page that you malloc'd, at a different offset (use the array page index % prime number slightly smaller than page size).  If the page does not exist, malloc a new page.  Every so often free the page you just wrote to.  Every now and then fork a child process to double the above effort.  After a child has run for a while, let the child die.  Be sure the child releases the parent process group before spawning the threads.

The above does a lot of really nasty things that are difficult for the OS to meter.  By allocating and touching memory, you force the OS to keep the pages in real memory, and to spend a lot of time swapping to virtual memory.  By using lots of threads, you saturate multiple CPU/multiple core environments.  The tight loops use up your entire time slice given by the scheduler.  Forking child processes keeps the OS busy doing process forks and cleanups.  Dropping the parent process group makes it more difficult to meter resources used by a single process.  Because the children kill themselves after a few loops, the OS has a difficult time picking a bad process to kill when system resources expire.  You can get really nasty and run through our array of pages (index % prime) rather than (index++) to help thrash the CPU caches.

If you have a highly threaded OS, rather than a monolithic OS, you can have the children processes do other things as well, such as open lots of files to read and write (write to /dev/null and read from /dev/zero), open network sockets, etc.  Because syscalls can block, allowing the OS to schedule a new task, these are less effective.  However, they are still fun to include as they consume additional resources that would otherwise get a few CPU cycles.

A children that run tight loops that do floating point arithmetic can also help saturate the CPU.  Run through 0 to pi, calculating the square root of sin as quickly as you can... or play around with natural logs, etc.  Anything that uses built in functions of the floating point unit will be fine.  Again, tight loops to prevent paging which would give the scheduler an excuse to task switch.  Same idea as before, child runs for a bit with lots of threads, then exits.  The parent continues to spit out new children when possible.


--------------------
Just another spore in the wind.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Seuss]
    #13704945 -

Although I understood very little of that, Seuss, I found it strangely entertaining to read.  The whole time I was picturing the inside of a processor to look like this...


At 0:25 Seuss introduced his code! :lol:


--------------------
You invented the wheel....You push the motherfucker!!

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: ToTheSummit]
    #13705521 -

:lol:

Thanks for the answer Seuss! I get the basics. Seems like it does not happen accidentally by simply writing some stupid C code.

Can you still recover the OS if it is on its knees from your method?

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Annom]
    #13706139 -

> Can you still recover the OS if it is on its knees from your method?

Usually not, especially if you are running it from the console.  More often than not, you end up yanking the power cable (or holding the power button) to force a hard reboot.  You know it is bad when the machine stops responding to pings.

> Seems like it does not happen accidentally by simply writing some stupid C code.

I caused OS-X to kernel panic a few times with bad Open-GL code, but this was a few years ago.  I haven't seen snow leopard crash on me, but I haven't written much code for it lately.


--------------------
Just another spore in the wind.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Seuss]
    #13711347 -

Suess, I used to want to understand code on your level but I'm too stupid. I bet you have atleast a moderate amount of assembly under your belt(or twine that you use to hold your pants up). I remember malloc from C++ so I know you do that arcane shit.

I'll stick to scripting to control the code geniuses like you write.


--------------------
Never judge a man until you walk a mile in his shoes. But, by that time you're a mile away and you got his shoes, so fuck em.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Annom]
    #13711374 -

Annom said:
Can I write a program, or is there a shell command, that will crash the machine?
I certainly don't want to try, but am interested in what stability actually means.


You create a forkbomb, just run:

Code:
:(){ :|: & };:


This code basically keeps on creating processes until the computer run out of ram. Then will crash. This code doesn't cause any permanent harm to a system though.

The administrator can prevent a forkbomb by limiting the number of processes a user can own.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Seuss]
    #13713876 -

Suess, if the system admin limits the resources available to users, this method will effectively crash the system from that particular user's perspective but the system itself will remain usable to other users including the admin, who can just kill all the processes owned by the offending user.  Is this correct?

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: ChuangTzu]
    #13739492 -

Zoo, shut up troll!  None of that shit even makes sense.  I've been going to 2600 for 20 years.  Been in the upper part of Defcon for years.  Name the IP I'll take the system down! period.  (You need a satellite down)  These are the guys that make a living doing this shit. Do you even know what a transistor is, or lambda bleed over at switching over 1GHz.  It wont say "Free Kevin" this time.  I already got them made :bongload:  "Keep the Shroomery down"


--------------------

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: noesis man]
    #13739536 -

WTF are you blabbering about? 

You may have been going to 2600 for 20 years, but you're still less than a month old on Shroomery.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: ChuangTzu]
    #13739562 -

ChuangTzu said:
Seuss, if the system admin limits the resources available to users, this method will effectively crash the system from that particular user's perspective but the system itself will remain usable to other users including the admin, who can just kill all the processes owned by the offending user.  Is this correct?


It really depends upon the system and how good it is at protecting limited resources.  Typically, an Unix based OS limits resources on a per-process basis rather than a per-user basis.  The code I described is designed to make it very difficult for the OS to know what to limit.  Small threads that do not have any system calls will utilize their entire timeslice from the scheduler.  This keeps the user process running for as long as possible before the OS has a chance to intervene.  Small threads also saturate multiple CPUs and multiple cores, again to keep the OS away.  Forking new processes keep the OS busy when it finally does get a chance to run.  Because the child processes release their parent processes group, the OS will see them as an independent process (with init as the parent).  From the OS perspective, the user is running lots and lots of little processes, not one big giant process.  The children cleanly terminate after a short while of running; this keeps the OS busy cleaning up process tables and doesn't give the OS a target to limit because the processes are not running long (thus they are well behaved).

VM (virtual machine) based operating systems are much better at limiting system resources rather than user resources.  They allocate a certain amount of system resources to each virtual machine instance, thus if a user trashes their VM, the underlying machine/OS doesn't really care.

Quote:
noesis man
Zoo, shut up troll!  None of that shit even makes sense. ... Do you even know what a transistor is


I don't know if you are talking to me or to ChuangTzu.  Regardless, neither of us are trolls.  ChuangTzu is one of the smarter people that I know.  He knows much more about quantum physics and semiconductors than I do.  This is impressive as my background is in Electrical Engineering and Computer Science.  I have done work in PCB layout and VLSI design and have several papers published in IEEE journals related to semiconductor technology.

Quote:
DawksThe administrator can prevent a forkbomb by limiting the number of processes a user can own.


What I describe isn't really a fork bomb.  Forking is certainly a part of it, but the child processes are designed to utilize resources and die off after a short bit of time, thus the OS stays busy allocating and freeing resources.

There are always ways of preventing such attacks, but the more complexity added to the OS to meter resources, the less efficient the OS runs when everything is behaving properly.  With respect to computer security, there is a direct trade-off between security and usability; you increase one at the expense of the other.


--------------------
Just another spore in the wind.

Extras: Filter Print Post Top
Re: How to crash Linux? [Re: Seuss]
    #13739590 -

> I caused OS-X to kernel panic a few times with bad Open-GL code, but this was a few years ago.

Now that you mention it. I have caused a few crashes writing (simple) code for GPUs using CUDA. At least I didn't know what else to do than press and hold the power button.

>  noesis man: (You need a satellite down)

Yes, if you ask. GPS would be nice. I will let my GPS receiver log coordinates for the next 24 hours and see when you finished the job.

Extras: Filter Print Post Top
Jump to top Pages: 1

Shop: Myyco.com Golden Teacher Liquid Culture For Sale   Unfolding Nature Unfolding Nature: Being in the Implicate Order

General Interest > Science and Technology
Threaded Mode Threaded  Previous topic Previous  View all topics Index  Next topic Next 

Similar ThreadsPosterViewsRepliesLast post
* For anyone looking to try linux as a desktop OS
( 1 2 all )		 windex 6,371 37 02/07/03 02:32 AM
by Malformed
* Linux: A European threat to our computers YthanA 2,483 13 09/08/20 10:58 PM
by PsilyZee
* Best Linux/Unix Distribution? *DELETED*
( 1 2 3 all )		 T0aD 6,237 52 07/06/04 05:48 PM
by tomu
* Thinking about switching to Linux, need your help
( 1 2 all )		 moog 5,276 31 05/25/05 02:26 PM
by MAIA
* Linux+ certification monoamine 1,305 13 07/19/04 11:01 PM
by AhronZombi
* Why do you use Linux?
( 1 2 3 all )		 automanM 3,955 47 03/27/10 09:41 PM
by frith
* YaST crashes during partioning ummikko 1,105 16 04/14/05 05:57 AM
by MAIA
* Linux... sell me on it. ShroomismM 2,521 19 07/01/08 11:51 PM
by automan

Extra information
You cannot start new topics / You cannot reply to topics
HTML is disabled / BBCode is enabled
Moderator: trendal, automan, Northerner
823 topic views. 0 members, 3 guests and 6 web crawlers are browsing this forum.
[ Show Images Only | Sort by Score | Print Topic ]
Search this thread:

Copyright 1997-2026 Mind Media. Some rights reserved.

Generated in 0.029 seconds spending 0.007 seconds on 16 queries.