Prime+Scope implementation

[GalHorowitz]

This PR adds a Prime+Scope [Purnal et al.] implementation, including an implementation of the genetic algorithm (termed "PrimeTime" by the authors) which searches for optimal prime patterns on the given CPU.

Currently the API exposes three functions:

• ps_prime(), which primes all monitored lines
• ps_scope(), which times all monitored line
• ps_prime_and_scope(...), which primes all monitored lines, and then repeatedly scopes them, returning the first accessed line

Are there any further functions which should be exposed?

The PR includes example usage at demo/PS.c and demo/PS-prime-time.c for using the attack and finding prime patterns respectively. The PS demo itself contains an optimal pattern for the i5-8250U CPU, and it would only work well on other CPUs by changing the pattern.

[XedSama]

Hi,

I tried to work around with those functions (actually only ps_prime() and ps_scope in demo/PS.c) and I would like to know if your results were constants or not. I work with an Intel i5-3230M CPU with optimized pattern (R5_S1_SS012012) and if sometime, my results are quite good (up to 100/100, avg ~90/100 on 1000 x PS.c run), there is other time were my trace never go beyond 10/100 in the same situation.

PS is, as I understand it, a method for producing easily reproducible measures, so it seem strange to me that such fluctuation can be observed between several captures.

[GalHorowitz]

Hi,

I tried to work around with those functions (actually only ps_prime() and ps_scope in demo/PS.c) and I would like to know if your results were constants or not. I work with an Intel i5-3230M CPU with optimized pattern (R5_S1_SS012012) and if sometime, my results are quite good (up to 100/100, avg ~90/100 on 1000 x PS.c run), there is other time were my trace never go beyond 10/100 in the same situation.

PS is, as I understand it, a method for producing easily reproducible measures, so it seem strange to me that such fluctuation can be observed between several captures.

Hey, one factor that might cause some runs to fail is if the generation of eviction-sets fails, this happens at the start of the program and is independent of the PS run. You can use the PTE map to check if that is the cause, and in general enabling huge pages and disabling CPU frequency scaling might help with finding eviction-sets more consistently.

[XedSama]

Just an idea, but maybe we can rely on the evsets code in order to create evitions-sets more efficiently ?

[GalHorowitz]

Just an idea, but maybe we can rely on the evsets code in order to create evitions-sets more efficiently ?

The linear algorithm presented in that paper is already implemented in Mastik - you can enable it by setting the L3FLAG_LINEARMAP flag in the l3info_t struct you pass into ps_prepare.

[canertol]

I have tried running PS.c on two systems. It consumes all available memory and gets killed.

[GalHorowitz]

I have tried running PS.c on two systems. It consumes all available memory and gets killed.

The Prime+Scope code itself doesn't allocate a lot of memory (unless the reported number of L3 sets is incorrect),
but the code first calls mm_prepare and mm_initialisel3, which are responsible for the construction of eviction-sets.
I suggest testing the eviction-set construction mechanism independently (e.g. using tests/testl3.c), and if the problem is not there, to add some logging statements in ps_prepare to print

ps->ngroups = ps->mm->l3ngroups;
ps->groupsize = ps->mm->l3groupsize;

To make sure the number of L3 sets is not reported incorrectly, leading to the allocation of a lot of memory.

Otherwise, some more information on where/what is causing the excessive allocations might be needed so I can reproduce the behavior on my end.