I'm trying to reproduce data from InvisiSpec paper. InvisiSpec is a defense mechanism in hardware for Spectre attack. I'm using github code that was released by the author of the paper. I previously had issue building InvisiSpec on Gem5 but that issue is now solved.
Currently Gem5 from this repository is built with no errors on my system. And running it with following schemes successfully complete.
--scheme=UnsafeBaseline
--scheme=FuturisticSafeFence
--scheme=SpectreSafeFence
However SpectreSafeInvisibleSpec scheme aborts with core dumped. Apperently the source of leakage comes from the satisfyRequest function in the cache:
build/X86/mem/cache/cache.cc:192: void Cache::satisfyRequest(PacketPtr, CacheBlk*, bool, bool): Assertion `pkt->hasRespData()' failed.
I tried running this scheme for lower number of instructions as well as different cache configurations and different TSOs 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
Here is the backtrace:
build/X86/gem5.opt(_Z15print_backtracev+0x2c)[0x563bddc2e4ec]
build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x563bddc42c1a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fd71633f890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fd714b4de97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fd714b4f801]
/lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7fd714b3f39a]
/lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7fd714b3f412]
build/X86/gem5.opt(_ZN5Cache14satisfyRequestEP6PacketP8CacheBlkbb+0x6d1)[0x563bdda3d0f1]
build/X86/gem5.opt(_ZN5Cache14recvTimingRespEP6Packet+0xa7d)[0x563bdda45ced]
build/X86/gem5.opt(_ZN5Cache11MemSidePort14recvTimingRespEP6Packet+0x10)[0x563bdda46c40]
build/X86/gem5.opt(+0x9c809e)[0x563bdd3e609e]
build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd9)[0x563bddc35c59]
build/X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x87)[0x563bddc50a67]
build/X86/gem5.opt(_Z8simulatem+0xcba)[0x563bddc51aba]
build/X86/gem5.opt(+0xfc6d2e)[0x563bdd9e4d2e]
build/X86/gem5.opt(+0xcf1e9b)[0x563bdd70fe9b]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x64d7)[0x7fd7165f9697]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fd71672b278]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7fd7165f8db6]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8b5b)[0x7fd7165fbd1b]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8b5b)[0x7fd7165fbd1b]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fd71672b278]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fd7165f3029]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ac0)[0x7fd7165f9c80]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fd71672b278]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7fd7165f8db6]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fd71672b278]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fd7165f3029]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7fd716696546]
build/X86/gem5.opt(_Z6m5MainiPPc+0x83)[0x563bddc417e3]
build/X86/gem5.opt(main+0x33)[0x563bdcde0843]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fd714b30b97]
This issue is also reported in the corresponding github repository.
