From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3535ae9780efe698b30d5c4bf8f5b5b7@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 16 Apr 2009 20:00:12 -0400
To: 9fans@9fans.net
In-Reply-To: <9ab217670904161636p62f77a18ufe0c14ac6245f078@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] security questions
Topicbox-Message-UUID: df1f76da-ead4-11e9-9d60-3106f5b1d025

> > plan 9 doesn't have interrupt threads, but that's beside the point.
> >
> > interrupts are driven by the hardware, not users.  so smalloc, which
> > is used to allow user space to wait for memory if it is not currently
> > available doesn't make any sense.
>
> 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.

> > 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.

> > 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 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.

but what they aren't doing is writing fork bomb programs or programs
that fuzz device drivers.

> 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.

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

- erik