I really wish I understood this, it hits a bunch of topics that I've heard of and are/sound interesting, but I don't know enough to follow it. I don't get the link between the NX bit (which I get) and speculative access.
NX means not executable, so some bytes are excutable, some are non excutable. so some are instructions for the processor and others are data. Sometimes those are mixed and the cpu pukes out a bunch and restarts interpretation. most of the time those are normal. keep it normal and go fast.
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 incompetently as on this ARM implementation, then you can't even run perfectly good and correct code, because the CPU will attempt speculative execution on a location that you never asked it to execute code at, and then bork itself when it realizes that can't possibly work.
Naturally, this is the sort of problem that requires tedious dissection of what exactly happened, and copious amounts of alcohol.
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, that wrong instruction reads memory(?) against the “no data prefetch” settings for that part of memory, CPU blows up/halts/whatever.
The fix is to mark the area the branch was mispredicted to in such a way that the CPU won’t prefetch instructions. Thus that won’t be run and prefetch data, thus no violation. CPU execution continues taking the correct branch and everything is fine.
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.
Well, that was the whole issue. After marking the memory as not accessible via a data load, the CPU was still executing there and borking itself.
He had to also mark the memory as inaccessible for code loads.
Which, honestly is kinda stupid. Because nobody asked the processor to start executing there. It just took it upon itself to try to start executing there, later decided that was a bad thing, and then borked itself.
People talk about how terrible x86 is, but honestly, one of the reasons that x86 won for decades was because of making things that programmers did that might be suboptimal still work, even if a bit slowly (misaligned data accesses, for example). ARM does that now for that specific case, but didn't before 2002.
So there's an implementation tradeoff for whether you decide to spend transistors to reduce the number of sharp edges on the tool. Obviously ARM just doesn't give a shit about this particular sharp edge.
Speculative instruction fetches fetch code from "a location that you never asked it to execute code at" by design. If it already knew you asked it to execute code there, it wouldn't be speculative.
The Armv8/9-A architecture reference manual is clear that speculative instruction fetches are permitted in Device memory unless that memory is also marked NX. So if your hardware has side-effects from a certain address, but it maps it as Device non-NX memory, then your code is not "perfectly good and correct". Assigning correct memory attributes is one of the many things needed for correct code.
> Speculative instruction fetches fetch code from "a location that you never asked it to execute code at" by design. If it already knew you asked it to execute code there, it wouldn't be speculative.
Sure, but (a) the speculation is supposed to be transparent; and (b) ARM's response to a failure in speculative execution is arguably broken.
> The Armv8/9-A architecture reference manual
Sure, but before then marking memory as not readable would make it non-executable, and also mostly before then there was no or minimal speculation.
> then your code is not "perfectly good and correct".
Certainly it won't work on that machine. It might have worked perfectly well on prior machines, and we could argue all day about how reasonable ARM's implementation decisions were, but I will merely say that a documented flaw is, in fact, still a flaw.
Basically, the NX bit prevents CPU behavior (speculative fetches) that had a hand in Spectre-type vulnerabilities. That's surprising because that's not its purpose. This is for ARM CPUs.
No, NX precedes Spectre by a long shot. It was originally intended so an attacker couldn't use a buffer overflow to change the PC and execute directly out of the attacker-controlled buffer.
That is exactly what the poster to whom you replied said.
So Arm did not add another means to disable this kind of speculative execution, after Spectre was discovered, but they just reused the existing NX flag, expanding its functionality.
I know this is flagged, and I know the guidelines say not to complain about tangential annoyances, but the reason given is that "they're too common to be interesting" -- but is that true about LLM-written articles? A case could be made that it will only become more true if nobody objects.
I don't know what it is about LLM writing style, but I agree, it just triggers something in my brain and I can't get myself to read it.
Why is the original pattern (with the env var in double quotes) not vulnerable? Why can you close the single quotes early but you can't just include double quotes in your title? Is it something to do with the GitHub templating?
then in bash I believe this is safe, because bash will just substitute this as putting the BLAH variable as the first argument to echo without doing any further parsing. without the double quotes can be safe as well but more risky.
X=$(echo $BLAH)
and the only difference is bash will split the arguments. so if you have BLAH="x y" then bash will pass two arguments to echo. though, this can be dangerous if the command you are invoking has dangerous command line options.
however, they had something similar to:
TITLE=$(echo '${{ github.event.issue.title }}')
and this ${{ }} is some kind of template substitution that is happening before the command is sent to bash. so if the variable `github.event.issue.title` was `foo bar` then bash sees something like:
TITLE=$(echo 'foo bar')
and then you start to have problems because `'` can be put into the title to escape.
the bash variable substitution will protect you in a lot of cases from command line injection but if you pass user input directly into command evaluation without using variables then bash can't protect you.
Replying to my own post to note that the author of the app in my linked post is using an LLM to respond to everyone in the thread. They responded to me (with a clearly LLM written, sycophantic tone) and said that they updated the design. It looks less like the parody site now.
I remember seeing a video where someone was talking about how from someone on the YouTube team said that their goal is for you to to replace the word “algorithm” with “audience”.
Whether they achieve that goal or not is a different story.
I think that was actually Mr. Beast who said that [1]. The quote is also brought up in an interview with Rene Ritchie back when he was working for YouTube [2], and explaining what the algorithm does.
There's a recognizable style to the overall piece.
The subheadings for example "The summary is not the answer" and "The verification problem is real and it compounds" are typical being punchy but not really making much sense.
Also consider
>This is slower. That's real. It's more work. And it is, in practice, more accurate — because accuracy in information retrieval is a function of reading, not of being read to.
The over punchy - It's this. It's that. It's the other - is typical or LLMs. The accuracy being a function of reading not being read to doesn't really make sense - with both normal results and AI you are reading.
I'd prefer more proof / context than GP gave, but I personally find it very useful to see people making judgements about AI-assistance of articles. Almost no such articles are worth my time, and the more HN people saying it, the more I know not to click past the HN headline.
Same as a NSFW tag. It's not about adding to the discussion; it's a very brief warning to users who don't want to see that kind of content, and its brevity makes it come at almost no cost to users who don't care about SFW/NSFW or AI/OC distinctions.
I agree I run the risk of being wrong and could at least provide some evidence, but I think at the very least it can be one additional piece of information someone could use in their consumption of this content.
If you can't be bothered to write even one specific thing from the article content you object to, then your account might as well be a pre-LLM bot that just posts "first" or "LLM Content" which is somehow even lazier than an LLM blog post.
reply