https://josm.openstreetmap.de/browser/josm/trunk/src/org/ope...
It used to use a linear list of points, but it was VERY slow to draw, so I hacked this in to the code base a few years ago.
https://josm.openstreetmap.de/browser/josm/trunk/src/org/ope...
It used to use a linear list of points, but it was VERY slow to draw, so I hacked this in to the code base a few years ago.
on Linux, any cpus that don't have updated microcode will have AVX completely disabled as a mitigation for this issue. That's rather harsh if you ask me and would be very noticeable. Now I'm interested in finding out if I can get updated microcode..
From https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... :
> Specifying "gather_data_sampling=force" will use the microcode mitigation when > available or disable AVX on affected systems where the microcode hasn't been > updated to include the mitigation.
Disclaimer: I work on Linux at Intel. I probably wrote or tweaked the documentation and changelogs that are confusing folks.
Amusingly the 80286 supported execute-only segments, but this was dropped from 32-bit x86.
[0] It is possible on Intel in VM guests using EPT (Extended Page Tables), mlarkin@ experimented with protecting the host kernel in a special VM, called "Underjack". AMD SVM supports nothing like this.
[1] The custom AMD APU SoC in Sony's PS5 console supports "xotext" via NDA'd extensions, but there's no public documentation. (If _anyone_ knows details, pls share)
... btw, PROT_WRITE-only mappings are also impossible on x86 as well, so PROT_WRITE implicitly means PROT_READ. Not that I'm aware of any valid reason anyone might want this.
I'll also add a [2]:
[2] There's no way to do it in the page tables. But, if you have Protection Keys for Userspace (PKU), you can get it ... kinda. You can have a PROT_READ|PROT_EXEC mapping, assign it a pkey, then set PKEY_DISABLE_ACCESS in the PKRU register for that key. In fact, if you have a PKU CPU and you do an unadorned mmap(PROT_EXEC), the kernel will allocate you a pkey and do this under the covers FOR you. Anyone who can execute WRPKRU can easily undo this protection, but it's better than nothing.
That said, this would be great to see in OpenBSD (or any other OS).
To the downvote: I'm sure you've heard a drone buzzing above your head and getting nervous. A boat propeller does the same thing.
Granted, this was a lonely little fellow. But, he knew perfectly well what he was doing and repeatedly approached boats, despite the noise. He died after colliding with a tugboat prop.
"In a statement, Intel officials wrote: ... we do not rely on obfuscation of information behind red unlock as a security measure."
(BTW, I work on Linux at Intel, I'm not posting this in any official capacity)
There are a couple more than two, even in 2021.
Memory Protection Keys come to mind, as do the NPT/EPT tables when virtualization is in play. SEV and SGX also have their own ways of preventing the kernel from writing to memory. The CPU also has range registers that protect certain special physical address ranges, like the TDX module's range. You can't write there either.
That's all that comes to mind at the moment. It's definitely a fun question!