64-Bit Vista Kernel Will Be a "Black Box"

ryanskev writes with news from RSA Europe, where a Microsoft VP spoke bluntly about the lock-down that will apply to 64-bit Vista. From the article: "Microsoft will operate 64-bit versions of Windows Vista as a tabernacle, with the kernel as the holy of holies, where only its own high priests of security may venture." While Microsoft has seemed to be making some concessions to the likes of Symantec and McAfee, considerable doubt remains as to their ultimate future.

Comments

Jim Allchin of Microsoft responds

[Foolhardy]

Microsoft executive clarifies recent market confusion about Vista Security

Re:I'm confused

[phantomcircuit]

The only way to run kernel code is drivers, 32 bit drivers are currently only sometimes signed. ALL 64 bit drivers must be signed, or they won't be loaded. This is why there is a distinction between 32 bit and 64 bit Vista.

Re:I'm confused

[maynard]

No. There are certainly register extensions to support 64 bit registers. And both AMD and Intel chips support greater than 32 bits of address space (neither support full 64 bit addresses - which would be gargantuan and unnecessary right now). The real issue is what DRM support is on the motherboard in order to hardware verify the signatures of whatever drivers are inserted into the kernel. This does not need 64 bits.

However -- I too -- am not a kernel developer. I've read through the linux and BSD kernel sources. And I've read the Tannenbaum book. But I don't claim to be able to write the stuff.

OTOH: I could use a scotch. (nudge nudge) :)

Re:I'm confused

[Foolhardy]

The main reasons they aren't implementing the same thing in 32-bit Windows is because of "limitations of the 32-bit architecture" that apparently don't let them do what they want, and since a lot of programs already patch the syscall table in 32-bit windows, it'd break compatibility with a lot of software to change it now. Binary compatibility for drivers that patch the syscall table on 64-bit Windows isn't an issue because 64-bit Windows for AMD64 has always prevented syscall patching. They figure that the 32->64 bit change is big enough to pile on some more changes, like this.

This has more to do with system stability than it does for security. Many syscall interceptors are not multiproc safe or do bad things: if the computer bluescreens because of a poorly written syscall interceptor, Microsoft gets blamed for writing unstable software. The syscall interface is considered an internal interface, not to be tampered with by outside parties because its behavior has subtleties not documented, and could change. This is a technical enforcement of that policy.

Re:I'm confused

[TheRaven64]

Actually, the 32-bit model is better in a lot of ways. One of the ways AMD 'tidied up' the x86 instruction set with x86-64 was to get rid of the four ring model and move to a privileged/unprivileged model. They also threw away the segmented addressing[1]. This means you can't run a driver in ring-1 or 2 with its own segment and prevent it from accessing the kernel's segment but still let it have direct access to a device, which is possible with IA32. Of course, Windows NT didn't use this model in recent releases (it might have done in the 3.5 days; I can't remember), but OS/2 and later versions of Netware did.

[1] By the way, the Wikipedia x86-64 article is horrendously biased, and just plain wrong in this area to such an extent that I can't even be bothered to fix it. Apparently Minix 3 is not a 'modern operating system,' and the creators of Xen do not fall into the category of 'modern' in terms of operating system thought.

Re:Sounds like the right plan

[omicronish]

1) If other A/V companies can do A/V software without kernel access, why do McAffee (or as some other slashdotter erroneously called it, McCafe) and Symantec need kernel access? Why are they so special?

In case people are wondering, yes, 64-bit Vista anti-virus software exists. See this post for details.

Re:I'm confused

[zhiwenchong]

Haha.....
However, I think non-Quebecers need an explanation, so here goes:
Quebec French Profanity

You sign your driver, silly

[Anonymous Coward]

http://www.microsoft.com/whdc/system/platform/64bi t/kmsigning.mspx

There's 4 ways to sign your bits for kernel mode running on x64- all the way from making your own test cert and booting windows in a test mode to getting a commercial CA to sign with.

Re:Alpha supported 4 privilege modes

[TheRaven64]

Actually, the Alpha was rather more clever than that. It had only had two privilege modes, and no privileged instructions. One instruction was 'switch to a special mode where some hidden registers and then jump to an address in firmware' The instructions in the firmware (known as 'PALCode') could then check values in the (six, if I remember correctly) shadowed register to implement different privileged modes. Once entering the PALCode, the instruction sequence could not be pre-empted. This allowed the addition of atomic operations to the Alpha trivially. The VMS PALCode, for example, contained instructions defined in PALCode for appending numbers to queues, which could be used to implement inter-thread message passing easily.

Different operating systems had different firmware images. The VMS PALCode implemented a load of privileged instructions that corresponded to those found in the VAX. The NT PALCode implemented x86-style operations.

So, while VMS may have required four privilege modes, these were not intrinsically an attribute of the Alpha. Instead, various instructions defined in PALCode would check the status of a shadow register and refuse to operate if it had the wrong value. PALCode was an incredible concept, and it was a very sad day for the industry when the promise of the Itanium killed the Alpha.

Re:I'm confused

[Allador]

Microsoft is not the certificate authority here. You can get a code signing cert from a number of vendors.

Here's some more information from a 30-second google search:

http://www.microsoft.com/whdc/winlogo/drvsign/cros scert.mspx

http://www.microsoft.com/whdc/system/platform/64bi t/kmsigning.mspx

Obscurity?

[nuintari]

Sooooo, Microsoft can't fix their OS by cleaning up there code, so they are going for the security through obscurity approach? And while they are at it, taking swipes at Mcafee and Symantec marketshare? Great idea, cause yeah, that works. Anyone who knows anything about security, knows that obscurity is _not_ part of it.