9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] security questions
@ 2009-04-16 17:47 Devon H. O'Dell
  2009-04-16 18:30 ` erik quanstrom
  0 siblings, 1 reply; 94+ messages in thread
From: Devon H. O'Dell @ 2009-04-16 17:47 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

In the interests of academia (and from the idea of setting up a public
Plan 9 cluster) comes the following mail. I'm sure people will brush
some of this off as a non-issue, but I'm curious what others think.

It doesn't seem that Plan 9 does much to protect the kernel from
memory / resource exhaustion. When it comes to kernel memory, the
standard philosophy of ``add more memory'' doesn't quite cut it:
there's a limited amount for the kernel, and if a user can exhaust
that, it's not a Good Thing. (Another argument I heard today was
``deal with the offending user swiftly,'' but that does little against
full disclosure). There are two potential ways to combat this (though
there are additional advantages to the existence of both):

1) Introduce more memory pools with tunable limits.

The idea here would be to make malloc() default to its current
behavior: just allocate allocate space from available arenas in
mainmem. An additional interface (talloc?) would be provided for
type-based allocations. These would be additional pools that serve to
store specific kernel data structures (Blocks, Chans, Procs, etc.).
This provides two benefits:

 o Protection against kernel memory starvation by exhaustion of a
specific resource
 o Some level of debugalloc-style memory information without all of the overhead

I suppose it would be possible to allow for tunable settings as well
by providing a FS to set e.g. minarea or maxsize.

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.

2) Introduce a `devlimit' device, which imposes limits on specific
kernel resources. The limits would be set on either a per-process or
per-user basis (or both, depending on the nature of the limit).

#2 seems more like the unixy rlimit model, and the more I think about
it, the less I like it. It's a bit more difficult to `get right', it
doesn't `feel' very Plan 9-ish, and adding new limits requires more
incestuous code. However, the limits are more finely tuned.

Just wondering any thoughts on this, which seems more feasible, if
anybody would feel it's a `good idea,' and the like. I got mixed
(though mostly positive from those who understood the issue) feedback
on IRC when I brought up the problem. I don't have any sample cases in
which it would be possible to starve the kernel of memory.

--dho



^ permalink raw reply	[flat|nested] 94+ messages in thread

end of thread, other threads:[~2009-04-20 17:49 UTC | newest]

Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-16 17:47 [9fans] security questions Devon H. O'Dell
2009-04-16 18:30 ` erik quanstrom
2009-04-16 19:14   ` Venkatesh Srinivas
2009-04-16 20:10     ` Devon H. O'Dell
2009-04-16 20:19       ` Devon H. O'Dell
2009-04-17  4:48         ` lucio
2009-04-17  5:03           ` Eris Discordia
2009-04-17  9:47             ` lucio
2009-04-17 10:24               ` Eris Discordia
2009-04-17 11:55                 ` lucio
2009-04-17 13:08                   ` Eris Discordia
2009-04-17 14:15                     ` gdiaz
2009-04-17 16:39                     ` lucio
     [not found]                   ` <6FD675BC714D323BF959A53B@192.168.1.2>
2009-04-17 16:15                     ` Robert Raschke
2009-04-17 20:12                       ` John Barham
2009-04-17 21:40                         ` blstuart
2009-04-17 16:32               ` [9fans] VMs, etc. (was: Re: security questions) blstuart
2009-04-17 17:11                 ` tlaronde
2009-04-17 17:29                   ` erik quanstrom
2009-04-17 18:18                     ` tlaronde
2009-04-17 19:00                       ` erik quanstrom
2009-04-17 18:50                     ` blstuart
2009-04-17 18:31                   ` blstuart
2009-04-17 18:45                     ` erik quanstrom
2009-04-17 18:59                       ` blstuart
2009-04-17 19:05                         ` erik quanstrom
2009-04-17 20:21                           ` blstuart
2009-04-18 14:54                             ` erik quanstrom
2009-04-18 16:06                               ` Mechiel Lukkien
2009-04-19 20:52                               ` blstuart
2009-04-20 17:30                                 ` [9fans] VMs, etc maht
2009-04-20 17:44                                   ` erik quanstrom
2009-04-20 17:47                                     ` Devon H. O'Dell
2009-04-20 17:49                                     ` maht
2009-04-17 19:39                     ` [9fans] VMs, etc. (was: Re: security questions) tlaronde
2009-04-17 21:25                       ` blstuart
2009-04-17 21:59                         ` tlaronde
2009-04-17 23:41                         ` Mechiel Lukkien
2009-04-17 18:59                   ` Eris Discordia
2009-04-17 21:38                     ` blstuart
     [not found]                   ` <1322FA0842063D3D53C712DC@192.168.1.2>
2009-04-17 20:07                     ` J.R. Mauro
2009-04-17 19:02                 ` lucio
2009-04-17 21:01                   ` blstuart
2009-04-18  5:25                     ` lucio
2009-04-19 20:19                       ` blstuart
2009-04-17 19:16                 ` [9fans] Plan9 - the next 20 years Steve Simon
2009-04-17 19:39                   ` J.R. Mauro
2009-04-17 19:43                   ` tlaronde
2009-04-17 19:56                     ` J.R. Mauro
2009-04-17 20:14                     ` Eric Van Hensbergen
2009-04-17 20:18                       ` Benjamin Huntsman
2009-04-18  4:26                         ` erik quanstrom
2009-04-17 20:29                       ` J.R. Mauro
2009-04-18  3:56                         ` erik quanstrom
2009-04-18  4:12                           ` J.R. Mauro
2009-04-18  4:16                             ` erik quanstrom
2009-04-18  5:51                               ` J.R. Mauro
2009-04-18 12:52                       ` Steve Simon
2009-04-17 20:20                   ` John Barham
2009-04-16 20:51       ` [9fans] security questions erik quanstrom
2009-04-16 21:49         ` Devon H. O'Dell
2009-04-16 22:19           ` erik quanstrom
2009-04-16 23:36             ` Devon H. O'Dell
2009-04-17  0:00               ` erik quanstrom
2009-04-17  1:25                 ` Devon H. O'Dell
2009-04-17  1:54                   ` erik quanstrom
2009-04-17  2:17                     ` Devon H. O'Dell
2009-04-17  2:23                       ` erik quanstrom
2009-04-17  2:33                         ` Devon H. O'Dell
2009-04-17  2:43                           ` J.R. Mauro
2009-04-17  5:48                             ` john
2009-04-17  5:52                               ` Bruce Ellis
2009-04-17  5:52                               ` andrey mirtchovski
2009-04-17  5:57                                 ` Bruce Ellis
2009-04-17  9:26                           ` Charles Forsyth
2009-04-17 10:29                             ` Steve Simon
2009-04-17 11:04                               ` Mechiel Lukkien
2009-04-17 11:36                               ` lucio
2009-04-17 11:40                               ` lucio
2009-04-17 11:51                                 ` erik quanstrom
2009-04-17 12:06                               ` erik quanstrom
2009-04-17 13:52                                 ` Steve Simon
2009-04-17  1:59                   ` Russ Cox
2009-04-17 12:07                     ` maht
2009-04-17  2:07                   ` Bakul Shah
2009-04-17  2:19                     ` Devon H. O'Dell
2009-04-17  6:33                       ` Bakul Shah
2009-04-17  9:51                         ` lucio
2009-04-17 11:34                         ` erik quanstrom
2009-04-17 12:14                           ` Devon H. O'Dell
2009-04-17 18:29                             ` Bakul Shah
2009-04-17 11:59                         ` Devon H. O'Dell
2009-04-17  5:06                     ` Eris Discordia
2009-04-17  8:36             ` Richard Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).