71–80 of 196 posts
Wait....this isn't new - hypervisor-based container isolation has been in Windows Server since 2016 (it's called Hyper-V containers).
One of the core elements of this for the Serverless fast boot requirement is using a kernel that has legacy modules excised.
I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…
From memory, I seem to recall that Genode takes this to its logical conclusion: every process is isolated with virtualization primitives. As to why: isolating processes the old way needs jails to work properly, BSD lost the popularity contest, and Linux jails didn't get secure enough before VMs and containers took off.
Could there be side channel attacks? At what level?
Perhaps the whole kernel design needs to be revisited, which I assume is what’s being taken on by Fuchsia.
Earlier quoted context omitted.
Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other techno…
Deploying a hypervisor on top of a hypervisor (eg: a public cloud) usually makes very little sense so I don't see that as a trend. However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) so hypervisors typically in the form of ESX is still very much a thing and now that we are seeing tighter integration with things like unikernels that is whe…
I work in traditional finance, outside of Silicon Valley and there is a huge drive to move to the public cloud. For the same reason banks do not own their office buildings anymore - managing computing infrastructure is not their core business and - to be honest - they are not very good at it. I know people who have to move servers and applications to a different data centre because the lease on an old DC is ending, it is a huge headache, and they would much rather concentrate on their core business.
I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…
There is a need, however, for some pragmatism.
While a capabilities-based OS could be the right solution, it doesn’t exist today.
What we have is code built for some flavor of POSIX. People demand cost efficiency today.
So, engineers do what’s practical: build a multi-tenant system running code that expects to be the owner of the hardware.
It works good enough! For most people, the cost efficiency math works out. The sand boxing overhead is worth it, as it pales in comparison to the headcount required to manage your machines, or even VMs, if you replace them with Serverless products.
I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…
Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other techno…
The unit of isolation should be the library, not the process. Each time you call into another developer's library, the library should have only the privileges you explicitly pass to it as capabilities, and you should be able to specify whether these capabilities may be delegated outside the receiving library and whether they can outlive the method call. So every time you call outside your own code assembly, you know that that call can't access the network, can't write to disk, can't display anything to screen. If you need it to, you explicitly pass the connection to a particular host or a handle to a particular directory, and then it can't access anything outside of that.
Not sure if this is feasible performance-wise: if you do it at the binary level, it seems like it'd require remapping page tables and flushing the TLB with every external function call, which'd absolutely kill frameworks that have to execute callbacks many times a second. But there's a certain intuitive sense to making the unit of trust & communication the code written by a certain organization, and it also fixes attacks like npm malicious modules that haven't gotten all that much attention nor have effective mitigations beyond "audit all your dependencies".
Earlier quoted context omitted.
Threads are not the same because they are separate computation in the same address space. At some point though, permissions to disk, network, screen, input devices, etc. need to be an integrated part of computing for anything that runs more than one program. Take a look at QNX though, at some point it will be reinvented and heralded as a breakthrough, 40 years after it happened the first time.
That's a good point. But as I think about it in a sense threads are also a form of isolation in that they allow you to isolate units of business code so that they can run independently and be (potentially) protected from other business code monopolizing a shared resource while not actually doing work.
Earlier quoted context omitted.
Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other techno…
An idea I've been toying around with but don't have time to fully explore or implement: The unit of isolation should be the library , not the process. Each time you call into another developer's library, the library should have only the privileges you explicitly pass to it as capabilities, and you should be able to specify whether these capabilities may be delegated outside the receiving library and whether they can…
I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…
Each alternative lands on a different balance at different times. Partly because of their own innate qualities, partly because of path dependency, partly because a "new" approach can sometimes reveal previously-unnoticed assumptions and partly because the ratios of CPU, RAM, disk and network performance are ever-shifting and thus favouring this or that architecture in the moment.
What tends to happen is that performance gains draw the first wave to a "new" technology. Then as the bulk of the industry begins to move, isolation, robustness and backwards compatibility become relatively more important. These impose overheads that will eventually be swept away by the next "new" technology.
There are still qualitative differences, though. Where you draw the firm lines in architecture affects the range of possibilities. I can place tenancy boundaries "anywhere", but in practice a VM hypervisor will be able to provide a firmer boundary than asking people not to share passwords.
Earlier quoted context omitted.
Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other techno…
This gets silly, though. If you are going for full isolation where applications can't just let the user have data, then you have to coordinate every app talking to every other app. This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options. Is it safer? Hard to say. I can do less and have less capabilities without more active work from the developers. There is…
Off topic, but I don't understand your objection...
On Android Chrome the share button shows you a context sensitive choice of apps that will accept the object (a link, some text, etc), followed by a second choice of what the app can do with the object.
The flow for copy-then-paste is more convoluted and is waaay less discoverable. Copy then paste is still available for the situations where it has an advantage.
Earlier quoted context omitted.
Threads are not the same because they are separate computation in the same address space. At some point though, permissions to disk, network, screen, input devices, etc. need to be an integrated part of computing for anything that runs more than one program. Take a look at QNX though, at some point it will be reinvented and heralded as a breakthrough, 40 years after it happened the first time.
Processes running on the same host are a "separate computation in the same address space" - They share a filesystem namespace. Pods running on the same kubernetes cluster are a "separate computation in the same address space" - They share a DNS namespace. Servers running on the same internet are a "separate computation in the same address space" - They share an IP namespace. These are the same abstraction at multiple…
Convergent evolution doesn't mean we should all become the same organism.