Tag Archives: Operating Systems

Speculating about SteamOS

It’s been a tremendously long time since any new content appeared here (I’ve even been considering shutting this web log down) but today I find myself eager to share some thoughts!

What could stir me from my slumber? Somewhat surprisingly I find myself uncharacteristically excited about a gaming platform and, as I no longer share an office with fellow nerds, I have no recourse other than to gush at the internet.

Despite not being a huge gamer (I have likely bought fewer than half a dozen games in the last two years) Valve’s recent announcement of SteamOS has me rather excited. There are three main paths along which my mind wandered when pondering what SteamOS could be:

Firstly, as a self-confessed operating systems nerd (and someone who has spent most of his career on the fringes of that world) I’m excited to see how Valve have architected their Linux-based OS. Whilst it’s possible that they could just choose to ship a spin of an existing Linux distribution (such as Ubuntu or Fedora) I’m hoping they’ve been a little more adventurous.

Thinking about SteamOS for a few minutes whilst browsing their announcement page a system more akin to Android in many ways comes to mind – a highly customised OS platform tuned to the needs of an entertainment device, rather than a stripped down generic OS. I’m certainly not drawing the comparison with Android because I’m expecting Valve to have written huge swathes of OS components that make SteamOS a different beast to a more traditional Linux, quite the opposite – I fully expect them to make use of the excellent Linux userspace which is readily available and widely tested. It’s how they put their OS together and structure things in terms of distributing software, updates and security (more below) which I expect to be different. Particularly as there’s unlikely to be any need to consider ‘legacy’ applications.

It’s perhaps unsurprising that I half-hope, half-expect Valve to be using the tools of the Yocto Project to develop their custom Linux-based OS. Standing on the shoulders of giants in the Yocto community Valve could, with a relatively small team of engineers, create their OS with a focus on the unique requirements of their entertainment platform instead of getting bogged down in the sundry, largely solved, problems of distribution construction.

Secondly, as someone with an increasing interest in information security and secure and trusted Operating Systems I see a good requirement in the platform for interesting security work. I look forward to interesting security solutions which balance human factors (I expect the SteamOS to be primarily driven by a joypad) with the need for a hardened OS which protects a user and their sensitive data (most likely banking details) from attack whilst ensuring the platform remains as non-intrusive as possible.

Finally, as a Linux developer, I’m rather excited about the prospect of folks (particularly some of my friends and family) having Linux-based entertainment machines in their living rooms. I’ve been thinking about a largely vapourware project to build a digital platform to enable pen and paper role players to game with their group, regardless of geographical separation. The project has remained vapourware, at least in part, because each imagined iteration has fallen short of anything tangible – largely because there hasn’t been a compelling platform to target. I have considered (and in some cases prototyped) targeting the XBox, the web and tablets, as well as writing a cross-platform desktop solution, but have hit road blocks when attempting to architect for each of them. (Side-note: huge kudos to the Roll20 team for realising the vision). I hope to be able to target SteamOS using the tools I am familiar with and re-using components of a gaming platform, such as multiplayer chat facilities.

Oh yeah, fourthly – video games! \o/

Update (14/12/13) – the first version of SteamOS was released yesterday and it looks to be a fairly stock GNU/Linux created as a Debian derivative.

Plenty of Space Left for OS-level Innovation

As one of the few people still left without circles to drag people into I had to find some other ways to occupy some spare cycles this weekend.

One of the things I ended up spending time with was videos from Apple’s WWDC 2011, as I was curious to see what core OS changes they are making with Lion.

I’ve long been a fan of Apple Engineering and admire the really great software they are building on top of their excellent Unix foundations. The highlight in Lion for me is probably the App Sandbox. Though XPC, Versions and push notifications/iCloud are all very interesting.

The App Sandbox gives each application which opts to use it a private container. File, network and hardware access are all prevented by default unless the app has registered for an exception. Once sandboxed the application can only access files within its sandbox, if the file access exceptions are enabled the user allows the application access to other files through the standard file access sheet (dialog) and behind the scenes the Powerbox has access to the full file system and gives file access to the selected file to the application.

This means in the worst case a compromised application should only ever be able to affect the few files the user has chosen to allow into the sandbox, rather than being able to wreak havoc with the entire file system.

The App Sandbox impresses me for many reasons:

  • Learning about it I had an aha moment, I immediately began to imagine the underlying implementation of such a container mechanism.
  • The developer positioning is excellent; “come play in our sandbox and we’ll keep you and your users safe” rather than talk of jails, etc. The positioning as a last line of defence seems wise also.
  • They have a well tested kernel-level technology for sandboxing from the iOS and are able to leverage this technology created for handsets on the desktop, thanks to their shared core OS.
  • It’s trivially easy to adopt for most developers and has a clear and easy to use migration path.
    All a developer need do is opt in to the sandbox, pick which of the small amount of exceptions (15 or so?) they want for their app and that’s it.
    Migration is handled through a manifest file which tells the OS where to pull files from on first run of the newly sandboxed application.
  • Powerbox is a badly named but cleverly designed arbitrator allowing applications to work as usual whilst still offering users protection. All the application need do is use standard Apple API’s and the OS does the real work.

Next I’m going to go and read up on Linux security mechanisms. I expect that at least one of the kernel-level security frameworks will enable such behaviour, I just wonder if they are so easy for developers to adopt. Guiltily I’ve gotten into the habit of disabling SELinux each time I do a clean OS install, because when it first started cropping up there were too many things I wanted to do which were blocked and not enough time, inclination or (if I recall correctly) documentation for me to work out how to get do them in a compliant way.

I wonder how much has changed in the intervening years and what SMACK and Tomoyo do differently?

Update: I may have mocked the term Powerbox but it’s not one Apple coined, browsing some security focused OS research I discovered the term again and a little more digging revealed that Wikipedia has a section on it in their File Dialog page and that Capdesk was the first desktop environment to include a Powerbox file dialog.

Interesting OS tidbits

Spent some time on Sunday reading about various operating systems. Fun things learnt:

1. /proc (procfs), as a concept, originated from Plan 9.
2. Windows NT‘s kernel is a microkernel, just like Minix and Hurd. Well, not just like. NT isn’t a pure microkernel, but I had no idea it even used some microkernel concepts.
3. Midori is the general use version of Singularity, Microsoft Research’s language-based kernel. Built using an extension of C#. It’s rumoured that Windows Mobile 8 will be built on Midori.

Thanks for the fun Sunday morning Wikipedia!