Guest blog from Simon Crosby explaining what Bromium is and how it works

With the release of Bromium's vSentry product, we figured we'd re-post this article from one of Bromium's founders: Simon Crosby. Simon submitted this as a guest blog post on June 20, 2012, where it has since received 7000 views and 17 comments.

With the release of Bromium's vSentry product, we figured we'd re-post this article from one of Bromium's founders: Simon Crosby. Simon submitted this as a guest blog post on June 20, 2012, where it has since received 7000 views and 17 comments.

Many of you know that Simon Crosby, former XenSource cofounder & Citrix CTO, left Citrix to cofound a new company called "Bromium." Bromium has been operating in stealth mode... until today. This is a guest post from Simon explaining what Bromium's technology is, how it will work, and what it can be used for. Simon's been a reader and commenter on this site for years, so don't hold back any commentary on his new company!

Bromium micro-virtualization: trustworthy systems by design

Bromium aims to transform the resilience of computer systems, making them affordable, manageable and trustworthy by design. We are aware that this is a lofty goal, and we know we can’t achieve it overnight. But we are confident that our architecture possesses key ingredients to dramatically advance the state of the art. It is simple, elegant and can be broadly applied.

We believe that a trustworthy system empowers the user without increasing risk to the enterprise, and can enable IT to securely navigate the challenges of consumerization, mobility, and personal use of enterprise devices. Bromium’s key innovation—micro-virtualization—is the key building block of a trustworthy system. Micro-virtualization protects vulnerable software (even when the device hasn’t been patched) and secures enterprise data at runtime, automatically discarding malware to deliver a resilient system—all industry firsts that save money and time, and keep users productive.

Bromium micro-virtualization is a second-generation virtualization technology that extends the isolation principles of virtualization into a running operating system (OS - let’s assume Windows for now). It is implemented by the Bromium Microvisor, a lightweight special-purpose hypervisor that is deployed as a small MSI package that extends a single, natively installed Windows desktop, making it naturally resilient in spite of user errors and software vulnerabilities, and protecting it when accessing data or code of unknown provenance and unfathomable trust. The Microvisor is completely hidden from the user, who enjoys a native desktop user experience.

The Microvisor automatically, instantly and invisibly identifies each vulnerable task and instantly hardware-isolates it within a micro-VM - a lightweight, hardware-backed isolation container that polices access to Windows services. Micro-VMs run natively, with full performance, but continually protect the system – even from unknown threats: A micro-VM can only access Windows services and resources via “enlightened” service APIs that cause the virtualization hardware to pause execution of the micro-VM (a hardware VM_EXIT) yielding control to the Microvisor.

The architecture specifically relies on Intel VT to guarantee that task-specific mandatory access control (MAC) policies will be executed, in a trusted execution context, whenever a micro-VM attempts to access key Windows services. It imposes tight control over access to sensitive files, networks and devices according to the “principle of least privilege”. The Microvisor creates micro-VMs instantaneously, and can easily control hundreds of concurrent micro-VMs on a modern (Core i3/i5/i7) PC. Micro-VMs are tiny because they contain only task-specific state, and they run natively. They are hardware isolated from each other and from Windows. Trusted and untrusted tasks can thus coexist on a single system with guaranteed mutual isolation. To Windows, micro-VMs are just tasks - it schedules them for execution, and tracks their performance and resource usage. Key properties of the system include:

  • When a micro-VM executes, any changes it attempts to make to its view of the “golden” IT provisioned Windows instance are “Copy on Write” or CoW. For example, if an attacker changes a Windows kernel memory page, it only succeeds in modifying an instantly created local copy of that page, and not the original.
  • Each micro-VM is granted only a narrow view of the file system that contains just the files it needs – an implementation of the principle of “least privilege” – with CoW update semantics.
  • When a micro-VM terminates (the user closes the window, or it terminates) the Microvisor discards the task’s memory image and uses a persistence policy to determine whether to persist any new files. Any persisted files are securely tagged with meta-data that encodes their provenance and trust; the Microvisor ensures that untrusted files can only be accessed from a micro-VM.
  • The Microvisor restricts micro-VM access to network services: Untrustworthy tasks cannot access “trusted” networks or “high value” SaaS/RDS applications, and access to “high value” sites over an untrustworthy network requires a secure end-to-end VPN.

Because micro-VMs are just tasks, their lifecycle and resource management must be automatic and instantaneous, in response to user actions. This permits us to use virtualization to deliver enhanced security and resilience without any change to the end user experience. It also means no new IT skill sets or tools are required to manage the Microvisor. The Microvisor is managed using simple enterprise policies and has no management console of its own.

The Microvisor’s attack surface is narrow. To escape from a micro-VM an attacker must compromise the system at the enlightened Windows service API – the hypercall API. The Microvisor does not trust hypercalls and the interface is implemented in less than 10,000 lines of hardened code. The architecture changes the attack surface of the system from O(10M) LOC to O(10K) LOC.

Micro-virtualization in Action

Micro-virtualization adds hardware-enforced task isolation to the operating system. It can be used to solve some of the most challenging problems in enterprise IT where traditional software abstractions for isolation have been shown to be inadequate. Some uses are discussed below.

Blocking advanced persistent threats

Recent security compromises have shown that sophisticated attackers use advanced malware to evade host and network based security. Using micro-virtualization it is possible to make end points vastly more secure.

By ensuring that each vulnerable or untrustworthy task (eg: opening a web page or an email attachment) is executed in its own micro-VM, Bromium can guarantee that a compromised task cannot access enterprise data or applications.

Bromium assumes that at some point a task in a micro-VM will be attacked and will be compromised. The granular isolation afforded by the Microvisor, together with the resource control policies, ensures that any attack will be confined to the micro-VM, that no enterprise data will be stolen, and that the attack will be automatically discarded.

Protection of Sensitive Applications

Increasingly, users need to access enterprise applications from untrustworthy networks. While it is possible to securely identify the user, the enterprise still cannot trust the device. If a key-logger or screen-scraper has compromised the PC then data from the application session can be stolen.

This problem can be overcome by first ensuring that all access to untrustworthy domains and documents is isolated in micro-VMs. Second, we can isolate access to the remote application within an additional micro-VM so that application data cannot be stolen. The Microvisor permits the micro-VM to communicate only with the authenticated remote application using an encrypted session. It can also enforce enterprise policies to prevent local storage/printing of sensitive data.

Data loss prevention

Bromium micro-Virtualization can empower every user with powerful Data Loss Prevention (DLP) features. An untrusted micro-VM cannot access files that are hidden by its resource policy, but it is possible to define policies that would allow this in some circumstances. For example, one could permit a user to attach a confidential document to an untrusted web mail, only if the document is encrypted when presented to the micro-VM, and the enterprise is securely notified.

Desktop virtualization done right

Many enterprises have been piloting deployments of Virtual Desktop Infrastructure (VDI) as part of their desktop virtualization strategy. But VDI is useful for only a small percentage of users. For the vast majority of users the preferred client form factor is the PC, with a strong trend toward laptops that serve a mobile workforce. Micro-virtualization delivers every benefit of VDI together with application security on the devices that users love to use – their PCs and laptops.

  • Every new micro-VM is created from the known-good golden image, which only changes under IT control
  • Enterprise data is protected at runtime, ensuring security and compliance
  • Users get to safely use enterprise data and applications both on- and off-line, from any network
  • The desktop is protected from malware, viruses and APTs
  • Granular policies for access to and distribution of enterprise data are applied on every PC, for every task
  • IT manages updates when it suits them, using existing tools for image management and patch distribution.

PC configuration & lifecycle management

Desktop administration teams in the enterprise are rightly concerned about the security of their desktops when new vulnerabilities are exposed and before devices can be patched.

Because Bromium assumes that any task may be compromised and because the Microvisor is designed to isolate compromised tasks, the desktop will always be protected, even with vulnerable software. IT staff can apply patches when it suits them and users, with full confidence that their systems are always protected.

Perhaps as importantly, Bromium enabled PCs do not need to be re-imaged when an attack occurs. The system shrugs off malware, keeping the system “gold”. This saves countless hours of IT time, reduces support calls, and keeps users productive.

Onward, toward trustworthy computing!

Bromium micro-virtualization adds granular, resilient task-based isolation to Windows. It has the opportunity to dramatically enhance security, simplify software lifecycle management, and to protect data at all times, by making endpoints trustworthy and resilient. It can achieve this without changes in management practice or toolsets, and without sacrificing the powerful native desktop user experience. It has the opportunity to be a key ingredient of any future trustworthy computer system.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Virtualization at last reduces complexity and services directly the things that matter most, applications and data.  Nice work Simon!


Sounds pretty awesome, it will be great to see a demo at some point.


Well done getting to this point, gotta respect that and they fact the VC are wet between the legs throwing money at you.

I do however wonder for this to be useful how tasks running in micro VMs talk to each other and not break the security model without creating management complexity?

Saw the Citrix Receiver announcement. WTF is that all about. That's a hopeless approach and hopefully a marketing thing only. The last thing we need is for Citrix to pick up yet another virt tech that they do nothing with.... But hey 500M last time and maybe more this time.

Congrats Simon and Bromium, look forward to seeing where this could go despite the many management challenges I expect you will face.



Good point. I am sure only trusted white listed apps will be able to talk to each other similar to the fork command but maybe Simon can clarify.


I applaud the effort you, Ian, Gaurav, and the  rest of the Bromium team has done with the Microvisor. I am sure the road ahead leads to a successful adoption rate because you have a one of a kind solution in your hands.

Taken to the extreme, it sounds like the stance of Bromium is the following:

- No need for VDI (but Client Hypervisor with is fine if you like to centrally manage patching OS and Apps)

- No need for AV

- No need for OS patching

I do hope that sometime you will give VDI a little more credit though.

It sounds like Bromium is saying FU to SBC in general but I still believe you are leaving out a large user base. I don't want to have to purchase laptops or invest in App Virt (when we don't want to manage apps) in order to work remotely. I want the same experience at work and at home. Bromium will be great on XenClient so everyone can have the same golden image, but Server Hosted seems to be completely ignored.

IT consumerization has gone to the extreme in our environment and users install their own apps and even their own OS in some cases.

We have a large Mac user base that are running Fusion with Windows on it so I could use VDI for them.  We are only interested in Desktop Virt and self service User Virt technologies like AppSense StrataApps.


Also Simon, I think there is a flaw in your theory that if you compromise a VDI desktop then you are in the datacenter.

We are building VDI on servers in our client subnet where our other desktops are located and outside of the datacenter.


@Icelus - Bromium is a security technology is isn't inherently tied to the application delivery model. Which is to say it isn't a replacement for VDI or App Virtualization or any of those things.  Rather it's an attempt at improving security with the key applications that are typical modern day exploit vectors namely the browser and email client.

@appdetective - As you say, the secret sauce is the delicate balance between interoperabiliy and isolation. This is really the area where Bromium will either succeed or fail trying to be overly secure without compromise for the nature of how user's work or it will be more open to interoperability while risking the very principles it's designed to protect.  Secret sauce indeed.



@appdetective - For what it's worth, I don't get the Receiver announcement either.  Unless it's simply a way to snag more partner/customer base I don't see where it fits.



@Icelus - As the Product Manager for AppSense StrataApps I'd love to hear more of your thoughts around your use case. I thought StrataApps and Bromium may be complimentary. Feel free to ping me directly.


@Shawn Bass

I understand that Bromium is not a replacement to VDI and I questioned it in their blog a while ago. However saying that, Bromium requires Hardware Virtualization and this is what I am understanding:

- It will work on traditional Desktops

- Fairly certain it would work on a Client Hosted Desktops

- Uncertain if it would work on VDI Desktops

- Uncertain if it would work on RDS Desktops


Hi guys. Thanks for the feedback, as you can imagine it's been NUTS since yesterday, but I wanted to cover a few things:

@appdetective - I talked to Brian about this. I want to actually put a Bromium laptop in your hands. I'm a big fan of your candor and technical aptitude and I'd welcome your honest feedback on the product. I've asked Brian to look into a way for me to give you a laptop while maintaining your anonymity.

@shawn I was serious when I said your tweet covered it well, I know you meant to be snarky but you nailed it. Chances are if a company has standardized on Receiver they'd actually be a perfect candidate for Bromium. We're not chasing the BYO play out the door, our first focus is on corporate imaged Windows laptops


@Bromium gurus:

The Microvisor is a welcome in-band windows addition for virtualization, do you see a benefit to in the future also introduce an out-of-band windows solution that monitors the status of the Microvisor contained within a VM? This might be similar to what McAfee is doing with DeepSAFE and is a great concept.

So in case the Microvisor of 10K LOC is compromised, then the out-of-band manager can automatically rectify the problem?

This would give use cases for Client Side and Server Side VMs, because as it stands now the Bromium Microvisor is rooting for Traditional PCs and is completely ignoring VMs that are and will continue to be implemented.

A use case for VM Desktops instead of Traditional Desktops is the ability to have single instance management of the OS and Base Apps. Without this, in a traditional environment you have to treat a PC as a unique case by case basic. Sure you can automate updates to all of the decentralized OS and Base Apps, but in the end it is much cleaner to have a single instance model.

Single instance management as either an OS, App, or User is a DevOps mentality. I am a Sr. Programmer in the Canadian Fed Gov't and I will always write my code to have the least amount of lines as possible, which means generic functions and code sharing as much as possible. The same applies here.

Sure enterprises have tools in place to do a task well, and that's fine, but they do not speak for everyone and if an organization has to evaluate to invest in the "traditional" toolset or the "VDI" toolset then I would choose VDI because of single instance management.

(By VDI I mean Server Hosted Desktops and Client Hosted Desktops because that is what is truely VDI, not what VMware called it.)

I also think VDI-in-a-Box is the best way to implement Server Hosted Desktops, not the other crap.

It is clear that you are on the side of Traditional Desktops, but this is going to be a mixed world that we live in and there will still be Server Hosted and Client Hosted virtual desktops.

Bromium should master these implementations just as they have mastered the Traditional Desktop! Hell, I would work for you for free to help!


Ok, getting to some of your other points:

@rahvintzu we will be demonstrating the technology at BriForum.

@Icelus we are not anti-VDI. we are anti marketing VDI as a security solution. look, most major attacks these days are zero days and malware is becoming polymorphic. single image management is as vulnerable to the aforementioned threats as a well managed physical desktop. our point is: deploy VDI for desktop management if you want, but don't do it under the auspices of security.

DeepSafe was a good idea, but it still suffers from the single proposition that the changes you reference must be detected. detection requires signatures, and signatures are vulnerable to zero day and polymorphic attacks. there's no magic CRC check you can perform on the kernel to tell if it's been infected by something you can't detect. it's must easier to do a check against hypercall API and the microvisor than it is to do the same against the entirely of the windows kernel.


Good to hear Tal,

Hopefully a Bri-video will be made during this time, for those of us on other continents.



Exactly how is (so called) micro virtualiazation is different from sandboxing, emulation, shims and what have you not?

At about 1:40 mark of your video (bromium. com) you make a claim that the software run is infact "hardware isolated" As an englush I would say that's utter bollocks (as myself I'd say I spell like craps)

Then we have on and on about security, I think you fckn nailed every cliche(! - :)

A hacker wouldn't blurt out *** the way you do.



@kimmo thanks for playing - let me ask you this: what sandbox technology that you know of today can protect you from a zero day attack or polymorphic malware?



The "magic CRC check" can be performed with formal verification like sel4 does, and it would have to be done out-of-band of windows so it can't be tampered with.

You guys have done an amazing job cutting the TCB 10 fold, and in doing so you actually might have created another opportunity to further extend into the realm of formal verification where it can only be done successfully on Virtual Desktops.


@Icelus Thanks! But WRT your first comment, I still think that telling the difference between "acceptable change" and "unacceptable change" falls back to the concept of blacklisting and detection-based protection. We *assume* that every micro-virtualized task is compromised at inception rather than exert resources trying to prove or disprove that hypothesis, we rely on task isolation to prevent any threat from compromising the underlying OS, filesystem, and network.

Once that's done then we move to your second paragraph about TCB - basically the only thing we have to detect for is the integrity of the hypercall API itself rather than the entire underlying kernel.

Make sense?