Re: breakpoint assistance: single-step out of line

[Roland McGrath <roland at redhat dot com>]

> Another important aspect is that userspace may be hostile.  Beyond
> just containing oddball instruction sequences, it may deliberately
> rewrite its own .text, or otherwise interfere with probing in order to
> produce crashes or security breaches.

Indeed.  Another way to say what I meant to express about this is that the
kernel implementation must be robust to any potential user-mode activity
and protect the kernel and other user address spaces from any side effects.
(That's what a kernel is for, after all.)  At worst, some pathological or
hostile case that might scramble things so they work differently than they
would have in the absence of the single-stepping procedure, should be able
to scramble or crash only the probed user address space.  Anything less is
a dangerous bug unacceptable for any production system.  The ideal we
strive for is that at worst, a probe will have to be backed out and produce
some orderly error at the script level, but not at all disrupt the normal
(pathological) behavior of the user task.

> This one is an old shangri-la saw, but it may be desirable to block
> visibility of the breakpoint itself, to make a systemtap session
> relatively invisible.

In the aforementioned "fancy VM tricks" shangri-la, you get this too.  That
is, the process memory as seen by debuggers and core dumps and such will
have original pages rather than breakpoint-touched ones.  With the final
demise of segmentation, I don't think there is any way at all in the
hardware to prevent normal memory reads by the process itself from seeing
the breakpoint.  Of course you can mess around for the one single-stepped
copied instruction, but for every other instruction you are SOL.


Thanks,
Roland