On Mon, 1 Feb 1999, Matthew Dillon wrote:

> :So, never do stupid things as root; that's always my moto.  Well, so I did
> :something stupid as root, but it wasn't inherrently *that* stupid, at
> :least not stupid enough to require a hard boot :).  Below is the source
> :...
> :Except I decided to test that feature that overrides the device filename
> :(normally /dev/audit).  Instead, I chose /dev/mem.  Don't do that (ouch). 
> :The machine began to churn -- ok, so the buffer expands as necessary
> :without limit, which is something that will go away once I actually write
> :...
> :swap_pager_getswapspace: failed
> :
> :from the kernel.  And needless to say, it loops fairly tightly and we
> :...
> 
>     Uh.  Mmmmmm...... Hmmmmmm :-)
> 
>       i = read(fd, &size, sizeof(size));
>       ... malloc(bufsize * sizeof(char))
>       i = read(fd, buf, bufsize);
>     
>     When you are reading /dev/mem, 'size' can turn out to be anything.
>     You are then allocating 'size' bytes ( which could be some insane
>     value ).  Finally, you try to read() from /dev/mem into the buffer
>     the same insane value.
> 
>     The system is almost certainly trying to kill this process, but it
>     can't because the process is stuck in an uninterruptable system read()
>     of an insane amount of data.
> 
>     I don't think there is anything to 'fix' here.  The system is making
>     the best of a bad situation.  Perhaps, though, we could test for signal
>     9 within the insanely huge read() loops and pop out.

I did a signal test inside /dev/urandom (probably yet to be committed, but Bruce
said he was going to.)  There's no reason we can't do one here, but we may
have to break read()s of /dev/mem to smaller chunks to allow for this. Maybe
there is a better way to break out of a running system call, and have it
return immediately, but I haven't seen one.

> 
>                                               -Matt
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Feldman                                    _ __  ___ ___ ___  
 gr...@unixhelp.org                           _ __ ___ | _ ) __|   \ 
             http://www.freebsd.org/     _ __ ___ ____ | _ \__ \ |) |
 FreeBSD: The Power to Serve!      _ __ ___ ____ _____ |___/___/___/ 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to