Re: architecture paper draft

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi, Stephen -


> > (For what it's worth, I'm still hoping for greater expertise to
> > make itself known on the subject of use of copy_from_user and its
> > kin from arbitrary kprobes contexts, to provide safety guarantees.)
> 
> The "safe" answer is just Don't Do That.
> [...]

Thank you for chiming in!  Can you confirm that it is unwise to assume
that the only failure mode of code that Still Does That is a page fault
(which may be able to catch).

Given that we do need to enable at least some user-space access from
relatively unrestricted contexts, is there anything we can do safely?
Like, for example, is there a function that can walk paging tables
by hand, able to cleanly return in case of something odd (absent
page, screwed-up table, ...)?  Something that might be slow, and
succeed only some of the time, but at least is crash-proof?

Alternately, is it the case that if our probe functions can conservatively
assess that any user-space access is at the moment unsafe (in_interrupt())?
Then the probe function can make that check, and block any errant attempts.
This would require the kprobes layer not to not hold spinlocks of its
own while the probe functions are being run, since that would in effect
hard-code a "no, it's unsafe" indication.

In addition, this method may require that the kprobes handler not be
started from an interrupt context wrapped around the "int 3" trap (x86).
Changing this might require extensive changes to kprobes, to perhaps
insert "simple" diversionary branches into the executable image instead
of traps.  Intel folks prefer this sort of approach for performance
reasons, but we may have come across an even better reason for it.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature