Slashdot Mirror
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.
I know this isn't PC to say on Slashdot.. but MS shouldn't allow undocumented hooks to the kernel. Instead they should provide an API for that.
What's the difference between the 32 bit and 64 bit kernel? And what does a 'tabernacle of security' mean?
I don't think there's a significant difference in DRM hardware between 32bit and 64bit systems. Why make the distinction? If they're going to secure Windows - why not secure Windows?
Am I the only one who read the line "Making concessions to Symantec and McAffee," and the first concessions that popped into my mind were "Just a little security hole here, buffer overflow there, ect."
I'm no fan of MS, especially when it comes to their horrible security track record. However, if they really can manage to get it right (or even significantly better) in Vista, they shouldn't be going and making concessions to the people who've been making a living off the things that were broken in their last OS.
Microsoft wants to be responsible for its own security - more importantly, Microsoft wants to reap the financial rewards for becoming responsible for its own security. The personal home user will end up paying a bit more for lack of competition in security software, which won't matter to Microsoft - the real market is corporate sales.
Others have tried this before. Never works. Unless it uses trusted hardware, it can allways be run in emulation to facilitate analysis.
If it uses trusted hardware, then it will have other serious problems, like making virtualisation hard or impossible, something that could make it fail entirely in the market.
This tough act is just a smokescreen for something else. Hmmm. Do they think they could get around some (e.g. EU) interoperability requirements that way?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Isn't this just another variation of security by obscurity?
Which everyone by now should have learned does *not* work.
Either way Mcafee & Symantec will claim that it was needed later, simple business.
If the new model seems to be secure, Mcafee and Symantec will boast about how they've kept the next generation of Windows safe.
If the new model is less secure, McAfee & Symantec will "point out" the need for their products.
Win win for AV companies...
Isn't this just another variation of security by obscurity? Which everyone by now should have learned does *not* work.
Actually it does work. Where people go wrong is using it as their sole security measure. In concert with various other good practices obscurity is good.
Yeah, and no-one really needs more than 640k of ram.
How we know is more important than what we know.
Engineering is the art of compromise.
I'm running some applications (logic synthesis) that need a few gigabytes of RAM. It's really nice to be address that linearly instead of stuff like highmem.
So, it's not about the integers, it's about the pointers (logically).
Given that Joe Public no longer believes MS has control over security, they need to build some new mental images to sell. 64-bit black boxes sound pretty solid.
Engineering is the art of compromise.
If it will stop crapware like StarForce and the Sony rootkit from sneaking extra drivers in, bring on the kibosh. People who want to tinker can use one of the fine Open Source operating system kernels that run on 64-bit Intel machines. Those that just want to play games or run Office can feel a little bit safer from malware.
Sorry Symantec, but after dealing with the disaster that is Norton Internet Security, I won't shed a tear when I read that you've filed for Chapter 7.
0 1 - just my two bits
Will not go very well, at least in beginning. This enhanced security won't sell it. There won't be drivers for some existing stuff ever. Seems that MS wants to push this version and keep 32-bit as legacy, but in the end when end user can't make it work as well as 32-bit, it is just going to slip and create confusion. In long run it may pay off, when systems and components are designed for 64-bit, until then, 32-bit will be preference. I wonder if any of corporate users are going to put 64-bit on employeees workstations in upcoming months -it seems as a big risk without much gain.
For 32-bit versions of Vista, it'll be mostly as you were on security
Translation: You're screwed! Upgrade to 64 bit ASAP (P.S. some of your software won't work)
Defender has already become the most popular download ever from Microsoft
If I was MS, I certainly wouldn't brag about anti-malware being the most popular application.
referring to third parties being able to patch 64 bit Vista - "It's just not the way the box was designed...we're putting a stop to that."
Great. What happens when MS doesn't quickly put out a patch... no choice on using the good samaritan patches anymore, you just have to sit and twiddle your thumbs.
referring to ever being able to secure 32 bit Windows - "That train has left the station."
I think it's more like the Windows train has left the station. Why bother to convert to 64 bit Windows? Switch to something else as soon as possible.
Thats exactly what I want. I do not want to have any software patch the kernel.
If there is no way for the spyware to patch the kernel I don't need McAfee or Symantec there at all. First thing I do with a new home machine is to strip off the AV software provided by Dell as cramware. Machines run so much faster and more reliably without. Then I turn off AutoRun and hook it up to my internal network which has twin SPI firewalls.
I have never had a virus but I have had machines go wonky because of buggy AV code.
I want to have as few kernel mode device drivers as is possible. Printers should not require kernel mode, nor should video cameras etc. Only the bare essentials talking directly to the DMA interfaces should ever use kernel mode.
I don't need to run my code in kernel space and I don't think anyone else does either.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
kernel overflows.. same way you modify a linux kernel after it's had the "no more modules may be installed" bit turned on. See, it's really easy for hackers, they just grab the latest kernel bug that has been found and plug it in to their rootkit. Same with dodgee spyware people. But legitimate software developers can't do that. It'd be unethical.
How we know is more important than what we know.
You can bet this is going to make life very hard for the folks like VLC or anyone who wants to do something clever with the audio system. Wonder how they are going to push it, however? Sure, they can go for attrition, and make sure all new machines come with Vista, but there are a lot of Win32 machines out there that have more than enough CPU. There were some big jumps from the 200mhz-600mhz range, but now with 2-3ghz more or less normal and no 'got to have it' devices like USB3 this is going to be a tough sell. Heck, even with DirectX 10 being reserved for Vista, game publishers would be suicide to go after that market for a couple years. While it might give a few more FPS, you can bet the vice-like grip on hardware will doom any of the older games from running on the system... I mean, heck, if you could access the video, you might just try to display content without the secret hardware handshake.
+++ UGUCAUCGUAUUUCU
This makes me think of Kid-Proof caps. Only the kids will be able to open the cap to get into the kernel. Users who want to install legit stuff, forget it.
...but could you cite some examples?
One thing would be the Xbox hack, although that involved an attack on the hardware as well.
There are counless successful projects to port Linux to some closed (i.e. black-box) hardware.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Probably because the 64 bit version will break a lot of code. For example a lot of TV boards write their own drivers (for better or worse) and these won't work. Anything that writes it's own driver or have to get to ring 0 will break.
So the 32 bit will be if you want anything to run, the 64 bit will be for people who want to play DRM'd content on their PC. Maybe an exaggeration, but I think that's about it.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
And there are thousands of Philistines, including some very 1337 H4x0r5, at the gates
It's "Mac", not "MAC". MAC is an acronym: Media Access Control [address]. Mac is short for Macintosh.
And Apple makes most of its money from selling hardware, so I sincerely doubt they'll drop that and try to squeeze money out of selling an operating system exclusively.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
The kernel has a reputation for being not particularly bad.
The reason the kernel is an issue, is that the new "threat" against Windows security is the owner/administrator of the machine. Microsoft needs to try to implement DRM, in order to get into bed with the media companies and sell music and Zunes to play it. You can't implement DRM if the user can patch the kernel to work around the DRM. Thus, they're going to try to prevent end-users from having the capacity to modify this behavior of their own computer.
The "security companies" are taking collateral damage from this, because their applications have to intercept all reads/writes (to files, the network, whatever) in order to scan all data against a blacklist of known malware in order to try to protect the comically fragile userspace. This scanning is implemented through kernel patches, I guess.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
firefox kicked their assess with the better browser. Mac could do the same with the better platform.
How has Firefox "kicked their ass"? I'm not trying to defend IE, but last I saw, it still had nearly 90% of the marketshare. That's the kind of market domination that many companies would kill for.
We all know what to do, but we don't know how to get re-elected once we have done it
hate to burst your bubble but not retaining emails is the policy of MANY large companies. It is not done purely because they are trying to play dirty, people say stupid things in emails that can easily be taken out of context if you don't know the receiving and sending parties. By ensuring the policy is that old mail MUST be deleted they also don't have a huge burden of searching massive terabytes of mail stores everytime some company or person wants to order them to hand over XYZ emails. PS the burst lawsuit is just yet another example of leech like companies using the law to tie up other companies resources in the hope they will settle. I have no sympathy for scum like them.
No, Zeinfelds world view is entirely sane and very defensible. I agree with him.
Let's review a few facts:
The foundation of any security system is the kernel. If the kernel is not running in a known state, you have no security system - period.
There is absolutely zero point in having user accounts, authentication, file permissions and so on if programs can load code into the kernel ... which they can, because for historical reasons Windows programs require admin rights, and even if they didn't, ultimately any program can ask the user to do something on its behalf and most will.
The solution is clear - forbid any unknown code from loading into the kernel. Only then can you have a sane system built on solid foundations. It is not a "right to read" scenario, because you can still mark individual drivers as loadable in Vista IIRC if you put it into developer mode (which makes it clear that you are in a special mode), but even if it wasn't, it'd be a price worth paying to help fix the internet.
In fact, rootkits and kernel infesting malware have been on the rise in Windows the last few years, and are much more common than you seem to think.
Having kernel hooks wouldn't help AV programs detect this if the malware was well written and had already attached itself - you often need to get out of the environment to detect such problems, as with a live CD. After it was infected, anything the kernel reported would be suspect.
The trick to catching malware is covering the vectors through which it enters the system. No more, no less. The grandparent is spot on as far as I'm concerned.
64bit Windows will see deployment in the server room on corporate data centers. In this area security is secondary to audit compliance. Server ops will turn on the default Win64 kernel security and it will do whatever it does. Auditors will check the AV box and move on to the next server. Everyone is happy. Server ops has one less thing to do and auditors have an easier job of auditing. I know that's cynical but that's how it works.
Let's remember that the reason Windows is in the server room in the first place is because MS sold it on the premise that's easier to run. Not faster, not with less hardware, not even with fewer people but with a lower skill set. Cheaper. So embedded security is not about security, it's about skill sets. Set it, forget it, hope for the best. If it smashes on the rocks then everyone did their best anyway and no one can be held accountable.
Unfortunately that's not the solution Microsoft chose. What they did is make a kernel that will only load code that has been approved by and paid a toll to Microsoft the amount of which is determined by Microsoft. That's vastly different than what you presented as the solution. On my Linux box unknown code is not permitted to load in the kernel but I'm the one who determines what is loaded into the kernel not Microsoft and there is no required payoff to allow code to load into the kernel.
Who is John Galt?
There have been enough zero-day image loader exploits pushed out via advertising networks that you don't have to have done anything wrong or inadvisable to get infected these days.
And by "malicious" we mean "Disney doesn't like it".
After all, it's not the user who's being protected here, it's the media corporations Microsoft is trying to sell Windows as a distribution channel to.
Alternatively, it could be "Provides good native OpenGL acceleration". After all, portable applications would be the death of Windows.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
or to paraphrase: Marketing
The problem with microkernels is that you're putting the "fence" where it looks pretty -- not where it's practical. The appropriate place for the fence is where the minimum amount of data has to cross it, and that's not necessarily where it contains the minimum amount of code.
Device drivers must, at some level, have a kernel component; because nothing in userland is allowed to talk to I/O ports. Only the kernel can do that. At the very least there must be a kernel component which accepts an instruction to read or write an I/O address and returns a result, via some method which is available to userland software. Of course, if you have a totally generic kernel driver which allows any userland program arbitrary access to any I/O ports without checking, then you have just knocked down the fence altogether. So a kernel driver needs to have at least some sanity-checking built into it.
Je fume. Tu fumes. Nous fûmes!
The problem is that a black box is always running in an unknown state - it's entirely a trust issue between you and the vendor, regarding the solidity of their authentication methods, security protocols and limitations on execution privileges. If a key is compromised, a way is found to bypass the authentication process or there's a suitably buggy driver, all bets are off again.
Of course, proclaiming "no unknown code may run in kernel mode" does make security a much simpler issue; you can bet the farm on how the gate holds, instead of putting locks on doors.
I don't need to run code in kernel space either, but I need to have the right to do so in order not to be held hostage by one particular company that decides what I can and cannot do with my own computer.
-- Ed Avis ed@membled.com
You cannot cover all incoming vectors, there's just too many of 'em. And every program you run opens another, no thanks. With the kernel reasonably trustworthy sealed-off from anything, you may have a chance of recovering from any other disaster without re-installing everything but the kitchen sink. Then you can trust the kernel to report processes, file permissions and dir contents correctly, which can then be correctly terminated.
A compromised kernel allows you neither: dir contents are inaccurate, malware has its processes hidden from the taskmanager, its files from the explorer and whatever deletion requests your antivirus software issues, they're not going to be carried out at all. As long as you can't trust the kernel, everything you try is moot and converse, if you can trust the kernel, you can start repairing the system from secure sources (cdrom, intranet etc.). And since nothing can wedge itself too deep anywhere, repairing and cleaning should be feasible, at least.