Track Program_Counter(PC)/regs of L4Linux Task
grizzard at ece.gatech.edu
Tue Dec 13 21:33:20 CET 2005
Thanks for your response. A few clarifications to let you know where I
am coming from:
Martin Pohlack wrote:
> I don't know what kind of cooperation between tasks you assume, but you
> could try to instrument all tasks in the system to give you the required
> information via shared memory, without hacking the kernel.
Actually, I assume no cooperation between tasks. The purpose of the
monitoring task is to test the trustworthyness of the L4Linux task, so I
don't want to trust a possibly untrustworthy L4Linux task to cooperate.
>>-Obtain the PC/regs for the first thread (thread 0) for L4Linux just
>>before the thread executes it's first instruction. It would be nice to
>>make the thread wait for a signal before beginning execution.
> The registers before the first instruction seem to be useless. IP and
> SP are set via exregs, the rest should be execution defined. You could
> directly get IP and SP from the exregser.
>>-Obtain the PC/regs for any additional thread created or any thread
>>moved for L4Linux (i.e. from a l4_thread_ex_regs call) just before that
>>thread executes. Again, it would be nice to make that thread wait for a
>>signal before beginning its execution.
>>-Randomly preemptively obtain the PC/regs for all threads of L4Linux.
> I don't know what you mean by "Randomly preemptively".
> You could hack something in into the timeout interrupt handler of fiasco
> and use somewhat random timeouts.
The thinking behind random preemption is to somehow ensure that the
monitoring agent gets a random sample of where the PC is. I was
thinking along the lines of randomly change the timeout interrupt in
fact. I'm not sure how good this would be for performance though; just
a loose idea right now.
>>-Obtain the PC/regs for all threads of L4Linux on demand.
> Use exregs, for the IP, SP you can directly get the answer by issueing
> -1, IIRC. This should also explain your 0xffffffff below.
Not completely sure what you mean here. Are you refering to the
l4_thread_ex_regs system call? What do you mean by issueing -1, IIRC?
If so, is it possible to use that from within the fiasco kernel? Or did
you mean do that from with the L4Linux task? Also, I believe that does
explain the 0xffffffff addresses. I must be seeing the 0xffffffff for
IP and SP when a l4_thread_ex_regs is called with those values filled in
More information about the l4-hackers