Linked by Thom Holwerda on Tue 20th May 2014 21:23 UTC, submitted by BloopFloop
OSNews, Generic OSes

Arrakis is a research operating system from University of Washinton, built as a fork of Barrelfish.

In Arrakis, we ask the question whether we can remove the OS entirely from normal application execution. The OS only sets up the execution environment and interacts with an application in rare cases where resources need to be reallocated or name conflicts need to be resolved. The application gets the full power of the unmediated hardware, through an application-specific library linked into the application address space. This allows for unprecedented OS customizability, reliability and performance.

The first public version of Arrakis has been released recently, and the code is hosted on GitHub.

Thread beginning with comment 589224
To read all comments associated with this story, please click here.
The spice must flow
by Dirge on Tue 20th May 2014 21:54 UTC
Dirge
Member since:
2005-07-14

Cool I have been seeing allot more OS and hobby OS news lately. Much prefer it to smartphone news. Cudos

Reply Score: 6

RE: The spice must flow
by bassbeast on Thu 22nd May 2014 18:21 in reply to "The spice must flow"
bassbeast Member since:
2007-11-11

I agree the more OS stuff the better, there is really no point in covering smartphone hardware as its "here today, gone this afternoon" and by the time the story reaches here its already been beaten by something better.

As for TFA my question would be...what is the difference between this and an application based VM? As that is what it sounds like they are going for, to have a basic hypervisor that only handles basic tasks like I/O and memory while the program gets center stage. This could be sweet for non Internet based applications but anything connected to the net would be at serious risk running "bare metal" hence why browsers and AVs have sandboxing, having separation of the application from the hardware is a good thing if it has access to the net thanks to bad actors.

I know TFA says the "application will handle it" but if that worked we wouldn't have zero days, no program is perfect and having layers at least makes multiple blocks a bad actor has to bypass to get to the hardware. If I'm reading this right the bad guy would only have to bypass the single application to have unrestricted access to the hardware...ohh that isn't good, not good at all.

Reply Parent Score: 3

RE[2]: The spice must flow
by Alfman on Thu 22nd May 2014 22:21 in reply to "RE: The spice must flow"
Alfman Member since:
2011-01-28

bassbeast,

I know TFA says the "application will handle it" but if that worked we wouldn't have zero days, no program is perfect and having layers at least makes multiple blocks a bad actor has to bypass to get to the hardware. If I'm reading this right the bad guy would only have to bypass the single application to have unrestricted access to the hardware...ohh that isn't good, not good at all.


I do not know the answers to your questions. It looks like this is more for scientific research than serving applications, security may simply be out of scope.

However speaking hypothetically about the security of this model, when the application is running on bare metal, the raw performance probably increases a little, but it's not obvious to me how bare metal applications could increase the scope of a breach?

Consider a regular user process on linux is successfully hacked, the hacker can access everything that the application could access (databases/files/network/etc). Other unrelated services may be isolated by the OS, but are still potentially at risk anyways even if the OS does not become compromised (smtp daemon, /etc files, unprotected home directories, side channel attacks, etc).

To be clear, I'm in favor of having OS security as well, but just to play devil's advocate: doesn't running a network facing application on a multiuser OS _increase_ the vulnerability surface compared to just running a network facing application with no OS?

Reply Parent Score: 3