[gem5-users] Re: Architectural state of registers - O3CPU
I would like to add some additional information. The register number does vary in each iteration, sometimes it is above 100. So I think it should be the physical register value. If my understanding is correct, the physical register should be set during the IEW stage before the instruction is commited or squashed at the last stage. Otherwise out-of-order execution wouldn't be possible. So in the end I am searching the point at which the physical register is set and marked as ready for subsequent instruction, which depend on this specific register. Gesendet: Mittwoch, 14. Februar 2024 um 18:35 Uhr Von: "Eliot Moss" An: "The gem5 Users mailing list" Cc: reverent.gr...@web.de Betreff: Re: [gem5-users] Re: Architectural state of registers - O3CPU On 2/14/2024 12:26 PM, reverent.green--- via gem5-users wrote: > Hey Eliot, > thank you for your answer. I have a follow-up question. > I know, that there are more physical registers than architectural ones and that the achitectural state should be set in > the final commit state. > So if the debug message linked in my earlier mail shows e.g.: "Setting int register 54 to 0x53000", this "register 54" > should be a physical register and it can be used without setting the architectural state? > Do you know, at which point in the O3 steps this physical register is set after an instruction? That's something where I'd need to dig into the code the make sure. However, the number 53 is fairly large so my first impression is that it is a physical register number, not a logical (architectural) one. On the other hand, if you count up integer registers, floating point registers, vector registers, etc., 53 could be in the range of the architectural registers. I do know that if you request debug trace information from gem5, it will tend to refer to architectural registers. I don't know precisely where the physical register is set, but my first thought is IEW - the W part stands for Writeback, i.e., when registers typically are written. However, loads are probably written later since they are not computational but wait for a response from the cache. As I recall, the load/store queue processing is a separate step in the pipeline, coming later than IEW. EM ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Architectural state of registers - O3CPU
Hey Eliot, thank you for your answer. I have a follow-up question. I know, that there are more physical registers than architectural ones and that the achitectural state should be set in the final commit state. So if the debug message linked in my earlier mail shows e.g.: "Setting int register 54 to 0x53000", this "register 54" should be a physical register and it can be used without setting the architectural state? Do you know, at which point in the O3 steps this physical register is set after an instruction? Kind regards Gesendet: Mittwoch, 14. Februar 2024 um 17:47 Uhr Von: "Eliot Moss" An: "The gem5 Users mailing list" Cc: reverent.gr...@web.de Betreff: Re: [gem5-users] Architectural state of registers - O3CPU On 2/14/2024 11:19 AM, reverent.green--- via gem5-users wrote: > Hello everyone, > can someone give me a hint, where exactly in the code the architectural state of (load) instructions is getting set and > becomes visible? I tried to trace instructions during the execution via log outputs, but got a bit lost during the IEW > stage. > I know, that instructions, which depend on specific registers will wait until the register is marked ready from an > earlier usage. (https://github.com/gem5/gem5/blob/stable/src/cpu/o3/regfile.hh#L273) > But is this already equivalent to the architectural state? > > And how is this handled during a wrong speculative execution because of the following rollback/squashing? > Kind regards > Robin A typical out-of-order processor does register renaming, so there are generally *many* more physical registers than architectural ones, and the hardware maintains a dynamic mapping. If necessary, the architectural state can be constructed, but generally would not be unless you're switching threads or something. While IEW may update the registers (I believe), it is the commit stage that makes the change "permanent". Does that help? Eliot Moss ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Architectural state of registers - O3CPU
Hello everyone, can someone give me a hint, where exactly in the code the architectural state of (load) instructions is getting set and becomes visible? I tried to trace instructions during the execution via log outputs, but got a bit lost during the IEW stage. I know, that instructions, which depend on specific registers will wait until the register is marked ready from an earlier usage. (https://github.com/gem5/gem5/blob/stable/src/cpu/o3/regfile.hh#L273) But is this already equivalent to the architectural state? And how is this handled during a wrong speculative execution because of the following rollback/squashing? Kind regards Robin___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Dispatch / Issue stage in O3 pipeline
So in theory it should be possible, that the entry is accessed during the calculations and therefore cached, despite of being squashed shortly after? Is there a difference whether an instruction is squashed because of a branch misspeculation or a page fault? Gesendet: Mittwoch, 24. Januar 2024 um 06:35 Uhr Von: "Jiayi Huang" An: "The gem5 Users mailing list" Cc: reverent.gr...@web.de Betreff: Re: [gem5-users] Dispatch / Issue stage in O3 pipeline Faults and exceptions are checked and handled when the instruction is to be committed/retired. Before the commit/retire time of the faulty instruction, the following instructions will proceed as normal. These following instructions will be squashed when the previous faulty instruction is handled. On Tue, Jan 23, 2024 at 10:41 PM reverent.green--- via gem5-users <gem5-users@gem5.org> wrote: Hello everyone, I have a C PoC code with the crucial part written in inline assembly, trying to exploit transient executions. The Konata pipeline viewer showed, that first my faulty instruction (triggers pagefault because of failed permission check in tlb.cc) is executed and moved along the pipeline. During the meantime, subsequent instructions are put in the pipeline, but every instruction does not proceed further than the "Dispatch" stage. The transient window should be long enough. As a comparison, during the spectre attack, the instructions are transiently executed and therefore, it is possible to leak the secret via Flush+Reload. (http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html) Here, the branch misspeculation causes a load of the value in an instruction, which is later squashed. Why is it "executed"/loaded here and not stopped at the dispatch stage? Are there more security checks inside gem5 which prevent it in this case? I know, that the spectre example uses se.py and not the full system gem5 simulation, but spectre also works using full system simulation. Thank you very much in advance. An answer here would be really helpful. Kind regards ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Dispatch / Issue stage in O3 pipeline
Hello everyone, I have a C PoC code with the crucial part written in inline assembly, trying to exploit transient executions. The Konata pipeline viewer showed, that first my faulty instruction (triggers pagefault because of failed permission check in tlb.cc) is executed and moved along the pipeline. During the meantime, subsequent instructions are put in the pipeline, but every instruction does not proceed further than the "Dispatch" stage. The transient window should be long enough. As a comparison, during the spectre attack, the instructions are transiently executed and therefore, it is possible to leak the secret via Flush+Reload. (http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html) Here, the branch misspeculation causes a load of the value in an instruction, which is later squashed. Why is it "executed"/loaded here and not stopped at the dispatch stage? Are there more security checks inside gem5 which prevent it in this case? I know, that the spectre example uses se.py and not the full system gem5 simulation, but spectre also works using full system simulation. Thank you very much in advance. An answer here would be really helpful. Kind regards ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Transient execution during Page Fault - X86 O3 FS simulation
I analyzed a few debug log outputs. The control flow varies here https://github.com/gem5/gem5/blob/stable/src/cpu/o3/commit.cc#L1172, when the instruction triggers the page fault in the TLB. Whether or not I remove this check for a fault in the commit step for my address, the instruction remains unchanged if the PageFault is triggered earlier. Without PageFault: "MOVSX_B_R_M : ld t1b, DS:[rax] : MemRead : D=0x00401753 A=0x7f5bd1b11000" With PageFault: "MOVSX_B_R_M : ld t1b, DS:[rax] : MemRead : A=0x7f5bd1b11000" Is my assumption correct, that a PageFault leads to an earlier "ignoring" of the instruction and therefore, the value isn't even computed, rather than computed upfront and "deleted" after? Only without PageFault, the next parts of the instruction is also executed: "MOVSEX_B_R_M : sexti rcx, t1, 0x7 : IntAlu : D=0053" Kind regards Robin Gesendet: Freitag, 29. Dezember 2023 um 19:32 Uhr Von: "reverent.green--- via gem5-users" An: gem5-users@gem5.org Cc: reverent.gr...@web.de Betreff: [gem5-users] Transient execution during Page Fault - X86 O3 FS simulation Hello everyone, I am currently looking into transient execution vulnerabilities using the gem5 simulator. I successfully tried out the spectre example and want to create something similar for meltdown. For these experiments, I am using the O3 CPU model. - The first step was to change the simulation from SE to FS in order to have the kernel space memory mapped. - I'm using a modified meltdown PoC, which creates two mappings to the same shared memory and clears the User/Supervisor Bit for one of them. (https://github.com/IAIK/transientfail/tree/master/pocs/meltdown/US) - After accessing the mapping, it returns the Page Fault after checking the user bit of the PTE (https://github.com/gem5/gem5/blob/stable/src/arch/x86/tlb.cc#L476) Now my question: When I remove this user/supervisor check in gem5 specifically for my address, the PoC leaks the "secret" value via Flush+Reload without a problem, because it can be accessed and therefore should be in the cache. But when the Page Fault is created, the value is not leaked. I try to follow the execution chain for the specific PC and address shown for the triggered page fault for multiple weeks, but up until now failed to identify the exact problems here. Can someone enlighten me, how gem5 handles an instruction after this specific point? In my understanding, the transient execution should still be visible after the security check. Where is the exact point the instruction results are "removed", s.t. they aren't available in the cache anymore and in which step of the out-of-order pipeline does the magic happen? If you have further questions, I try to answer them as detailed as possible. Any tips would be really appreciated, thank you in advance. Kind regards Robin ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Transient execution during Page Fault - X86 O3 FS simulation
Hello everyone, I am currently looking into transient execution vulnerabilities using the gem5 simulator. I successfully tried out the spectre example and want to create something similar for meltdown. For these experiments, I am using the O3 CPU model. - The first step was to change the simulation from SE to FS in order to have the kernel space memory mapped. - I'm using a modified meltdown PoC, which creates two mappings to the same shared memory and clears the User/Supervisor Bit for one of them. (https://github.com/IAIK/transientfail/tree/master/pocs/meltdown/US) - After accessing the mapping, it returns the Page Fault after checking the user bit of the PTE (https://github.com/gem5/gem5/blob/stable/src/arch/x86/tlb.cc#L476) Now my question: When I remove this user/supervisor check in gem5 specifically for my address, the PoC leaks the "secret" value via Flush+Reload without a problem, because it can be accessed and therefore should be in the cache. But when the Page Fault is created, the value is not leaked. I try to follow the execution chain for the specific PC and address shown for the triggered page fault for multiple weeks, but up until now failed to identify the exact problems here. Can someone enlighten me, how gem5 handles an instruction after this specific point? In my understanding, the transient execution should still be visible after the security check. Where is the exact point the instruction results are "removed", s.t. they aren't available in the cache anymore and in which step of the out-of-order pipeline does the magic happen? If you have further questions, I try to answer them as detailed as possible. Any tips would be really appreciated, thank you in advance. Kind regards Robin ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Using own kernel binary for FS simulation
Hello everyone, I am currently using "x86-ubuntu-18.04.img" and "x86-linux-kernel-5.4.49" from gem5 resources for my full-system simulation in gem5. For my next experiment, I need a custom kernel module, which I already inserted into and built in the ubuntu image. The problem is, that the image uses a kernel version (4.15.0-45-generic), which is not available in the list of prebuilt x86 linux kernels (https://resources.gem5.org/resources?q=architecture%3AX86+kernel=1=relevance=10) I tried to extract the kernel executable binary from the ubuntu image in order to have the same version for the simulation, but gem5 won't start using this kernel. There is only an "Kernel panic - not syncing: Attempted to kill the idle task!" error and after that, the simulation halts/aborts. Does anyone have a solution for this problem? My goal is to use a custom kernel module inside the simulation and I need the same kernel version in the image and the gem5 simulation. Thank you in advance. Best regards Robin___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Loading kernel module using insmod during simulation
Hello everyone,
I am trying to load a kernel module (https://github.com/misc0110/PTEditor#install-kernel-part-from-source) into the running Linux kernel while executing my code. My goal is to get PTEditor working inside the full system simulation.
Now I have a few questions:
1. Is it possible to load the kernel module during runtime via system(...) in the C code?
2. If it is possible, how can I achieve it?
I've tried to load it with a "system('insmod /localpath/to/module.ko')", but this isn't working. My next idea would be, to integrate the module into the building process of gem5 in order to get access during the simulation.
Thank you in advance.___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Squashing Instructions after Page Table Fault
s a TLB miss for the address, but after that the PageTableWalker gets the PML4 entry 0x00 and raises a Page fault. - My expectation (and goal) is, that during the read of the kernel address, the Page Table Walk is successfull until the Page Table Entry. Now I have a few questions: 1. After the TLB miss at tick 15059514670500, the CPU removes many commited instructions at the PC the miss occured. Why are these instructions commited, although the Page Fault is being raised? 2. Does anyone have an idea, why the Page Fault already occurs at the PML4 entry level? And why this entry is only 0x0? Thank you again in advance. I am very happy if someone could help or clarify this. Kind regards, Robin Gesendet: Montag, 09. Oktober 2023 um 14:29 Uhr Von: "Yuan Yao via gem5-users" An: "The gem5 Users mailing list" Cc: "Yuan Yao" Betreff: [gem5-users] Re: Squashing Instructions after Page Table Fault Hi Robin, The "Page-Fault" message is printed out on the constructor of a fault, so gdb that line and move up frames can help. By the way, a page fault can also be generated during page walks (see here). The faulty PTE is not inserted into TLB. Debug flag PageTableWalker tracks all these errands. Hope this helps. Br, Y. On 10/9/23 13:37, reverent.green--- via gem5-users wrote: Hey Eliot, thank you for your help. I experimented with the checks and I was a bit suprised, that the Page Fault seems not to be raised after a unsuccessful user/supervisor check. After enabling the necessary debug flags and including more Debug statements into the code, I observed that the Page Fault is not raised after entering the If-statement, but before it. Here is a short snippet of my outputs: 14442496349500: system.repeat_switch_cpus5.mmu.dtb: inUser = 1 | entry_user = 1 | badWrite = 0 (Line 470) 14442496349500: system.repeat_switch_cpus5.mmu.dtb: Checks done! (Line 485) 1444249635: system.repeat_switch_cpus5.mmu.dtb: inUser = 1 | entry_user = 1 | badWrite = 0 1444249635: system.repeat_switch_cpus5.mmu.dtb: Checks done! 14442496361000: Page-Fault: RIP 0x402da9: vector 14: #PF(0x4) at 0x880019688110 14442496387000: system.repeat_switch_cpus5.mmu.itb: inUser = 1 | entry_user = 0 | badWrite = 1 14442496387000: system.repeat_switch_cpus5.mmu.itb: * If [Line 471]. * 14442496424000: system.repeat_switch_cpus5.mmu.dtb: inUser = 0 | entry_user = 0 | badWrite = 1 14442496424000: system.repeat_switch_cpus5.mmu.dtb: Checks done! 14442496464000: system.repeat_switch_cpus5.mmu.dtb: inUser = 0 | entry_user = 0 | badWrite = 1 14442496464000: system.repeat_switch_cpus5.mmu.dtb: Checks done! I expected, that the Page Fault is raised at line 476, but it doesn't seem so. For further context, my goal is to get this code (https://github.com/IAIK/meltdown/blob/master/reliability.c) working in gem5. Currently, "libkdump_read" (https://github.com/IAIK/meltdown/blob/master/libkdump/libkdump.c#L528) only returns 0 in gem5. My guess is, that I need to change much more than initially thought. With reference to the answer of Yuan, I guess that I also need to change stuff in the function chain for handling a fault. Can anyone confirm this? Best regards, Robin Gesendet: Mittwoch, 04. Oktober 2023 um 17:00 Uhr Von: "Eliot Moss via gem5-users" An: "The gem5 Users mailing list" , yuan....@it.uu.se Cc: reverent.gr...@web.de, "Eliot Moss" Betreff: [gem5-users] Re: Squashing Instructions after Page Table Fault On 10/4/2023 10:03 AM, reverent.green--- via gem5-users wrote: > Hi Yuan, > thank you very much for your detailed response. My understanding of the > fault handling in gem5 is getting better and better. Using debug flags, I > can trace the control flow during the execution of my code. > I am currently inspecting tlb.cc in further detail, but I am still searching > for the exact check for my problem. To further specify my question: > During the attempt to access kernel memory, the “user/supervisor” (U/S) > pagetable attribute is used to check whether this page table belongs to > kernel memory or not. If I want to access the memory, it should raise the > page table fault. I am looking for this specific check. My goal is, to > experiment with gem5 and to customize it. Currently, the instruction is not > executed when raising a Page Table Fault. In a first step, I want to change > the check in order to execute the instruction although it wants to access > kernel memory. So I explicitly search for this check inside this command > chain during the Page Fault handling. > Thank you very much in advance. > Best regards > Robin Assuming we're talking about the x86 architecture, line 471 i
[gem5-users] Re: Squashing Instructions after Page Table Fault
Hey Eliot, thank you for your help. I experimented with the checks and I was a bit suprised, that the Page Fault seems not to be raised after a unsuccessful user/supervisor check. After enabling the necessary debug flags and including more Debug statements into the code, I observed that the Page Fault is not raised after entering the If-statement, but before it. Here is a short snippet of my outputs: 14442496349500: system.repeat_switch_cpus5.mmu.dtb: inUser = 1 | entry_user = 1 | badWrite = 0 (Line 470) 14442496349500: system.repeat_switch_cpus5.mmu.dtb: Checks done! (Line 485) 1444249635: system.repeat_switch_cpus5.mmu.dtb: inUser = 1 | entry_user = 1 | badWrite = 0 1444249635: system.repeat_switch_cpus5.mmu.dtb: Checks done! 14442496361000: Page-Fault: RIP 0x402da9: vector 14: #PF(0x4) at 0x880019688110 14442496387000: system.repeat_switch_cpus5.mmu.itb: inUser = 1 | entry_user = 0 | badWrite = 1 14442496387000: system.repeat_switch_cpus5.mmu.itb: * If [Line 471]. * 14442496424000: system.repeat_switch_cpus5.mmu.dtb: inUser = 0 | entry_user = 0 | badWrite = 1 14442496424000: system.repeat_switch_cpus5.mmu.dtb: Checks done! 14442496464000: system.repeat_switch_cpus5.mmu.dtb: inUser = 0 | entry_user = 0 | badWrite = 1 14442496464000: system.repeat_switch_cpus5.mmu.dtb: Checks done! I expected, that the Page Fault is raised at line 476, but it doesn't seem so. For further context, my goal is to get this code (https://github.com/IAIK/meltdown/blob/master/reliability.c) working in gem5. Currently, "libkdump_read" (https://github.com/IAIK/meltdown/blob/master/libkdump/libkdump.c#L528) only returns 0 in gem5. My guess is, that I need to change much more than initially thought. With reference to the answer of Yuan, I guess that I also need to change stuff in the function chain for handling a fault. Can anyone confirm this? Best regards, Robin Gesendet: Mittwoch, 04. Oktober 2023 um 17:00 Uhr Von: "Eliot Moss via gem5-users" An: "The gem5 Users mailing list" , yuan@it.uu.se Cc: reverent.gr...@web.de, "Eliot Moss" Betreff: [gem5-users] Re: Squashing Instructions after Page Table Fault On 10/4/2023 10:03 AM, reverent.green--- via gem5-users wrote: > Hi Yuan, > thank you very much for your detailed response. My understanding of the > fault handling in gem5 is getting better and better. Using debug flags, I > can trace the control flow during the execution of my code. > I am currently inspecting tlb.cc in further detail, but I am still searching > for the exact check for my problem. To further specify my question: > During the attempt to access kernel memory, the “user/supervisor” (U/S) > pagetable attribute is used to check whether this page table belongs to > kernel memory or not. If I want to access the memory, it should raise the > page table fault. I am looking for this specific check. My goal is, to > experiment with gem5 and to customize it. Currently, the instruction is not > executed when raising a Page Table Fault. In a first step, I want to change > the check in order to execute the instruction although it wants to access > kernel memory. So I explicitly search for this check inside this command > chain during the Page Fault handling. > Thank you very much in advance. > Best regards > Robin Assuming we're talking about the x86 architecture, line 471 in tlb.cc is where the check in question happens: https://github.com/gem5/gem5/blob/48a40cf2f5182a82de360b7efa497d82e06b1631/src/arch/x86/tlb.cc#L471 Note that the raw bits of the PTE have been abstracted out in the gem5 TLB entry data structure, hence properties such as entry->user. HTH Eliot Moss ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Squashing Instructions after Page Table Fault
Hi Yuan, thank you very much for your detailed response. My understanding of the fault handling in gem5 is getting better and better. Using debug flags, I can trace the control flow during the execution of my code. I am currently inspecting tlb.cc in further detail, but I am still searching for the exact check for my problem. To further specify my question: During the attempt to access kernel memory, the “user/supervisor” (U/S) pagetable attribute is used to check whether this page table belongs to kernel memory or not. If I want to access the memory, it should raise the page table fault. I am looking for this specific check. My goal is, to experiment with gem5 and to customize it. Currently, the instruction is not executed when raising a Page Table Fault. In a first step, I want to change the check in order to execute the instruction although it wants to access kernel memory. So I explicitly search for this check inside this command chain during the Page Fault handling. Thank you very much in advance. Best regards Robin Gesendet: Samstag, 30. September 2023 um 01:28 Uhr Von: "Yuan Yao via gem5-users" An: "The gem5 Users mailing list" Cc: "Yuan Yao" Betreff: [gem5-users] Re: Squashing Instructions after Page Table Fault Hi Robin, If I understand it correctly, a Page Table Fault instruction is not squashed but *not executed*. The instruction generating a fault is marked ready to commit. Then, during the commit phase, the fault generated by the instruction is handled. To explain this in more detail let me I take an example of how Page Fault of a load is handled with gem5: 1, DefaultIEW::executeInsts() => ldstQueue.executeLoad(Inst) => inst->InitiateAcc() (dynamic inst) => staticInst->initiateAcc() (static inst) => initiateMemRead (dynamic inst again) => cpu->pushRequest() => LSQ->pushRequest() => Follow this function chain, gem5 will ultimately start the translation via the MMU module. 2, Later after the translation is done, the page fault and the faulty instruction is marked by *translation->finish(...)* in pagetable_walker.cc (via walker:recevTimingResp, assuming that there is a page walk). The 'finish()' function is defined in the O3 pipeline components. In this case: LSQ::SingleDataRequest::finish. 3, Because the faulty instruction is not yet committed, DefaultIEW::executeInsts() will check the instruction again, but this time the instruction is marked as 'TranslationCompleted'. However since , so the instruction will be marked as executed and is forward to the commit stage (iewState->instToCommit(inst)). 4, As the instruction moves to the head of ROB, the commitInst() function of the commit unit will call commitHead(), which further calls cpu->trap(), then fault->invoke() to handle the fault. Different faults have different invoke functions. To your question, please take a look at PageFault::invoke() at arch/x86/faults.cc. The CPU then setup the CR2 register etc and will read the ROM to launch the procedure to transfer control to OS fault handler. (The microrom is defined in romutil.py) 5, And after the page handler is finished the fault instruction (still at the head of ROB) will be re-executed. The above is based on gem5 21.0.0.0 but I don't think the code changes much for the above discussions. Hope this helps. PS. Page access write is checked at the translate function in tlb.cc. Br, Yuan On 9/29/23 12:28, reverent.green--- via gem5-users wrote: A short addition. I also couldn't find a specific check for the user/supervisor Page Table Attribute anywhere. Are there parts in the code, where specific bits are checked or does gem5 uses some other kind of implementation here? Gesendet: Freitag, 29. September 2023 um 12:04 Uhr Von: "reverent.green--- via gem5-users" An: gem5-users@gem5.org Cc: reverent.gr...@web.de Betreff: [gem5-users] Squashing Instructions after Page Table Fault Hello, I am currently trying to locate the code that is used to squash instructions if a Page Table Fault is triggered in the O3 CPU. After using the PageTableWalker Debug Flags, my current guess would be gem5/src/arch/x86/pagetable_walker.cc in line 199. Furthermore I inspected the files in the src/cpu/o3 directory, but couldn't find anything specific to squashing instructions after a fault. Is my assumption correct, that the O3 CPU implementation does not handle these things on its own, but the architectural part of the implementation does it? I am missing something, feel free to point it out. Thank you in advance for your help. Kind regards Robin ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org VARNING: Klicka inte på länkar och öppna inte bilagor om du inte känner igen avsändaren och vet att innehållet är säker
[gem5-users] Re: Squashing Instructions after Page Table Fault
A short addition. I also couldn't find a specific check for the user/supervisor Page Table Attribute anywhere. Are there parts in the code, where specific bits are checked or does gem5 uses some other kind of implementation here? Gesendet: Freitag, 29. September 2023 um 12:04 Uhr Von: "reverent.green--- via gem5-users" An: gem5-users@gem5.org Cc: reverent.gr...@web.de Betreff: [gem5-users] Squashing Instructions after Page Table Fault Hello, I am currently trying to locate the code that is used to squash instructions if a Page Table Fault is triggered in the O3 CPU. After using the PageTableWalker Debug Flags, my current guess would be gem5/src/arch/x86/pagetable_walker.cc in line 199. Furthermore I inspected the files in the src/cpu/o3 directory, but couldn't find anything specific to squashing instructions after a fault. Is my assumption correct, that the O3 CPU implementation does not handle these things on its own, but the architectural part of the implementation does it? I am missing something, feel free to point it out. Thank you in advance for your help. Kind regards Robin ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Squashing Instructions after Page Table Fault
Hello, I am currently trying to locate the code that is used to squash instructions if a Page Table Fault is triggered in the O3 CPU. After using the PageTableWalker Debug Flags, my current guess would be gem5/src/arch/x86/pagetable_walker.cc in line 199. Furthermore I inspected the files in the src/cpu/o3 directory, but couldn't find anything specific to squashing instructions after a fault. Is my assumption correct, that the O3 CPU implementation does not handle these things on its own, but the architectural part of the implementation does it? I am missing something, feel free to point it out. Thank you in advance for your help. Kind regards Robin ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Meltdown simulation & analysis in FS mode using fs.py
Thanks for your replys, I updated my gem5 version to the latest stable branch and the "palignr" warning is gone. @Jason U mentioned, that gem5 may not even be vulnerable to meltdown. Do you think it is feasible to change some parts of the O3 code in order to make it vulnerable and after that analyze meltdown code? That also means in some runs, gem5 aborts after a few chars and sometimes it does not even leak one char before it aborts. Maybe I can experiment with debug flags a bit more. Kind regards, Robin Gesendet: Donnerstag, 20. Juli 2023 um 22:38 Uhr Von: "Hoa Nguyen via gem5-users" An: "The gem5 Users mailing list" Cc: reverent.gr...@web.de, "Jason Lowe-Power" , "Hoa Nguyen" Betreff: [gem5-users] Re: Meltdown simulation & analysis in FS mode using fs.py Hi all, It appears that you're using an older version of gem5 that does not have the palignr instructions implemented. The current stable branch has those instructions implemented. I'm not sure if this is a problem in your setup or related to this problem, but I wanted to add that I was not able to boot Ubuntu server 22.04 with the previous version of gem5 (v22 I think). I'm able to boot the OS using gem5 v23. Regards, Hoa Nguyen On Thu, Jul 20, 2023, 09:33 Jason Lowe-Power via gem5-users <gem5-users@gem5.org> wrote: Hi Robin, This may be helpful: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html For `warn: instruction 'palignr_Vdq_Wdq_Ib' unimplemented`, this is an AVX (or SSE) instruction that gem5 doesn't implement. Overall, I'm not sure if gem5 is vulnerable to meltdown. I think that the instruction is squashed when the TLB detects a page table fault and it does not proceed to memory. You can check the O3 code to be sure, though. Cheers, Jason On Thu, Jul 20, 2023 at 2:52 AM reverent.green--- via gem5-users <gem5-users@gem5.org> wrote: Hello everyone, I am currently working on a meltdown simulation & analysis using the fs.py script. Using se.py is not possible, because there is no kernel space mapping. As for the meltdown test code, I'm using this repo: https://github.com/IAIK/meltdown After playing a bit with the multiple parameter options, my current command line call is: "./build/X86/gem5.opt configs/example/fs.py --cpu-type=X86O3CPU --bp-type=LTAGE --caches --l2cache -n 8 --kernel=fs_stuff/vmlinux-5.4.49 --disk-image=fs_stuff/x86-ubuntu.img --script=fs_stuff/test" As you can see here, I am using the X86O3CPU and the branch predictor LTAGE (mainly because spectre only works using LTAGE). In theory, this should work and the test binary is executed in the simulation, but unfortunately the simulation either stops right before the leak or during the leakage (not at an exact point everytime, sometimes 1 char, sometimes 4 chars). The simulation does not abort by itself but looks like it's stuck somewhere. I waited for over one hour, but there was no extra char leaked. First I thought something is missing to even leak anything here, but after some tries do in fact leak some parts of the secret before stopping, there should be another problem. When the meltdown code is executed, the console log is spammed with "warn: instruction 'palignr_Vdq_Wdq_Ib' unimplemented"". At first I thought this could be the missing piece, but even with these warnings, some parts of the secret were leaked in some tries. My first goal is to get the complete leak in the result including a normal exit of the gem5 simulation. Does anyone here have an idea or experience at this topic? It would be very helpful to discuss possible problems and solutions. Thank you very much in advance. Kind regards Robin ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Meltdown simulation & analysis in FS mode using fs.py
Hello everyone, I am currently working on a meltdown simulation & analysis using the fs.py script. Using se.py is not possible, because there is no kernel space mapping. As for the meltdown test code, I'm using this repo: https://github.com/IAIK/meltdown After playing a bit with the multiple parameter options, my current command line call is: "./build/X86/gem5.opt configs/example/fs.py --cpu-type=X86O3CPU --bp-type=LTAGE --caches --l2cache -n 8 --kernel=fs_stuff/vmlinux-5.4.49 --disk-image=fs_stuff/x86-ubuntu.img --script=fs_stuff/test" As you can see here, I am using the X86O3CPU and the branch predictor LTAGE (mainly because spectre only works using LTAGE). In theory, this should work and the test binary is executed in the simulation, but unfortunately the simulation either stops right before the leak or during the leakage (not at an exact point everytime, sometimes 1 char, sometimes 4 chars). The simulation does not abort by itself but looks like it's stuck somewhere. I waited for over one hour, but there was no extra char leaked. First I thought something is missing to even leak anything here, but after some tries do in fact leak some parts of the secret before stopping, there should be another problem. When the meltdown code is executed, the console log is spammed with "warn: instruction 'palignr_Vdq_Wdq_Ib' unimplemented"". At first I thought this could be the missing piece, but even with these warnings, some parts of the secret were leaked in some tries. My first goal is to get the complete leak in the result including a normal exit of the gem5 simulation. Does anyone here have an idea or experience at this topic? It would be very helpful to discuss possible problems and solutions. Thank you very much in advance. Kind regards Robin___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
