Re: how to turn off NX bit in assembly?
- From: "Rod Pemberton" <do_not_have@xxxxxxxxxxxxx>
- Date: Mon, 17 Nov 2008 09:29:46 -0500
"Alexei A. Frounze" <alexfrunews@xxxxxxxxx> wrote in message
news:87c2ffd3-d6b9-4d33-98f6-0458a793a28f@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Nov 17, 12:24 pm, "Rod Pemberton" <do_not_h...@xxxxxxxxxxxxx>stopped?
wrote:
Hey, anyone ever think about using NX to ensure running code can be
usingI guess you could use a PF on an unmapped page too? I.e., instead of
manor.interrupts or instead of waiting for the code to return, one could
selectively enable execution on one code segment or map only one page of
code using the faults to stop execution in an additional controlled
slamE.g., a sliding execution window, if the application starts to runaway,
into the wall...
That's the mechanism behind the virtual memory: you use fewer physical
pages to execute the code than the code needs. Upon a page fault some
page is unmapped and flushed to the disk and another one is brought in
from the disk and mapped.
Does NX only apply to pages?... If so, which is easire to do and undo:
map/unmap pages or set/clear NX? I'd think that keeping as many pages
mapped as possible would be a benefit to the OSes speed, wouldn't it? But,
if it's more complicated to set/clear NX...
Instead of unmapping and flush a page upon a page fault and loading another
to continue execution, one could terminate the program at that point.
That's the mechanism for CPU/PC
virtualization -- you catch accesses to the regions where memory-
mapped hardware is expected to be. It's harder with "runaway" apps,
since generally it's nontrivial to detect such an app.
If it executes across a unmapped page boundary or into a page or area that's
been marked NX, you have the option to terminate at that point. Of course,
the granularity isn't really there if it's executing a tight loop. I should
probably look at the debug registers to see what control of code they
offer... IIRC, they could interrupt on flow control.
And even if you
do detect it, what's the next useful step other than termination,
possibly logging an error and restarting the app from the beginning?
Yes, terminate. :) I'm sort of interested at the moment (and was a while
ago...) with the ability to start and stop code execution at whim under
control of another program (OS kernel). The "at whim" part is the problem.
It requires the control program to regain control. While the newer cpu's
have more features that could be used/abused for the purpose, older ones
don't. If there is an existing method with timers, interrupts, NMI, I've
overlooked it. Perhaps ACPI? One could... always rework the compiler
generate code which forfits control, but then you still have the problem of
applications not produced with the modified compiler.
RP
.
- Follow-Ups:
- Re: how to turn off NX bit in assembly?
- From: Chuck Crayne
- Re: how to turn off NX bit in assembly?
- From: robertwessel2@xxxxxxxxx
- Re: how to turn off NX bit in assembly?
- From: Alexei A. Frounze
- Re: how to turn off NX bit in assembly?
- References:
- how to turn off NX bit in assembly?
- From: simplicity
- Re: how to turn off NX bit in assembly?
- From: Rod Pemberton
- Re: how to turn off NX bit in assembly?
- From: Alexei A. Frounze
- how to turn off NX bit in assembly?
- Prev by Date: Re: Steve, have you had any problems with C5LIB.C writing to disk?
- Next by Date: Re: X86 Opcode and Instruction Reference 1.00: Massive update
- Previous by thread: Re: how to turn off NX bit in assembly?
- Next by thread: Re: how to turn off NX bit in assembly?
- Index(es):
Relevant Pages
|