[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    Re: [EROS-Arch] machine-level capabilities
From:       Seth Johnson <seth.johnson () realmeasures ! dyndns ! org>
Date:       2001-04-05 15:56:20
[Download RAW message or body]


Okay, that's all good.  And you're right, this is more of the area that
I'm concerned about.

Thanks.

Seth Johnson

"Jonathan S. Shapiro" wrote:
> 
> Taken in context with a question that Seth asked me privately some time
> ago, I now think that I understand what he is getting at.
> 
> A while back, Seth asked me privately if one could do "machine level"
> capabilities. After some discussion back and forth, it became clear that
> he was contemplating whether capabilities could be taken all the way
> down to protecting access to functional units and/or disk blocks.  Based
> on his current line of discussion, I'm guessing that what he's after is
> preserving the ability to run arbitrary software on the hardware, but
> without losing protection.
> 
> I want to preface my answer here by saying that at some level I think
> the question is mistargeted. We have, for example, considered the
> possibility of placing all of EROS on a chip, and the result is just as
> powerful as current processors (actually more so). If this were done, we
> would get to a world where the available chip architectures would be
> x86, mips, ..., eros-chip. I'm inclined to suggest that just as
> switching from x86 to mips doesn't change the "universal logic tool"
> aspect of the machine, switching to "eros-chip" would not lose this.
> 
> But in the context of the later discussion on BIOS's, I now think that
> Seth was really trying to ask a different question: how fine-grain can
> we make capabilities? Can we possibly get to the point where each
> functional operating unit of the machine is protected by one or more
> capabilities and still have a useful design?
> 
> The short answer is: "in abstract, yes, but for current hardware no".
> 
> The longer answer:
> 
> We could certainly build a microkernel that exists purely as a thin
> layer over the existing hardware, and permits (subject to capabilities)
> any action that the hardware permits. KeyKOS was certainly designed with
> this in mind, but it did not carry this down to the level of individual
> motherboard components. The VxWorks system actually allows you to
> compile in (or out) support for things chip by chip, though it isn't a
> capability architecture.
> 
> As a practical matter, we would have to do a certain amount of defining
> common APIs, because there are simply too many chips to deal with. This
> inevitably loses some of the full power of the underlying chips, but for
> a moment let us set this problem aside.
> 
> The larger problem is that chips don't exist in isolation, and that
> support chips generally aren't virtualizable. Let me use DMA controllers
> as an example.
> 
> A typical PCI controller has on-board DMA that speaks to physical
> memory. If one allows a program to directly manipulate the DMA
> registers, one thereby allows the program access to all of main memory
> -- and therefore full control over the machine.
> 
> One could imagine virtualizing this DMA programming interface in a way
> that permitted the DMA chip to be used, but only to overwrite authorized
> pages of memory. You'ld need to rewrite the software. At this point we
> are starting to introduce protection, but we have already lost the full
> flexibility that Seth is after. If the entire architecture (including
> support chips) were virtualizable, then this might be possible *without*
> losing full flexibility, but that is not true today.
> 
> The point is that useful protection requires choosing the right
> granularity of control. It must be low enough to be efficient and
> non-intrusive, but high enough that it can successfully control the
> interactions between the low-level components of the system.
> 
> The closest anyone has come (that I know about) is to build machines
> that are fully virtualizable, in which the architecture of the base
> machine can be efficiently simulated such that an operating system
> cannot tell whether it is running on the original machine or a
> simulation. There has been considerable and successful work on this.
> 
> In the end, however, I think the answer to Seth's question is pretty
> immediate: security, by definition, is about prohibiting undesired
> actions at a given level in the virtual machine hierarchy (what you do
> in the privacy of your own emulated machine is your business, provided
> you don't do it in the state of Connecticut, where they have legislation
> about such things). You cannot simultaneously prohibit things and
> preserve the full flexibility of the underlying machine.
> 
> Jonathan
> _______________________________________________
> eros-arch mailing list
> eros-arch@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/eros-arch

_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch

[prev in list] [next in list] [prev in thread] [next in thread]