Hi Martin,
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 for eip/esp.
Thanks!
Julian