Bromium vSentry now runs on Windows Server, but what's all this about supporting XP & VDI desktops?

Yesterday Bromium released vSentry 1.1, adding support for Windows Server while also claiming to now support Windows XP, 32-bit Windows 7, and VDI desktops.

Yesterday Bromium released vSentry 1.1, adding support for Windows Server while also claiming to now support Windows XP, 32-bit Windows 7, and VDI desktops. In truth, the only new feature added is support for Windows Server 2008 R2, which ultimately means that you can now publish vSentry-secured applications to users running any OS. To that end, Bromium could just as easily say they support Android, iOS, Linux, Windows CE, and Wyse Blazer. I'm mentioning this at the top of the article not to take anything away from what is really awesome technology, but because I feel like we need to level set exactly what's going on. Now let's break it down...

I'm a fan of vSentry's approach to security, but I wish it could work on all desktops in all situations, not just Windows 7 x64 physical desktops in an organization that has an Office KMS server (that's a long story, but according to Bromium it's required to comply with MS licensing). That said, this is advanced technology that requires advanced hardware and a surplus of memory to function well, so it's understandable that there are limitations. The licensing complications are, sadly, more or less expected at this point. (I'm looking at you again, Microsoft)

Because of those limitations, a lot of systems are left off the compatibility list. VDI virtual machines, for example, can't take advantage of vSentry because it's not possible to virtualize the VT extensions that vSentry leverages to create its micro-VMs. For the same reason (lack of VT), older physical desktops are also left in the dark. It also means that 32-bit machines aren't included because of the limited amount of memory. *(While it is possible to pass VT through to VMs, vSentry requires ownership of VT, which can only be held by one entity. In a virtualized environment, that's the hypervisor. Thanks David Stafford and Icelus for pointing it out/clearing it up!)

Windows Server 2008 support, and RDS support specifically, can help deal with those challenges. On one hand, just being able to use vSentry on a datacenter hosted desktop is a leap forwards. There are far more RDS desktop and application users in the world than there are VDI users, and this technology now gives IT the ability to secure browsers (IE for now, more in the future) accessed via RDS. In the RDS world, where one bad user can screw over hundreds of other users and a downed server can throw off the balance in a farm, that's a big deal.

As I mentioned before, vSentry on an RDS server is how Bromium can tout the ability to secure Windows XP, 32-bit Windows 7, and VDI. Rather than running IE locally on those desktops, you can now "secure" them by accessing IE running in an RDS session that is also running vSentry. Make no mistake, though, this release of vSentry does not add native support for microkernel virtualization to those OSes. It just means that users can now connect to vSentry-secured browsers on terminal servers. Obviously, I’d prefer a native solution, but this can be useful.

There's one thing, though, that's causing me to think twice about this. The lack of VT virtualization means that to run vSentry on a server, that server must be a physical server with direct access to the VT extensions, despite the fact that the vast majority of terminal servers in the world today are virtualized. That means that in order to get vSentry-secured browsing on incompatible machines, you'll need to stand up a farm of physical terminal servers. Odds are that's a change in philosophy for you, and there is a cost associated with that. (But hey, you found a way to use all that rack space you freed up when your virtualized!)

So, does this change the value vSentry if I have to add physical servers to support incompatible machines? The answer, I think, comes down to how much you value security. In other words, you have to be willing to put up with a solution that’s limited to specific, physical hardware in order to get the level of security that vSentry offers. The underlying technology remains unchanged, and its capabilities remain impressive, but at the end of the day we're still talking about securing physical devices as opposed to virtual ones. I'm not certain that there's an easy solution to expand the technology beyond that. If there were, Bromium would have gone that route as opposed to this one.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Perhaps someone can chime in, but how does is vSentry handle state change that you want to persist after the thread is terminated?

Is there some sort of global whitelist/blacklist, how is user installed applications handled...


"VDI virtual machines, for example, can't take advantage of vSentry because it's not possible to virtualize the VT extensions that vSentry leverages to create its micro-VMs"

Just curious,,, What is missing for vSentry on VM's? - ESXi 5.1 with VM's at HW version 9 and VMware Workstation 8+,Fusion 4+ VM's and ESX 5.0 at HW version 8 all support VT-x and Extended Page Tables in guest VMs.


The Bromium gurus can correct me if I am wrong but vSentry requires ownership of VT where Hypervisors also require ownership of VT. VT only supports single owners so it is the limitation of VT that limits the uses of vSentry because of it's architecture.

Bromium is using VT for Security while Hypervisors are using VT for Management. It's currently a scenario where we either have to pick Security or Management but not both.

The only way I can see vSentry working with hypervisors is if they gave into this model and let the hypervisor do what it does best, provide the management. Maybe that means an out of band vSentry virtual appliance where the in band vSentry agent sends the request to it and passes it to the hypervisor, or maybe that means direct interaction with the agents to the hypervisor, not sure. But that won't be for many years.

Bromium is a great technology and a unique solution to the Security problem, but right now it's only useful running it on Physical environments with direct access and ownership of VT but with the clever use of application virtualization they can reach other endpoints.

Unfortunately it doesn't help our SMB scenario where we just have VDI and no RDS, and if I have to introduce RDS then that will just make VDI redundant. Basically we have picked using VT for management over security but I hope that one of these days we won't have to choose.


Thanks, Icelus, that's a good explanation. I'll update the article a little to avoid confusion.


I must add that Mac and Android support is great, but if they are targeting the enterprise shouldn't they go after the bigger piece of the pie (Windows CHVDs and SHVDs)?

I understand that the enterprise market share for CHVD and SHVD are insanely small compared to physical PCs, but I would say that the enterprise market share for Macs and Android devices are even smaller. And this is coming from a customer with around 50 Macs deployed so we aren't against them.

It has made me very uneasy that instead of tackling the VT problem, they are dismissing the CHVD and SHVD landscape and saying that customers would have  to virtualize IE in order to have a safe browsing experience. This is worrisome to me and IMO it would have been a better tactic to acknowledge CHVD and SHVD as a workspace as well as acknowledge the limitations of VT and vSentry and possibly consider alternatives to fully support the environments.


I am consistently humbled by the intelligence of this site's readership. Icelus is exactly right. I couldn't have said it better myself. Intel is exploring mechanisms to allow sharing of VT, it's on their roadmap, but I think it would be fair to say we are at least a year away from there.

To answer some other questions:

rahvintzu - We don't persist state we persist provenance. It's not like we keep a suspended micro-VM for every documents or file you save from untrusted vectors, we just remember that it came from an untrusted source and such when you open that file, it opens in a micro-VM. If it doesn't make sense I'd be happy to schedule a demo and walk you through how it works.

David - as Icelus pointed out, we need to own VT in order to create our hardware-backed isolation layer for each micro-VM.


With regard to Icelus' 2nd comment: I think I'd like to agree to disagree on the TAM for the CHVD and SHVD market. We're not interested in "taking over" desktop virtualization, that's a crowded space. We're interested in offering protection in depth to enterprises who are targets of advanced persistent threats.

Our goal is to exponentially reduce the attack surface of any organization that deploys us. If that organization has already invested in SHVD then we owe them a mechanism for protecting the SHVD infrastructure from APT's.

The only people who can "tackle the VT problem" are Intel. Part of our strategy is to explore devices that rely on other chipsets, especially as we move onto mobile platforms like Android.

We are always open to discussion on these topics. Nothing is written in stone. We're a small startup moving at a million miles per minutes, that means we're amendable to change. On that note, I'd love to have a call with you and talk through the strategy.


I wonder if the hypervisor manufacturers could create some sort of enlightenment capability that would enable sharing VT ownership. Alternatively, maybe it's possible to use some sort of hypervisor "plugin" approach - sort of like VMsafe. If all else fails, I assume it's possible to integrate this technology as a closed-source component inside an open source hypervisor, i.e. Xen.



Tal congrats on the progress. I believe the published app use case benefits should not be overlooked. Many organizations use XenApp for work from home access, disaster recovery etc. The application payloads here are little more than IE and Office.

As many know just because it's remote you can't assume that you won't be compromised through the client. This was a question asked my numerous people well before the Bromium existed. The response was better roadmap access gateway functionality.

Since the browser is so often compromised for malware and so on, the additional layer of Bromium has real potential value for every user who comes into the XenApp farm.

I'm not sure if Windows Surface tablets for the enterprise will ship with VT, but that's another use can I see where some will want to offer a more secure browsing experience.

1 million percent agree that Intel needs to enable VT sharing. Who ever does that first provides a good use case with Bromium like technologies to stay with Intel.

Tal, do you think AMD will ever play the game? I'd also love to hear if you think ARM based processors anytime in the next 3 years will be able to take advantage of your technology.



Thanks for the follow-up, it's much appreciated given our combative history ;).

Unfortunately talking with me would provide you little benefit because I am just a Sr. Programmer/DBA admin from a fed gov't SMB dept. A small cog that is in the middle of a take over coup by a central IT gov dept with a 2 billion/year budget and specializes in Cloud Computing.

We require some form of SBC for management of both of our internal/external users and since we are a small SMB and require UIA we believe majority SHVD is simpler than the RDS/Traditional PC combo.


Thanks for the info Tal, I think I will organise a demo via the official site.


Dan - we are exploring "all of the above", including "none of the above". What we end up doing will largely be defined by what our customers want.

Harry - we haven't dug deep into it, but plugging into AMD-V ( would be interesting if you could show me a TAM that would be worth the development effort. We're closely monitoring Intel's progress in the phone and tablet market because ARM-v7-A also has virtualization extensions, so both AMD and ARM are ostensibly "Bromium ready" :)

As for the Windows Surface Tablets, I believe the Surface Pro will have an i5 processors with VT.

Icelus - Well, I'm happy to discuss our strategy with you whether you're a customer or not, you're  a sharp chap.


@Gabe the license issue you mention. An explanation blog would be great.

Tal, hope the cross app policy management continues to evolve for your laptop use cases. If that happens when shared VT is available this could start to become very real.

I also wonder what the security model is for Bromium itself. It's software after all, which no doubt will have it's own set of bugs. If there is a security vulnerability in a Bromium world how would that be patched and how would the security model limit infection to only exploited instances or would every process potentially be impacted.


@appdetective: Nothing is bullet-proof. Our goal is to exponentially reduce the attack surface of your laptop. A 10^4 attack surface reduction is what we're shooting for. 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 tiny hardened code. This becomes the new "attack surface". So an attack that compromises vSentry by compromising the host first would likely succeed, but we have to ask ourselves: How would the attack compromise the host in the first place if vSentry was there first?

We are, as you likely anticipate, working on protecting against this attack (which we refer to as "insider threat") as well.. But I have nothing to report at the moment :) 10^4 will have to be sufficient for now.


@Tal Look forward to seeing the progress. Will be interesting to see what hacker world makes of it. I'll assume they'll see this as a new problem to crack as well as the various f'ed up governments that are well funded to research how to do it.

Would be cool to see if you can be hacked at Defcon and so on. If not, the external endorsements would instill a lot a more confidence IMHO.

Good luck, i'm cheering for you.


input this URL:

(  )

you can find many cheap and high stuff

Believe you will love it.




"VDI virtual machines, for example, can't take advantage of vSentry because it's not possible to virtualize the VT extensions that vSentry leverages to create its micro-VMs"

How come Utopic Software, another hardware isolation solution, doesn't suffer from this same issue?