No, the vulnerability is very much specific to hyperthreading.
No it isn't.
Without hyperthreading, there would be no practical way to get sufficiently detailed information for an attack (not without physical access to the CPU to do DPA or something similar).
Cache observation attacks have been theorized as a possibility for quite a while, but this paper shows that hyperthreading has finally made it easy enough that it can actually be done.
DJB's paper shows that it can "actually be done", and he's using an Athlon, not a P4. This is a cache timing attack and they are as old as caches are.
The solution is not to disable HT or wail about how it's a "security hole"--because we know that the same attacks can be made on any system that either multitasks or has a cache too small for the lookup tables. It's to use high performance encryption algorithms that have neither data nor key dependencies, which means no table lookups. There are a number of them out there. AES just isn't one of them (it can be high performance, or it can be free of data and key dependencies, but thus far it doesn't appear that it can be both).
The vulnerability is not Intel-specific. This kind of timing information can be leaked on any system that has data caches that are either too small to hold the entire lookup table an algorithm uses, or on an OS which multitasks, or use a lookup table with certain characteristics, or....
The problem is not with hyperthreading. It's not with Linux. It's with the implementation of the encryption algorithms. They need to stop assuming that table lookups are constant-time. Because they're not. As good as constant-time for most purposes, yes. But for cryptography they're not good enough.
It wasn't there in NT 4. The NT Option Pack provided Index Server (or whatever its exact name is, something along those lines) as one of its components. The NTOP was an add-on released a long time after NT 4 itself.
Index Server is exensible using an API known as IFilter. Third-party filters allow the indexing of, for example, PDFs.
The IFilter API is used by various MS search tools. Index Server is one. "MSSearch" (used for SQL Server and Exchange full text indexing) is another. SharePoint Portal Server's FTS tool is another.
The engines of these products are all pretty similar; all seem to use BM25 as their ranking algorithm.
However, they're all different, and they all store their indices and configuration information slightly differently.
It's long surprised and dismayed me that MS hasn't built into Windows a decent front-end to Index Server, because it's actually a very effective and useful tool. It's just a pain in the ass to configure and use.
Except that Google could provide the exact same level of integration as MS have, if they so desired. MSN Desktop Search uses documented APIs in documented ways. The extensibility interfaces it uses are open to anyone who wants to use them. If Google's search doesn't use them, that's no-one's fault but Google's.
You'll further notice that the search bar isn't integrated into the OS. It's a separate download from msn.com. It's doing nothing that third party developers couldn't do.
No, being merely "constant time" isn't good enough, as djb also points out.
Most DES and AES implementations are "constant time". The problem is they use lookup tables, which can be driven from cache, thus altering the timings of the function. In other words, they introduce a kind of data dependency--because whether a given portion of the lookup table is cached or not depends on the offset being looked up. Precomputed tables are used to provide constant-time operations, yet actually have the effect of introducing timing problems.
As far as I can tell, the only solutions are to either provide a mechanism for encryption operations to gain exclusive use of processor resources (which means no context switching allowed at all) and be written to ensure that their lookup tables fit in cache and never suffer contention, or to use encryption algorithms that don't use lookup tables at all.
Of these solutions, only the second is even remotely practical.
Timing attacks are pretty hardware independent; they're more a trait of algorithms (requiring table lookups and hence cache hits and misses). Sure, one could create processors without data caches, but would one really want to?
The only real solution to such timing attacks is to disable multitasking; anything that can replace cache lines can disclose information. Hyperthreading may be a little "worse" in that it can make the cache contention a bit worse, but the problem exists with hyperthreading disabled.
This is why MS invented APIPA (automatic private ip addressing), in the 169.254.0.0/16 range, which made its debut with Windows 98. If a network adaptor is set to DHCP but no DHCP server responds, it picks an IP in that range. This allows ad hoc local networks to form.
ZeroConf takes APIPA and adds to it multicast DNS (again, because ad hoc networks don't have DNS servers that they can publish names to). Any machine on the local network can listen to the mDNS requests and respond accordingly; it uses specially formed DNS names to publish services (in a manner broadly equivalent to, but IIRC incompatible with, SRV records).
UPnP uses a different mechanism for service discovery (it uses multicast HTTP instead of multicast DNS). It also goes a step further and allows devices to publish known, standardized interfaces.
ZeroConf lets iTunes search for other local iTunes and share media libraries. IIRC only iTunes knows how to talk to these other iTunes instances, because there's no ZeroConf standard "media library" facility.
UPnP lets *media players* search for other local *media players*. These media players are, as long as they conform to the right interface, mutually compatible; it doesn't matter if a "Media Library" is a SAN or a program like Winamp or WMP or some putative networked iPod or hifi system; it just conforms to a standard "Media Library" interface and can stream files accordingly. Likewise the "Media Renderer"; I can control a Media Renderer without caring about its exact nature (it might be a hifi or a PC or something else entirely).
UPnP works well, and can do everything ZeroConf does and then some; it's probably most widely used for Internet Gateway Devices; you get your nice cheap combined cable modem/router box from Linksys, and Windows can see and recognize the device, allowing it to report on connection status, provide a "built-in" link to the device's management web page, and so on and so forth.
It's not clear to me why the average home user wants to be told by the OS of *his* computer that he can't do the things that he wants to do. Limited user accounts make sense on multiuser systems (where users *don't* own the system and so shouldn't be allowed to damage either it, or each other). They don't make sense when someone's the sole user and owner of a machine. If I want to install Bonzai Buddy or check out the latest e-mail offering nekkid pictures of Anna Kournikova, nothing in the OS should hinder me.
Except it doesn't run in the kernel. Things like IE, Media Player, DCOM, UPnP, the shell, Movie Maker, Index Server, IIS (except for http.sys, which is only a tiny part of IIS),.NET, they're not in the kernel. So why should they be included?
A fair comparison is between the NT kernel and its associated drivers (ntoskrnl.exe, hal.dll, *.sys) and some key user mode components (csrss.exe, smss.exe, perhaps lsass.exe, and their associated libraries), and Linux. NT's still probably "bigger" (because it contains things like all the GDI code, which doesn't much overlap with Linux), but not as much as the article makes out.
No, it moved GDI into kernel mode. Win32 remains a mix between user-mode and kernel-mode; many Win32 APIs are just thin wrappers around the NT kernel API, others are more complex and have relatively significant user-mode portions.
will get moreso with the development of private orbital capacity
In spite of all the clamour over Rutan's little plane, private orbital capacity has been around for decades. It's been developed. It exists. It's for sale, and the costs are coming down. All thanks to the good people at ESA.
In any case, there are plenty of other viable non-nuclear power sources; offshore wind generation, for example. Putting the windmills offshore solves the aesthetic/environmental issues with windmills. We have the technology and the know-how to do it, and a large-scale deployment will drive the costs right down.
For instance, if we don't believe abortion is right as a form of birth control, but we believe that homosexuals deserve to have some form of union, who do we vote for in our current political system?
I would have thought this was simple. You vote democrat (as they're the closest thing to a mainstream pro-equal rights party), and you don't have any abortions. Don't like 'em? Don't have one. It's not complicated.
Actually, I think you shouldn't make such an assumption.
The "C/C++" crowd seem to be made up of two kinds of people:
a) C programmers who don't understand that C++ has a different featureset, different idioms, a much better library, and so on, and so who asume that C++ is still only "C with classes".
b) people who know neither language particularly well.
Neither group is particularly desirable, of course, unless you really only want C, in which case the first group may have some useful members.
"Just to be clear, unparseable XHTML is not XHTML."
And broken HTML is not HTML.
The reason browsers try to parse broken HTML is not because the HTML spec requires them to do so (it doesn't, and it gives such documents no semantics). It's because neither early browsers nor page authors followed the specs strictly; early browsers would try to render malformed pages (either deliberately or through not explicitly rejecting such pages), and early page authors would (usually unwittingly) exploit this fact.
If the first HTML renderers had followed the HTML spec and no more then the web would not be the mess it is today.
XHTML doesn't really fix any of this; it resolves a small class of ambiguities that un-DTDed HTML hypothetically has (in HTML one needs to refer to the DTD to determine whether something of the form <img> is an empty element or a malformed element that lacks is closing tag (the DTD says whether things are empty or not); in XML (and hence XHTML) it's unambiguously an error because XML requires even empty elements to have closing tags, or use special shorthand). But it's not this that make it easier to parse; that alone has negligble impact on ease of parsing.
Instead, it's the attitude that goes along with it--if it's not well-formed, reject it with an error message. There's no reason that the HTML spec couldn't be held in similarly high esteem.
Slashdot Mirror
You have seen (or, indeed, heard) the PowerMac G5s, right?
Cool and quiet they ain't.
High-end PPCs appear to have lost any power and heat advantages they once had over x86.
No, the vulnerability is very much specific to hyperthreading.
No it isn't.
Without hyperthreading, there would be no practical way to get sufficiently detailed information for an attack (not without physical access to the CPU to do DPA or something similar).
Yes there would. As shown for example here.
Cache observation attacks have been theorized as a possibility for quite a while, but this paper shows that hyperthreading has finally made it easy enough that it can actually be done.
DJB's paper shows that it can "actually be done", and he's using an Athlon, not a P4. This is a cache timing attack and they are as old as caches are.
The solution is not to disable HT or wail about how it's a "security hole"--because we know that the same attacks can be made on any system that either multitasks or has a cache too small for the lookup tables. It's to use high performance encryption algorithms that have neither data nor key dependencies, which means no table lookups. There are a number of them out there. AES just isn't one of them (it can be high performance, or it can be free of data and key dependencies, but thus far it doesn't appear that it can be both).
The vulnerability is not Intel-specific. This kind of timing information can be leaked on any system that has data caches that are either too small to hold the entire lookup table an algorithm uses, or on an OS which multitasks, or use a lookup table with certain characteristics, or....
The problem is not with hyperthreading. It's not with Linux. It's with the implementation of the encryption algorithms. They need to stop assuming that table lookups are constant-time. Because they're not. As good as constant-time for most purposes, yes. But for cryptography they're not good enough.
No and no.
It wasn't there in NT 4. The NT Option Pack provided Index Server (or whatever its exact name is, something along those lines) as one of its components. The NTOP was an add-on released a long time after NT 4 itself.
Index Server is exensible using an API known as IFilter. Third-party filters allow the indexing of, for example, PDFs.
The IFilter API is used by various MS search tools. Index Server is one. "MSSearch" (used for SQL Server and Exchange full text indexing) is another. SharePoint Portal Server's FTS tool is another.
The engines of these products are all pretty similar; all seem to use BM25 as their ranking algorithm.
However, they're all different, and they all store their indices and configuration information slightly differently.
It's long surprised and dismayed me that MS hasn't built into Windows a decent front-end to Index Server, because it's actually a very effective and useful tool. It's just a pain in the ass to configure and use.
Except that Google could provide the exact same level of integration as MS have, if they so desired. MSN Desktop Search uses documented APIs in documented ways. The extensibility interfaces it uses are open to anyone who wants to use them. If Google's search doesn't use them, that's no-one's fault but Google's.
You'll further notice that the search bar isn't integrated into the OS. It's a separate download from msn.com. It's doing nothing that third party developers couldn't do.
Er. Lookup tables *are* used to make high performance constant-time algorithms. That's, you know, the entire problem.
No, being merely "constant time" isn't good enough, as djb also points out.
Most DES and AES implementations are "constant time". The problem is they use lookup tables, which can be driven from cache, thus altering the timings of the function. In other words, they introduce a kind of data dependency--because whether a given portion of the lookup table is cached or not depends on the offset being looked up. Precomputed tables are used to provide constant-time operations, yet actually have the effect of introducing timing problems.
As far as I can tell, the only solutions are to either provide a mechanism for encryption operations to gain exclusive use of processor resources (which means no context switching allowed at all) and be written to ensure that their lookup tables fit in cache and never suffer contention, or to use encryption algorithms that don't use lookup tables at all.
Of these solutions, only the second is even remotely practical.
Timing attacks are pretty hardware independent; they're more a trait of algorithms (requiring table lookups and hence cache hits and misses). Sure, one could create processors without data caches, but would one really want to?
The only real solution to such timing attacks is to disable multitasking; anything that can replace cache lines can disclose information. Hyperthreading may be a little "worse" in that it can make the cache contention a bit worse, but the problem exists with hyperthreading disabled.
Works perfectly when I've tried it with Linksys devices.
"What's wrong with DHCP?"
It needs a DHCP server.
This is why MS invented APIPA (automatic private ip addressing), in the 169.254.0.0/16 range, which made its debut with Windows 98. If a network adaptor is set to DHCP but no DHCP server responds, it picks an IP in that range. This allows ad hoc local networks to form.
ZeroConf takes APIPA and adds to it multicast DNS (again, because ad hoc networks don't have DNS servers that they can publish names to). Any machine on the local network can listen to the mDNS requests and respond accordingly; it uses specially formed DNS names to publish services (in a manner broadly equivalent to, but IIRC incompatible with, SRV records).
UPnP uses a different mechanism for service discovery (it uses multicast HTTP instead of multicast DNS). It also goes a step further and allows devices to publish known, standardized interfaces.
ZeroConf lets iTunes search for other local iTunes and share media libraries. IIRC only iTunes knows how to talk to these other iTunes instances, because there's no ZeroConf standard "media library" facility.
UPnP lets *media players* search for other local *media players*. These media players are, as long as they conform to the right interface, mutually compatible; it doesn't matter if a "Media Library" is a SAN or a program like Winamp or WMP or some putative networked iPod or hifi system; it just conforms to a standard "Media Library" interface and can stream files accordingly. Likewise the "Media Renderer"; I can control a Media Renderer without caring about its exact nature (it might be a hifi or a PC or something else entirely).
UPnP works well, and can do everything ZeroConf does and then some; it's probably most widely used for Internet Gateway Devices; you get your nice cheap combined cable modem/router box from Linksys, and Windows can see and recognize the device, allowing it to report on connection status, provide a "built-in" link to the device's management web page, and so on and so forth.
It's not clear to me why the average home user wants to be told by the OS of *his* computer that he can't do the things that he wants to do. Limited user accounts make sense on multiuser systems (where users *don't* own the system and so shouldn't be allowed to damage either it, or each other). They don't make sense when someone's the sole user and owner of a machine. If I want to install Bonzai Buddy or check out the latest e-mail offering nekkid pictures of Anna Kournikova, nothing in the OS should hinder me.
http://funroll-loops.org/
And solaris is for servers.
Sounds like a match made in hell.
Except it doesn't run in the kernel. Things like IE, Media Player, DCOM, UPnP, the shell, Movie Maker, Index Server, IIS (except for http.sys, which is only a tiny part of IIS), .NET, they're not in the kernel. So why should they be included?
A fair comparison is between the NT kernel and its associated drivers (ntoskrnl.exe, hal.dll, *.sys) and some key user mode components (csrss.exe, smss.exe, perhaps lsass.exe, and their associated libraries), and Linux. NT's still probably "bigger" (because it contains things like all the GDI code, which doesn't much overlap with Linux), but not as much as the article makes out.
Except, uh, they don't do anything of the sort.
They most certainly do.
IBM do tender for UK government contracts.
Periods are what women emit from their vaginas each month.
Except that increasingly people don't write IP stacks that way because it doesn't scale.
some DirectX
No, NT 4 had full DirectX 3 support.
moved Win32 into kernel mode
No, it moved GDI into kernel mode. Win32 remains a mix between user-mode and kernel-mode; many Win32 APIs are just thin wrappers around the NT kernel API, others are more complex and have relatively significant user-mode portions.
In spite of all the clamour over Rutan's little plane, private orbital capacity has been around for decades. It's been developed. It exists. It's for sale, and the costs are coming down. All thanks to the good people at ESA.
In any case, there are plenty of other viable non-nuclear power sources; offshore wind generation, for example. Putting the windmills offshore solves the aesthetic/environmental issues with windmills. We have the technology and the know-how to do it, and a large-scale deployment will drive the costs right down.
I would have thought this was simple. You vote democrat (as they're the closest thing to a mainstream pro-equal rights party), and you don't have any abortions. Don't like 'em? Don't have one. It's not complicated.
Actually, I think you shouldn't make such an assumption.
The "C/C++" crowd seem to be made up of two kinds of people:
a) C programmers who don't understand that C++ has a different featureset, different idioms, a much better library, and so on, and so who asume that C++ is still only "C with classes".
b) people who know neither language particularly well.
Neither group is particularly desirable, of course, unless you really only want C, in which case the first group may have some useful members.
"Just to be clear, unparseable XHTML is not XHTML."
And broken HTML is not HTML.
The reason browsers try to parse broken HTML is not because the HTML spec requires them to do so (it doesn't, and it gives such documents no semantics). It's because neither early browsers nor page authors followed the specs strictly; early browsers would try to render malformed pages (either deliberately or through not explicitly rejecting such pages), and early page authors would (usually unwittingly) exploit this fact.
If the first HTML renderers had followed the HTML spec and no more then the web would not be the mess it is today.
XHTML doesn't really fix any of this; it resolves a small class of ambiguities that un-DTDed HTML hypothetically has (in HTML one needs to refer to the DTD to determine whether something of the form <img> is an empty element or a malformed element that lacks is closing tag (the DTD says whether things are empty or not); in XML (and hence XHTML) it's unambiguously an error because XML requires even empty elements to have closing tags, or use special shorthand). But it's not this that make it easier to parse; that alone has negligble impact on ease of parsing.
Instead, it's the attitude that goes along with it--if it's not well-formed, reject it with an error message. There's no reason that the HTML spec couldn't be held in similarly high esteem.
"Richard Stallman was in the car earlier but apparently had been dropped off prior to the accident."
So near and yet so far.
"When a third party vendor wants to distribute a Microsoft DLL with their product, don't they have to get permission from you?"
No.
"Wouldn't there be a list somewhere in Redmond of the third party applications that have distributed vulnerable copies of gdiplus.dll?"
No.
"Can you tell us what they are?"
You tell me....