Date: Sat, 6 Jan 2018 09:31:42 -0700 From: Warner Losh <imp@bsdimp.com> To: Eric McCorkle <eric@metricspace.net> Cc: Wojciech Puchar <wojtek@puchar.net>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure Message-ID: <CANCZdfqZnZhKXD3SKgyro%2BYLX7j5BYrmCZ7xEGwYY6AWkQpKzg@mail.gmail.com> In-Reply-To: <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> References: <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net> <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <alpine.BSF.2.20.1801061701200.40627@puchar.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 6, 2018 at 9:12 AM, Eric McCorkle <eric@metricspace.net> wrote: > On 01/06/2018 11:07, Wojciech Puchar wrote: > > sorry for stupid question but for my understanding these attacks works > > as below: > > > > 1) perform access to byte not allowed virtual address and use next > > instruction to store relative to private space so cache is filled > > depending on value that one shouldn't be able to access. > > > > 2) as kernel get trap on access violation it will generate SIGSEGV or > > SIGBUS which is directed by application using signal(2) so it can be > > ignored. > > > > 3) other part of code perform some timing magic and detects this way > > where cache is filled - so byte value can be guessed properly. > > > > > > My question is - why simply any access attempts to kernel space cannot > > generate SIGKILL? Of course it would harm program development, but as > > today developers doesn't usually use timesharing machine but have > > private computers, simple sysctl variable would suffice. > > I'd thought of this myself. The problem is that the cache effects could > still be observed by another process. > > While is doesn't defeat the attack, tt does still complicate attacks, so > I think it's worth considering. The problem is that the attempts to access kernel space are speculative. There's no way to get the 'speculative trap' that would have been generated had the code actually executed. There literally is no signal to the kernel this just happened. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqZnZhKXD3SKgyro%2BYLX7j5BYrmCZ7xEGwYY6AWkQpKzg>