Transient Execution Attacks
|
|
|
- Walter French
- 5 years ago
- Views:
Transcription
1 Transient Execution Attacks Daniel Gruss September 12, 2018 Graz University of Technology 1 Daniel Gruss Graz University of Technology
2 Timeline Meltdown/Spectre (1) : Daniel has an implementation for KASLR-break with prefetch 2 Daniel Gruss Graz University of Technology
3 Timeline Meltdown/Spectre (1) : Daniel has an implementation for KASLR-break with prefetch : Anders blogs about it + we decide to write a paper together (first paragraph on KAISER in that paper) 2 Daniel Gruss Graz University of Technology
4 Timeline Meltdown/Spectre (1) : Daniel has an implementation for KASLR-break with prefetch : Anders blogs about it + we decide to write a paper together (first paragraph on KAISER in that paper) : Richard starts working on KAISER patch 2 Daniel Gruss Graz University of Technology
5 Timeline Meltdown/Spectre (1) : Daniel has an implementation for KASLR-break with prefetch : Anders blogs about it + we decide to write a paper together (first paragraph on KAISER in that paper) : Richard starts working on KAISER patch : Anders + Daniel meet for the first time at RuhrSec Daniel Gruss Graz University of Technology
6 Timeline Meltdown/Spectre (1) : Daniel has an implementation for KASLR-break with prefetch : Anders blogs about it + we decide to write a paper together (first paragraph on KAISER in that paper) : Richard starts working on KAISER patch : Anders + Daniel meet for the first time at RuhrSec : Anders + Daniel share a room at BH USA 2 Daniel Gruss Graz University of Technology
7 Timeline Meltdown/Spectre (1) : Daniel has an implementation for KASLR-break with prefetch : Anders blogs about it + we decide to write a paper together (first paragraph on KAISER in that paper) : Richard starts working on KAISER patch : Anders + Daniel meet for the first time at RuhrSec : Anders + Daniel share a room at BH USA discuss whether there might be something like Meltdown 2 Daniel Gruss Graz University of Technology
8 Timeline Meltdown/Spectre (1) : Daniel has an implementation for KASLR-break with prefetch : Anders blogs about it + we decide to write a paper together (first paragraph on KAISER in that paper) : Richard starts working on KAISER patch : Anders + Daniel meet for the first time at RuhrSec : Anders + Daniel share a room at BH USA discuss whether there might be something like Meltdown conclude that a bug of that dimension would have been found long ago 2 Daniel Gruss Graz University of Technology
9 Timeline Meltdown/Spectre (2) : Anders meets Graz team at CCS Daniel Gruss Graz University of Technology
10 Timeline Meltdown/Spectre (2) : Anders meets Graz team at CCS : Anders + Michael discuss speculative execution and reading kernel memory when sharing a room at BH EU 3 Daniel Gruss Graz University of Technology
11 Timeline Meltdown/Spectre (2) : Anders meets Graz team at CCS : Anders + Michael discuss speculative execution and reading kernel memory when sharing a room at BH EU Early 2017: Paul Kocher + Mike Hamburg start thinking about Speculative Execution 3 Daniel Gruss Graz University of Technology
12 Timeline Meltdown/Spectre (2) : Anders meets Graz team at CCS : Anders + Michael discuss speculative execution and reading kernel memory when sharing a room at BH EU Early 2017: Paul Kocher + Mike Hamburg start thinking about Speculative Execution : Anders tells Halvar Flake about this idea and Halvar encourages him to continue investigating it 3 Daniel Gruss Graz University of Technology
13 Timeline Meltdown/Spectre (2) : Anders meets Graz team at CCS : Anders + Michael discuss speculative execution and reading kernel memory when sharing a room at BH EU Early 2017: Paul Kocher + Mike Hamburg start thinking about Speculative Execution : Anders tells Halvar Flake about this idea and Halvar encourages him to continue investigating it : Anders has a first speculative execution PoC working (no full exploit yet) 3 Daniel Gruss Graz University of Technology
14 Timeline Meltdown/Spectre (2) : Anders meets Graz team at CCS : Anders + Michael discuss speculative execution and reading kernel memory when sharing a room at BH EU Early 2017: Paul Kocher + Mike Hamburg start thinking about Speculative Execution : Anders tells Halvar Flake about this idea and Halvar encourages him to continue investigating it : Anders has a first speculative execution PoC working (no full exploit yet) : KAISER paper was accepted at ESSoS 3 Daniel Gruss Graz University of Technology
15 Timeline Meltdown/Spectre (2) : Anders visits Graz. He later ( ) blogged about this meeting: 4 Daniel Gruss Graz University of Technology
16 Timeline Meltdown/Spectre (2) : Anders visits Graz. He later ( ) blogged about this meeting: tried to pitch my idea, because with the workload I had I knew it would be difficult for me to realize alone. Unfortunately, I wasn t the only one fully booked out and Daniel, Michael and myself were super skeptical at that time, despite the slight encouragement I d had at Troopers. So we decided to finish the stuff we were already doing first 4 Daniel Gruss Graz University of Technology
17 Timeline Meltdown/Spectre (2) : Anders visits Graz. He later ( ) blogged about this meeting: tried to pitch my idea, because with the workload I had I knew it would be difficult for me to realize alone. Unfortunately, I wasn t the only one fully booked out and Daniel, Michael and myself were super skeptical at that time, despite the slight encouragement I d had at Troopers. So we decided to finish the stuff we were already doing first : Posted KAISER patch to the Linux Kernel Mailing List (LKML) 4 Daniel Gruss Graz University of Technology
18 Timeline Meltdown/Spectre (3) May 2017: Jann Horn discovers Spectre 5 Daniel Gruss Graz University of Technology
19 Timeline Meltdown/Spectre (3) May 2017: Jann Horn discovers Spectre : Jann Horn reports Spectre to Intel 5 Daniel Gruss Graz University of Technology
20 Timeline Meltdown/Spectre (3) May 2017: Jann Horn discovers Spectre : Jann Horn reports Spectre to Intel : Jann Horn finds Meltdown + reports it to Intel 5 Daniel Gruss Graz University of Technology
21 Timeline Meltdown/Spectre (3) May 2017: Jann Horn discovers Spectre : Jann Horn reports Spectre to Intel : Jann Horn finds Meltdown + reports it to Intel : Graz team meets Anders at DIMVA / ESSoS Daniel Gruss Graz University of Technology
22 Timeline Meltdown/Spectre (4) : Anders blogs about negative result 6 Daniel Gruss Graz University of Technology
23 Timeline Meltdown/Spectre (4) : Anders blogs about negative result Fall 2017: Anders works with Microsoft(?) 6 Daniel Gruss Graz University of Technology
24 Timeline Meltdown/Spectre (4) : Anders blogs about negative result Fall 2017: Anders works with Microsoft(?) : Paul (+ Mike?) + Yuval + Genkin + Stefan sit at the same table and discuss speculative execution 6 Daniel Gruss Graz University of Technology
25 Timeline Meltdown/Spectre (4) : Anders blogs about negative result Fall 2017: Anders works with Microsoft(?) : Paul (+ Mike?) + Yuval + Genkin + Stefan sit at the same table and discuss speculative execution : Contacted by Intel asking to sign-off the patch 6 Daniel Gruss Graz University of Technology
26 Timeline Meltdown/Spectre (5) : Yearly student project announcements on our homepage... one of the projects Out-of-order-execution-based Channels 7 Daniel Gruss Graz University of Technology
27 Timeline Meltdown/Spectre (5) : Yearly student project announcements on our homepage... one of the projects Out-of-order-execution-based Channels : We discovered Meltdown (leaking data from L3) 7 Daniel Gruss Graz University of Technology
28 Timeline Meltdown/Spectre (5) : Yearly student project announcements on our homepage... one of the projects Out-of-order-execution-based Channels : We discovered Meltdown (leaking data from L3) : Bug report with Meltdown code sent to Intel 7 Daniel Gruss Graz University of Technology
29 Timeline Meltdown/Spectre (5) : Yearly student project announcements on our homepage... one of the projects Out-of-order-execution-based Channels : We discovered Meltdown (leaking data from L3) : Bug report with Meltdown code sent to Intel : First call with Intel 7 Daniel Gruss Graz University of Technology
30 Timeline Meltdown/Spectre (6) : First call with Paul + team 8 Daniel Gruss Graz University of Technology
31 Timeline Meltdown/Spectre (6) : First call with Paul + team We re surprised and confused that they found something different than we did (Spectre) 8 Daniel Gruss Graz University of Technology
32 Timeline Meltdown/Spectre (6) : First call with Paul + team We re surprised and confused that they found something different than we did (Spectre) They were surprised and confused about Meltdown 8 Daniel Gruss Graz University of Technology
33 Timeline Meltdown/Spectre (6) : First call with Paul + team We re surprised and confused that they found something different than we did (Spectre) They were surprised and confused about Meltdown : First call with Thomas + Werner 8 Daniel Gruss Graz University of Technology
34 Timeline Meltdown/Spectre (6) : First call with Paul + team We re surprised and confused that they found something different than we did (Spectre) They were surprised and confused about Meltdown : First call with Thomas + Werner We re surprised they found something different and confused what it is they found 8 Daniel Gruss Graz University of Technology
35 Timeline Meltdown/Spectre (7) : First call with Jann Horn 9 Daniel Gruss Graz University of Technology
36 Timeline Meltdown/Spectre (7) : First call with Jann Horn : Tom Lendacky (AMD) publicly states AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode 9 Daniel Gruss Graz University of Technology
37 Timeline Meltdown/Spectre (8) : The Register writes about Kernel-memory-leaking Intel processor design flaw 10 Daniel Gruss Graz University of Technology
38 Timeline Meltdown/Spectre (8) : The Register writes about Kernel-memory-leaking Intel processor design flaw posts on Twitter that he can leak a secret bit from speculative execution 10 Daniel Gruss Graz University of Technology
39 Timeline Meltdown/Spectre (8) : The Register writes about Kernel-memory-leaking Intel processor design flaw posts on Twitter that he can leak a secret bit from speculative execution posts code on Github 10 Daniel Gruss Graz University of Technology
40 Timeline Meltdown/Spectre (8) : The Register writes about Kernel-memory-leaking Intel processor design flaw posts on Twitter that he can leak a secret bit from speculative execution posts code on Github :18: We tell Intel that given code is public, the embargo probably won t hold and ask them to consider an earlier publication 10 Daniel Gruss Graz University of Technology
41 Timeline Meltdown/Spectre (8) : The Register writes about Kernel-memory-leaking Intel processor design flaw posts on Twitter that he can leak a secret bit from speculative execution posts code on Github :18: We tell Intel that given code is public, the embargo probably won t hold and ask them to consider an earlier publication posts on Twitter that he can read kernel memory 10 Daniel Gruss Graz University of Technology
42 Timeline Meltdown/Spectre (9) :28: Erik Bosman posts PoC video on Twitter 11 Daniel Gruss Graz University of Technology
43 Timeline Meltdown/Spectre (9) :28: Erik Bosman posts PoC video on Twitter :48: We were allowed to publish 11 Daniel Gruss Graz University of Technology
44 Timeline Meltdown/Spectre (9) :28: Erik Bosman posts PoC video on Twitter :48: We were allowed to publish :27: We publish Meltdown and Spectre 11 Daniel Gruss Graz University of Technology
45 Timeline Meltdown/Spectre (9) :28: Erik Bosman posts PoC video on Twitter :48: We were allowed to publish :27: We publish Meltdown and Spectre : We ask Anders Fogh to join our collaboration 11 Daniel Gruss Graz University of Technology
46 CPU Cache printf("%d", i); printf("%d", i); 12 Daniel Gruss Graz University of Technology
47 CPU Cache printf("%d", i); printf("%d", i); Cache miss 12 Daniel Gruss Graz University of Technology
48 CPU Cache printf("%d", i); printf("%d", i); Cache miss Request 12 Daniel Gruss Graz University of Technology
49 CPU Cache printf("%d", i); printf("%d", i); Cache miss Request Response 12 Daniel Gruss Graz University of Technology
50 CPU Cache printf("%d", i); printf("%d", i); Cache miss i Request Response 12 Daniel Gruss Graz University of Technology
51 CPU Cache printf("%d", i); printf("%d", i); Cache miss Cache hit i Request Response 12 Daniel Gruss Graz University of Technology
52 CPU Cache DRAM access, slow printf("%d", i); printf("%d", i); Cache miss Cache hit i Request Response 12 Daniel Gruss Graz University of Technology
53 CPU Cache DRAM access, slow printf("%d", i); printf("%d", i); Cache miss Cache hit i No DRAM access, much faster Request Response 12 Daniel Gruss Graz University of Technology
54 Flush+Reload ATTACKER Shared Memory VICTIM flush access access 13 Daniel Gruss Graz University of Technology
55 Flush+Reload ATTACKER Shared Memory VICTIM flush access cached Shared Memory cached access 13 Daniel Gruss Graz University of Technology
56 Flush+Reload ATTACKER Shared Memory VICTIM flush access Shared Memory access 13 Daniel Gruss Graz University of Technology
57 Flush+Reload ATTACKER Shared Memory VICTIM flush access access 13 Daniel Gruss Graz University of Technology
58 Flush+Reload ATTACKER Shared Memory VICTIM flush access access 13 Daniel Gruss Graz University of Technology
59 Flush+Reload ATTACKER Shared Memory VICTIM flush access Shared Memory access 13 Daniel Gruss Graz University of Technology
60 Flush+Reload ATTACKER Shared Memory VICTIM flush access Shared Memory access 13 Daniel Gruss Graz University of Technology
61 Flush+Reload ATTACKER Shared Memory VICTIM flush access Shared Memory access fast if victim accessed data, slow otherwise 13 Daniel Gruss Graz University of Technology
62 Memory Access Latency Cache Hits Number of accesses Access time [CPU cycles] 14 Daniel Gruss Graz University of Technology
63 Memory Access Latency Cache Hits Cache Misses Number of accesses Access time [CPU cycles] 14 Daniel Gruss Graz University of Technology
64 Out-of-order Execution int width = 10, height = 5; float diagonal = sqrt ( width * width + height * height ); int area = width * height ; printf (" Area %d x %d = %d\n", width, height, area ); 15 Daniel Gruss Graz University of Technology
65 Out-of-order Execution Dependency int width = 10, height = 5; float diagonal = sqrt ( width * width + height * height ); int area = width * height ; Parallelize printf (" Area %d x %d = %d\n", width, height, area ); 15 Daniel Gruss Graz University of Technology
66 Out-of-Order Execution L1 Instruction Cache ITLB Frontend Branch Predictor µop Cache µops Instruction Fetch & PreDecode Instruction Queue 4-Way Decode µop µop µop µop MUX CDB Execution Engine Reorder buffer µop µop µop µop µop µop µop µop Execution Units Allocation Queue µop µop µop µop Scheduler µop µop µop µop µop µop µop µop ALU, AES,... ALU, FMA,... ALU, Vect,... ALU, Branch Load data Load data Store data AGU Instructions are fetched and decoded in the front-end Memory Subsystem Load Buffer Store Buffer DTLB L1 Data Cache STLB L2 Cache 16 Daniel Gruss Graz University of Technology
67 Out-of-Order Execution L1 Instruction Cache ITLB Frontend Branch Predictor µop Cache µops Instruction Fetch & PreDecode Instruction Queue 4-Way Decode µop µop µop µop MUX CDB Execution Engine Reorder buffer µop µop µop µop µop µop µop µop Execution Units Allocation Queue µop µop µop µop Scheduler µop µop µop µop µop µop µop µop ALU, AES,... ALU, FMA,... ALU, Vect,... ALU, Branch Load data Load data Store data AGU Instructions are fetched and decoded in the front-end dispatched to the backend Memory Subsystem Load Buffer Store Buffer DTLB L1 Data Cache STLB L2 Cache 16 Daniel Gruss Graz University of Technology
68 Out-of-Order Execution L1 Instruction Cache ITLB Frontend Branch Predictor µop Cache µops Instruction Fetch & PreDecode Instruction Queue 4-Way Decode µop µop µop µop MUX CDB Execution Engine Reorder buffer µop µop µop µop µop µop µop µop Execution Units Allocation Queue µop µop µop µop Scheduler µop µop µop µop µop µop µop µop ALU, AES,... ALU, FMA,... ALU, Vect,... ALU, Branch Load data Load data Store data AGU Instructions are fetched and decoded in the front-end dispatched to the backend processed by individual execution units Memory Subsystem Load Buffer Store Buffer DTLB L1 Data Cache STLB L2 Cache 16 Daniel Gruss Graz University of Technology
69 Building Meltdown char data = *( char *) 0 xffffffff81a000e0 ; printf ("%c\n", data ); 17 Daniel Gruss Graz University of Technology
70 Building Meltdown char data = *( char *) 0 xffffffff81a000e0 ; printf ("%c\n", data ); segfault at ffffffff81a000e0 ip sp ffce4a80610 error 5 in reader 17 Daniel Gruss Graz University of Technology
71 Building Meltdown Adapted code *( volatile char *) 0; array [84 * 4096] = 0; // unreachable 18 Daniel Gruss Graz University of Technology
72 Building Meltdown Flush+Reload over all pages of the array Access time [cycles] Page 19 Daniel Gruss Graz University of Technology
73 Building Meltdown Flush+Reload over all pages of the array Access time [cycles] Page This also works on AMD and ARM! 19 Daniel Gruss Graz University of Technology
74 Building Meltdown Out-of-order instructions leave microarchitectural traces 20 Daniel Gruss Graz University of Technology
75 Building Meltdown Out-of-order instructions leave microarchitectural traces We can see them for example through the cache 20 Daniel Gruss Graz University of Technology
76 Building Meltdown Out-of-order instructions leave microarchitectural traces We can see them for example through the cache Give such instructions a name: transient instructions 20 Daniel Gruss Graz University of Technology
77 Building Meltdown Out-of-order instructions leave microarchitectural traces We can see them for example through the cache Give such instructions a name: transient instructions We can indirectly observe the execution of transient instructions 20 Daniel Gruss Graz University of Technology
78 Building Meltdown Combine the two things char data = *( char *) 0 xffffffff81a000e0 ; array [ data * 4096] = 0; 21 Daniel Gruss Graz University of Technology
79 Building Meltdown Flush+Reload again... Access time [cycles] Page... Meltdown actually works. 22 Daniel Gruss Graz University of Technology
80 Building Meltdown Flush+Reload over all pages of the array Access time [cycles] Page Index of cache hit reveals data 23 Daniel Gruss Graz University of Technology
81 Building Meltdown Flush+Reload over all pages of the array Access time [cycles] Page Index of cache hit reveals data Permission check is in some cases not fast enough 23 Daniel Gruss Graz University of Technology
82
83
84
85 Details: Exception Handling Basic Meltdown code leads to a crash (segfault) 26 Daniel Gruss Graz University of Technology
86 Details: Exception Handling Basic Meltdown code leads to a crash (segfault) How to prevent the crash? 26 Daniel Gruss Graz University of Technology
87 Details: Exception Handling Basic Meltdown code leads to a crash (segfault) How to prevent the crash? Fault Handling Fault Suppression Fault Prevention 26 Daniel Gruss Graz University of Technology
88 Meltdown with Fault Suppression Intel TSX to suppress exceptions instead of signal handler if( xbegin () == XBEGIN_ STARTED ) { char secret = *( char *) 0 xffffffff81a000e0 ; array [ secret * 4096] = 0; xend (); } for ( size_t i = 0; i < 256; i ++) { if ( flush_ and_ reload ( array + i * 4096) == CACHE_ HIT ) { printf ("%c\n", i); } } 27 Daniel Gruss Graz University of Technology
89 Meltdown with Fault Prevention Speculative execution to prevent exceptions int speculate = rand () % 2; size_t address = (0 xffffffff81a000e0 * speculate ) + (( size_t )& zero * (1 - speculate )); if (! speculate ) { char secret = *( char *) address ; array [ secret * 4096] = 0; } for ( size_t i = 0; i < 256; i ++) { if ( flush_ and_ reload ( array + i * 4096) == CACHE_ HIT ) { printf ("%c\n", i); } } 28 Daniel Gruss Graz University of Technology
90 Make it faster Improve the performance with a NULL pointer dereference 29 Daniel Gruss Graz University of Technology
91 Make it faster Improve the performance with a NULL pointer dereference if( xbegin () == XBEGIN_ STARTED ) { *( volatile char *) 0; char secret = *( char *) 0 xffffffff81a000e0 ; array [ secret * 4096] = 0; xend (); } 29 Daniel Gruss Graz University of Technology
92
93
94 Uncached memory Assumed that one can only read data stored in the L1 with Meltdown 30 Daniel Gruss Graz University of Technology
95 Uncached memory Assumed that one can only read data stored in the L1 with Meltdown Experiment where a thread flushes the value constantly and a thread on a different core reloads the value 30 Daniel Gruss Graz University of Technology
96 Uncached memory Assumed that one can only read data stored in the L1 with Meltdown Experiment where a thread flushes the value constantly and a thread on a different core reloads the value Target data is not in the L1 cache of the attacking core 30 Daniel Gruss Graz University of Technology
97 Uncached memory Assumed that one can only read data stored in the L1 with Meltdown Experiment where a thread flushes the value constantly and a thread on a different core reloads the value Target data is not in the L1 cache of the attacking core We can still leak the data at a lower reading rate 30 Daniel Gruss Graz University of Technology
98 Uncached memory Assumed that one can only read data stored in the L1 with Meltdown Experiment where a thread flushes the value constantly and a thread on a different core reloads the value Target data is not in the L1 cache of the attacking core We can still leak the data at a lower reading rate Meltdown might implicitly cache the data 30 Daniel Gruss Graz University of Technology
99
100 Practical attacks Dumping the entire physical memory takes some time 31 Daniel Gruss Graz University of Technology
101 Practical attacks Dumping the entire physical memory takes some time Not very practical in most scenarios 31 Daniel Gruss Graz University of Technology
102 Practical attacks Dumping the entire physical memory takes some time Not very practical in most scenarios Can we mount more targeted attacks? 31 Daniel Gruss Graz University of Technology
103 VeraCrypt Open-source utility for disk encryption 32 Daniel Gruss Graz University of Technology
104 VeraCrypt Open-source utility for disk encryption Fork of TrueCrypt 32 Daniel Gruss Graz University of Technology
105 VeraCrypt Open-source utility for disk encryption Fork of TrueCrypt Cryptographic keys are stored in RAM 32 Daniel Gruss Graz University of Technology
106 VeraCrypt Open-source utility for disk encryption Fork of TrueCrypt Cryptographic keys are stored in RAM With Meltdown, we can extract the keys from DRAM 32 Daniel Gruss Graz University of Technology
107
108 Take the kernel addresses... Kernel addresses in user space are a problem 34 Daniel Gruss Graz University of Technology
109 Take the kernel addresses... Kernel addresses in user space are a problem Why don t we take the kernel addresses Daniel Gruss Graz University of Technology
110 ...and remove them...and remove them if not needed? 35 Daniel Gruss Graz University of Technology
111 ...and remove them...and remove them if not needed? User accessible check in hardware is not reliable 35 Daniel Gruss Graz University of Technology
112
113 Kernel Address Isolation to have Side channels Efficiently Removed
![KAISER /ˈkʌɪzə/ 1. [german] Emperor, ruler of an empire 2.](/docs-images/92/109573532/images/114-0.jpg "largest penguin, emperor penguin Kernel Address Isolation to have Side")
114 KAISER /ˈkʌɪzə/ 1. [german] Emperor, ruler of an empire 2. largest penguin, emperor penguin Kernel Address Isolation to have Side channels Efficiently Removed
115 KAISER Illustration Without KAISER: Shared address space User memory Kernel memory 0 1 context switch 36 Daniel Gruss Graz University of Technology
116 KAISER Illustration User memory Without KAISER: Shared address space Kernel memory 0 1 context switch User memory With KAISER: User address space Not mapped 0 1 context switch SMAP + SMEP switch addr. space Kernel address space Kernel memory Interrupt dispatcher Daniel Gruss Graz University of Technology
117 KAISER (Stronger Kernel Isolation) Patches 37 Daniel Gruss Graz University of Technology
118 KAISER (Stronger Kernel Isolation) Patches Our patch Adopted in Linux 37 Daniel Gruss Graz University of Technology
119 KAISER (Stronger Kernel Isolation) Patches Our patch Adopted in Linux Adopted in Windows 37 Daniel Gruss Graz University of Technology
120 KAISER (Stronger Kernel Isolation) Patches Our patch Adopted in Linux Adopted in Windows Adopted in OSX/iOS 37 Daniel Gruss Graz University of Technology
121 KAISER (Stronger Kernel Isolation) Patches Our patch Adopted in Linux Adopted in Windows Adopted in OSX/iOS now in every computer 37 Daniel Gruss Graz University of Technology
![Foreshadow / Foreshadow-NG 1 [Van+18; Wei+18] 1 Jo Van Bulck et al.](/docs-images/92/109573532/images/122-0.jpg "Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution.")
122 Foreshadow / Foreshadow-NG 1 [Van+18; Wei+18] 1 Jo Van Bulck et al. Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. In: USENIX Security Symposium Daniel Gruss Graz University of Technology
123 L1TF/Foreshadow Demo
124 Mitigating L1TF/Foreshadow Either: 40 Daniel Gruss Graz University of Technology
125 Mitigating L1TF/Foreshadow Either: hyperthreading: only schedule mutually trusting threads on same physical core 40 Daniel Gruss Graz University of Technology
126 Mitigating L1TF/Foreshadow Either: hyperthreading: only schedule mutually trusting threads on same physical core context switch: flush L1 when switching to guest 40 Daniel Gruss Graz University of Technology
127 Mitigating L1TF/Foreshadow Either: Or: hyperthreading: only schedule mutually trusting threads on same physical core context switch: flush L1 when switching to guest 40 Daniel Gruss Graz University of Technology
128 Mitigating L1TF/Foreshadow Either: Or: hyperthreading: only schedule mutually trusting threads on same physical core context switch: flush L1 when switching to guest disable EPTs 40 Daniel Gruss Graz University of Technology
129
130
131 Spectre (variant 1) index = 0; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
132 Spectre (variant 1) index = 0; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
133 Spectre (variant 1) index = 0; char* data = "textkey"; if (index < 4) Speculate els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
134 Spectre (variant 1) index = 0; char* data = "textkey"; if (index < 4) Execute els en th e Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
135 Spectre (variant 1) index = 1; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
136 Spectre (variant 1) index = 1; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
137 Spectre (variant 1) index = 1; char* data = "textkey"; if (index < 4) Speculate els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
138 Spectre (variant 1) index = 1; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
139 Spectre (variant 1) index = 2; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
140 Spectre (variant 1) index = 2; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
141 Spectre (variant 1) index = 2; char* data = "textkey"; if (index < 4) Speculate els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
142 Spectre (variant 1) index = 2; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
143 Spectre (variant 1) index = 3; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
144 Spectre (variant 1) index = 3; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
145 Spectre (variant 1) index = 3; char* data = "textkey"; if (index < 4) Speculate els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
146 Spectre (variant 1) index = 3; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
147 Spectre (variant 1) index = 4; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
148 Spectre (variant 1) index = 4; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
149 Spectre (variant 1) index = 4; char* data = "textkey"; if (index < 4) Speculate els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
150 Spectre (variant 1) index = 4; char* data = "textkey"; if (index < 4) Execute els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
151 Spectre (variant 1) index = 5; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
152 Spectre (variant 1) index = 5; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
153 Spectre (variant 1) index = 5; char* data = "textkey"; if (index < 4) Speculate els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
154 Spectre (variant 1) index = 5; char* data = "textkey"; if (index < 4) Execute els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
155 Spectre (variant 1) index = 6; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
156 Spectre (variant 1) index = 6; char* data = "textkey"; if (index < 4) then Prediction else LUT[data[index] * 4096] 0 42 Daniel Gruss Graz University of Technology
157 Spectre (variant 1) index = 6; char* data = "textkey"; if (index < 4) Speculate els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
158 Spectre (variant 1) index = 6; char* data = "textkey"; if (index < 4) Execute els en e th Prediction LUT[data[index] * 4096] 42 0 Daniel Gruss Graz University of Technology
159 Spectre (variant 4) index = 0; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
160 Spectre (variant 4) index = 0; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
161 Spectre (variant 4) index = 0; index = index & 0x3; // sanitization char* data = "textkey"; c LUT[data[index] * 4096] 43 Speculate ig er id s on no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
162 Spectre (variant 4) index = 0; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
163 Spectre (variant 4) index = 1; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
164 Spectre (variant 4) index = 1; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
165 Spectre (variant 4) index = 1; index = index & 0x3; // sanitization char* data = "textkey"; c LUT[data[index] * 4096] 43 Speculate ig er id s on no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
166 Spectre (variant 4) index = 1; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
167 Spectre (variant 4) index = 2; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
168 Spectre (variant 4) index = 2; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
169 Spectre (variant 4) index = 2; index = index & 0x3; // sanitization char* data = "textkey"; c LUT[data[index] * 4096] 43 Speculate ig er id s on no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
170 Spectre (variant 4) index = 2; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
171 Spectre (variant 4) index = 3; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
172 Spectre (variant 4) index = 3; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
173 Spectre (variant 4) index = 3; index = index & 0x3; // sanitization char* data = "textkey"; c LUT[data[index] * 4096] 43 Speculate ig er id s on no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
174 Spectre (variant 4) index = 3; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
175 Spectre (variant 4) index = 4; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
176 Spectre (variant 4) index = 4; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
177 Spectre (variant 4) index = 4; index = index & 0x3; // sanitization char* data = "textkey"; c LUT[data[index] * 4096] 43 Speculate ig er id s on no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
178 Spectre (variant 4) index = 4; index = index & 0x3; // sanitization char* data = "textkey"; Execute x de n i = 0 LUT[data[index] * 4096] 43 ig no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
179 Spectre (variant 4) index = 5; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
180 Spectre (variant 4) index = 5; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
181 Spectre (variant 4) index = 5; index = index & 0x3; // sanitization char* data = "textkey"; c LUT[data[index] * 4096] 43 Speculate ig er id s on no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
182 Spectre (variant 4) index = 5; index = index & 0x3; // sanitization char* data = "textkey"; Execute x de n i = 1 LUT[data[index] * 4096] 43 ig no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
183 Spectre (variant 4) index = 6; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
184 Spectre (variant 4) index = 6; index = index & 0x3; // sanitization char* data = "textkey"; consider Prediction ignore LUT[data[index] * 4096] LUT[data[index] * 4096] 43 Daniel Gruss Graz University of Technology
185 Spectre (variant 4) index = 6; index = index & 0x3; // sanitization char* data = "textkey"; c LUT[data[index] * 4096] 43 Speculate ig er id s on no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
186 Spectre (variant 4) index = 6; index = index & 0x3; // sanitization char* data = "textkey"; Execute x de n i = 2 LUT[data[index] * 4096] 43 ig no re Prediction LUT[data[index] * 4096] Daniel Gruss Graz University of Technology
187 Spectre (variant 1.1) Speculative Buffer Overflows Speculatively write to memory locations Many more gadgets than previously anticipated Very interesting for sandboxes Causes some protection mechanisms to fail 44 Daniel Gruss Graz University of Technology
188 Spectre (variant 1.2) Speculative Buffer Overflows Speculatively write to memory locations which are not writable Actually a variant of Meltdown A permission bit is ignored during out-of-order execution But no scenario where it makes sense without speculative execution? 45 Daniel Gruss Graz University of Technology
189 Spectre (variant 2) Animal* a = bird; a->move() fly() swim() swim() Prediction LUT[data[index] * 4096] 0 46 Daniel Gruss Graz University of Technology
190 Spectre (variant 2) Animal* a = bird; a->move() () fly swim() Speculate sw im () Prediction LUT[data[index] * 4096] 46 0 Daniel Gruss Graz University of Technology
191 Spectre (variant 2) Animal* a = bird; a->move() fly() swim() swim() Prediction LUT[data[index] * 4096] 0 46 Daniel Gruss Graz University of Technology
192 Spectre (variant 2) Animal* a = bird; a->move() Execute fl ) y( swim() sw im () Prediction LUT[data[index] * 4096] 46 0 Daniel Gruss Graz University of Technology
193 Spectre (variant 2) Animal* a = bird; a->move() fly() fly() swim() Prediction LUT[data[index] * 4096] 0 46 Daniel Gruss Graz University of Technology
194 Spectre (variant 2) Animal* a = bird; a->move() Speculate fl ) y( fly() sw im () Prediction LUT[data[index] * 4096] 46 0 Daniel Gruss Graz University of Technology
195 Spectre (variant 2) Animal* a = bird; a->move() fly() fly() swim() Prediction LUT[data[index] * 4096] 0 46 Daniel Gruss Graz University of Technology
196 Spectre (variant 2) Animal* a = fish; a->move() fly() fly() swim() Prediction LUT[data[index] * 4096] 0 46 Daniel Gruss Graz University of Technology
197 Spectre (variant 2) Animal* a = fish; a->move() Speculate fl ) y( fly() sw im () Prediction LUT[data[index] * 4096] 46 0 Daniel Gruss Graz University of Technology
198 Spectre (variant 2) Animal* a = fish; a->move() fly() fly() swim() Prediction LUT[data[index] * 4096] 0 46 Daniel Gruss Graz University of Technology
199 Spectre (variant 2) Animal* a = fish; a->move() () fly fly() sw i Execute m () Prediction LUT[data[index] * 4096] 46 0 Daniel Gruss Graz University of Technology
200 Spectre (variant 2) Animal* a = fish; a->move() fly() swim() swim() Prediction LUT[data[index] * 4096] 0 46 Daniel Gruss Graz University of Technology
201 Spectre (variant 5) SpectreRSB Similar to Spectre variant 2: Redirect an indirect branch (a return in this case) Fill buffer with wrong values 47 Daniel Gruss Graz University of Technology
202 Mitigating Spectre Trivial approach: disable speculative execution 48 Daniel Gruss Graz University of Technology
203 Mitigating Spectre Trivial approach: disable speculative execution No wrong speculation if there is no speculation 48 Daniel Gruss Graz University of Technology
204 Mitigating Spectre Trivial approach: disable speculative execution No wrong speculation if there is no speculation Problem: massive performance hit! 48 Daniel Gruss Graz University of Technology
205 Mitigating Spectre Trivial approach: disable speculative execution No wrong speculation if there is no speculation Problem: massive performance hit! Also: How to disable it? 48 Daniel Gruss Graz University of Technology
206 Mitigating Spectre Trivial approach: disable speculative execution No wrong speculation if there is no speculation Problem: massive performance hit! Also: How to disable it? Speculative execution is deeply integrated into CPU 48 Daniel Gruss Graz University of Technology
207 Spectre Variant 1 Mitigations 49 Daniel Gruss Graz University of Technology
208 Spectre Variant 1 Mitigations Workaround: insert instructions stopping speculation 49 Daniel Gruss Graz University of Technology
209 Spectre Variant 1 Mitigations Workaround: insert instructions stopping speculation insert after every bounds check 49 Daniel Gruss Graz University of Technology
210 Spectre Variant 1 Mitigations Workaround: insert instructions stopping speculation insert after every bounds check x86: LFENCE, ARM: CSDB 49 Daniel Gruss Graz University of Technology
211 Spectre Variant 1 Mitigations Workaround: insert instructions stopping speculation insert after every bounds check x86: LFENCE, ARM: CSDB Available on all Intel CPUs, retrofitted to existing ARMv7 and ARMv8 49 Daniel Gruss Graz University of Technology
212 Spectre Variant 1 Mitigations 50 Daniel Gruss Graz University of Technology
213 Spectre Variant 1 Mitigations Speculation barrier requires compiler supported 50 Daniel Gruss Graz University of Technology
214 Spectre Variant 1 Mitigations Speculation barrier requires compiler supported Already implemented in GCC, LLVM, and MSVC 50 Daniel Gruss Graz University of Technology
215 Spectre Variant 1 Mitigations Speculation barrier requires compiler supported Already implemented in GCC, LLVM, and MSVC Can be automated (MSVC) not really reliable 50 Daniel Gruss Graz University of Technology
216 Spectre Variant 1 Mitigations Speculation barrier requires compiler supported Already implemented in GCC, LLVM, and MSVC Can be automated (MSVC) not really reliable Explicit use by programmer: builtin load no speculate 50 Daniel Gruss Graz University of Technology
217 Spectre Variant 2 Mitigations (Microcode/MSRs) Intel released microcode updates Indirect Branch Restricted Speculation (IBRS): 51 Daniel Gruss Graz University of Technology
218 Spectre Variant 2 Mitigations (Microcode/MSRs) Intel released microcode updates Indirect Branch Restricted Speculation (IBRS): Do not speculate based on anything before entering IBRS mode 51 Daniel Gruss Graz University of Technology
219 Spectre Variant 2 Mitigations (Microcode/MSRs) Intel released microcode updates Indirect Branch Restricted Speculation (IBRS): Do not speculate based on anything before entering IBRS mode lesser privileged code cannot influence predictions 51 Daniel Gruss Graz University of Technology
220 Spectre Variant 2 Mitigations (Microcode/MSRs) Intel released microcode updates Indirect Branch Restricted Speculation (IBRS): Do not speculate based on anything before entering IBRS mode lesser privileged code cannot influence predictions Indirect Branch Predictor Barrier (IBPB): 51 Daniel Gruss Graz University of Technology
221 Spectre Variant 2 Mitigations (Microcode/MSRs) Intel released microcode updates Indirect Branch Restricted Speculation (IBRS): Do not speculate based on anything before entering IBRS mode lesser privileged code cannot influence predictions Indirect Branch Predictor Barrier (IBPB): Flush branch-target buffer 51 Daniel Gruss Graz University of Technology
222 Spectre Variant 2 Mitigations (Microcode/MSRs) Intel released microcode updates Indirect Branch Restricted Speculation (IBRS): Do not speculate based on anything before entering IBRS mode lesser privileged code cannot influence predictions Indirect Branch Predictor Barrier (IBPB): Flush branch-target buffer Single Thread Indirect Branch Predictors (STIBP): 51 Daniel Gruss Graz University of Technology
223 Spectre Variant 2 Mitigations (Microcode/MSRs) Intel released microcode updates Indirect Branch Restricted Speculation (IBRS): Do not speculate based on anything before entering IBRS mode lesser privileged code cannot influence predictions Indirect Branch Predictor Barrier (IBPB): Flush branch-target buffer Single Thread Indirect Branch Predictors (STIBP): Isolates branch prediction state between two hyperthreads 51 Daniel Gruss Graz University of Technology
224 Spectre Variant 2 Mitigations (Software) Retpoline (compiler extension) 52 Daniel Gruss Graz University of Technology
225 Spectre Variant 2 Mitigations (Software) Retpoline (compiler extension) push < call_target > call 1f 2: lfence ; speculation barrier jmp 2b ; endless loop 1: lea 8(% rsp ), % rsp ; restore stack pointer ret ; the actual call to < call_target > always predict to enter an endless loop 52 Daniel Gruss Graz University of Technology
226 Spectre Variant 2 Mitigations (Software) Retpoline (compiler extension) push < call_target > call 1f 2: lfence ; speculation barrier jmp 2b ; endless loop 1: lea 8(% rsp ), % rsp ; restore stack pointer ret ; the actual call to < call_target > always predict to enter an endless loop instead of the correct (or wrong) target function 52 Daniel Gruss Graz University of Technology
227 Spectre Variant 2 Mitigations (Software) Retpoline (compiler extension) push < call_target > call 1f 2: lfence ; speculation barrier jmp 2b ; endless loop 1: lea 8(% rsp ), % rsp ; restore stack pointer ret ; the actual call to < call_target > always predict to enter an endless loop instead of the correct (or wrong) target function performance? 52 Daniel Gruss Graz University of Technology
228 Spectre Variant 2 Mitigations (Software) Retpoline (compiler extension) push < call_target > call 1f 2: lfence ; speculation barrier jmp 2b ; endless loop 1: lea 8(% rsp ), % rsp ; restore stack pointer ret ; the actual call to < call_target > always predict to enter an endless loop instead of the correct (or wrong) target function performance? ret may fall-back to the BTB for prediction 52 Daniel Gruss Graz University of Technology
229 Spectre Variant 2 Mitigations (Software) Retpoline (compiler extension) push < call_target > call 1f 2: lfence ; speculation barrier jmp 2b ; endless loop 1: lea 8(% rsp ), % rsp ; restore stack pointer ret ; the actual call to < call_target > always predict to enter an endless loop instead of the correct (or wrong) target function performance? ret may fall-back to the BTB for prediction microcode patches to prevent that 52 Daniel Gruss Graz University of Technology
230 Spectre Variant 4 Mitigations (Microcode/MSRs) Intel released microcode updates 53 Daniel Gruss Graz University of Technology
231 Spectre Variant 4 Mitigations (Microcode/MSRs) Intel released microcode updates Disable store-to-load-forward speculation Performance impact of 2 8% 53 Daniel Gruss Graz University of Technology
232 Spectre Variant 5 Mitigations (Software) Already implicitly patched on some architectures RSB stuffing (part of retpoline) 54 Daniel Gruss Graz University of Technology
233 What does not work Prevent access to high-resolution timer 55 Daniel Gruss Graz University of Technology
234 What does not work Prevent access to high-resolution timer Own timer using timing thread 55 Daniel Gruss Graz University of Technology
235 What does not work Prevent access to high-resolution timer Own timer using timing thread Flush instruction only privileged 55 Daniel Gruss Graz University of Technology
236 What does not work Prevent access to high-resolution timer Own timer using timing thread Flush instruction only privileged Cache eviction through memory accesses 55 Daniel Gruss Graz University of Technology
237 What does not work Prevent access to high-resolution timer Own timer using timing thread Flush instruction only privileged Cache eviction through memory accesses Just move secrets into secure world 55 Daniel Gruss Graz University of Technology
238 What does not work Prevent access to high-resolution timer Own timer using timing thread Flush instruction only privileged Cache eviction through memory accesses Just move secrets into secure world Spectre works on secure enclaves 55 Daniel Gruss Graz University of Technology
239 Meltdown vs. Spectre Meltdown attacks Spectre attacks 56 Daniel Gruss Graz University of Technology
240 Meltdown vs. Spectre Meltdown attacks Meltdown, LazyFP (v3.1), Foreshadow, Foreshadow-NG,... Spectre attacks v1, v1.1, v2, v4, SpectreRSB (v5) 56 Daniel Gruss Graz University of Technology
241 Meltdown vs. Spectre Meltdown attacks Meltdown, LazyFP (v3.1), Foreshadow, Foreshadow-NG,... Out-of-Order Execution Spectre attacks v1, v1.1, v2, v4, SpectreRSB (v5) Speculative Execution Out-of-Order Execution 56 Daniel Gruss Graz University of Technology
242 Meltdown vs. Spectre Meltdown attacks Meltdown, LazyFP (v3.1), Foreshadow, Foreshadow-NG,... Out-of-Order Execution no prediction required Spectre attacks v1, v1.1, v2, v4, SpectreRSB (v5) Speculative Execution Out-of-Order Execution fundamentally rely on prediction 56 Daniel Gruss Graz University of Technology
Software-based Microarchitectural Attacks
SCIENCE PASSION TECHNOLOGY Software-based Microarchitectural Attacks Daniel Gruss April 19, 2018 Graz University of Technology 1 Daniel Gruss Graz University of Technology Whoami Daniel Gruss Post-Doc
Meltdown & Spectre. Side-channels considered harmful. Qualcomm Mobile Security Summit May, San Diego, CA. Moritz Lipp
Meltdown & Spectre Side-channels considered harmful Qualcomm Mobile Security Summit 2018 17 May, 2018 - San Diego, CA Moritz Lipp (@mlqxyz) Michael Schwarz (@misc0110) Flashback Qualcomm Mobile Security
Microarchitectural Attacks and Defenses in JavaScript
Microarchitectural Attacks and Defenses in JavaScript Michael Schwarz, Daniel Gruss, Moritz Lipp 25.01.2018 www.iaik.tugraz.at 1 Michael Schwarz, Daniel Gruss, Moritz Lipp www.iaik.tugraz.at Microarchitecture
Project 5: Optimizer Jason Ansel
Project 5: Optimizer Jason Ansel Overview Project guidelines Benchmarking Library OoO CPUs Project Guidelines Use optimizations from lectures as your arsenal If you decide to implement one, look at Whale
Architectural Core Salvaging in a Multi-Core Processor for Hard-Error Tolerance
Architectural Core Salvaging in a Multi-Core Processor for Hard-Error Tolerance Michael D. Powell, Arijit Biswas, Shantanu Gupta, and Shubu Mukherjee SPEARS Group, Intel Massachusetts EECS, University
On the Rules of Low-Power Design
On the Rules of Low-Power Design (and Why You Should Break Them) Prof. Todd Austin University of Michigan austin@umich.edu A long time ago, in a not so far away place The Rules of Low-Power Design P =
Lecture Topics. Announcements. Today: Memory Management (Stallings, chapter ) Next: continued. Self-Study Exercise #6. Project #4 (due 10/11)
Lecture Topics Today: Memory Management (Stallings, chapter 7.1-7.4) Next: continued 1 Announcements Self-Study Exercise #6 Project #4 (due 10/11) Project #5 (due 10/18) 2 Memory Hierarchy 3 Memory Hierarchy
7/19/2012. IF for Load (Review) CSE 2021: Computer Organization. EX for Load (Review) ID for Load (Review) WB for Load (Review) MEM for Load (Review)
CSE 2021: Computer Organization IF for Load (Review) Lecture-11 CPU Design : Pipelining-2 Review, Hazards Shakil M. Khan CSE-2021 July-19-2012 2 ID for Load (Review) EX for Load (Review) CSE-2021 July-19-2012
CSE 2021: Computer Organization
CSE 2021: Computer Organization Lecture-11 CPU Design : Pipelining-2 Review, Hazards Shakil M. Khan IF for Load (Review) CSE-2021 July-14-2011 2 ID for Load (Review) CSE-2021 July-14-2011 3 EX for Load
Precise State Recovery. Out-of-Order Pipelines
Precise State Recovery in Out-of-Order Pipelines Nima Honarmand Recall Our Generic OOO Pipeline Instruction flow (pipeline front-end) is in-order Register and memory execution are OOO And, we need a final
EECS 470 Lecture 8. P6 µarchitecture. Fall 2018 Jon Beaumont Core 2 Microarchitecture
P6 µarchitecture Fall 2018 Jon Beaumont http://www.eecs.umich.edu/courses/eecs470 Core 2 Microarchitecture Many thanks to Prof. Martin and Roth of University of Pennsylvania for most of these slides. Portions
Pipelined Processor Design
Pipelined Processor Design COE 38 Computer Architecture Prof. Muhamed Mudawar Computer Engineering Department King Fahd University of Petroleum and Minerals Presentation Outline Pipelining versus Serial
Final Report: DBmbench
18-741 Final Report: DBmbench Yan Ke (yke@cs.cmu.edu) Justin Weisz (jweisz@cs.cmu.edu) Dec. 8, 2006 1 Introduction Conventional database benchmarks, such as the TPC-C and TPC-H, are extremely computationally
Architecture ISCA 16 Luis Ceze, Tom Wenisch
Architecture 2030 @ ISCA 16 Luis Ceze, Tom Wenisch Mark Hill (CCC liaison, mentor) LIVE! Neha Agarwal, Amrita Mazumdar, Aasheesh Kolli (Student volunteers) Context Many fantastic community formation/visioning
Supporting x86-64 Address Translation for 100s of GPU Lanes. Jason Power, Mark D. Hill, David A. Wood
Supporting x86-64 Address Translation for 100s of GPU s Jason Power, Mark D. Hill, David A. Wood Summary Challenges: CPU&GPUs physically integrated, but logically separate; This reduces theoretical bandwidth,
Overview. 1 Trends in Microprocessor Architecture. Computer architecture. Computer architecture
Overview 1 Trends in Microprocessor Architecture R05 Robert Mullins Computer architecture Scaling performance and CMOS Where have performance gains come from? Modern superscalar processors The limits of
A Static Power Model for Architects
A Static Power Model for Architects J. Adam Butts and Guri Sohi University of Wisconsin-Madison {butts,sohi}@cs.wisc.edu 33rd International Symposium on Microarchitecture Monterey, California December,
Department Computer Science and Engineering IIT Kanpur
NPTEL Online - IIT Bombay Course Name Parallel Computer Architecture Department Computer Science and Engineering IIT Kanpur Instructor Dr. Mainak Chaudhuri file:///e /parallel_com_arch/lecture1/main.html[6/13/2012
Chapter 4. Pipelining Analogy. The Processor. Pipelined laundry: overlapping execution. Parallelism improves performance. Four loads: Non-stop:
Chapter 4 The Processor Part II Pipelining Analogy Pipelined laundry: overlapping execution Parallelism improves performance Four loads: Speedup = 8/3.5 = 2.3 Non-stop: Speedup p = 2n/(0.5n + 1.5) 4 =
SATSim: A Superscalar Architecture Trace Simulator Using Interactive Animation
SATSim: A Superscalar Architecture Trace Simulator Using Interactive Animation Mark Wolff Linda Wills School of Electrical and Computer Engineering Georgia Institute of Technology {wolff,linda.wills}@ece.gatech.edu
Compiler Optimisation
Compiler Optimisation 6 Instruction Scheduling Hugh Leather IF 1.18a hleather@inf.ed.ac.uk Institute for Computing Systems Architecture School of Informatics University of Edinburgh 2018 Introduction This
Processors Processing Processors. The meta-lecture
Simulators 5SIA0 Processors Processing Processors The meta-lecture Why Simulators? Your Friend Harm Why Simulators? Harm Loves Tractors Harm Why Simulators? The outside world Unfortunately for Harm you
EECS 470. Lecture 9. MIPS R10000 Case Study. Fall 2018 Jon Beaumont
MIPS R10000 Case Study Fall 2018 Jon Beaumont http://www.eecs.umich.edu/courses/eecs470 Multiprocessor SGI Origin Using MIPS R10K Many thanks to Prof. Martin and Roth of University of Pennsylvania for
Dynamic Scheduling II
so far: dynamic scheduling (out-of-order execution) Scoreboard omasulo s algorithm register renaming: removing artificial dependences (WAR/WAW) now: out-of-order execution + precise state advanced topic:
Asanovic/Devadas Spring Pipeline Hazards. Krste Asanovic Laboratory for Computer Science M.I.T.
Pipeline Hazards Krste Asanovic Laboratory for Computer Science M.I.T. Pipelined DLX Datapath without interlocks and jumps 31 0x4 RegDst RegWrite inst Inst rs1 rs2 rd1 ws wd rd2 GPRs Imm Ext A B OpSel
7/11/2012. Single Cycle (Review) CSE 2021: Computer Organization. Multi-Cycle Implementation. Single Cycle with Jump. Pipelining Analogy
CSE 2021: Computer Organization Single Cycle (Review) Lecture-10 CPU Design : Pipelining-1 Overview, Datapath and control Shakil M. Khan CSE-2021 July-12-2012 2 Single Cycle with Jump Multi-Cycle Implementation
INTERFACING WITH INTERRUPTS AND SYNCHRONIZATION TECHNIQUES
Faculty of Engineering INTERFACING WITH INTERRUPTS AND SYNCHRONIZATION TECHNIQUES Lab 1 Prepared by Kevin Premrl & Pavel Shering ID # 20517153 20523043 3a Mechatronics Engineering June 8, 2016 1 Phase
Out-of-Order Execution. Register Renaming. Nima Honarmand
Out-of-Order Execution & Register Renaming Nima Honarmand Out-of-Order (OOO) Execution (1) Essence of OOO execution is Dynamic Scheduling Dynamic scheduling: processor hardware determines instruction execution
Instructor: Dr. Mainak Chaudhuri. Instructor: Dr. S. K. Aggarwal. Instructor: Dr. Rajat Moona
NPTEL Online - IIT Kanpur Instructor: Dr. Mainak Chaudhuri Instructor: Dr. S. K. Aggarwal Course Name: Department: Program Optimization for Multi-core Architecture Computer Science and Engineering IIT
CSE502: Computer Architecture CSE 502: Computer Architecture
CSE 502: Computer Architecture Out-of-Order Execution and Register Rename In Search of Parallelism rivial Parallelism is limited What is trivial parallelism? In-order: sequential instructions do not have
USING THE GAME BOY ADVANCE TO TEACH COMPUTER SYSTEMS AND ARCHITECTURE *
USING THE GAME BOY ADVANCE TO TEACH COMPUTER SYSTEMS AND ARCHITECTURE * Ian Finlayson Assistant Professor of Computer Science University of Mary Washington Fredericksburg, Virginia ABSTRACT This paper
Computer Science 246. Advanced Computer Architecture. Spring 2010 Harvard University. Instructor: Prof. David Brooks
Advanced Computer Architecture Spring 2010 Harvard University Instructor: Prof. dbrooks@eecs.harvard.edu Lecture Outline Instruction-Level Parallelism Scoreboarding (A.8) Instruction Level Parallelism
COTSon: Infrastructure for system-level simulation
COTSon: Infrastructure for system-level simulation Ayose Falcón, Paolo Faraboschi, Daniel Ortega HP Labs Exascale Computing Lab http://sites.google.com/site/hplabscotson MICRO-41 tutorial November 9, 28
Outline Simulators and such. What defines a simulator? What about emulation?
Outline Simulators and such Mats Brorsson & Mladen Nikitovic ICT Dept of Electronic, Computer and Software Systems (ECS) What defines a simulator? Why are simulators needed? Classifications Case studies
Performance Evaluation of Recently Proposed Cache Replacement Policies
University of Jordan Computer Engineering Department Performance Evaluation of Recently Proposed Cache Replacement Policies CPE 731: Advanced Computer Architecture Dr. Gheith Abandah Asma Abdelkarim January
CSE502: Computer Architecture CSE 502: Computer Architecture
CSE 502: Computer Architecture Out-of-Order Execution and Register Rename In Search of Parallelism rivial Parallelism is limited What is trivial parallelism? In-order: sequential instructions do not have
IF ID EX MEM WB 400 ps 225 ps 350 ps 450 ps 300 ps
CSE 30321 Computer Architecture I Fall 2010 Homework 06 Pipelined Processors 85 points Assigned: November 2, 2010 Due: November 9, 2010 PLEASE DO THE ASSIGNMENT ON THIS HANDOUT!!! Problem 1: (25 points)
Using Variable-MHz Microprocessors to Efficiently Handle Uncertainty in Real-Time Systems
Using Variable-MHz Microprocessors to Efficiently Handle Uncertainty in Real-Time Systems Eric Rotenberg Center for Embedded Systems Research (CESR) Department of Electrical & Computer Engineering North
When Electromagnetic Side Channels Meet Radio Transceivers
Screaming Channels When Electromagnetic Side Channels Meet Radio Transceivers Giovanni Camurati, Sebastian Poeplau, Marius Muench, Tom Hayes, Aurélien Francillon What s this all about? - A novel attack
High Performance Computing for Engineers
High Performance Computing for Engineers David Thomas dt10@ic.ac.uk / https://github.com/m8pple Room 903 http://cas.ee.ic.ac.uk/people/dt10/teaching/2014/hpce HPCE / dt10/ 2015 / 0.1 High Performance Computing
Combined Circuit and Microarchitecture Techniques for Effective Soft Error Robustness in SMT Processors
Combined Circuit and Microarchitecture Techniques for Effective Soft Error Robustness in SMT Processors Xin Fu, Tao Li and José Fortes Department of ECE, University of Florida xinfu@ufl.edu, taoli@ece.ufl.edu,
ΕΠΛ 605: Προχωρημένη Αρχιτεκτονική
ΕΠΛ 605: Προχωρημένη Αρχιτεκτονική Υπολογιστών Presentation of UniServer Horizon 2020 European project findings: X-Gene server chips, voltage-noise characterization, high-bandwidth voltage measurements,
Freeway: Maximizing MLP for Slice-Out-of-Order Execution
Freeway: Maximizing MLP for Slice-Out-of-Order Execution Rakesh Kumar Norwegian University of Science and Technology (NTNU) rakesh.kumar@ntnu.no Mehdi Alipour, David Black-Schaffer Uppsala University {mehdi.alipour,
Warp-Aware Trace Scheduling for GPUS. James Jablin (Brown) Thomas Jablin (UIUC) Onur Mutlu (CMU) Maurice Herlihy (Brown)
Warp-Aware Trace Scheduling for GPUS James Jablin (Brown) Thomas Jablin (UIUC) Onur Mutlu (CMU) Maurice Herlihy (Brown) Historical Trends in GFLOPS: CPUs vs. GPUs Theoretical GFLOP/s 3250 3000 2750 2500
Recent Advances in Simulation Techniques and Tools
Recent Advances in Simulation Techniques and Tools Yuyang Li, li.yuyang(at)wustl.edu (A paper written under the guidance of Prof. Raj Jain) Download Abstract: Simulation refers to using specified kind
TDD Making sure everything works. Agile Transformation Summit May, 2015
TDD Making sure everything works Agile Transformation Summit May, 2015 My name is Santiago L. Valdarrama (I don t play soccer. I m not related to the famous Colombian soccer player.) I m an Engineer Manager
Lecture Topics. Announcements. Today: Pipelined Processors (P&H ) Next: continued. Milestone #4 (due 2/23) Milestone #5 (due 3/2)
Lecture Topics Today: Pipelined Processors (P&H 4.5-4.10) Next: continued 1 Announcements Milestone #4 (due 2/23) Milestone #5 (due 3/2) 2 1 ISA Implementations Three different strategies: single-cycle
CMP 301B Computer Architecture. Appendix C
CMP 301B Computer Architecture Appendix C Dealing with Exceptions What should be done when an exception arises and many instructions are in the pipeline??!! Force a trap instruction in the next IF stage
CSE502: Computer Architecture CSE 502: Computer Architecture
CSE 502: Computer Architecture Speculation and raps in Out-of-Order Cores What is wrong with omasulo s? Branch instructions Need branch prediction to guess what to fetch next Need speculative execution
How different FPGA firmware options enable digitizer platforms to address and facilitate multiple applications
How different FPGA firmware options enable digitizer platforms to address and facilitate multiple applications 1 st of April 2019 Marc.Stackler@Teledyne.com March 19 1 Digitizer definition and application
Parallel Programming Design of BPSK Signal Demodulation Based on CUDA
Int. J. Communications, Network and System Sciences, 216, 9, 126-134 Published Online May 216 in SciRes. http://www.scirp.org/journal/ijcns http://dx.doi.org/1.4236/ijcns.216.9511 Parallel Programming
Memory-Level Parallelism Aware Fetch Policies for Simultaneous Multithreading Processors
Memory-Level Parallelism Aware Fetch Policies for Simultaneous Multithreading Processors STIJN EYERMAN and LIEVEN EECKHOUT Ghent University A thread executing on a simultaneous multithreading (SMT) processor
Issue. Execute. Finish
Specula1on & Precise Interrupts Fall 2017 Prof. Ron Dreslinski h6p://www.eecs.umich.edu/courses/eecs470 In Order Out of Order In Order Issue Execute Finish Fetch Decode Dispatch Complete Retire Instruction/Decode
Multiple Predictors: BTB + Branch Direction Predictors
Constructive Computer Architecture: Branch Prediction: Direction Predictors Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology October 28, 2015 http://csg.csail.mit.edu/6.175
EECS 470 Lecture 5. Intro to Dynamic Scheduling (Scoreboarding) Fall 2018 Jon Beaumont
Intro to Dynamic Scheduling (Scoreboarding) Fall 2018 Jon Beaumont http://www.eecs.umich.edu/courses/eecs470 Many thanks to Prof. Martin and Roth of University of Pennsylvania for most of these slides.
Improving GPU Performance via Large Warps and Two-Level Warp Scheduling
Improving GPU Performance via Large Warps and Two-Level Warp Scheduling Veynu Narasiman The University of Texas at Austin Michael Shebanow NVIDIA Chang Joo Lee Intel Rustam Miftakhutdinov The University
SW simulation and Performance Analysis
SW simulation and Performance Analysis In Multi-Processing Embedded Systems Eugenio Villar University of Cantabria Context HW/SW Embedded Systems Design Flow HW/SW Simulation Performance Analysis Design
DASH: Deadline-Aware High-Performance Memory Scheduler for Heterogeneous Systems with Hardware Accelerators
DASH: Deadline-Aware High-Performance Memory Scheduler for Heterogeneous Systems with Hardware Accelerators Hiroyuki Usui, Lavanya Subramanian Kevin Chang, Onur Mutlu DASH source code is available at GitHub
Setting up a Digital Darkroom A guide
Setting up a Digital Darkroom A guide http://www.theuniversody.co.uk Planning / Theory Considerations: What does the facility need to be capable of? Downloading images from digital cameras, (in all Raw
Software Engineering Design & Construction
Winter Semester 16/17 Software Engineering Design & Construction Dr. Michael Eichberg Fachgebiet Softwaretechnik Technische Universität Darmstadt Introduction - Software Engineering Software Engineering
SCALCORE: DESIGNING A CORE
SCALCORE: DESIGNING A CORE FOR VOLTAGE SCALABILITY Bhargava Gopireddy, Choungki Song, Josep Torrellas, Nam Sung Kim, Aditya Agrawal, Asit Mishra University of Illinois, University of Wisconsin, Nvidia,
Dynamic Scheduling I
basic pipeline started with single, in-order issue, single-cycle operations have extended this basic pipeline with multi-cycle operations multiple issue (superscalar) now: dynamic scheduling (out-of-order
RS-485 Transmit Enable Signal Control Nigel Jones
RMB Consulting Where innovation and execution go hand in hand RS-485 Transmit Enable Signal Control Nigel Jones Quite a few embedded systems include multiple processors. Sometimes these processors stand
Blackfin Online Learning & Development
Presentation Title: Introduction to VisualDSP++ Tools Presenter Name: Nicole Wright Chapter 1:Introduction 1a:Module Description 1b:CROSSCORE Products Chapter 2: ADSP-BF537 EZ-KIT Lite Configuration 2a:
Lecture 4: Introduction to Pipelining
Lecture 4: Introduction to Pipelining Pipelining Laundry Example Ann, Brian, Cathy, Dave each have one load of clothes to wash, dry, and fold Washer takes 30 minutes A B C D Dryer takes 40 minutes Folder
Automated Software Engineering Writing Code to Help You Write Code. Gregory Gay CSCE Computing in the Modern World October 27, 2015
Automated Software Engineering Writing Code to Help You Write Code Gregory Gay CSCE 190 - Computing in the Modern World October 27, 2015 Software Engineering The development and evolution of high-quality
Parallelism Across the Curriculum
Parallelism Across the Curriculum John E. Howland Department of Computer Science Trinity University One Trinity Place San Antonio, Texas 78212-7200 Voice: (210) 999-7364 Fax: (210) 999-7477 E-mail: jhowland@trinity.edu
Chapter 16 - Instruction-Level Parallelism and Superscalar Processors
Chapter 16 - Instruction-Level Parallelism and Superscalar Processors Luis Tarrataca luis.tarrataca@gmail.com CEFET-RJ L. Tarrataca Chapter 16 - Superscalar Processors 1 / 78 Table of Contents I 1 Overview
Pre-Silicon Validation of Hyper-Threading Technology
Pre-Silicon Validation of Hyper-Threading Technology David Burns, Desktop Platforms Group, Intel Corp. Index words: microprocessor, validation, bugs, verification ABSTRACT Hyper-Threading Technology delivers
Improving Loop-Gain Performance In Digital Power Supplies With Latest- Generation DSCs
ISSUE: March 2016 Improving Loop-Gain Performance In Digital Power Supplies With Latest- Generation DSCs by Alex Dumais, Microchip Technology, Chandler, Ariz. With the consistent push for higher-performance
CS/ENGRD 2110 Object-Oriented Programming and Data Structures Spring 2012 Thorsten Joachims. Lecture 17: Heaps and Priority Queues
CS/ENGRD 2110 Object-Oriented Programming and Data Structures Spring 2012 Thorsten Joachims Lecture 17: Heaps and Priority Queues Stacks and Queues as Lists Stack (LIFO) implemented as list insert (i.e.
EECS 473 Final Exam. Fall 2017 NOTES: I have neither given nor received aid on this exam nor observed anyone else doing so. Name: unique name:
EECS 473 Final Exam Fall 2017 Name: unique name: Sign the honor code: I have neither given nor received aid on this exam nor observed anyone else doing so. NOTES: 1. Closed book and Closed notes 2. Do
Computer Architecture
Computer Architecture Lecture 01 Arkaprava Basu www.csa.iisc.ac.in Acknowledgements Several of the slides in the deck are from Luis Ceze (Washington), Nima Horanmand (Stony Brook), Mark Hill, David Wood,
Why (Special Agent) Johnny (Still) Can t Encrypt: A Security Analysis of the APCO Project 25 Two-Way Radio System
Why (Special Agent) Johnny (Still) Can t Encrypt: A Security Analysis of the APCO Project 25 Two-Way Radio System Sandy Clark Travis Goodspeed Perry Metzger Zachary Wasserman Kevin Xu Matt Blaze Usenix
From Model to Application: Developing a believable opponent in the game of Set!
From Model to Application: Developing a believable opponent in the game of Set! Niels Taatgen,, Marcia van Oploo, Jos Braaksma and Jelle Niemantsverdriet Contents The Game The Predictions The Experiment
Mitigating Inductive Noise in SMT Processors
Mitigating Inductive Noise in SMT Processors Wael El-Essawy and David H. Albonesi Department of Electrical and Computer Engineering, University of Rochester ABSTRACT Simultaneous Multi-Threading, although
ECE473 Computer Architecture and Organization. Pipeline: Introduction
Computer Architecture and Organization Pipeline: Introduction Lecturer: Prof. Yifeng Zhu Fall, 2015 Portions of these slides are derived from: Dave Patterson UCB Lec 11.1 The Laundry Analogy Student A,
Analysis of Dynamic Power Management on Multi-Core Processors
Analysis of Dynamic Power Management on Multi-Core Processors W. Lloyd Bircher and Lizy K. John Laboratory for Computer Architecture Department of Electrical and Computer Engineering The University of
Performance Metrics. CS356 Unit 8. The Memory Wall. Options for Improving Performance. Memory. Latency: Total time for a to complete
7 7 Performance Metrics CS56 Unit 8 Memory Latency: Total time for a to complete Often hard to improve dramatically Example: Takes roughly 4 years to get your bachelor's degree From perspective of an Throughput/Bandwidth:
ACCELERATE SOFTWARE DEVELOPMENT WITH CONTINUOUS INTEGRATION AND SIMULATION
ACCELERATE SOFTWARE DEVELOPMENT WITH CONTINUOUS INTEGRATION AND SIMULATION A How-to Guide for Embedded Development WHEN IT MATTERS, IT RUNS ON WIND RIVER EXECUTIVE SUMMARY Adopting the practice of Continuous
ESE 350 HEXAWall v 2.0 Michelle Adjangba Omari Maxwell
ESE 350 HEXAWall v 2.0 Michelle Adjangba Omari Maxwell Abstract This project is a continuation from the HEXA interactive wall display done in ESE 350 last spring. Professor Mangharam wants us to take this
An architecture for Scalable Concurrent Embedded Software" No more communication in your program, the key to multi-core and distributed programming.
An architecture for Scalable Concurrent Embedded Software" No more communication in your program, the key to multi-core and distributed programming. Eric.Verhulst@altreonic.com www.altreonic.com 1 Content
CS 110 Computer Architecture Lecture 11: Pipelining
CS 110 Computer Architecture Lecture 11: Pipelining Instructor: Sören Schwertfeger http://shtech.org/courses/ca/ School of Information Science and Technology SIST ShanghaiTech University Slides based on
January 11, 2017 Administrative notes
January 11, 2017 Administrative notes Clickers Updated on Canvas as of people registered yesterday night. REEF/iClicker mobile is not working for everyone. Use at your own risk. If you are having trouble
10. BSY-1 Trainer Case Study
10. BSY-1 Trainer Case Study This case study is interesting for several reasons: RMS is not used, yet the system is analyzable using RMA obvious solutions would not have helped RMA correctly diagnosed
Incidents Elie Bursztein and Jean Goubault Larrecq
A Logical Framework for Anticipation of Network Incidents and Jean Goubault Larrecq PhdStudent LSV ENS CACHAN CNRS INRIA DGA Outline Introduction Network Evolution Attack Model Evolution Anticipation game
אני יודע מה עשית בפענוח האחרון: התקפות ערוצי צד על מחשבים אישיים
אני יודע מה עשית בפענוח האחרון: התקפות ערוצי צד על מחשבים אישיים I Know What You Did Last Decryption: Side Channel Attacks on PCs Lev Pachmanov Tel Aviv University Daniel Genkin Technion and Tel Aviv University
Track and Vertex Reconstruction on GPUs for the Mu3e Experiment
Track and Vertex Reconstruction on GPUs for the Mu3e Experiment Dorothea vom Bruch for the Mu3e Collaboration GPU Computing in High Energy Physics, Pisa September 11th, 2014 Physikalisches Institut Heidelberg
Disclosing Self-Injury
Disclosing Self-Injury 2009 Pandora s Project By: Katy For the vast majority of people, talking about self-injury for the first time is a very scary prospect. I m sure, like me, you have all imagined the
8-bit Microcontroller with 512/1024 Bytes In-System Programmable Flash. ATtiny4/5/9/10
Features High Performance, Low Power AVR 8-Bit Microcontroller Advanced RISC Architecture 54 Powerful Instructions Most Single Clock Cycle Execution 16 x 8 General Purpose Working Registers Fully Static
AGENTLESS ARCHITECTURE
ansible.com +1 919.667.9958 WHITEPAPER THE BENEFITS OF AGENTLESS ARCHITECTURE A management tool should not impose additional demands on one s environment in fact, one should have to think about it as little
A Case for Opportunistic Embedded Sensing In Presence of Hardware Power Variability
A Case for Opportunistic Embedded Sensing In Presence of Hardware Power Variability L. Wanner, C. Apte, R. Balani, Puneet Gupta, and Mani Srivastava University of California, Los Angeles puneet@ee.ucla.edu
The adventures of a Suricate in ebpf land
The adventures of a Suricate in ebpf land É. Leblond Stamus Networks Nov. 10, 2016 É. Leblond (Stamus Networks) The adventures of a Suricate in ebpf land Nov. 10, 2016 1 / 34 1 ebpf technology 2 Suricata
System Level Analysis of Fast, Per-Core DVFS using On-Chip Switching Regulators
System Level Analysis of Fast, Per-Core DVFS using On-Chip Switching s Wonyoung Kim, Meeta S. Gupta, Gu-Yeon Wei and David Brooks School of Engineering and Applied Sciences, Harvard University, 33 Oxford
OOO Execution & Precise State MIPS R10000 (R10K)
OOO Execution & Precise State in MIPS R10000 (R10K) Nima Honarmand CDB. CDB.V Spring 2018 :: CSE 502 he Problem with P6 Map able + Regfile value R value Head Retire Dispatch op RS 1 2 V1 FU V2 ail Dispatch
The Advancement of Simulator Models
The Advancement of Simulator Models How the Evolution of Simulator Technology has Impacted its Application Michael M. Petersen Xcel Energy The Age of Simulation Simulation is the imitation of the operation
IF ID EX MEM WB 400 ps 225 ps 350 ps 450 ps 300 ps
CSE 30321 Computer Architecture I Fall 2011 Homework 06 Pipelined Processors 75 points Assigned: November 1, 2011 Due: November 8, 2011 PLEASE DO THE ASSIGNMENT ON THIS HANDOUT!!! Problem 1: (15 points)
Benchmarking C++ From video games to algorithmic trading. Alexander Radchenko
Benchmarking C++ From video games to algorithmic trading Alexander Radchenko Quiz. How long it takes to run? 3.5GHz Xeon at CentOS 7 Write your name Write your guess as a single number Write time units
Real Time Operating Systems Lecture 29.1
Real Time Operating Systems Lecture 29.1 EE345M Final Exam study guide (Spring 2014): Final is both a closed and open book exam. During the closed book part you can have a pencil, pen and eraser. During
Instruction Level Parallelism Part II - Scoreboard
Course on: Advanced Computer Architectures Instruction Level Parallelism Part II - Scoreboard Prof. Cristina Silvano Politecnico di Milano email: cristina.silvano@polimi.it 1 Basic Assumptions We consider