Generally speaking, gem5 tends to be pretty loose as far as checking whether instructions are privileged or not. Real programs tend to behave themselves because on a real system they would crash if they didn't. That means it's usually not very important to implement those checks to get correct (or correct enough) behavior, and secondarily it avoids a small amount of overhead from having to do the checks. Having the checks probably wouldn't be a bad thing, but it's just not been a priority.
Gabe On Thu, Aug 27, 2020 at 11:11 AM Jason Lowe-Power via gem5-users < [email protected]> wrote: > Hi David, > > That is very strange. I would also expect gem5 to produce a protection > fault on that code. I would try a couple of things: > 1. Try running interactively in gem5 (e.g., with m5term) and seeing what > happens > 2. Try using gdb interactive *in gem5*. In other words, run gdb inside the > simulator > 3. Try using the KVM CPU which will allow you to boot linux and run your > program in seconds instead of hours :). > > gem5 should not be missing any protection checks. It is possible that an > instruction was mis-classified as being a user-mode instruction and not > privileged, but that's unlikely. > > Cheers, > Jason > > On Thu, Aug 27, 2020 at 10:56 AM David Klopp via gem5-users < > [email protected]> wrote: > >> Hello, >> >> I have a questions regarding executing privileged instructions in gem5. I >> tested the following program on the AtomicSimple and O3 CPU type (arch x86) >> inside gem5 (version 20.0.0.2) running a full system Linux with kernel >> version 5.4.55: >> >> static inline void invlpg(unsigned long addr) { >> asm volatile("invlpg (%0)" ::"r" (addr) : "memory"); >> } >> >> int main() { >> int mem; >> invlpg((unsigned long) &mem); >> } >> >> The program was executed without an error. I would have expected, that >> some kind of error occurs, because invlpg is a privileged instruction, so I >> should not be able to execute it in user mode. To verify that this >> behaviour is indeed special to gem5 and not related to my kernel, disk >> image or program, I booted the same Linux system with the same kernel and >> disk image in qemu and executed the same binary. Executing the program in >> qemu resulted in a general protection fault. >> Is gem5 missing some kind of check which prevents executing privileged >> instruction in user mode, or is this somehow expected behaviour and I >> missed something ? >> _______________________________________________ >> gem5-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> > _______________________________________________ > gem5-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-users mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
