Hacker News Reader

Comment by rwmj | Hacker News Reader

Would it be fair to say that having any sequence of bytes in memory which looks like the xdcbt instruction (even if those bytes are just data) is unsafe? Given that a stale entry in the branch prediction table might end up pointing at those bytes.

View on HN

PowerPC instructions are always four-byte aligned, and the Execute bits are checked very early, so the only instructions the developer had to care about were those that were compiled into the code segment.

SolarNet addresses one aspect of the issue but there's another important one here for PowerPC. Every instruction has to start on a 4-byte boundary[1] so if a sequence of bytes that make up the Evil Instruction is present but at a 1 byte offset you're still perfectly safe. This isn't true for x86, where if you start executing at byte 1000 you might get one valid sequence of instructions but if you start executing at byte 1001 you might get another equally valid but malicious sequence[2].

[1] Unless there's some variable width mode like ARM's thumb I'm not aware of, but even then you're limited to 2 byte boundaries.

[2]http://mainisusuallyafunction.blogspot.com/2012/11/attacking...

Data and code are not quite so interchangeable (thankfully). Typically programs have code segments and data segments, and processors actually have support for specifying the difference in behavior. A branch predictor would probably not run against pointers to memory segments without the execute bit set.

... unless they suffer from the same problem as Intel CPU's Meltdown fiasco. Where the branch prediction runs concurrently with the security checking. The branch predictor hits and speculates, firing the bug, while the security check then decides "that's an invalid branch" and discard it--but it's too late the bug side-effect his occurred.

But I think for it to happen randomly, you'd need an invalid pointer that just so happens to jump to what "becomes" an instruction with a bug, and a branch. That seems pretty rare on first glance.

Actually, this is exactly the assumption that led to the Meltdown bug. The Intel CPU speculative (non-retired) instruction pipeline runs instructions which access memory and load it into cache and execute the instructions, delaying the check that the memory is accessible within the current context until later (just before instruction retirement).

It's certainly possible that a CPU could delay the same sort of exception processing for "NX" flags until later in the pipeline, but still before retirement, allowing a similar sort of problem as Meltdown.

If that's true, then it may be better to disable that particular opcode itself from the chip.

84 million XBox 360s in the wild so it may be a bit late for that :-) Consoles have very predictable patterns of execution and only run a limited set of software so it's not so much a problem there. It would be a much more serious problem if this was a chip for a general purpose PC.

There may still be JITs and web browsers on consoles.

The 360 didn't open up the ability for titles to generate their own code and run it. Some internal features of the 360 did (the back compat stuff, and some other projects I can't talk about), but in general you couldn't JIT without some special permissions bits.

And presumably once you have those, you're already on the other side of the airtight hatchway and can control the machine directly?

Reply on news.ycombinator.com