Intel hardware bug

[Eric McCorkle]

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).