Date: Thu, 4 Jan 2018 12:06:22 -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: <13341e69-a8f5-253d-ccb8-e2c14d2322f9@metricspace.net> In-Reply-To: <ae3298c9-d4f2-83a4-5fbf-52dbb1a49aa0@metricspace.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> <ae3298c9-d4f2-83a4-5fbf-52dbb1a49aa0@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/04/2018 12:03, Eric McCorkle wrote: > You could block meltdown, I suppose, by making the entire > kernel address space absolutely forbidden under penalty of an > uncatchable signal. Actually, scratch that; it doesn't work. The caches are still affected, and could be measured by another core. I suppose you could attempt to flush them upon killing a process in this way, but you still have a window, so it's only a probabilistic defense.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13341e69-a8f5-253d-ccb8-e2c14d2322f9>