back to article 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 …

  1. Anonymous Coward
    Anonymous Coward

    As much as an MS fanboi that i am,

    why do I get a bad feeling about this.

    Much like UEFI, I cant help but feel this is a way to tie folks into something further down the line.

    Like the app store for example..

    Not to mention it will ultimately be cracked....

    Or am I just being old and cynical...

    1. Adam Jarvis

      Re: Why do I get a bad feeling about this...

      Because you're running a Core 2 Duo and not a Intel nehalem processor (i3,i5,i7) series or newer?

      Given past history, the final release could cut off anything below a nehalem.

      (Is there a hidden context to the free consumer upgrade, in that you need nehalem onwards)

      It would save an awful lot of free upgrades for MS, and keep HP, Dell and Lenovo Happy.

      Do MS really want to support anything below, given all the proprietary driver issues - Authentec Fingerprint Readers as a good example of no longer getting support (now owned by Apple).

      1. Sandtitz Silver badge

        Re: Why do I get a bad feeling about this... @Adam

        "Given past history, the final release could cut off anything below a nehalem."

        Windows 8 requires at least Pentium 4 "Prescott" (circa 2004) or any AMD64 capable CPU (2003). Microsoft has communicated that the requirements will be the same for Windows 10. This could change - of course - but what OS-specific features do Nehalems have that earlier CPUs didn't?

        Windows Vista/7/8 had the Upgrade Advisor program which checked whether your installed SW and HW was supported or had workarounds available.

        "Authentec Fingerprint Readers as a good example of no longer getting support"

        This would really depend on the support agreement between Authentec and OEMs. The agreements may contain provisions of driver support for upcoming Operating Systems (or) for the next X years.

        1. Adam Jarvis

          Re: Why do I get a bad feeling about this...

          Nehalems (i3,i5,i7) support VT-d, (the point of the article), without VT-d hardware support - Device Guard doesn't work, older processors below Nehalems don't have it.

          In terms of Authentec Drivers, they were removed, when Apple removed the Authentec Website (without notice either). HP have switched software, so I very much doubt they will be writing new drivers for Windows 10, for older hardware. Past experience also says it won't happen.

      2. BinkyTheMagicPaperclip Silver badge

        Re: Why do I get a bad feeling about this...

        VT-d is a chipset technology, not a processor technology. From Nehalem onwards the memory controller was integrated into the CPU package meaning that the lines became increasingly blurred.

        VT-d works fine (for varying values of 'fine') on Core 2 chipsets provided it is the right chipset (X38, X48, S3200/S3210, most of the Q chipsets) and the BIOS has it enabled with a bug free implementation (in reality this means nothing from Asus will work, most Intel boards will, plus Supermicro, some DFI IIRC)

        1. BinkyTheMagicPaperclip Silver badge

          Re: Why do I get a bad feeling about this...

          ..although, this will naturally be a version of Windows 8's Hyper-V, with additions. Therefore it will require a 64 bit CPU with second level address translation, which is indeed Nehalem onwards for Intel.

          See http://blogs.msdn.com/b/uk_faculty_connection/archive/2012/10/24/hyper-v-list-of-slat-capable-cpus-for-hosts.aspx

        2. Ammaross Danan

          Re: Why do I get a bad feeling about this...

          You also forget that the K-branded i-series CPUs (e.g. Core i7-4790K, et al) do NOT have VT-d (as opposed to the non-K CPUs such as the Core i7-4770 which do have VT-d). Fortunately, people interested in K-branded CPUs are likely intelligent enough to not need this particular form of malware protection.

          "But if an enterprise is saying 'Hey, sign this for me,' it will be done with a key that only works for that company."

          Now if it can be done for individual users that have some legacy software (such as the original Starcraft....), I think this would work well for home users. Otherwise, you'll severely limit the amount of software one is able to run...

          1. This post has been deleted by its author

      3. Anonymous Coward
        Anonymous Coward

        Re: Why do I get a bad feeling about this...

        @Adam Jarvis.

        The issue of the CPU hadn't even entered my mind. But for what its worth, I'm running an i7 on a Samsung RF710.

      4. Roger B

        Re: Why do I get a bad feeling about this...

        Huh, it's almost like you are looking at my laptop, Intel Dual-Core T2390 with an Authentec Fingerprint reader! Anyhows, hopefully you are wrong, this is going to be one of two PCs I am hoping will be taking Windows 10, the other being a just as ancient Dual core desktop machine.

    2. Anonymous Coward
      Anonymous Coward

      Re: As much as an MS fanboi that i am,

      We have been there before. It's not exactly a new thing to digitally sign applications to stop them from being altered, but the problem is that such a mechanism immediately gets used as a revenue generator, thus shutting out all those applications you have been using for years but whose developers cannot afford the usually extortionate fee.

      OSX has a similar mechanism (t's one of the reasons you need to register as a developer). That's not expensive (I think it's $99 or so), but ensures there is at least some track back to the developer.

      In both cases, however, the question emerges how inhouse and contracted developments and customisations are approved - to me, that's the threat vector (next to ruthless exploitation of this lock down, because the real aim could be to kill off pesky competing software such as LibreOffice - which, by the way, does not have a dev registration for OSX either).

      No, I'm not a fan of handing Microsoft any control.

      1. david 12 Bronze badge

        Re: As much as an MS fanboi that i am,

        No, OSX does not have a similar mechanism. This is a HARDWARE ENFORCED mechanism.

        1. Anonymous Coward
          Anonymous Coward

          Re: As much as an MS fanboi that i am,

          No, OSX does not have a similar mechanism. This is a HARDWARE ENFORCED mechanism.

          Ah, OK, so we're back to trust chips and the like. Yeah, that really worked the last time, didn't it?

          There seems to be a cycle in here: however stupid the idea is, leave it on the shelf for 7 years or so and it'll show up again. We need a term for this, like zombie tech.

          1. Anonymous Coward
            Anonymous Coward

            Re: As much as an MS fanboi that i am,

            "Ah, OK, so we're back to trust chips and the like. Yeah, that really worked the last time, didn't it?"

            Erm yes it did. Secure Boot has had no significant security breaks so far.

      2. MIc

        Re: As much as an MS fanboi that i am,

        THEN DON'T USE THE FEATURE

        I know... it's complicated

        1. Anonymous Coward
          Anonymous Coward

          Re: As much as an MS fanboi that i am,

          @ Mic:

          Genuinely trying to work out what you are saying.

          1. b166er

            Re: As much as an MS fanboi that i am,

            Well perhaps he means that Device Guard isn't mandatory?

    3. streaky Silver badge

      Re: As much as an MS fanboi that i am,

      It does somewhat rely on the HV itself being secure, which they commonly aren't. I'd suspect all that's really happening is a raising of the competency barrier required to insert malicious code into the kernel - which might not actually be a bad thing, what's probably at question is the extent to which it's actually a good thing, or rather how competent it is.

    4. Anonymous Coward
      Anonymous Coward

      If you use the word extortion again

      I'll have your legs broken.

      This is all about Microsoft extorting money from developers go get their applications signed by Microsoft. Nothing more.

    5. boltar Silver badge

      Re: As much as an MS fanboi that i am,

      "Not to mention it will ultimately be cracked...."

      Since SMM in some intel chips has been cracked and SMM can do whatever it damn well pleases and not even a hypervisor can stop it - this is all just playing to the crowds. The real reason obviously is MS wanting you to have to get their permission to run programs on their OS by requiring them to be signed. This facility might be "optional" for now, but I bet it won't stay that way.

      1. Michael Wojcik Silver badge

        Re: As much as an MS fanboi that i am,

        Since SMM in some intel chips has been cracked and SMM can do whatever it damn well pleases and not even a hypervisor can stop it - this is all just playing to the crowds.

        Excessively reductive. An IOMMU-protected watchdog still prunes a significant portion of the attack tree, even if SMM represents a way around it. There is certainly plenty of non-SMM-based malware out there, and there will continue to be such malware for the foreseeable future.

        Security is about cost transfer under threat models. It's not about perfect solutions. I don't know why some people find that concept so difficult.

        No software security mechanism protects against suborning an authorized user. That doesn't mean no all software security is a waste of time.

  2. JimmyPage Silver badge
    Stop

    My first thought

    Have Microsoft detailed their policy on signing enterprise software specifically:

    1) How long the process will take ?

    A 24-hour turnaround would be acceptable. However I suspect there will be all sorts of hurdles to jump over that means an organisation needs to have a definite timeline to fit into migration/deployment projects.

    2) Cost ?

    AND

    3) Support lifecycle

    because once you have Device Guard in your organisation, it would be a little unfortunate if Microsoft suddenly stopped offering to sign Enterprise software, or decided that it would charge $10,000 per executable.

    1. Anonymous Coward
      Anonymous Coward

      Re: 1: RTFA

      "Enterprises with legacy apps can send hashes of the executables to Redmond to be signed within minutes, we're told."

    2. Suricou Raven

      Re: My first thought

      4) Terms of acceptability.

  3. Christopher Reeve's Horse

    But what about...

    ...individuals with legacy 'apps'? Or does this render your back catalogue of purchased software obsolete?

    If the solution is to click OK on a UAC type pop up window, then I'm not sure this would really solve anything.

    I can't imagine a middle ground, so I'm just going to assume legacy 'apps' are doomed.

    1. Dave Pickles

      Re: But what about...

      And what about developers? Even if the compiler is allowed to run, it wouldn't be possible to test the resulting executable without waiting for a signature. Could play havoc with project timescales...

      1. Dave 126 Silver badge

        Re: But what about...

        >And what about developers?

        Again, Device Guard will have to be actively turned on by an administrator.

    2. Dave 126 Silver badge

      Re: But what about...

      >But what about... ...individuals with legacy 'apps'?

      The article says: Device Guard, when enabled by an administrator...

      So, to answer your question: If you don't want it, don't enable it.

      1. Roland6 Silver badge

        Re: But what about...

        Device Guard, when enabled by an administrator...

        Expect that to be implemented as enabled by default on home/consumer rated OEM installs and disabled by default only on volume licence distributions.

        Also we can expect Windows Security to permanently flag the PC as being insecure, just because you've disabled this 'security' feature, thereby masking all other security events... You can see this at with XP, simply enable/disable the option to automatically check for Windows updates and see Windows XP go from being secure to being insecure!

        1. h4rm0ny

          Re: But what about...

          >>"Expect that to be implemented as enabled by default on home/consumer rated OEM installs and disabled by default only on volume licence distributions."

          IF your unsupported assumption turns out to be true, then the user could, you know, turn it off again. And if a user can't manage that then they're exactly the sort of person who shouldn't be turning it off anyway.

          1. Roland6 Silver badge

            Re: But what about... @h4rm0ny

            >>" And if a user can't manage that then they're exactly the sort of person who shouldn't be turning it off anyway."

            That was the reason why I was suggesting that MS would enable this as default on Home/Consumer systems. The article and discussion was assuming that MS would ship Device Guard disabled across the range, so only knowledgeable users would enable it, but that sort of defeats the primary objective of making Windows more secure/safe for normal users...

            But then they've kept EMET out of Windows because it could cause badly written programmes to crash...

            My objection was that I would hope MS will permit me to turn this off and not to automatically red flag the security status of my machine in the system tray because of this.

  4. Tomislav

    What about free software for home users, like Putty or Wireshark? Or something that updates often and does not like Microsoft very much like Java or Flash? Seems like Microsoft is trying to go the walled garden iRoute...

    1. Steve Davies 3 Silver badge
      Mushroom

      FOSS is the Devil in the Microsoft World

      despite their overtures towards it.

      FOSS can't be controlled in the same was other vendors can.

      Microsoft do look at the environment that Apple have created for the iPhone/iPad/iPod and want to copy it. But even Apple has developer access. If they didn't then how would the gazillion apps for the iPhone etc be created.

      As a developer, the first thing I'll do is work out how to bypass this. I have apps that will never get signed my Microsoft. I'm certainly not going to pay them a fee for developing programs for my own use. I know that I'm not alone there.

      If you can't bypass the signing then MS will be signing (sic) their own death warrant.

      Even on Crapple MacBook etc systems, I can code an application and run it without signing.

      1. Anonymous Coward
        Anonymous Coward

        Re: FOSS is the Devil in the Microsoft World

        On OS X in "System Preferences" - "Security" there's:

        Allow apps downloaded from:

        (1) Mac App Store

        (2) Mac App Store & Identified Developers

        (3) Anywhere

        I don't see why Microsoft wouldn't implement a similar function.

        1. Lostintranslation

          Re: FOSS is the Devil in the Microsoft World

          I can, and it begins with a $ sign.

        2. Roland6 Silver badge

          Re: FOSS is the Devil in the Microsoft World

          I don't see why Microsoft wouldn't implement a similar function.

          Suspect they will, only it will be via a registry key for which there is no public documentation.

          Which means because this function will be enabled/disabled via the Windows Administrator rather than in the BIOS etc. we have already identified the weak point in Device Guard's security...

          1. Dave 126 Silver badge

            Re: FOSS is the Devil in the Microsoft World

            >What about... ...Java or Flash?

            And your point is? :)

    2. Ammaross Danan

      "But if an enterprise is saying 'Hey, sign this for me,' it will be done with a key that only works for that company."

      This would allow businesses to get a hash for a specific version of Java they must have. Home users are likely more SOL for that aging copy of Starcraft however....

  5. Warm Braw Silver badge

    Identity badges don't guarantee good behaviour

    The trouble with this type of approach to security is that knowing (or thinking you know) what something "is" doesn't really tell you very much about what it "does" - or might do when it thinks you aren't looking.

    The real problem is the old-fashioned idea of user-level permissions: just because a user launches an executable file doesn't mean that the resulting process context should have access to everything the launching user has access to. There has to be an intermediate step of delegating only sufficient access for the application to do its job. There are ways of doing this that aren't too painful - for example by giving the application access only to those files that the user has explicitly picked in the user interface - but there is inevitably some additional inconvenience in doing this. Unfortunately, a small loss of convenience doesn't seem to be a price most users are prepared to pay for better security.

    1. Vehlin

      Re: Identity badges don't guarantee good behaviour

      This is why the best solution is to run on an account with the minimum privileges and elevate when required. Much less pain for the user and almost as secure.

      1. Adam 1 Silver badge

        Re: Identity badges don't guarantee good behaviour

        Minimal access levels is a good idea because the attack surface is reduced and the bad things the malware can achieve is more limited. But I will point out that encrypting all the xlsx files under "My Documents" doesn't require any privileges beyond what such a user would have.

    2. h4rm0ny

      Re: Identity badges don't guarantee good behaviour

      >>"The trouble with this type of approach to security is that knowing (or thinking you know) what something "is" doesn't really tell you very much about what it "does" - or might do when it thinks you aren't looking."

      That's not the way it helps. The point is that if it isn't what it's supposed to be, you're unlikely to be the first victim. It will rapidly be reported and its signature revoked.

  6. Anonymous Coward
    Anonymous Coward

    Sounds more like a DRM mechanism than helping protect the OS from compromise.

    1. h4rm0ny

      >>"Sounds more like a DRM mechanism than helping protect the OS from compromise."

      Ideally, it would be both. If software can be verified at the hardware level then you can say goodbye to intrusive DRM that can hit performance or has to keep signing you into an online account, etc. Win-Win, imo.

  7. Jess--

    I see mention of being able to get an executable signed for use within an enterprise (but only within that enterprise).

    but the only way I see of getting an executable signed to run on ANY machine is submitting it to the windows store.

    Seems to me that they are trying to make it so that in the future if you want to develop for the windows platform you MUST sell it through the windows store.

    1. John P

      It clearly states "when enabled by an administrator", so this is going to be much like Bitlocker or any other security feature that MS have introduced over the last 10 years, a great feature but you only turn it on if you know it won't cause you any issues.

      1. jason 7 Silver badge

        Bingo! That's what I was going to ask. Is it switched on by default? I guess not.

        MS has loads of security built into Windows but they always leave it switched off by default.

        I'm amazed they haven't bothered to build EMET into Windows 10 yet.

        I think MS are terrified to becoming branded security Nazis by the press if they happen to switch on security that could blow out some old guys bit of shareware from 2002.

        Damned if they do...

        1. Roland6 Silver badge

          Building EMET into Windows would actually be doing something useful - it would improve Windows and permit EMET to run at a much higher security level than it does as a user space add-on!

        2. Anonymous Coward
          Anonymous Coward

          @Jason7 - You know very well...

          this is not about security, do you? Security is the justification for taking away control from you like in UEFI Secure Boot.

          1. h4rm0ny

            Re: @Jason7 - You know very well...

            >>"Security is the justification for taking away control from you like in UEFI Secure Boot."

            Well on any x86 device so far, that's only meant taking away control from people who can't work out how to get into the UEFI BIOS and switch Secure Boot to "Off".

            Which admittedly, may include you.

            1. jason 7 Silver badge

              Re: @Jason7 - You know very well...

              Yeah I can read and also know how how to press either 'F2' or 'Del'.

              Those that moan most about stuff really should just learn how to use it first.

  8. SecretSonOfHG

    Kernel has total control

    "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.

    1. diodesign (Written by Reg staff) Silver badge

      Re: Kernel has control

      "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.

      1. Peter Gathercole Silver badge

        Re: Kernel has control

        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.

      2. SecretSonOfHG

        Re: Kernel has control

        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.

  9. justincormack

    surely?

    Well maybe that is the end of the iommu as an Intel premium feature. A lot of machines do not have it enabled, Intel will even sell you server chips without iommu if they can.

  10. A Non e-mouse Silver badge

    Sooo.....Microsoft can't make Windows secure, so they're going to run Windows under a hypervisor which is secure.

    Am I alone in thinking this is wrong?

    1. Brewster's Angle Grinder Silver badge

      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.

      1. BinkyTheMagicPaperclip Silver badge

        x86 has four protection rings, of which commonly only 2 are used (with the honourable excelption of the horrific and weird IOPL DLLs in OS/2 that run at ring 2). x64 has less rings and operates a little differently

  11. Peter Gathercole Silver badge

    IOMMU?

    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.

    1. /dev/null

      Re: IOMMU?

      Perzackly. IOMMUs (in the classic sense, as described in the Minix paper) combine the concepts of virtual memory and DMA and have been around for yonks. VT-d/AMD-Vi, on the other hand, does the same thing for virtual *machines*, and is rather newer.

    2. Bronek Kozicki Silver badge

      Re: IOMMU?

      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.)

      1. Peter Gathercole Silver badge

        Re: IOMMU? @Bronek

        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.

  12. Pascal Monett Silver badge

    "If that enterprise wants to sign bad stuff, they are entitled to do that"

    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.

    1. Dave 126 Silver badge

      Re: "If that enterprise wants to sign bad stuff, they are entitled to do that"

      >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.

      1. Pascal Monett Silver badge

        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.

  13. Brent Longborough
    Black Helicopters

    What could possibly go wrong?

    "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.

  14. Mystic Megabyte Silver badge
    Windows

    Turtles all the way down

    "Device Guard itself runs in its own pocket of memory with its own minimal instance of Windows"

    And inside of that is another little Device Guard etc.etc.

  15. Terje

    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.

    1. dogged

      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.

    2. Dave 126 Silver badge

      >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.

      1. Roland6 Silver badge

        Re: the administrator for your granny's laptop

        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...

        1. Dave 126 Silver badge

          Re: the administrator for your granny's laptop

          >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.

          1. Roland6 Silver badge

            Re: the administrator for your granny's laptop

            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.

  16. theOtherJT

    How is it stored?

    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.

    1. Dave 126 Silver badge

      Re: How is it stored?

      That's a valid question. From the article: The details are a little vague – more information will emerge at the Build event next week, so hopefully someone can give you an answer soon.

  17. Mikel

    I can't boo this one

    I've been saying Windows belongs in a virtual machine for years. This will off course do away with running Windows in this more secure mode as a VM under a real hypervisor.

    1. Loud Speaker

      Re: I can't boo this one

      Windows belongs in a virtual machine for years. <P>

      A virtual car crusher?

  18. Portia

    Hasn't AppLocker been around for a while?

    Doesn't that force apps to be signed before running?

    Is it turned on by default?

    1. Anonymous Coward
      Anonymous Coward

      AppLocker is not hardware based enforcement

  19. mike acker

    not addressing the Core Problem

    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

    1. Anonymous Coward
      Anonymous Coward

      Re: not addressing the Core Problem

      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.

      1. h4rm0ny

        Re: not addressing the Core Problem

        >>"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.

  20. BinkyTheMagicPaperclip Silver badge

    This is opening a wriggly can of worms

    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!

    1. Bronek Kozicki Silver badge

      Re: This is opening a wriggly can of worms

      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.

  21. Alan Denman

    Sounds like RT to me........

    Tarted up marketing for a 'walled garden' paywall.

  22. ByeLaw101

    Trace ON

    It's been done before, and we know how that ends!

    Ed Dillinger: Part of the Master Control Program?

    Alan Bradley: No, it'll run independently. It can watchdog the MCP as well.

  23. volsano

    Mal ad ware

    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.

  24. Chairo

    Ultimately, the idea is to stop miscreants installing malware on a machine

    -> Ultimately, the idea is to stop users installing open source software on a machine

    Boosting their app shop takeup is probably just a welcome side effect.

  25. Anonymous Coward
    Anonymous Coward

    Windows is the malware

    Windows is the malware - we know from Snowden that they're spying on whoever they wish to. What's the point of trying to keep other stuff out?

    1. Anonymous Coward
      Anonymous Coward

      Re: Windows is the malware

      From Snowden we know that this spying capability was primarily under *NIX based devices such as Android and IOS phones. Apparently they couldn't crack Windows Phone at the time though...

      1. Anonymous Coward
        Anonymous Coward

        Re: Windows is the malware

        "...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.

  26. Spaceman Spiff

    The most compelling

    The most compelling security feature to use with Windows is to not use Windows at all!

    1. Anonymous Coward
      Anonymous Coward

      Re: The most compelling

      dear oh dear.

      Eadon you are not. Stop trying.

  27. Anonymous Coward
    Anonymous Coward

    Watchdog?

    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.

  28. Boris the Cockroach Silver badge
    Windows

    And whats the betting

    windows 10 will still be pwned by a truetype font doing a buffer overrun to run untrusted code.

    me ? cynical?? never

  29. Anonymous Coward
    Anonymous Coward

    DADDY?

    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........!

  30. icesenshi
    Facepalm

    As if tpm and uefi weren't enough already.

  31. JP19

    "the most compelling security innovations"

    They used the word compelling which immediately classes as worthless crap you are not interested in.

  32. Pirate Dave Silver badge
    Pirate

    I wonder

    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...).

  33. John Savard Silver badge

    Not Useful Enough

    Enterprises can get Microsoft to sign, for them, old applications they want to use.

    But what about the home user? This will mean not being able to run legacy applications, if one wants to have the security this provides.

    If there were a way that users could sign their own applications for their own use, locally, on their computers - without this adding a risk that it could be used by attacking programs to sign themselves - then it would be useful to people like myself.

    This presumably would mean having a hardware-isolated program that could talk to the keyboard and the display. Since programs only need to be signed once, the inconvenience of booting into signing mode would be acceptable.

  34. Christian Berger Silver badge

    Well it's "Trusted Computing" all over again

    This is just one part of a larger concept.

    1. It will bring _no_ benefit to security, as it'll be working in the wrong places. For example you will still be able to exploit a browser to steal cookies and such or install any form of spyware/adware. In fact certain players in the field will probably even get their malware propperly signed. No malware today actually accesses the hardware since that would be rather stupid. If you are already "System" on that system, you have already won. Since nobody re-installs Windows regularly, you are even persistent on that machine.

    2. As a side effect it'll limit the software you can run on those machines. For example FOSS will probably not run on such a machine as it will eventually not run any unsigned code. There may be a temporary figleaf solution where Microsoft signs a generic bootloader, but since that completely breaks the chain of trust, it'll likely be advertised as a huge security problem and removed.

    3. The area it will make sense is DRM. If Microsoft can limit the access to your hardware, they can potentially keep you from grabbing DRMed streams.

    There should be laws against this sort of thing, and actually in Germany that would clash with your basic right of "Integrity and Confidality of Information Processing Equipment" as derived by the constitutional court some years ago.

    1. h4rm0ny
      Facepalm

      Re: Well it's "Trusted Computing" all over again

      I don't know what is worse some days. The people who post confident assertions when they clearly don't know what they're talking about, or the people who mod them up because the poster speaks authoritatively.

      There are basic errors in your post.

      >>1. It will bring _no_ benefit to security, as it'll be working in the wrong places. For example you will still be able to exploit a browser to steal cookies and such or install any form of spyware/adware

      It is a tool that verifies the software you have installed matches an approved version. Do you also object to signed packages on GNU/Linux? Someone who doesn't understand that there is a security benefit to being able to verify software has no business talking on the subject of security. And your operating principle of 'unless something solves all types of security problems then it provides no benefit' is stunningly flawed.

      Also, the browser steals cookies? Okay. :D

      >>"In fact certain players in the field will probably even get their malware propperly signed"

      Modern malware goes through huge numbers of variations for all sorts of reasons, including getting past anti-virus scanners. If you have to get something signed for every small variation of your malware, that's a staggering limitation. In fact, just getting one version of your malware through instantly becomes much harder as you have to have an account to register it with. Once something you submit is flagged as malware that entire account and every other piece of malware you used it for is effectively scorched. Good luck routinely creating thousands of accounts, getting them approved and then passing off tiny variations in malware with each of them.

      And it's fairly easy to recognize malware. Or rather I should say that there are groups that are extremely good at this. Most malware gets about because it's not picked up as malware by people's systems. You can put it up on some compromised site and trick people into installing it because they're ignorant of what it is. But with this turned on, you have to trick Microsoft's QC team into believing it's innocent. And that's a lot harder than tricking some average end-user.

      And then of course there's the fact that once something is recognized as malware, its signature gets revoked. This process can happen extremely quickly meaning it's perfectly likely that by the time the malware actually reaches you personally, it's already reached someone else and it got flagged.

      >>"No malware today actually accesses the hardware since that would be rather stupi"

      Cough Stuxnet Cough. Plus there are entire families of trojans that infect the bootstack which, whether you call it accessing the hardware or not, is happening below the level of the OS which is what is relevant. Anyway, this is another of your basic errors. This security measure isn't protecting the hardware, it is hardware-based. A fundamental difference you have not grasped.

      >>"2. As a side effect it'll limit the software you can run on those machines"

      That's not a side-effect. That's what the technology does.

      >>"For example FOSS will probably not run on such a machine as it will eventually not run any unsigned code"

      FOSS software can be signed just the same as proprietary or closed source software. The process is no different. And for the minority who actually compile it themself rather than download a binary (kids today!), this doesn't affect that as the very fact that you're compiling your own code means you have a bypass on this system.

      >>"There should be laws against this sort of thing"

      Against what? Having an optional whitelist of software you can turn on?

      >>"and actually in Germany that would clash with your basic right of "Integrity and Confidality of Information Processing Equipment"."

      Complete and utter rubbish.

  35. thedarke

    Errm- a Hypervisor != Hyper-V

    Seeing a lot of comments about VMs- what was said was a Hypervisor. That doesn't necessarily mean a full VM, or even Hyper-V. It could even be a Microvisor. Others have been doing this for a while (Bromium are a good example), and frankly, they're monkeying with things they don't have full control over. At least if it's internally developed it's also getting cross support from the OS team.

    This could be a total pile of crap, or it could be actually pretty good. Given other work they've been doing for the Windows 10 family, I'm not entirely cynical about it.

    Microsoft don't care about a walled garden market- they do care about negative PR from malware stories and the constant barrage from *nix and Fanboi commentards saying "We don't get viruses" (total BS, but still widely believed BS).

    And just to point out I don't have a horse in this race- written in Chrome on my OSX laptop, next to my FreeBSD server, and Windows desktop :)

  36. Alex 18

    It could be the scope is smaller than a walled garden

    The article wasn't given all the information by MS, but from what I can read, this *isn't* for "all Windows applications that want to run on Windows 10." It's for only the parts that want kernel-like access. MS are proposing that anything with deep permissions be signed by them and gate-keepered by this Device Guard. But any application that only needs work-a-day access - i.e. doesn't need to change the kernel - will be fine as normal.

    The extra protection being offered is to the kernel and low-level drivers only. And for an average user, the only applications that will want to make changes to such low level code are a) anti-malware software trying to hook into the OS at the most fundamental level possible, and b) malware trying to do the same. The theory here is that option (a) can get signed by MS and allowed through by the Device Guard - option (b) will be stopped before being able to root you.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019