Windows 10 Device Guard: Microsoft's effort to keep malware off PCs On Wednesday, at the RSA conference in San Francisco, Microsoft veep Scott Charney outlined a new security mechanism in Windows 10 called Device Guard. We've taken a closer look. The details are a little vague – more information will emerge at the Build event next week – but from what we can tell, Device Guard wraps an extra …
"Windows 10 kernel, which has total control over the PC, is compromised, Device Guard will remain fire-walled off"
So the kernel does not have total control over the PC because it can't reach Device Guard? That's a bit of an overstatement. Either the kernel has total control or does not, there's no middle ground in this.
More like "Device Guard will be running on a VM so the kernel can't mess with its internals" Of course, the kernel can stop the Device Guard VM and replace it with another. Or be patched to stop asking Device Guard for permission to run an application. So, compromised kernel still means compromised machine, as long as hackers take the time to create their own version of Device Guard.
The only additional barrier they are raising is that hackers now have to get their malware signed by Microsoft. Which seems they are making easy to do.
Cat and mouse. Forever.
"Of course, the kernel can stop the Device Guard VM and replace it with another."
No, that's not possible according to Microsoft's design. Read the article again, please, I think you missed an important point.
There's an always-on hypervisor, which runs under the kernel and Device Guard. Device Guard is allocated its 'secured' corner, the kernel gets the rest. The kernel controls the vast majority of the machine as a result, but the barrier between the kernel and Device Guard isn't controlled by the kernel. That separation is enforced by the hypervisor.
I didn't want to bog down the story with an OS development 101 class, so I kept it simple. But I think it's all clear if you read it through.
This is all in theory: as linked to in the article, previous secure execution environments on other platforms have been popped by bugs in the interface between the two sandboxes.
C.
In machines running type 1 hypervisors (I'm going to use HV because I'm tired of typing "hypervisor"), the kernel very rarely "gets the rest". Once you start slicing and dicing with a HV, you can have as many OS images as the HV and the hardware MMU supports, and each OS only sees the bits it's given access to by the HV.
This is the very nature of Virtual Machines. In some implementations, the OS does not even have to know it's running in a VM, as it's given what it thinks is real-mode access to it's own virtual address space, so it does not even know that other VMs and OS images exist on the same hardware, let alone be able to see or tamper with their memory.
Yes, I read the article and that was the point of my post. Article says
"If the Windows 10 kernel, which has control over the PC, is compromised,...."
vs. you reply saying
"The kernel controls the vast majority of the machine"
Small difference in words, big difference in meaning.
My reaction to hypervisors as a security mechanism is always, "Isn't that what the OS is supposed to do?" But, it's another layer. Kernels are big, necessarily include components written by third parties and do user facing operations (like IP stacks). There seems to be a recognition, as best I follow it, that we can write a much smaller, tighter kernel (the hypervisor) that does security and delegates the rest up the stack. The x86 has four protection rings, and it seems like we're finally catching up and putting device drivers in a separate ring.
I'm sure that there are aspects of this that I haven't appreciate, but from the Minix paper on IOMMU, I really cannot see how this specific feature provides the protection.
IOMMU is not a new concept. It's there to allow bus attached devices controlled access to the real memory address space of the machine for DMA type transfers. I first came across a feature to implement this was in the Unibus I/O address mapping system (Unibus map) in 16 bit PDP11 computers with 18 and 22 bit addressing extension back in the 1970s. The basic concept is to allow an I/O adapter controlled access to part of the main system memory in a way that does not allow access to bits outside of the control.
In that implementation, the OS set up the Unibus map for the I/O (Most Unibus devices were only 16 bit capable, so they needed a translation mechanism to be able to write outside of the first 64K of memory), and the DMA then occurs (it was more simplistic then, because there were no overlapped I/O operations, so differed I/O operations requiring the state of the UNIBUSMAP to be saved through context switches were not an issue). The protection offered was actually a side effect of the mechanism. This gave protection from rogue Unibus DMA transfers, but left control in the hands of the OS.
This is what is described in the IOMMU Minux paper, nothing else.
In order to implement something like this to provide protection from from the OS itself, it is necessary to have the checking code in a higher protection ring than the OS. This is normally reserved for type 1 hypervisors, and the capabilities for this have existed for many years. It would have been perfectly possible to add this type of function to the hypervisor or to a service VM running parallel to the OS, so the OS makes a hypervisor call to check the validity of, well, pretty much anything at all including checking the cryptographic signature of new code. In this way, running Device Guard as a service VM controlled by the hypervisor rather than the OS means that it cannot be tampered with by anything in the OS. This is what I think Device Guard actually is, supported by the statement "with its own minimal instance of Windows". Make the hypervisor and Device Guard also signed by UEFI, and it's pretty difficult to tamper with the system as a whole.
Of course, VM segregation requires an MMU and an appropriate security protection ring, and it is possible that this is why there is some confusion about which part of the MMU is providing the protection, but IMHO, it's not the IO function of the MMU described by the Minix paper, more the general features of a VM capable Memory Management Unit. It's probably the Extended Page Tables feature that is actually required for Intel processors.
This is the type of thing that IBM have been doing in their mainframe operating systems running under VM (the mainframe hypervisor product) or PRISM for many years. As I understand it, the RACF security system runs in a separate VM to provide additional security.
I suspect you are slightly confused here. To start with, IOMMU (as implemented in modern PCs) relies on hardware level isolation provided by CPU and PCIe root complex and managed by the hypervisor, i.e. lower level than kernel of a virtual machine. The innovative part in Windows 10 design is that the OS itself (as seen by the user) is actually a virtual machine with all PCIe devices passed through, running on top of a hypervisor, alongside with a different tiny virtual machine called Device Guard. Hardware level isolation is required to ensure that device passthrough will not be used to hack Device Guard (or hypervisor) from inside OS seen by the user (i.e. virtual machine employing device passthrough).
Of course, since the hypervisor itself is presumably closed source Windows, this just moves vulnerability point away from the user, rather than remove it (which arguably cannot be done anyway). If Microsoft used open source for hypervisor and Device Guard that would be really innovative (for them), nevertheless this seem like a good step to me. Perhaps because it's similar to my own setup (two Windows 7 VMs running on top of single Linux hypervisor with kvm/vfio device passthrough for GPU , USB etc.)
My main career focus recently, AIX on IBM Power servers has been providing virtualised I/O, with the hypervisor doing all of the basic device manipulation, and the communication from the hosted OS being handled by virtual devices for close on a decade (the main features were implemented in Power 5 systems running AIX 5.3, although basic LPARs and mapped/guarded device control was in earlier hardware and versions of AIX), so I do understand how a hypervisor can sanitise device access.
I also understand service Virtual Machines and also quite a lot about how I/O MMUs and the associated CPU MMU features work, included how nested page tables and hardware protection rings are implemented. There may be some novel aspects of controlling access to particular adapters/busses at a hardware level that is unique to Intel hardware, but although that appears to be the main function of Device Guard, it was not how the article was presented.
I was working on Virtual Machines using a hardware hypervisor on Amdahl mainframes (running UNIX) with device and memory page level hardware protection back in the late 1980s, so very little of this is new to me.
It is not me that is confused, except possibly about the way that the article was written.
So, just another layer of buggy crap wrapped around a bad idea that will change next to nothing for the user, unless it is the need for a more powerful CPU and yet more RAM because of the resource hog that this thing is going to be.
And when that solution has been proven to be useless and just as subvertible as anything else MS has tried, what next ? ANOTHER layer of software firewalled by hardware to ensure that the previous one is not bugged ?
Windows will not die because some other OS takes its market share by storm, it's going to die fibrillating in the throes of its own morass, and other OSes will just have to fill the void.
>Windows will not die because some other OS takes its market share by storm, it's going to die fibrillating in the throes of its own morass, and other OSes will just have to fill the void.
A trend that has reduced the amount people use Windows is a lot of productivity work can be done in OS-agnostic web browsers. This work can be responding to emails, or it can be CAD modelling hosted on AWS, as examples. Another trend is the use of mobile devices, mostly running Android or iOS. Still, I haven't seen anything that suggests the imminent demise of Windows.
Where did I say that the demise of Windows was imminent ?
What I said is that the demise of Windows is now inevitable.
But the coffers of Microsoft are such that said demise is going to take a bloody long time.
Even though some might say that it has started.
"When enabled/disabled by an administrator".
Isn't that (or something similar) what the UEFI lobby said? And now M$ is changing the emphasis there, so that you may not be able to turn of secure boot.
This thing is going to go the same way, as part of the War on General Purpose Computing and free software.
I fail to see in what way shape or form this will benefit the vast majority of users. Sure big enterprises with very locked down environments fine. most SMB style operations, not very much, home users not in any way.
Not to mention you need a separate patching regime for the Hypervisor and mini windows to keep them secure as well as the normal windows update mechanic will be unable to touch them.
Home Users are now getting free stuff that's "good enough" for them. Office Online (not 365)_ is free and good enough. W10 will be a free upgrade. The only revenue from home users is services (XBox music and video) and app sales which are tiny. Home users are only worth supporting at all because of "mindshare", it's the same reason that MS operating systems were always so easy to pirate.
Enterprise however, actually pays money. So they get stuff written to help them.
Not rocket science.
>I fail to see in what way shape or form this will benefit the vast majority of users.
If you become the administrator for your granny's laptop, you won't have to answer phone calls asking what some obscure security dialogue box means. Basically, you will impose a walled-garden on them, giving the same appeal as a Chromebook or iOS device. Many users won't be bothered that they can only use MS-approved software, since it will cover all their needs (email, skype, photo-editing, office tasks etc).
I'm over-simplifying, but I'm giving an example of how a home user *might* find this useful.
Trouble is that as the administrator for my granny's PC, I've already given her a limited user account. So I get calls asking to do SysAdmin tasks when either they want some things installed or something else needs updating and the updater needs admin privileges... So don't see this really saving much.
Basically, what this does is to force users to get all Windows applications and updates from the MS Store; and we all know the delights of walled gardens...
>Basically, what this does is to force users to get all Windows applications and updates from the MS Store; and we all know the delights of walled gardens...
My toaster is a walled garden. My kettle is a walled garden. My clock radio is a walled garden, and it never asks for updates. They are fit for purpose.
Walled gardens suit some people just fine. If a person doesn't know enough to turn this feature off, there is a fair chance they would be better off inside the walls.
Most dogma (such as 'walled gardens are always bad') are mental walled gardens.
If a person doesn't know enough to turn this feature off, there is a fair chance they would be better off inside the walls.
Actually, given what I've seen over the years, the issue isn't so much about a person not knowing enough to know how to turn something off, but not knowing/appreciating why it was on in the first place and modifying their behaviour accordingly.
With Windows we've seen this in spades as many users default to using as their normal account, one with 'admin' privileges enabled by default...
Walled gardens suit some people just fine.
Agree, I live with the iStore walled garden that limits what app's I can load on my iPad, so I also have an Android device which permits me to step outside of the walled garden as and when I find it necessary (just a shame it doesn't also let me have root access on the same terms).
As for your toaster, kettle etc. the extent to which these have become a walled garden has probably past people by: Putting aside costs, if the appliance fails it is unlikely that it can be repaired.
Presumably device guard has to live on the disk somewhere, and if I can get raw write access to the disk I should be able to kill it, no?
Or are they suggesting that Windows 10 is going to live on something like an LVM volume managed by the hypervisor? I'm not sure I like the sound of that. I don't see that playing nicely with my various multi-boot setups.
this is another band-aid,-- and it does not address the Core Problem: an application program should not be able to affect(compromise) its host operating software.
hacking involves corrupting a program that is already running via which privilege escallation may be obtained,-- thus to corrupt the o/s itself.
this fundamental issue must be corrected if MSFT/Windows wishes to become a viable commercial OS
I'd take one step back from that being Windows specific - given that most machines are really set up single user, I question why it is required to install software with admin rights so all potential system users have access to it.
I would love to have the option of running applications only inside my user environment. That would do away with the need for admin rights for installers (which is IMHO one of the biggest problems in keeping things secure as you give far too much in the way of rights to an app that should not need it), and it would contain issues with the app to that one user environment. Adobe, for instance, should be be allowed to go near any admin rights.
>>"That would do away with the need for admin rights for installers (which is IMHO one of the biggest problems in keeping things secure as you give far too much in the way of rights to an app that should not need it), and it would contain issues with the app to that one user environment. Adobe, for instance, should be be allowed to go near any admin rights."
This is not invalid, it's a common security principle in many areas. The problem with it though, is you end up with your user space starting to become a de facto admin space. There are so many things that software needs to do that can be harmful if subverted that you can only go so far down that road before you find it's not having much affect in terms of securing you. Userspace is not the panacea some people are starting to treat it as.
I agree about Adobe, however, and would actually extend that to not being allowed to go near a computer in the first place.
The support for this will probably be limited to a small selection of hardware. The main issue here is not that it's a bad idea to use an IOMMU (it's probably a good idea), the issue is that everything will be running under a hypervisor.
It will doubtless be Windows 8's Hyper V with improvements
The issues with this are
1) Speed. It will be (slightly) slower. A worthwhile tradeoff, perhaps.
2) Drivers. A VM is not the same as real hardware. It may break some drivers or degrade their functionality (particularly graphics drivers)
3) Communication between mini VM and the wider world. If it needs to do this, presumably it's via a network card and will require two IP addresses. If via the main Windows VM, that's an attack surface. It'd have to be an SR IOV compliant network adapter (more expensive), as otherwise multiple cables are require, surely.
4) Cross expansion card communication. An IOMMU only protects communication between a VM and a card/memory that is not assigned to it if the PCI-e root port the card is attached to supports ACS. Otherwise one VM with one card assigned, can write to the memory space of another card in another VM, when they both share the same (non ACS protected) root port. ACS is not supported on plenty of implementations
5) BIOS. You'll need a new system simply because the quality of consumer BIOSes for VTd/IOMMU is pathetic and manufacturers will not fix it because Windows historically hasn't needed it aka everything from Asus and 'we don't support Linux'
I'll be interested to see what happens when it's run under an existing Hypervisor - my Windows 8 installation already runs under a hypervisor (Xen), using an IOMMU (passthrough of network, graphics cards to the VM), on a Core2 CPU no less (not that I would recommend this)
The security record for hypervisors isn't bad, but there has been information leakage/denials of service between VMs and to the hypervisor itself. It's not a magic bullet.
The bright side of this is that running a decent hypervisor on commodity hardware may become substantially cheaper!
It is a can of worms, but I think probably not as bad. A fresh fish bait (rather than something old and mouldy), I'd say.
1) agreed, although virtualisation overhead in modern CPUs is really small, especially if hypervisor does not over-commit memory, CPUs etc.
2) and 4) agreed again, however I suspect this would be only enabled on certified machines with correct ACS support
3) it is possible that Device guard will not need communication with wider world but if it does, hypervisor could manage network card and set a bridge, with different IP for each VM. Of course this implies only certain cards would work, see above
5) again, I do not imagine that this would work on any old PC, so again some kind of certification would be needed
Also, since my Windows already runs under a hypervisor (and plenty of business with their own VDI setup) it is imaginable that this solution would only work for some some setups, where Windows 10 is installed bare metal on supported (and certified) hardware. All in all, I think it's a win for average consumer.
A huge number of malicious scripts come via advertising -- bad Javascript, bad Java, and Bad Flash.
I would love to see all unsigned,untrusted, Javascript being simply rejected. Would really force the ad industry to do quality control on their stuff before they try to insist that I run it on my machine.
"...primarily under *NIX based devices such as Android and IOS phones."
The vast majority are actually from Windows desktops, laptops and servers. Very soft targets those.
"Apparently they couldn't crack Windows Phone at the time though..."
It just wouldn't be worth the effort with such a small user base. Heck, there are more people in the world running Linux desktops.
Since when using a watchdog system to look after your OS is anything new? Lots of embedded systems do it already, for eons.
Tiny secure system keeps checking if big system is working. Big system crashes or misbehaves, tiny system kills big system, resets it to factory default, all is well.
You have to compromise the watchdog first to make it think everything is fine, and/or spoofing is not impossible either.
I see nothing new there.
DADDY whats that they are building around our garden it looks like a wall?
NO Son thats a Double layer titanium reinforced razor wire topped electrified smart fence they are building around our garden "completely secure". walls are SO last decade!!
but DADDY how will we get out?
Dont Worry Son some nice Hacker chap will P0rn the power supply to the fence and let us out through a big hole just like a gate opening. If they cant then Lawyers will decide that its anti competitive and after getting rich on the proceeds of court cases will force big holes in the fence for us. but by then we will have staved to death as this is a rose garden full of thorns not a vegetable garden full of good things.
BUT DADDY.....
NO BUTS Son its the M$ way or the Highway. we cant afford Apple and im not having you mess with that Linux. the M$ evangelist says its DANGEROUS........!
if something similar could be done using VMWare instead of Hyper-V. That could be very interesting, and remove at least a smidgen of the taint from the whole thing being a MS product. Plus, perhaps a real security-focused company could write the code that runs in the Device Guard VM - we know MS isn't traditionally too good at the security part (otherwise we wouldn't need Device Guard...).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
