Re: [9fans] security questions

[erik quanstrom <quanstro@quanstro.net>]

> The benefit to this approach is that we would have an extremely easy
> way to add new constraints as needed (simply create another tunable
> pool), without changing the API or interfering with multiple
> subsystems, outside of changing malloc calls if needed. The limits
> could be checked on a per-process or per-user (or both) basis.
>
> We already have a pool for kernel memory, and a pool for kernel draw
> memory. Seems reasonable that we could have some for network buffers,
> files, processes and the like.

the network buffers are limited by the size of the network queues,
or they are pre-allocated.

you're right though.  there are a number of dynamicly allocated
resources in the kernel that are not managed.  in the old days,
the kernel didn't dynamicly allocate anything.  when things are
staticly allocated you don't have this problem, but everyone
complains about running out of $whatit structures.  if you
do dynamic allocation, then people complain about $unimportant
resource starving $important resource.

assuming a careful kernel and assuming that hostile users are
booted, resource contention is just about picking who loses.
and you're not going to get agreement that you're doing a good
job when you're picking losers.  ☺

- erik