Date: Thu, 4 Jan 2018 12:03:32 -0500 From: Eric McCorkle <eric@metricspace.net> To: Brett Glass <brett@lariat.org>, =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= <des@des.no>, Erich Dollansky <freebsd.ed.lists@sumeritec.com> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, "Ronald F. Guilmette" <rfg@tristatelogic.com> Subject: Re: Intel hardware bug Message-ID: <ae3298c9-d4f2-83a4-5fbf-52dbb1a49aa0@metricspace.net> In-Reply-To: <201801041621.JAA17566@mail.lariat.net> References: <02563ce4-437c-ab96-54bb-a8b591900ba0@FreeBSD.org> <19876.1515025752@segfault.tristatelogic.com> <20180104132807.266fe46c.freebsd.ed.lists@sumeritec.com> <86vaghu0ps.fsf@desk.des.no> <201801041552.IAA17267@mail.lariat.net> <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <201801041621.JAA17566@mail.lariat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/04/2018 11:21, Brett Glass wrote: > At 09:03 AM 1/4/2018, Eric McCorkle wrote: > >> The attack looks like this: >> >> 1) Fetch kernel/other process memory, which eventually faults >> 2) Do a bit-shift/mask operation to pluck out one bit of the fetched >> value. This gets executed speculatively on the fetched value in (1). >> 3) Execute fetches of two different addresses depending on some bit in >> the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This >> also gets executed speculatively despite the fact that (1) ends up >> faulting. >> 4) Recover from fault in (1) >> 5) Measure performance of accesses to the two addresses to determine >> which one is cached. > > Hmmmm. The obvious way to combat this would be to make this class of fault > fatal rather than allowing recovery to occur. Of course, this would > reveal errors > in sloppy code, which some developers would not like. (I recall how much > some > folks squawked back in the olden days, when segmentation faults - remember > segments? - revealed bugs in their code. I, personally, liked segmentation > because I was a perfectionist.... I wanted my code to crash dramatically if > there was an error so I could fix it.) > That breaks the entire way that page faults and virtual memory works, though. You could block meltdown, I suppose, by making the entire kernel address space absolutely forbidden under penalty of an uncatchable signal. This won't stop spectre (same attack against another process' pages), or a similar attack within the same address space (say, to break out of some kind of intra-process isolation).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ae3298c9-d4f2-83a4-5fbf-52dbb1a49aa0>