Last week talkback contributor "Troll Hunter," defending the view that software exploits are hardware independent made the comment that Microsoft's patches affect software, not hardware.
Neither part of that view is correct: not the obvious part -that exploits are purely software dependent - and not the non obvious part: that all fixes are software.
To look at the obvious bit first: it's clear that developing an exploit is a two step process:
It seems tautalogical to assert that step one is software dependent - even in cases like the German BSD group's exploit for the (hardware) bug in the pre-200Mhz UltraSPARC II - so let's agree that this is generally true.
Step two, however, is done in software but usually relies on knowledge of hardware behavior. Thus an exploit for x86 is generally not easily recoded for use with the same OS on different hardware. For example a trival buffer overflow error in Microsoft's code for Message Queuing (MS05-017) is easily exploitable on Windows/XP for x86 but that same exploit code fails when applied to Windows/XP on Itanium.
And that, of course, is also the key to the non obvious part of Troll Hunter's mistake: Microsoft and Intel have indeed tried to patch the hardware.
Meeting the PC community's idea of "Security" was a key part of the Itanium agenda -in fact one of the reasons Intel has now had to replace the x86 compatible hardware component on its next generation Itanium products with software is simply that making it work better than it has so far means forfeiting the hardware patch effect they were trying to implement.
Look at any facet of Itanium and what you see is an overriding design focus on limiting exploitability at the hardware level - from boot weirdness to page management, the thing is aimed at preventing most of the known x86 hardware dependent exploit methods.
It's something like a bad pun (anyone know the right word?), but it would even be possible to argue that Intel's primary motivation for getting into the thing -its inability to patent the x86 instruction set and so put AMD out of business - was a response to an x86 exploit. ( -:) )
Many of those same protections were pioneered, of course, in RISC designs like those for SPARC and PPC and some, noteably some page protection bits, have now made into x86 via AMD's Sun mediated Opteron design. Hardware, however, requires software and what little hardware protection there is in the x86 is generally not yet utilized by most of the software running on it - and one of Apple's problems is that the BSD community has developed a lot of good software workarounds for vulnerabiities like the x86's rigid execution order, but Apple can't afford the performance cost of using them to out-do Microsoft in this arena.