Notes from the Intelpocalypse

Posted Jan 5, 2018 6:59 UTC (Fri) by epa (subscriber, #39769)
In reply to: Notes from the Intelpocalypse by roc
Parent article: Notes from the Intelpocalypse

Right - but on Itanium it would be more straightforward to fix, since you could set a compiler flag to just remove speculative load instructions from the kernel (as a quick fix), adding them back where they are proven safe. Indeed, the compiler could be taught not to speculatively lift loads outside bounds checks.

In user space, I imagine that the explicit speculative load instruction used on Itanium does do all the same memory access checking as an ordinary non-speculative load, so it can't be used to snoop in the same way as the hidden speculative execution on x86_64.

Notes from the Intelpocalypse

Posted Jan 5, 2018 10:12 UTC (Fri) by ortalo (guest, #4654) [Link]

Well, maybe I am a somehow disingenuous, admittedly back then the hardware-based solutions looked better, but I have to question everything, including the fact that the most prominent hardware vendor of that time really did try to favor software development tools rather than its own silicon-oriented intellectual property, don't you think?
Anyway, I would love to be proven wrong and see some of this past research resurrect into a nice powerfull-enough deterministic processor and the associated innovative software development environment for current and near-future critical systems. In my opinion, it is the right time now and many would certainly consider helping it (in good faith I assure you ;-).

Notes from the Intelpocalypse

Posted Jan 5, 2018 11:16 UTC (Fri) by roc (subscriber, #30627) [Link] (1 responses)

Your second paragraph seems to be talking about Meltdown, but Spectre 1 is still a problem for user-space applications. It is probable that Meltdown wouldn't have worked on Itanium.

FWIW in C I don't think it's easy to tell what is a bounds check and which loads are guarded by which checks.

I agree that it would be a bit easier to fix these specific issues in Itanium. I don't think that makes this a "Itanium should have won!" moment.

Notes from the Intelpocalypse

Posted Jan 7, 2018 16:02 UTC (Sun) by mtaht (subscriber, #11087) [Link]

The discussions over at comp.arch have been quite informative,(https://groups.google.com/forum/#!forum/comp.arch)

And it does look like the mill was invulnerable by design to spectre/meltdown. They did find and fix a bug where the compiler could lift a memory access ahead of its guard, but near as I can tell that would have caused a segfault rather than a permissions violation.