Messages in this thread | | | Date | Tue, 3 Oct 2023 16:00:10 +0300 | From | Alexey Dobriyan <> | Subject | Re: [PATCH] x86_64: test that userspace stack is in fact NX |
| |
On Mon, Oct 02, 2023 at 07:23:10AM -0700, Dave Hansen wrote: > On 10/1/23 09:31, Alexey Dobriyan wrote: > > Here is how it works: > > > > * fault and fill the stack from rsp with int3 down until rlimit allows, > > * fill upwards with int3 too, overwrite libc stuff, argv, envp, > > * try to exec int3 on each page and catch it with either SIGSEGV or > > SIGTRAP handler. > > > > Note: trying to execute _every_ int3 takes 30-40 seconds even on fast > > machine, so only 1 int3 per page is tried. > > > > Tested on F37 kernel and on custom kernel which did > > > > vm_flags |= VM_EXEC; > > > > to stack VMA. > > I guess the subject implies it, but it's probably worth a sentence or > two in the changelog about this being 64-bit only. > > IIRC, there _are_ x86_64 CPUs that don't support NX. It's also entirely > possible for a hypervisor to disable NX enumeration for a guest. Those > two are (probably) rare enough that they can be ignored for now. But it > might mean adding a CPUID check at some point. > > Basically, could you spend a moment in the changelog to talk about: > > 1. 32-bit kernels on NX hardware > and > 2. 64-bit kernels on non-NX hardware
Sure. My logic whas that i386 is dead arch, but this test is easy to port to i386, only 2 simple functions.
I don't want to parse /proc/cpuinfo. If someone knows they're shipping NX-incapable hardware, just let them disable the test.
| |