With full-system mode, you can do kernel introspection. The kernel resides in
the simulated memory which you have complete control over; you can do whatever
you want to do with it. The kernel is what is responsible for managing the
processes and their memory so if you want interesting kernel-level information,
you might look into reading the kernel's physical memory directly.
With complete access to the full memory layout, you can play tricks with the
physical memory and OS symbols to access structures, namely task_struct and
mm_struct. It's difficult to do this and requires a bit of trial and error to
figure out which symbols the kernel exposes to allow you to do this, but it is
possible. The trick is to read the hex values from physical memory and compare
them with the Linux kernel source; you can reason about which fields are
pointers and which have values that are defined in the source. It just takes
work to puzzle out the rest. I did this once with Simics so it is possible, but
it's time consuming.
If you obtain access to the task_struct list, you can get access to the
mm_struct which give you the full memory layout for each process. With the full
memory layout, you can discern which areas of each process' virtual address
space are mapped and which physical frames (in the simulated memory) correspond
to those virtual address. In this way, you can get both the virtual and
physical addresses of addresses for any process.
As Jason mentioned, you can use /proc/{some_pid}/maps to figure out the virtual
address ranges that are mapped (at a specific point in the execution of that
process). Furthermore, you can use pagemap to figure out what the physical
address is. The catch with using these methods is that the simulator has to be
running and the process that you're interested in examining has to be running
to read the files (because the maps and pagemaps features are pseudo files). If
you have a short-running process, you typically have to add a `while(1)` loop
into the application to figure out the mappings.
Also as Jason mentioned on X86, you can examine the ring level that the CPU is
in to figure out if the kernel is executing or if the process is running in
userspace; if you don't understand what we're talking about, read
http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection/. You
can examine the segmentation registers and figure out at any given time what's
going on. (If you don't know much about memory, I'd read the rest of his blog
posts on the topic as well. It's a nice summary of Linux memory for the
uninitiated.) Also, userspace processes should not have access to kernel space
data. Linux draws a line in the virtual memory sand for different architectures
to specify what is "kernel space" and what is "user space". With X86-64, 48
bits [47...0] are used for virtual addresses. (The 47th bit gets sign-extended
to the 63rd bit so that all of the intervening bits don't really matter.) If
the sign extended bits are 1s, then the accesses are going into kernel space
and you can be reasonably sure that the kernel is executing. So, the fool proof
method is the CPL level in the code segment register, but you can sometimes
tell by the accesses if the kernel is running or not. If you want to learn
about memory in Linux, the canonical document, at least in my mind is:
https://www.kernel.org/doc/gorman/. (Although, the book is a bit dated.)
If you're looking to track a specific process in X86, you should be able to
monitor the CR3 register to verify that the correct process is running; the CR3
holds the base frame for the page tables so it's a decent way to figure out if
a 'special' process is being run.
-Brandon
-----Original Message-----
From: gem5-dev [mailto:[email protected]] On Behalf Of Jason Lowe-Power
Sent: Wednesday, August 31, 2016 8:59 AM
To: gem5 Developer List <[email protected]>
Subject: Re: [gem5-dev] Architecture of gem5
Hi Jasmin,
In full-system mode, gem5 runs a full operating system and all software.It is
analogous to a pure virtualization platform. In full-system mode, gem5 must
model all devices, etc. that the OS expects to interact with.
This is in comparison to syscall-emulation mode. In SE mode, gem5 only executes
user-mode code. All OS system calls are routed into the simulator and are
*emulated*.
To answer your questions:
- Is it possible to reason wether an instruction is user instruction or
kernel instruction?
Yes and no. No, there is no simple function to call to see if you are currently
running in kernel or user mode. However, depending on your kernel / OS certain
PC addresses represent kernel vs user-mode code. Additionally, you could watch
what mode the CPU is in (ring-0 vs ring-3, etc), depending on the architecture.
- Can we know to which process is an instruction belongs inside of the OS?
This is a little more tricky, but it may be possible based on the physical
address of the PC and using OS interfaces (e.g., /proc on Linux).
- How is memory mapped to OS processes?
Again, this is tricky, but may be possible with introspection into /proc or
something similar.
Overall, I believe something may exist that does what you're trying to do.
There was a presentation a few years ago at the gem5 users workshop that did
some of these things. See the PDF here:
http://gem5.org/wiki/images/9/9f/2012_12_01_gem5_workshop_Streamline.pdf. I
don't know what the current state of that project is. You may want to contact
the author directly.
Hope this helps!
Jason
On Wed, Aug 31, 2016 at 6:28 AM Jasmin Jahic <[email protected]> wrote:
> Hello,
>
> I will try to refine my last question a bit. In the gem5 full system
> mode;
>
> - Is it possible to reason wether an instruction is user instruction or
> kernel instruction?
> - Can we know to which process is an instruction belongs inside of the
> OS?
> - How is memory mapped to OS processes?
>
> I hope that someone has some knowledge about the questions above. If
> yes, they would help a lot.
>
> Best regards,
> Jasmin
>
>
> On Tue, Aug 30, 2016 at 6:22 PM, Stine, James
> <[email protected]>
> wrote:
>
> > Many apologies - my email got corrupted. Please ignore last Email.
> >
> > James
> >
> > > On Aug 30, 2016, at 11:21 AM, Stine, James
> > > <[email protected]>
> > wrote:
> > >
> > > I can make smaller if you want.. Let me know if not what you need
> > > or
> > want. Thanks for letting me know! Take care.
> > >
> > > J
> > >
> > > <Memo_to_OSU_Faculty_SHPE.pdf>
> > >
> > >
> > >> On Aug 30, 2016, at 11:18 AM, Jasmin Jahic
> > >> <[email protected]>
> > wrote:
> > >>
> > >> Hello,
> > >>
> > >> I have one question regarding the architecture of gem5 and I hope
> > >> that
> > you
> > >> can help me. I am interested where gem5 in Full system mode ends
> > >> and
> > where
> > >> the OS is completely taking over?
> > >>
> > >> For example, can I influence scheduling of the tasks by modifying
> > >> the
> > gem5
> > >> code directly, or is the gem5 simply running the OS as any other
> > program?
> > >>
> > >> Another example, from the OS's console I can start a simple binary.
> Can
> > I
> > >> modify the code to load a binary or is that handled completely
> > >> through
> > the
> > >> OS, and gem5 cannot distinguish between instructions coming from
> > >> the
> OS
> > or
> > >> other process and the regular binary I would run from the console?
> > >>
> > >> Best regards,
> > >> Jasmin
> > >> _______________________________________________
> > >> gem5-dev mailing list
> > >> [email protected]
> > >> http://m5sim.org/mailman/listinfo/gem5-dev
> > >
> >
> > _______________________________________________
> > gem5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/gem5-dev
> >
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev