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

11–20 of 51 posts

Re: The NX bit is not just about security

#11

Post by eqvinox »

Nail2680 wrote: post #6
Nail2680 wrote: post #3

Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.

Well it was a hot take.

Are you unaware that you can write code to RW memory, remap it to RX and then run it? That's how all JIT works these days.

(Or did you confuse cache flushing with TLB flushing? The remap does the latter, not the former.)

Re: The NX bit is not just about security

#12

Post by Nail2680 »

RiverCrochet wrote: post #10
Nail2680 wrote: post #3

Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.

L take. RAM is too slow for self-modifying code to be anywhere but F tier. This isn't 6502 land.

But it could be, there are bits about doing computation in RAM, self modifying code could work.

Re: The NX bit is not just about security

#14

Post by neerajsi »

Nail2680 wrote: post #3

Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.

Disallowing smc is a significant perf/power win. For cpus that run a large variety of large code (e.g. a web browser or ux stack), being able to cache a large instruction footprint and fetch/decode it quickly is important. Having to have the icache snoop data writes and entangle the i-fetch with the store buffer machinery would be a huge penalty to pay for a niche use case. Unlike loads, which are a small fraction of instructions to disambiguate with stores, you'd have to disambiguate every single instruction.

JIT is important to Apple platforms, and they seem to manage to make it work well enough even with the need for explicit invalidation.

Re: The NX bit is not just about security

#15

Post by jnwatson »

RiverCrochet wrote: post #9
tripdout wrote: post #2

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.

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.

Re: The NX bit is not just about security

#16

Post by Nail2680 »

eqvinox wrote: post #11
Nail2680 wrote: post #6

Earlier quoted context omitted.

Well it was a hot take.

Are you unaware that you can write code to RW memory, remap it to RX and then run it? That's how all JIT works these days. (Or did you confuse cache flushing with TLB flushing? The remap does the latter, not the former.)

Yeah, that works okay, but really is a you shouldn't, with pipelining you lose all the predictive decoding. The Synthesis kernel did some cool ass shit with this, but failed in other architectures due to pipelining, which speeds up shit, but change the opcodes(with other instructions(ie selfmodyfing code)) and shit gets flushed.

Re: The NX bit is not just about security

#17

Post by Nail2680 »

neerajsi wrote: post #14
Nail2680 wrote: post #3

Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.

Disallowing smc is a significant perf/power win. For cpus that run a large variety of large code (e.g. a web browser or ux stack), being able to cache a large instruction footprint and fetch/decode it quickly is important. Having to have the icache snoop data writes and entangle the i-fetch with the store buffer machinery would be a huge penalty to pay for a niche use case. Unlike loads, which are a small fraction of…

So that is only true because we do it, there is a world where we optimize differently and that self modifying version works better, reread the synthesis kernel thesis(one, it is super easy, two they did this), we could have hardware that does this. Because we don't have hardware that does this we don't

Re: The NX bit is not just about security

#18

Post by dmitrygr »

This is doubly weird because actually purposefully executing from device memory is not allowed: “Trying to execute code from a region marked as Device is UNPREDICTABLE.” So: can’t reliably execute from there but can speculatively instruction fetch from there. Funsies!

https://support.arm.com/documentation/100941/0101/Memory-typ...

Re: The NX bit is not just about security

#19

Post by achierius »

> 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, as ARM very much does want to maintain uniformity across userspace implementations. E.g. Nvidia shouldn't add new traps for architecturally-legal behavior, since then code compiled for Apple hardware wouldn't work on Grace. Or worse, not trap for architecturally-illegal behavior, since then code compiled for Grace might not work for anyone else at all!

Re: The NX bit is not just about security

#20

Post by achierius »

neerajsi wrote: post #14
Nail2680 wrote: post #3

Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.

Disallowing smc is a significant perf/power win. For cpus that run a large variety of large code (e.g. a web browser or ux stack), being able to cache a large instruction footprint and fetch/decode it quickly is important. Having to have the icache snoop data writes and entangle the i-fetch with the store buffer machinery would be a huge penalty to pay for a niche use case. Unlike loads, which are a small fraction of…

FWIW if you look at WebKit/JavaScriptCore, the trend has been towards less-frequent code modification, e.g. inline caches are mostly no longer repatched inline. Whole-function reoptimization is still worth the overhead of sys_icache_invalidate() + `ISB`'ing everyone involved, but at smaller granularities not so much.
Post reply on HN