www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OT: Evidence of A Intel Virtual Memory Vulnerability

reply Jack Stouffer <jack jackstouffer.com> writes:
The gist of the story is that an Intel vulnerability is requiring 
OS vendors to institute Page Table Isolation in their kernels. 
This fix has an _across the board_ 5-7% slowdown on Intel chips.

Worse yet, programs which do lots of syscalls will see around a 
30% slowdown or more, including compilation.

AMD is not effected.

Details and discussion:
Reddit: 
https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
HN: https://news.ycombinator.com/item?id=16046636
Jan 03 2018
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 3 January 2018 at 15:51:35 UTC, Jack Stouffer wrote:

 The gist of the story is that an Intel vulnerability is 
 requiring OS vendors to institute Page Table Isolation in their 
 kernels. This fix has an _across the board_ 5-7% slowdown on 
 Intel chips.

 Worse yet, programs which do lots of syscalls will see around a 
 30% slowdown or more, including compilation.

 AMD is not effected.

 Details and discussion:
 Reddit: 
 https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
 HN: https://news.ycombinator.com/item?id=16046636


Attack details published by Google Project Zero with official 
names https://meltdownattack.com
Jan 03 2018
parent Uknown <sireeshkodali1 gmail.com> writes:
On Thursday, 4 January 2018 at 00:55:45 UTC, Jack Stouffer wrote:

 On Wednesday, 3 January 2018 at 15:51:35 UTC, Jack Stouffer 
 wrote:

 The gist of the story is that an Intel vulnerability is 
 requiring OS vendors to institute Page Table Isolation in 
 their kernels. This fix has an _across the board_ 5-7% 
 slowdown on Intel chips.

 Worse yet, programs which do lots of syscalls will see around 
 a 30% slowdown or more, including compilation.

 AMD is not effected.

 Details and discussion:
 Reddit: 
 https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
 HN: https://news.ycombinator.com/item?id=16046636


 Attack details published by Google Project Zero with official 
 names https://meltdownattack.com


https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test

The linux kernel is not trusting even AMD chips. Supposedly even 
ARM is affected
Jan 03 2018
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 1/3/2018 7:51 AM, Jack Stouffer via Digitalmars-d wrote:

 The gist of the story is that an Intel vulnerability is requiring OS 
 vendors to institute Page Table Isolation in their kernels. This fix has 
 an _across the board_ 5-7% slowdown on Intel chips.
 
 Worse yet, programs which do lots of syscalls will see around a 30% 
 slowdown or more, including compilation.
 
 AMD is not effected.
 
 Details and discussion:
 Reddit: 
 https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
 HN: https://news.ycombinator.com/item?id=16046636


Calling it a vendor or architecture specific issue is a bit misleading, 
based on the reading I did today.  There's a couple different 
vulnerabilities here and they tie back to speculative (ie out of order) 
execution, timing of branch prediction, and timing of various 
conditions.  These techniques are _widely_ used among high speed 
processors and any that use them are likely to be vulnerable when an 
adversary can control and time execution of code and data in caches. 
The same basic techniques have shown up in a number of recent exploits, 
for example some of those in SSL and TLS over the last few years.

It's very interesting research and I fully expect more of this sort of 
issue as more and more research is done.
Jan 03 2018
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 4 January 2018 at 02:06:04 UTC, Brad Roberts wrote:

 Calling it a vendor or architecture specific issue is a bit 
 misleading, based on the reading I did today.


In my defense, when I posted this all people had to go off of 
where the linux git patches. I assume the announcement was 
release when it was is because the reddit post linked made it to 
the front page, which forced their hand.
Jan 05 2018
parent Joakim <dlang joakim.fea.st> writes:
On Friday, 5 January 2018 at 21:04:16 UTC, Jack Stouffer wrote:

 On Thursday, 4 January 2018 at 02:06:04 UTC, Brad Roberts wrote:

 Calling it a vendor or architecture specific issue is a bit 
 misleading, based on the reading I did today.


 In my defense, when I posted this all people had to go off of 
 where the linux git patches. I assume the announcement was 
 release when it was is because the reddit post linked made it 
 to the front page, which forced their hand.


Yes, the linux patches caused a lot of speculation so they pushed 
up the release from next week:

https://www.anandtech.com/show/12214/understanding-meltdown-and-spectre
Jan 05 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 04, 2018 at 12:55:45AM +0000, Jack Stouffer via Digitalmars-d wrote:
[...]

 Attack details published by Google Project Zero with official names
 https://meltdownattack.com


On Wed, Jan 03, 2018 at 06:06:04PM -0800, Brad Roberts via Digitalmars-d wrote:
[...]

 Calling it a vendor or architecture specific issue is a bit
 misleading, based on the reading I did today.  There's a couple
 different vulnerabilities here and they tie back to speculative (ie
 out of order) execution, timing of branch prediction, and timing of
 various conditions.  These techniques are _widely_ used among high
 speed processors and any that use them are likely to be vulnerable
 when an adversary can control and time execution of code and data in
 caches. The same basic techniques have shown up in a number of recent
 exploits, for example some of those in SSL and TLS over the last few
 years.
 
 It's very interesting research and I fully expect more of this sort of
 issue as more and more research is done.


I just read both the Meltdown paper and the Spectre paper.  This is
indeed extremely interesting research!  To quote from the Spectre paper:

	"While physical side channel attacks can be used to extract
	secret information from complex devices such as PCs and mobile
	phones, these devices face additional threats that do not
	require external measurement equipment because they execute code
	from potentially unknown origins."

This resonates with my continued reservation about remote code execution
technologies like Javascript, or anything, really, that involves
automatically executing Turing-complete code from an unknown source.
Unfortunately, it seems that this is the direction modern software has
been moving in, and it seems that the general populace has become
dependent on this kind of technology.  It will be very interesting, to
say the least, to see where all this leads.

My tl;dr summary of Meltdown and Spectre:

- Meltdown: out-of-order instruction execution enables the results of an
  illegal memory access to affect a side-channel (the concrete example
  is the CPU cache) in a measurable way before the CPU raises an error,
  sucht that memory contents that the code doesn't have permission to
  read are leaked out.

- Spectre: speculative execution of mispredicted branches, induced by an
  attacker, enables the results of code that isn't actually branched to,
  to produce a measurable effect on a side-channel (again, the concrete
  example is the CPU cache, but could be any other measurable
  side-channel), thus allowing an attacker to read data accessed by
  instructions that supposedly aren't even supposed to execute.


My code summary of Meltdown:

	ulong addr = kernelAddressMappedIntoUserSpace;
	ubyte b = *addr;	// causes segfault
	auto tmp = buf[b * 4096]; // produces cache effect before segfault happens
	...

	// In another process: extract the value of b, i.e., read from
	// kernel memory bypassing read permissions.
	auto b = measureCacheTimings();


My code summary of Spectre:

	/*
	 * Victim process:
	 */
	int i = userParameter;
	ubyte[] buf;
	if (i < buf.length) {
		// If branch was mispredicted, causes transient
		// out-of-bounds access that has measurable cache effect
		// before code effects are reverted by CPU
		auto r = result[buf[i] * 4096];
		...
	}

	/*
	 * Attacker process (assumed to be able to influence value of
	 * userParameter in victim process):
	 */

	// Mistrain CPU branch predictor to expect i < buf.length.
	foreach (_; 0 .. 1_000_000) {
		// induce victim process to run with userParameter == 1
		induceUserParameter(1);
	}

	// Force eviction of buf.length from CPU cache to ensure branch
	// misprediction in the victim process.
	accessManyMemoryLocations();

	// Induce victim process to run with out of bounds userParameter
	// == 10000.
	induceUserParameter(10000);

	// Extract value of out-of-bounds buf[10000], i.e., read from
	// arbitrary memory location.
	auto b = measureCacheTimings();


And best of all, both attacks target modern CPU hardware, and do not
need any exploitable flaws in the software.


T

-- 
When solving a problem, take care that you do not become part of the problem.
Jan 04 2018