From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <3535ae9780efe698b30d5c4bf8f5b5b7@quanstro.net> References: <9ab217670904161636p62f77a18ufe0c14ac6245f078@mail.gmail.com> <3535ae9780efe698b30d5c4bf8f5b5b7@quanstro.net> Date: Thu, 16 Apr 2009 21:25:06 -0400 Message-ID: <9ab217670904161825k467a8a4ew31689b207f6ab984@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: df3f6a1c-ead4-11e9-9d60-3106f5b1d025 2009/4/16 erik quanstrom : >> >> My misunderstanding then, as smalloc is available in port/alloc.c, >> which is also compiled into the kernel. I'm not concerned about oom >> conditions in userland. > > smalloc is used in the kernel, but only when running with up (user > process) and only when dealing with a "user's" data. for example, > when gathering up the response to a read on /proc/%d/regs or > whatever. > > 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*. >> > having the potential for running out of memory in an interrupt >> > handler might be a sign that a little code reorg is in order, if you >> > are worried about this sort of thing. (and even if you're not.) >> >> The potential for running out of memory in an interrupt handler exists >> if a user has found a way to consume kernel resources from userland >> and the interrupt needs to allocate that extra 1 byte. > > doctor, doctor it hurts when i do this! there's a simple solution. > never allocate in interrupt context. i haven't ever felt the need > to allocate in interrupt context. in fact drivers like 82598 or > the myricom driver never allocate during operation. It was a point, not an argument. You're dismissing it altogether, I'm saying that it's a potential issue. No, I haven't read the interrupt code for every driver. It could be a complete non issue, and it probably is. I'm just discussing it :). >> > in any event, i think there is more code to deal with these problems >> > in the kernel that first meets the eye. much of it is small and, if you're >> > not looking for it, easy to miss. >> >> I don't think so. > > are you telling me this code is not there, or that you've seen all of it? I think we have a miscommunication, because you cut out the rest of the context of my explanation, so I don't know how to address your question. Neither; it wasn't the point I was making. >> > i have had exactly 1 out-of-resource reboot in the last 18 months. >> > without real data on what and where the problems are, i would >> > think this would become a difficult issue. >> >> I don't know what your use case is, though I know that you probably >> use the system more heavily than I. I think with people trying to find >> issues, it could be a much easier endeavor, and I think it's a fun one >> to address. > > i have 35 people working hard to kill the systems with 700MB mailboxes, > and other tricks. Which is more heavily than I, as I thought :) > but what they aren't doing is writing fork bomb programs or programs > that fuzz device drivers. Right, and that's a real threat. >> We're shielded in part by our small userbase and relative lack of >> interest in examining code and auditing. But that's not security. > > i could argue that what you're looking into isn't the type of > security that plan 9 has ever provided. i think the assumption > has been that the environment has been a work group and > there aren't any hostile users. there are lots of problems when > you move away from that assumption. 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. That said, I don't disagree. Perhaps Plan 9's environment hasn't been assumed to contain malicious users. Which brings up the question: Can Plan 9 be safely run in a potentially malicious environment? Based on this argument, no, it cannot. Since I want to run Plan 9 in this sort of environment (and thus move away from that assumption), I want to address these problems, and I kind of feel like it's weird to be essentially told, ``Don't do that.'' 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. Either way, the code is in development, and I'm going to finish it. Don't use it if you don't want to :) > i would think the *first* order of business would be to encrypt > all traffic to the fs so users can't use snoopy to captures other > user's fs traffic This is another serious issue. Perhaps I'll tackle it next. > - erik --dho