eigenform

Yes, I'm pointing out the fact that the programmer is expected to manage the ALAT, and that these machines do not automatically recover from cases where your advanced loads are incorrect. That process is expected to be part of the instruction stream, and [we have collectively learned that] that's an expensive feedback loop.

Yes, it doesn't require determinism to work, but it means that your performance is especially sensitive to nondeterminism because the compiler cannot account for loads and stores that occur online. The SDM (see vol 1, section 9.5.1) describes this idea pretty well.

The difference is that this is not the programmer's responsibility in modern machines: instead we bake-in some hardware that watches the online state of the machine and then actively decides on what to do.

If you're trying to create a compiler that approaches the effectiveness of this statically, you're condemned to do a ton of extra work (you're essentially writing an emulator for your CPU core, and then a compiler that uses that model to produce optimal code - even then, you might not be accounting for nondeterminism on the actual target machine, and some information is simply not accessible to you when you are not on the target machine)

Additionally, if you look at the changelogs for old ABL, it seems like this policy decision (only supporting for PRO SKUs) has always been implemented in firmware:

https://github.com/amd/firmware_binaries/blob/main/cezanne/P...

AFAICT the situation here is, it should have never been enabled for these consumer parts in the first place.

Well, the FDIV bug is simpler. AFAICT this whole thing is tied up in the relationship between DVFS, silicon aging, and being able to have guarantees about clock reliability. That seems hard to reason about when you give BIOS vendors and users the ability to do over-volting/over-clocking (and of course, it's worse when you are maybe relying on all this in certain situations to try and approach parity with other hardware vendors who are taping out machines on CMOS processes that are more mature than yours).

afaict part of the messaging behind this quake is about the worry that big Sanriku earthquakes like this might make it easier for the northeast part of the trench to unlock (closer to Aomori and Hokkaido, where the Japan Trench starts turning into the Kuril Trench).

No reason that the rate of subduction has to be the same everywhere. Some of the plate boundaries might be moving into each other in different directions too, the coupling between plates is not necessarily the same everywhere.

Anyway, in the case of Cascadia, remember that the lack of big earthquakes over the past 100 years is probably telling you that we just happen to live in a time where strain is accumulating (D:)

The idea here is about maintaining a "path history"!

When looking up a register that tracks the "local" history of outcomes for a particular branch, you want to have a hash function that captures enough context to distinguish the different situations where that branch might be encountered.

Apart from folding a long "global history" of recent outcomes and mixing in the current program counter, I think many modern machines also mix in the target addresses of recently-taken branches.

please stop posting worthless drivel from your language model, thank you. it really cheapens the meaning of all these fancy words.

ie. marketed as "dense" instead of "efficient"

Probably because it's very likely that both AMD and Intel have had engineers working on this sort of thing for a long time, and they're now deciding to collectively hash out whatever the solution is going to be for both of them.

I'm not arguing MPX was a good solution, just that it's silly to assume folks designing x86 machines have been totally ignoring developments in that space for the past ten years.

fwiw "knee-jerk reaction to Apple MIE" is not exactly the right characterization of this. MPX existed and faded away, and it's not very surprising that x86-world would wait for someone else to try shipping hardware support for memory safety features before trying again.

I wonder if this is in response to FineIBT trying to figure out what to use as an undefined opcode? Apparently 0xd6 is being reserved as undefined going forward:

https://lore.kernel.org/lkml/20250814111732.GW4067720@noisy....

Yeah totally. It's really easy to forget about the fact that x86 is abstracting a lot of stack operations away from you (and obviously that's part of why it's a useful abstraction!).

x86 CALL/RET

I wonder if anyone has actually measured what the code size savings from this look like for typical programs, that would be an interesting read. RISC trope is to expose a "link register" and expect the programmer to manage storage for a return address, but if call/ret manage this for you auto-magically you're at least saving some space whenever dealing with non-leaf functions.

didn't realize that since the last time i looked at these docs, seems like they've added lots of nice block diagrams for all the different parts of the machine. neat!

Since everyone is upset about the lack of technical details in the article, I'll try:

The takeaway from that paper (imo, afaict) is that guest userspace can influence indirect predictor entries in KVM host userspace. I don't really know anything about Xen, but presumably it is unaffected because there is no Xen host userspace, just a tiny hypervisor running privileged code in the host context. With KVM, Linux userspace is still functional in the host context.

Presumably, the analogy to host kernel/userspace in KVM is dom0, but in Xen this is a guest VM. If cross-guest cases are mitigated in Xen (like in the case of KVM, see Table 2 in the paper), you'd expect that this attack just doesn't apply to Xen. Apart from there being no interesting host userspace, IBPB/STIBP might be enough to insulate other guests from influencing dom0. If you're already taking the hit of resetting the predictors when entering dom0, presumably you are not worried about this particular bug.

edit: Additional reading, see https://github.com/xen-project/xen/blob/master/xen/arch/x86/...

Yeah, they wrote a paper about the ALUs too, see:

https://ctho.org/toread/forclass/18-722/logicfamilies/Delega...

There are two distinct 32-bit FCLK execution data paths staggered by one clock to implement 64-bit operations.

If it weren't fused off, they probably would've supported 64-bit ops with an additional cycle of latency?

Not even true: Arm, Intel, AMD, and most other hardware vendors (who are actively making an effort to support Linux on their parts) actually publish useful[^1] documentation.

edit: Also, not knocking the Qualcomm folks working on Linux here, just observing that the lack of hardware documentation doesn't exactly help reeling in contributors.

[^1]: Maybe in some cases not as useful as it could be when bringing up some OS on hardware, but certainly better than nothing

Not surprising considering I haven't seen a programming manual or actual datasheet for these things in the first place. Usually helps if you tell the community how to interact with your hardware ..

preventing instructions from issuing seems like too hard of a requirement

If this were the case, you could perform SYSCALL in the shadow of a mispredicted branch, and then try to use it to leak data from privileged code.

When the machine encounters an instruction that changes privilege level, you need to validate that you're on a correct path before you start scheduling and executing instructions from another context. Otherwise, you might be creating a situation where instructions in userspace can speculatively influence instructions in the kernel (among probably many other things).

That's why you typically make things like this drain the pipeline - once all younger instructions have retired, you know that you're on a correct [not-predicted] path through the program.

edit: Also, here's a recent example[^1] of how tricky these things can be (where SYSCALL isn't even serializing enough to prevent effects in one privilege level from propagating to another)

[^1]: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf

(Sorry for the self-plug but) I also wrote a bit about the behavior of PREFETCH recently in case anyone is interested in this sort of thing. See this example (for Linux on AMD):

https://github.com/eigenform/perfect/blob/e5da0c693ba5d1b654...

.. and here's another example in the case of EntryBleed:

https://github.com/eigenform/perfect/blob/e5da0c693ba5d1b654...

Similar idea I think: organics depositing iron

That post[^1] linked by saagarjha above is talking about the case where the typed allocator (plus the layout of kernel memory, and whatever constraints on pointer arithmetic in the kernel) makes Spectre less useful. MTE itself isn't relevant to mitigating Spectre, but putting constraints on how the addresses of certain loads in the kernel are computed makes Spectre less useful.

Remember that Spectre V1 is about causing the kernel to [incorrectly and] speculatively perform a load, and then trying to leak the loaded value by measuring the state of the cache. You might reasonably want to try this since MTE tags are stored in kernel memory.

But if the set of all possible target addresses for relevant loads on a path subject to influence by userspace can be constrained to a particular memory region, you [presumably] cannot trivially use Spectre V1 to leak values from a different region.

Also, see this[^2] paper referenced in the article.

[^1]: https://mastodon.online/@ezhes_/115175838087995856

[^2]: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=983...

I think part of the argument is that doing a micro-op cache is not exactly cutting down on your power/area budget.

(But then again, do the AMD e-cores have uop caches?)

Don't know this for certain, but I always assumed that x86 implementations get away with this by predecoding cachelines. If you're going to do prefetching in parallel and decoupled from everything else, might as well move part of the work there too? (obviously not without cost - plus, you can identify branches early!)

[...] imagine that while you are loading 16 or 32 bytes from instruction cache, you need to predict the address of next loaded chunk in the same cycle, before you even see what you got from cache.

Yeah, you [ideally] want to predict the existence of taken branches or jumps in a cache line! Otherwise you have cycles where you're inserting bubbles into the pipeline (if you aren't correctly predicting that the next-fetched line is just the next sequential one ..)

In general, probably co-design with software. Apple is in a position where they design microprocessors that are only going to be running MacOS/iOS.

Yep, you typically don't see it because we learned that it's easier to just assume that the default prediction is "not-taken."

AFAICT if you're hinting that a branch is biased-taken, really the only thing you might be doing is avoiding potential latency/incorrect speculation that comes with an initial misprediction (when you discover a branch that isn't currently being tracked). I think it's basically just an injunction to "don't wait for a misprediction, just install this branch in your BTB immediately" (or something along those lines).

Think you're referring to the idea that "my compiler can know that some branch is always/never taken" and turn it into an unconditional control-flow instruction (either "always jump here", or "always continue sequentially" and don't emit anything!).

But the parent comment is talking about "hinting" for branches where the compiler cannot compute this ahead of time, and the CPU is responsible for resolving it during runtime. This is usually exposed by the ISA, ie. a bit in the branch instruction encoding that tells the machine "when you encounter this instruction for the first time, the default prediction should be 'taken'."

In practice, branches are usually predicted "not-taken" by default:

- It's advantageous to assume that control-flow is sequential because [pre-]fetching sequentially is the easy case

- It's wasteful to track the target addresses of branches in your predictor if they aren't taken at least once!