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). _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
