The lecture started with some tips for effective paper review process, which are as follows:

1) Justify when you write something negatives. Concentrate mostly on hows and whys?

2) Do not use the negatives that are already mentioned in the paper. Come up with your own negatives or positives that the authors have missed out.

3) Do a one-to-one mapping of abstract and conclusion to find out holes in the paper and attack/critically review those points asking why and what can/may be an issue.

4) Do not use the word "we". Use the autors or the paper. 

5) Review the paper based on when it came to the universe if not earth. Go back in time to that era if needed and then review it. 

6) question the plots and figures and find out the outliers and ask questions to the authors and see if they have answered it well and completely.

 

The second part of the lecture was mostly on one point: How to propose LLC replacement policies that can prevent cross-core eviction but not at the cost of performance and with minimal hardware overhead? 


Prologue: 
1. Notion of time should be tuned properly for better accuracy, for example, a pause between flush and reload will improve the effectiveness of the attack.

2. We jumped to the mitigation techniques, with an one minute recap on what did we cover and then started discussing about how to change cache replacement policies as a mitigation weapon.

Following ideas were debated and discussed:

1. A replacement policy can be augmented with core-id to prevent cross-core eveiction. So attacker can't evict victim's blocks. Then priya pointed out it will lead to starvation and ideas like randomness, static, dynamic tuning, ....... were debated to minimize the effect of starvation. 

2. The lecture concluded with a point that we need techniques that can mitigate cross-core attacks but not at the cost of performance and fairness. Students are encouraged to find better solutions before Thursday and discuss the same in Piazza. 

 

Some of the new proposals were:

1) communication between cores (see figure), where once core asks or seeks permission from the other one before replacing it. 

2) OS marks few pages as secure/non-secure and the blocks corresponding to that too, preventing a cross-core replacement of secure block.

3) Some kind of interrupt/trigger/............... block migration from one set to another ........

 

All of these proposals have serious performance bottleneck issues. Please see this figure 1.jpg  

 

After this discussion, We went to the root of the problem: inclusiveness and claimed that we can prevent cross-core evictions only when it results in back-invalidation-hits and the probability of this event is 12.5% (256KB L2/2MB/core of LLC). See figure 2.jpg

 

The lecture ended with a claim from Biswa that "For LRU replacement policy, fraction back-invalidation hit at the privates caches is very small". It is highly encouraged to demystify this statement. 

 
The idea will also be part of PA2 and PA2 will be with a more controlled environment with zero noise.