Re: [9fans] security questions

[erik quanstrom <quanstro@quanstro.net>]

> > interrupts are quite different.  there are lots of things that are
> > a bad idea in interrupt context.  but one can wakeup a kernel
> > proc that's sitting there waiting to deal with all the hair.
>
> Right, we're saying the same thing backwards. I just am not sure why
> smalloc was brought up. Yes, it is able to sleep until memory is
> available for the operation, but it's not used *everywhere*.

that's part of my point.  sometimes smalloc is appropriate,
sometimes it is not.  it depends on other things than just
what you are going to use the allocation for.

do you have a particular, concrete example?

> > but what they aren't doing is writing fork bomb programs or programs
> > that fuzz device drivers.
>
> Right, and that's a real threat.

but you can't defend against it unless you decide you
can have exactly n processes per system and each one can
have 1/n * userlandsize bytes of memory.  you could divvy
up memory by user to be a little bit more flexable, but
providing hard guarantees is going to be very limiting.

don't forget about the stack overcommitment issue.

> Yes, there are, but it doesn't mean that it's an invalid assumption.
> If you're arguing that my point is invalid because it's not a proper
> application of Plan 9, I'd argue that Plan 9 isn't fit for the
> Internet, where there are malicious users and script kiddies.

i just stated what i thought the historical situation was.  the
point was only that changing direction will be difficult.

i don't think the second part of your argument holds.
defending from a local threat (like a fork bomb) is much different
from defending against script kiddies.  it's also much harder.

also, script kiddies don't do a good job of targeting plan 9.

> If you don't want to run Plan 9 there, ok. Maybe I'm the only one on
> the list who does. Maybe someone will come out later who also wants
> to.

if i didn't think this could be useful, i wouldn't
bother replying.

- erik