Dtrace and illegal addresses

Been playing more with dtraces and illegal address probes. DTrace
is supposed to be totally safe to run on a system. It accepts code
from user space and does complex things at probe time and/or interrupt
time.

How does it do this?

Nicely and logically I would say. Theres a number of layers which give the
desired protection. Firstly, any D script code is validated in a sandbox
to ensure the user app is not passing down non-sandbox proof code.
I havent vetted all that code yet, but a cursory parse shows it looks logical,
disallowing things like jumps or loops, or invalid p-code instructions.

Next, the protection model distinguishes uids which are allowed to read
or write addresses in the kernel.

Assuming you have permission (i.e. probably root), then it can validate
reads/writes to ensure only scratch pad registers or known memory
blocks are accessed or that the address is in kernel address space.
(Defining kernel addressable memory gets complex with loadable
modules, VM and user vs kernel space, along with PCI type I/O addresses).

Assuming we get through all of this, the final layer of protection is
the CPU faulting on an invalid memory reference. Wherever dtrace can
do something suspect, a hint is set (on the cpu we are running on), to
flag to the interrupt handler to pass back a notification of any
GPF, and to continue execution. This ensures that the error can be passed
back without a user app core dumping or the kernel panicing with
an unexpected address violation.

It seems logical and sweet to me.

I have just patched in the bad address logic - I need to validate it
(not sure if I am going to get a page fault or a int13 segmentation violation
so will need to handle both).

I need this to debug a problem with the copyinstr() D function.

Post created by CRiSP v10.0.2a-b5877