Access ARM Data Fault Address Register (System Control Register) in Fiasco.OC

Stark, Josef j.stark at
Fri Jan 26 15:34:29 CET 2018


> This MRC is a privileged instruction and cannot be called in user-level.
> If for whatever reason you need to know DFAR (why?), you need to do the
> mrc in the kernel and have an interface to retrieve it from there.
> Taking any security considerations aside, add another function to L4::Thread
> (Thread_object in the kernel) to get the value, it's an easy option.
I did this now, we already had a custom function that reads all the general
purpose registers, and IP and SP (by calling Thread::user_ip() and 
Thread::user_sp()) so there I inserted my assembler call. Now the 
call doesn't freeze the system anymore and it returns a value. But
the strange thing is that when I have 3 threads in a process and
only 1 is faulting and I call this function for all of them, they all
return the same value from their DFAR (0xe07c).
When I instead read the DFSR (c5 instead of c6), they all return 0x7.
But I'm thinking that when only one of the threads is faulting, their DFSRs
or DFARs should return different values. What am I missing?
The IP and SP registers appear to be read correctly and with different values.

> (why?)
I have a userspace application that has registered itself as fault handler
for its child. Now, when a page fault arrives, I want to identify the faulting
thread by comparing the page fault address from the pf-report with the
DFAR registers of each of the threads. I'm using Genode on top of
Fiasco.OC, and Genode's pagefault report doesn't include a direct way
to identify/access the faulting thread.

Thanks for your help!

Best regards,

More information about the l4-hackers mailing list