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
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-leave@gem5.org
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" <jyhuang91@gmail.com>
An: "The gem5 Users mailing list" <gem5-users@gem5.org>
Cc: reverent.green@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-leave@gem5.org