Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The NX bit is not just about security

purplesyringa.moe

Post reply on HN
Print view View original

31–40 of 51 posts

Re: The NX bit is not just about security

#31

Post by my123 »

adrian_b wrote: post #24
achierius wrote: post #19

> while ARM does provide a reference implementation of the architecture, vendors are free to customize it at will, or even roll their own implementations A nitpick, but this is only true for some vendors, depending on their license, and is very much company-by-company. Many vendors, even big names like Meta, don't have the ability to roll their own. And even for the ones who do, 'customize at will' is a bit strong, a…

TFA contains a reference to the Linux kernel, where there is a workaround for a quirk in the Apple CPUs, where in hypervisor mode they diverge from the official Aarch64 specification. So by "vendors" it was indeed meant "some vendors" who can afford to not care much about compatibility with the specification.

It's an old comment.

iirc it's a documented feature now - FEAT_E2H0, https://support.arm.com/documentation/109697/2025_12/Feature...

And it was retroactively defined to be allowed starting from Armv8.0.

Apple designs pre-date the ID register bit for it being a thing so it takes a quirk there however.

Re: The NX bit is not just about security

#32

Post by phire »

eqvinox wrote: post #13

Honestly feels like a misdesign in ARM. Where does it ever make sense for Device memory to not be data prefetchable, but allow instruction prefetch? It should IMHO disable all prefetch…

The problem is that unlike data prefetch, the so-called "instruction prefetch" is not actually prefetch at all.

It's simply speculative execution. Which doesn't look any different to regular execution. The fetcher has no idea that its predicted branch is about to invalidated and flushed, otherwise it would never have issued that fetch.

Actually, on a modern OoO core, [0] it's very rare for the instruction fetcher to not be doing speculative fetches. Even when it's not predicting a branch, the fact that it has "predicted" the lack of a branch is speculative in itself. It assumes it didn't fetch a branch in the last cycle, but it can't be sure until after instruction decoding, which takes at least 2 cycles (more on larger L1i caches).

About the only time the instruction fetcher is not doing speculative fetching is for a single cycle after each miss-predicted branch.

[0] Or even something technically in-order, like the Cortex A53 cores here. They might issue in-order, but because of how they implement dual issue, they look somewhat close to a simple OoO core... I suspect they actually do register renaming. And (most importantly) importantly they have a branch predictor.

Re: The NX bit is not just about security

#33

Post by repiret »

phire wrote: post #32
eqvinox wrote: post #13

Honestly feels like a misdesign in ARM. Where does it ever make sense for Device memory to not be data prefetchable, but allow instruction prefetch? It should IMHO disable all prefetch…

The problem is that unlike data prefetch, the so-called "instruction prefetch" is not actually prefetch at all. It's simply speculative execution. Which doesn't look any different to regular execution. The fetcher has no idea that its predicted branch is about to invalidated and flushed, otherwise it would never have issued that fetch. Actually, on a modern OoO core, [0] it's very rare for the instruction fetcher to…

No, the problem really is the prefetch itself when there are undesirable side-effects if the bus sees that memory read.

Re: The NX bit is not just about security

#34

Post by phire »

repiret wrote: post #33
phire wrote: post #32

Earlier quoted context omitted.

The problem is that unlike data prefetch, the so-called "instruction prefetch" is not actually prefetch at all. It's simply speculative execution. Which doesn't look any different to regular execution. The fetcher has no idea that its predicted branch is about to invalidated and flushed, otherwise it would never have issued that fetch. Actually, on a modern OoO core, [0] it's very rare for the instruction fetcher to…

No, the problem really is the prefetch itself when there are undesirable side-effects if the bus sees that memory read.

Well yes. That is why the "prefetch" is a problem.

But the original question was asking why disabling data prefetching to a memory region didn't automatically disable instruction prefetching at the same time.

And the answer is that speculative execution is a completely different mechanism that I'm not even sure can be disabled, at least not per memory region.

Re: The NX bit is not just about security

#36

Post by anyfoo »

Nowadays, it's considered bad form to map anything at 0... you now know one of the reasons why!

In the case that I know that has a 1:1 identity mapping of the address space, the physical address space doesn't actually have anything at 0 either, so it still doesn't need to be mapped.

Re: The NX bit is not just about security

#37

Post by renox »

phire wrote: post #34
repiret wrote: post #33

Earlier quoted context omitted.

No, the problem really is the prefetch itself when there are undesirable side-effects if the bus sees that memory read.

Well yes. That is why the "prefetch" is a problem. But the original question was asking why disabling data prefetching to a memory region didn't automatically disable instruction prefetching at the same time. And the answer is that speculative execution is a completely different mechanism that I'm not even sure can be disabled, at least not per memory region.

Why do you say this? The post is quite clear that marking the memory region as NX fix the issue caused by speculative execution.

Re: The NX bit is not just about security

#38

Post by sleirsgoevy »

anyfoo wrote: post #36

Nowadays, it's considered bad form to map anything at 0... you now know one of the reasons why! In the case that I know that has a 1:1 identity mapping of the address space, the physical address space doesn't actually have anything at 0 either, so it still doesn't need to be mapped.

Post author here. I wanted the code to be "as generic as possible", so I had to accept the possibility of some useful thing being at address 0.

Re: The NX bit is not just about security

#39

Post by sleirsgoevy »

MBCook wrote: post #28
zephen wrote: post #7

Earlier quoted context omitted.

In an attempt to go fast and beat benchmarks and other computers, CPUs attempt to speculatively execute code, and then later undo the results of the speculation if it turns out it was wrong. This causes all sorts of security issues (spectre, meltdown, and friends et al.) even when it's done relatively competently. When it's done in competently as on this ARM implementation, then you can't even run perfectly good and…

So in this specific case, if I understood correctly, here’s what should happen: Interrupt(?) fires to trigger hypervisor, hypervisor figures out what it needs to do, jumps to that code, does its job, returns. The “figured out what it needs to do” is the issue right? So what was actually happening was: Same start… CPU predicts what hypervisor will do, speculatively loads instructions from mispredicted branch target, t…

No, that instruction does not read memory. That instruction is itself IN the inaccessible memory.

It does not really matter how execution ended up in the HV in the first place. The misprediction happens due to having a branch-to-register instruction.

Re: The NX bit is not just about security

#40

Post by sleirsgoevy »

my123 wrote: post #31
adrian_b wrote: post #24

Earlier quoted context omitted.

TFA contains a reference to the Linux kernel, where there is a workaround for a quirk in the Apple CPUs, where in hypervisor mode they diverge from the official Aarch64 specification. So by "vendors" it was indeed meant "some vendors" who can afford to not care much about compatibility with the specification.

It's an old comment. iirc it's a documented feature now - FEAT_E2H0, https://support.arm.com/documentation/109697/2025_12/Feature... And it was retroactively defined to be allowed starting from Armv8.0. Apple designs pre-date the ID register bit for it being a thing so it takes a quirk there however.

This just means that Apple is a big enough player for ARM to retroactively amend the standard. Does not mean that what Apple did was not a violation of then-standard tho.
Post reply on HN