Fwd: A more general possible meltdown/spectre countermeasure

[Warner Losh]

On Sat, Jan 6, 2018 at 9:12 AM, Eric McCorkle <eric at 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