A more general possible meltdown/spectre countermeasure

[Eric McCorkle]

On 01/05/2018 23:32, Nathan Dautenhahn wrote:

> Another solution, which would handle the more complex attack above, (I
> know I'm piggybacking, not sure if that's bad) could be to partition a
> subset of the kernel address space for secrets, and then map those in
> only when needed, and flush out when done. I did some work a while
> back on page table isolation and protection from potentially malicious
> OSs called the nested kernel. I haven't reviewed these new
> side-channel attacks in great detail yet, but I'm currently working on
> pushing fine grained intra-address space isolation that might be a
> nice solution for easily managing and subsets of kernel data.
> 
> The paper and associated code etc. is all linked on nestedkernel.org.
> I think these attacks really motivate the nested kernel approach,
> although we didn't consider secret protection from side-channels.

This sounds more or less like what I had in mind: carve out some special
 region of kernel space for sensitive information.  Ideally, this could
be swapped out with an API for storing sensitive data in a secure device
(TPM, smart card, etc).

However, discussions of this approach over on the RISC-V lists suggest
that Intel apparently does some rather crazy things that end up
thwarting my proposed countermeasure.  (Apparently, they don't
acknowledge faults until the faulting instruction *commits*, which means
any number of transients could have followed)  I'll probably still put a
PoC together, but I fear it may not work on Intel.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20180106/d2aeacef/attachment.sig>