On 2023-01-15, Barry Grumbine <barry.grumb...@gmail.com> wrote:
> In case someone else runs in to this, and bothers to check misc@
>
> In this commit:
> https://marc.info/?l=openbsd-cvs&m=167283731726983&w=2
>
> --execute-only (aka NX bit, aka XD bit, aka Data Execution Prevention)
> was turned on
NX ("no execute") is used with kernel protections that can prevent
memory which is mapped as being _writable_ from being executed. That afaik
didn't change recently (at least not on purpose?).
execute-only is something else, it relates to mappings which are
protected such that they _can_ be executed but not _read_. It's now used
on aarch64 and riscv64 in snapshots (not everything in ports has been
fixed to work with it yet). There's work towards using it on amd64 but
the necessary cpu feature is only available on fairly new AMD machines
and very (for my version of 'very') new Intel machines.
> On my ancient T520 I had to go in to BIOS and set:
> -> Security
> --> Memory Protection
> ---> Execution Prevention [Enable]
>
> Everything works just peachy now.
It would be interesting to figure out what is happening with your
system (e.g. which change actually broke things) - there's no way it can
be the commit you point out. That's "restore previous behaviour when
compiling the EFI boot loader on aarch64/riscv64 which had got changed
in a different diff".
Any idea whether the problem is just in ramdisk kernels or did it affect
normal boot e.g. GENERIC.MP as well?
