mjyan0720 / invisispec-1.0 Goto Github PK

For L2 cache latency, the file "src/mem/protocol/MESI_Two_Level-L2cache.sm" does not show 8 cycle latency.
How did you simulate 8 cycles as RT for L2 cache, did you use different gem5 files?
Or you simulated with cycles specified in "src/mem/protocol/MESI_Two_Level-L2cache.sm" which do not sum to 8 cycles?

Hi, firstly, thank you very much for sharing your work. I really enjoyed reading your paper so I am trying to run your implementation.
However, when I just run your script (run_parsec_from_ckpt.sh), the simulation just finished with following message. The last line looks something wrong.
Exiting @ tick 18446744073709551615 because simulate() limit reached

Can you give me advice for solving this issue?
Thank you in advance.

warn: You are trying to use Ruby on ARM, which is not working properly yet.
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Apr 10 2019 12:33:30
gem5 started Apr 10 2019 23:32:48
gem5 executing on hpcserver.cse.tamu.edu, pid 5394
command line: ./build/ARM_MESI_Two_Level/gem5.opt configs/example/fs.py --kernel=/home/sungkeun/gem5-kernel/arm_parsec/binaries/vmlinux.aarch64.20140821 --dtb-file=/home/sungkeun/gem5-kernel/arm_parsec/binaries/vexpress.aarch64.20140821.dtb --disk-image=/home/sungkeun/gem5-kernel/arm_parsec/disks/aarch64-ubuntu-trusty-headless.img --machine-type=VExpress_EMM64 --num-cpus=8 --mem-size=2GB --num-l2caches=8 --num-dirs=8 --network=simple --topology=Mesh_XY --mesh-rows=4 --l1d_assoc=8 --l2_assoc=16 --l1i_assoc=4 --ruby --cpu-type=DerivO3CPU --needsTSO=0 --scheme=FuturisticSafeInvisibleSpec

Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
info: kernel located at: /home/sungkeun/gem5-kernel/arm_parsec/binaries/vmlinux.aarch64.20140821
warn: Highest ARM exception-level set to AArch32 but bootloader is for AArch64. Assuming you wanted these to match.
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
Info: simulation uses scheme: UnsafeBaseline; needsTSO=0; allowSpecBuffHit=1
warn: Sockets disabled, not accepting vnc client connections
warn: Sockets disabled, not accepting terminal connections
warn: Sockets disabled, not accepting gdb connections
info: Using bootloader at address 0x10
info: Using kernel entry physical address at 0x80080000
info: Loading DTB file: /home/sungkeun/gem5-kernel/arm_parsec/binaries/vexpress.aarch64.20140821.dtb at address 0x88000000
**** REAL SIMULATION ****
warn: Existing EnergyCtrl, but no enabled DVFSHandler found.
info: Entering event queue @ 0. Starting simulation...
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
warn: Address 0 is outside of physical memory, stopping fetch
Exiting @ tick 18446744073709551615 because simulate() limit reached

Exception: MI_example-cache.sm:401: Error: Invalid method call: Type 'Sequencer' does not have a method evictionCallback, 'evictionCallback_Addr' nor '':

Running with --scheme=UnsafeBaseline successfully completes but SpectreSafeInvisibleSpec aborts with core dump. I tried with low number of instructions as well as different cache configurations so find the source of memory leakage. But had no success.
build/X86/gem5.opt -d myout/gcc configs/example/se.py --cmd=../workspace/benchmarks/cpu2006/spec-SE/binaries/x86/linux/gcc -I 100000 --cpu-type=DerivO3CPU --caches --scheme=SpectreSafeInvisibleSpec --needsTSO=1

Exception: MI_example-dir.sm:448: Error: Unrecognized function name: 'queueMemoryRead_MachineID_Addr_Cycles':
File "/home/sam/InvisiSpec-1.0/SConstruct", line 1250:

I'm currently doing some research on defending against Spectre. I'd like to reproduce the results of InvisiSpec. I'm new to gem5. Sorry for asking you about using the experiment environment.

I saw in the example script run_spec_from_ckpt.sh that you use --checkpoint-restore=10000000000. Does this mean the skip the first 10 billion instructions; then, we simulate 1 billion instructions in the paper? And if I use --take-checkpoints=10000000000 to take a checkpoint running the unsafe baseline processor, can I use this checkpoint to run on other processors like IS-Sp?

Is there a file that I need to change for changing ruby cache latency?

Thanks a lot for making the code public. This definitely makes it easier for other researchers (including me) to start working on extending your work.

The code used by me for spectre attack:
https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

Spectre works when I use the original unmodified gem5 code:

1. Compiled spectre as: gcc spectre.c -o spectre -static
2. Built gem5 as: scons -j2 build/X86/gem5.opt
3. Changed the CPU from TimingSimpleCPU() to DerivO3CPU(branchPred=LTAGE()) in two_level.py
4. Ran spectre as: build/X86/gem5.opt configs/learning_gem5/part1/two_level.py spectre.
5. Spectre attack is successfully able to reveal the secret.

Spectre does not work when I use the modified gem5 code provided by you:

1. On the modified gem5 code provided by you, I couldn't build using X86 due to some errors in MI_example-cache.sm and MI_example-dir.sm.
2. Seeing that the example scripts used X86_MESI_Two_Level, I built gem5 using X86_MESI_Two_Level and was able to successfully build it.
3. However when I tried to run spectre as:
   build/X86_MESI_Two_Level/gem5.opt configs/learning_gem5/part1/two_level.py spectre, it is not working. The spectre attack is unable to reveal the secret.

Also, since most of the config options are added to se.py, I tried running the following command:

1. build/X86_MESI_Two_Level/gem5.opt configs/example/se.py --cpu-type=DerivO3CPU --needsTSO=0 --scheme=UnsafeBaseline --l1d_size=64kB --l1i_size=16kB --l2_size=256kB --caches --mem-type=DDR3_1600_8x8 --sys-clock=1GHz -c spectre.

2. I ran it this way because even two_level.py used 2 level caches with DDR3_1600_8x8 as mem type, sys clock as 1 GHz and DerivO3CPU as cpu type. The main purpose of two_level.py was to create 2 level cache

3. That is, I tried running spectre using UnsafeBaseline mode, but it is not working in unsafe baseline mode as well as in SpectreSafeInvisibleSpec mode. Ideally, spectre attack should have worked in unsafebaseline mode and successfully defended by SpectreSafeInvisibleSpec mode.

Could you please let me know how did you carry out the spectre attack and which code did you use to perform it. Please help me reproduce the spectre attack on your modified gem5 code.