Mill Computing, Inc. › Forums › The Mill › Architecture › Security of Self-Services & Inheritance
- AuthorPosts
- #1104 |
Two things. First, a design for a secure application; would it be reasonable on a mill? Then, some related questions about inherited/granted memory protection.
Say there’s an application that deals with a small amount of very sensitive data, with which it needs to be able to perform a few actions through a small api, but otherwise doesn’t need to know exactly what the data is. The goal is to reduce access to the sensitive data to the point where even if the application itself is completely hijacked, an attacker can’t get the sensitive data from memory (though she would still be able to access the api).
A typical example of this could be a TLS library and private keys of a server. The library itself does many things and has a large attack surface, but the necessary api around the private key itself is very small (e.g. ‘decrypt’ or ‘sign’).
So here is my mill-centric application design to solve this problem: As soon as the app starts up, spawn a private service that holds the sensitive data and provides a small api to use it via portal calls. (I say mill-centric because while this could be emulated on a conventional with a separate process and IPC, the latencies involved in task switching may outweigh the benefits.)
Is this design reasonable on a mill? Am I missing an obviously better design?
One problem I see with this design is that since memory is granted from a subset of the parent thread’s address space, the app would still have access to the service’s address space and the sensitive data even after it spawned. Is there a way to revoke/release your own regions for which you have permission? Instead, maybe the OS is responsible for spawning new services and threads, and therefore the service’s address space is granted from a different subset of the address space that doesn’t overlap with the application’s?
This is a central use-case of how we envisage Mill services being used.
There is a subtlety that a (software) private key as a service illustrates:
The private key had to be loaded from somewhere, and so its important that the turf the attacker exploits cannot itself access the key directly. So how can you create a child service to protect some data if the way it gets its data is by you giving it that data? You have access to the data too?
So the kernel may need to be aware of ‘user-space’ services within a ‘process’ (I use quotes as these are OS concepts and an OS on the Mill could do things differently) in order that a turf can rescind access rights to things.
This is rather like the POSIX (and Symbian) ‘capability’ model (quotes because a lot of people think them not capability models at all 😉 ), where you can rescind rights e.g. as a TCP server rescinds rights to bind on low ports after its started its listener.
So rights become something tracked at a turf level rather than at a ‘process’ level, with a process consisting of a collection of turfs and threads flying in close formation? This leads to thoughts about how operating systems conventionally track processes (or tasks, in L4 terms). A process is a collection of threads that share a user space. However, when you perform a Mill portal call, you are moving between protection domains (Mill turfs) without changing threads…
If the OS only allows you to create private services within a process, a hierarchical structure is maintained and its an evolutionary step for the kernel – which is still the intermediary for IPC – to track turfs as well as threads for a process.
However, the exciting ideas that the Mill also allows for is IPC to be between peers without kernel intermediary. However, this challenges how an OS conventionally tracks processes and determines the current running process and does things like preemption accounting and even so far as what
topandkillshow and do. So one thing the Mill may do for the state of the art is start a whole new chapter in OS research 😉And yes a turf can revoke your own protection regions. You can also imagine the OS being involved in turf creation so if you want to create a new child service, the OS can hand it unshared memory.
Sorry for the long rambling post. We’re happy to have this picked apart and discussed 🙂
When I think of an OS on the Mill, I think of turfs being associated with processes, services, and libraries.
A process has at least one persistent thread (which may be suspended for multitasking).
A service has threads launched by hardware interrupts, doing a quick job, then exiting.
A library has no threads associated with itself.
Libraries will export portal calls into themselves, services and processes may export portal calls.
When a process thread makes a portal call into a library/service, the thread remains associated with the process for general accounting purposes. Separate accounting for top and profilers of processes/turfs would make sense.I’m thinking a kill call aimed at a process should generally not immediately kill a thread currently running in another turf as that would tend to corrupt shared data structures in a library/service. The thread would continue until it returned to its home turf, but that presents another level of complexity.
This is a very interesting thing to think through 🙂
When a process thread makes a portal call into a library/service, the thread remains associated with the process for general accounting purposes.
What if a service maintains a work queue internally so it can do someone else’s work when you give it your high-priority slice? Perhaps it can be reasoned that this is a non-issue?
Some capability systems, Keykos in particular, had capabilities for accounting entities. With these, you can give your credit card to another process.
A similar mechanism could be created by grants to portals to functions that do the accounting. However, all that kind of machinery is way above the hardware. OS research guys will have fun with it – but then they will find a lot of fun on a Mill anyway 🙂
For most services I see work that can’t be done in the context of the requesting call being done in interrupt driven threads. One factor, a thread from process A may have access to perform the service for A, but not for process B when running service code.
Accounting time in a service to other than the nominal owner of a thread is hard if you don’t trust the service on the matter. In a general case one process (system scheduler in this case) knows little of how another works.
The reason you want to kill it may be that it is hung inside the portal-called function.
As Will said – the facility opens up all sorts of interesting possibilities for OS models. We designed it to ensure that existing OS models could be supported, with better performance. But that doesn’t rule out other models 🙂
- AuthorPosts
You must be logged in to reply to this topic.