From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <58cb7333f8a8658b306517d4af6255c4@quanstro.net> References: <9ab217670904161825k467a8a4ew31689b207f6ab984@mail.gmail.com> <58cb7333f8a8658b306517d4af6255c4@quanstro.net> Date: Thu, 16 Apr 2009 22:17:18 -0400 Message-ID: <9ab217670904161917r7f272befn70569686d40ccf5f@mail.gmail.com> From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] security questions Topicbox-Message-UUID: df5a8400-ead4-11e9-9d60-3106f5b1d025 2009/4/16 erik quanstrom : >> 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? No, you brought it up first, asking if I had looked at it. I think this particular thread of discussion is agreed upon and tangential. >> > 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. Yeah, that's part of the reason I posted here, was to see if other people had different ideas. This usually isn't a bad place to pull in thoughts and solutions. And of course processes aren't the only `potential evil.' I agree that my solution may not be the best one. But I can't come up with anything better right now, and at least this seems semi-Plan-9-ish. > don't forget about the stack overcommitment issue. Heh. >> 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. This thread certainly proves that :) > 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. Point taken. >> 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. Point taken :). So are there other / better ideas? Did anybody else read that paper about Viengoos? > - erik --dho