Hey David, Yeah, I take it back. I just ran a quick test and while I got a segfault on kvm, I didn't get a segfault with the gem5 CPU.
This is something we should probably fix, especially with all of the focus on security these days. Cheers, Jason On Thu, Aug 27, 2020 at 3:29 PM Gabe Black <[email protected]> wrote: > 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
