The Register article has a bit more information. This isn't really a vulnerability. It's definitely not "remote code execution". It works like this:

- Microsoft provides a tool called AppLocker that can be used to limit the programs that can be run on a system.
- The AppLocker tool is not intended as a tight "security boundary". Instead, it is a way to implement company policies like "no playing games at work", or to help with software licensing, i.e. "the company system image has a copy of Photoshop, but you aren't in the Design department, so you aren't licensed to run it", and perhaps to reduce attack surface area.
- The Microsoft-provided sample AppLocker configuration (intended to show the syntax for AppLocker rules) happens to have a sample rule that whitelists all programs under C:\windows. This is not a "recommended" rule -- it's a "sample" rule.
- If you leave this rule in, there are a large number of ways to escape the sandbox.
- A researcher found another one. Yay, I guess?

The new one is interesting because I wouldn't have considered regsvr32 to be a command that allows for running of arbitrary other commands. On the other hand, it shouldn't belong in a production whitelist in the first place, so being able to use it to escape the sandbox isn't particularly interesting.

Whether Kinect is a failure depends on exactly how you define success.

-- Controlling the games we're used to playing on the xbox? FAIL.
-- Getting good reviews from people who review games on our favorite gaming websites? FAIL.
-- Selling a lot of units? WIN.
-- Has some games that some consumers really like? WIN.
-- Good as an input mechanism for some interesting non-traditional uses? WIN.
-- The future of gaming? FAIL.
-- The future of computer-human interaction? PROBABLY.

As an additional note, the first version isn't terribly awesome, but inevitably it'll get better in the future.

One addition is that it is more likely nowadays than ever before for a really messed-up person to survive long enough to provide a contribution to society. Once upon a time, people that saw the world differently were more likely to be abandoned by parents, killed by peers, or starve to death as beggars. Nowadays, geeks are more likely than ever before to find a few people that understand them and are willing to give them a job, turning their unique attributes to good ends. Where geeks used to be lucky to avoid being executed for heresy, nowadays they can make a good living and sometimes even become rich and famous.

A few relevant thoughts come to mind.

First, all greatness depends on insanity. The sane come up with an interesting idea, start thinking about it, see a lot of hard work and little chance for reward, and give it up before it gets very far. The insane pursue the idea to the bitter end. 99% (or more) of the time, "the bitter end" means self-destruction and disappointment. 1% (or less) of the time, the result is something truly great that pushes science/art/civilization/whatever forward another tiny step. Sometimes it is both -- many important innovations were only seen as good long after the innovator had been punished for the crime of innovating.

Second, similar but not quite the same as the first, is a saying that I'm probably going to misquote. "The rational man adapts himself to fit into his surroundings. The irrational man persists in trying to adapt his surroundings to fit himself. Therefore, all progress depends on the irrational man." Unmentioned here is that 99.9% of the time, the irrational man will fail and will be harmed due to his efforts while 99.9% of the time the rational man will thrive or at least survive.

After the testing you will be baked and then there will be cake.

If you pay full price for Windows, you get full rights. Microsoft is willing to give you a discount if you accept more limited terms. Most people are ok with the limited terms and are therefore very happy to accept the discount. If you don't like those terms, you have the option of not buying the product.

I think it is a little bit interesting that Microsoft has divided the market between x86 and ARM differently than it has divided the market between x86 and amd64. In theory, you could have a general-purpose ARM-based server, desktop, or notebook. And in theory, you could have an x86-based tablet. So in theory, Microsoft should be adding "Windows 8 tablet edition for x86", "Windows 8 tablet edition for ARM", "Windows 8 Professional for ARM", and "Windows 8 Server for ARM" to its lineup. However, theory never quite matches up with reality.

In reality, of the editions listed above, only "Windows 8 tablet edition for ARM" is likely to have any market at all in the next 2 years, so Microsoft is probably not going to offer the other 3 editions. When the market changes (e.g. if ARM servers really take off), Microsoft will add editions as necessary for Windows 9. If Intel takes over the tablet market, there will certainly be a Windows 9 tablet edition for x86. And your guess is as good as mine about which of these editions will require secure boot.

I don't think it is accurate to say that "any ARM device that ships with Windows 8 will never run another operating system unless...". First, it should be changed to "any ARM device with the 'Designed for Windows 8' logo will never run another operating system unless..." since it isn't the presence of Windows 8 that determines the status of secure boot. Second, the "unless..." part is pretty important and should be emphasized. Just as Microsoft will be able to sign Windows, other organizations will be able to sign their own operating systems. And hacking/jailbreaking will always happen. So it is more accurate to say "any ARM device with the 'Designed for Windows 8' logo will have to be jailbroken before it can run any unsigned operating system".

In any case, it seems that Microsoft's rules here are the most open of any tablet manufacturer. Can you install your own copy of Linux on an iPad? No. Can you install your own copy of Linux on an Android device? Only if the manufacturer was kind enough to leave your bootloader unlocked. Can you install your own copy of Linux on a "Designed for Windows 8" device? Yes, as long as you get it signed first.

Open questions:

Will you be able to buy Windows 8 for ARM on a tablet that doesn't have the "Designed for Windows 8" logo certification? If so, then I imagine there will be a lot of vendors willing to forego the logo certification and advertise the tablet as "Linux-compatible". Of course, in that case, I would hope they would advertise that they passed all other "Designed for Windows 8" logo requirements. On the other hand, if Windows 8 for ARM is restricted to OEMs selling properly-certified tablets, OEMs will probably be less likely to sell Linux-compatible variants.

On what terms will 3rd parties be able to sign their operating systems? There will definitely be ways to do it, but it won't be free. Getting the OS signed will probably have a fee, and nobody will want to have an OS signed in their name unless the OS is a "closed system". In other words, I would be very nervous about getting a standard GRUB binary signed in my name, because anybody could then take that GRUB binary and use it as part of a rootkit, and it is not beyond the realm of possibility that I might be held liable for damages done by that rootkit. Instead, I would (at the very least) want to modify GRUB so that it shows a splash screen saying "Warning: this version of GRUB can load unsigned operating systems!". Or if the lawyers have their way, I would probably make my GRUB only load signed kernels so that I can pass the blame to whoever signed the kernel. Anybody signing a kernel will probably want to have the same attitude towards unsigned kernel drivers (and probably even unsigned user-mode drivers, since they usually have special capabilities and extra potential for causing mayhem).

How interested will people be in jailbreaking these devices? So far, the best tablets (the ones on which people want to install their custom builds of Linux) are NOT the "Designed for Windows 8" tablets. Will this change in the future? Microsoft's policy only matters if "Designed for Windows 8" tablets become the best tablets on the market. So far that is not the case. If this does wind up being our future, it is at least several years away. What will the tablet market look like then? Will "Designed for Windows 8" tablets really be the only game in town for your next Linux tablet, or will there be other options?

Will you really want to put your own build of Linux on these tablets? I mean, I love tinkering with my desktop and laptop computers as much as the next guy, but phones and tablets are not general-purpose computers -- they're appliances.

Will the major distro providers (Ubuntu, Debian, Red Hat, FreeBSD) step up to the plate and release signed versions of their distros? Will businesses see enough need for custom operating systems to build and sign a Linux image for internal use?

How does code signing play with various open-source licenses? Is it ok to sign a GPLv2 program? What about GPLv3?

The problem is that by having something signed in your name, you are sort of attesting that the code won't do any bad stuff, directly or indirectly. If you get a GRUB bootloader signed and then somebody uses your GRUB as part of a rootkit, your name is going to be on the rootkit. (Not sure about the actual laws, but there is potential for liability here. Do you have enough lawyers to risk it?)

One way to avoid taking the blame for unfortunate events is to pass the blame to someone else. In the case of code signing, that means a bootloader will only load a kernel if the kernel is signed. That means that if somebody uses the kernel in a rootkit, it isn't the bootloader's problem anymore -- the blame falls on whoever signed the kernel.

Taking it one step more, the kernel can avoid blame by ensuring that it only loads signed drivers. As long as all kernel-mode code is signed, the operating system can make certain assumptions about the world. It might still be running malware, but it's always user-mode malware, never a rootkit or a kernel-mode problem. Keyloggers can only work via approved and documented operating system APIs, etc.

Depending on how secure you want the system to be, you might even extend this "only load signed code" thing all the way into user mode. But that's optional, since the operating system already has a pretty good security layer in place for user mode code.

Probably not. Any OS can boot on a "Designed for Windows 8" ARM device as long as the OS gets itself signed. The device will boot non-Microsoft operating systems just fine as long as they're signed. The only problem is that getting a certificate is not free (probably around $500/year is my guess for what it would cost to be able to sign your own kernel).

The secure mode doesn't "only boot Windows". Instead, it is "only boot signed". There will probably be some Linux (or BSD) distro that goes and pays to get itself signed, and then you can install that distro on your "Designed for Windows 8" ARM device. If the distro includes VirtualBox's kernel-mode driver in the set of drivers that get signed, they you'll be able to use VirtualBox on the device as well. You'll no longer be able to compile your own kernel and kernel modules unless you pay to have them signed.

I agree that this is an overblown issue. However, your understanding is incorrect here. The OS being installed has to be signed with a key that is trusted by the device's UEFI, and the set of trusted keys is hard-coded when the device is manufactured. Microsoft's requirements specifically say that you must not be able to add new trusted keys after the device has been manufactured. I don't know what Microsoft's requirements are for what keys must be included or excluded from the set of trusted keys (I suspect that the "Microsoft Windows Hardware Compatibility" certificate will be trusted; I don't know whether Verisign or other 3rd parties will be allowed to be trusted), but looking at previous similar situations it is almost certain that there will be a way for a 3rd party to get an OS signed if they're willing to pay $500 for a certificate.

So corporations would probably be able to produce a corporate-branded edition of Linux (including signed bootloader, kernel, and kernel modules), either for internal use or to be shared with the world. Non-profit organizations that produce operating systems (FreeBSD and Linux) would have to release signed versions. End users would no longer be able to compile their own kernels or kernel modules if they want to have them run on "Designed for Windows 8" ARM hardware -- they would have to get the kernel and the kernel modules from a certified source. OR they could buy ARM hardware that isn't "Designed for Windows 8" and do whatever they want.

Yeah, the real reason was that the OEM couldn't be bothered to add Linux as an option because it increases production and support costs far more than the cost of a Windows license, while increasing your potential market by 0.01%. I read up on some manufacturers who tried providing Linux options. Generally they discovered that they got more accidental buyers than intentional ones, so offering the Linux option is terribly expensive for them -- they have to add a completely different disk image for the Linux version, they have to add a (potentially confusing) menu option to their order forms, they have to train support staff, the Linux version would tend to produce far more support calls and far more returns, etc., meaning that after all costs have been accounted for, the Linux version costs more for the OEM to produce than the Windows version. (This is for consumer-oriented products; it's usually a different story for server-oriented products.) The "Windows Tax" for most consumer machines is around $20, and even one additional support call can make those "savings" meaningless to the OEM.

Yes, this situation happens to play into Microsoft's hands, but it isn't Microsoft's fault, and there isn't any easy solution. If you can figure out a way for Dell to offer a Linux option for their consumer products that doesn't cost them anything in terms of manufacturing, advertising, training, or support, please share it with them. I'm sure they would be happy to talk. Until then, just buy the PC with the cheapest version of Windows on it (usually Home Basic) and format it as soon as you get it. Maybe try to get your $20 refunded if you really want to stick it to Microsoft on the principle of the thing.

Vista and later enable multiple apps to share use of the GPU (desktop composition). In order to make this work, they have to make GDI work on top of an extra layer of abstraction. With a well-written Vista-compatible video driver, this extra layer of abstraction has little to no performance penalty. However, with the XP-compatible video driver (works on Vista but has limitations), this abstraction has a significant performance penalty which is what you are seeing.

Many GPU manufacturers never released Vista-compatible drivers for their XP-compatible hardware. Instead, you have to run Vista or 7 with XP-compatible drivers and live with the issues.

One workaround is to disable Aero glass (desktop composition). Once that is done, the extra layer of abstraction is no longer needed and your GDI apps will work at regular speed again.

The other workaround is to upgrade to video hardware with a Vista-compatible driver.

Note that Windows 8 will remove support for the XP-compatible drivers.

This is also the case for essentially all "single-core" smartphones. The number of "cores" advertised is the number of full-speed general-purpose CPU cores visible to the applications running on the system-on-chip. There is almost always a smaller slower "modem processor" (often called the DSP) that is a slower ARM core (usually 600 MHz or so) that can handle cell phone processing, MP3 playback, and other non-interactive tasks. If the screen is off, a good smartphone OS should only have the modem processor active, which is how it gets any decent battery life.

Doesn't work. (I tried this a while back.) It turns out that the problem is that most SD card readers and/or their drivers don't support the necessary control of the SD card, so it doesn't matter what application you use -- the SD card can't be unlocked by most existing SD card readers.