Date: Sat, 6 Jan 2018 00:28:08 -0500 From: Eric McCorkle <eric@metricspace.net> To: Nathan Dautenhahn <ndd@cis.upenn.edu> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: A more general possible meltdown/spectre countermeasure Message-ID: <fa86303f-8fd0-e830-523f-94a55aba71ee@metricspace.net> In-Reply-To: <CAPzS-cK0A4EmQR18cCje%2BS8jppNFBC-FAvTQE6LC_prYvKjAyw@mail.gmail.com> References: <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net> <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <CANCZdfq2iHErm-pPU1cQ35zrvfdVFPBi1sKYshOyyWUgm3VHBA@mail.gmail.com> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <CANCZdfo2MPbYxrOyuwSO82FAx9ur_kxgwUijoZCaRL2MDxFxFQ@mail.gmail.com> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> <CANCZdfoYY5ACwbT0gUW-u=%2BHyG-Y2McoN%2B%2BNZZvqED=wU5MEUA@mail.gmail.com> <b4f8b84c-88f4-0b03-40c8-7fa07a496e26@metricspace.net> <CANCZdfq8UZWXdd9fc3yDTETPrCOYYojKyAzyjywrkG=d8OA6Jg@mail.gmail.com> <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> <CAPzS-cK0A4EmQR18cCje%2BS8jppNFBC-FAvTQE6LC_prYvKjAyw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb Content-Type: multipart/mixed; boundary="VvDKQxWj1LBLDsO8kW6mDydav7SWPi8CE"; protected-headers="v1" From: Eric McCorkle <eric@metricspace.net> To: Nathan Dautenhahn <ndd@cis.upenn.edu> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Message-ID: <fa86303f-8fd0-e830-523f-94a55aba71ee@metricspace.net> Subject: Re: A more general possible meltdown/spectre countermeasure References: <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net> <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <CANCZdfq2iHErm-pPU1cQ35zrvfdVFPBi1sKYshOyyWUgm3VHBA@mail.gmail.com> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <CANCZdfo2MPbYxrOyuwSO82FAx9ur_kxgwUijoZCaRL2MDxFxFQ@mail.gmail.com> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> <CANCZdfoYY5ACwbT0gUW-u=+HyG-Y2McoN++NZZvqED=wU5MEUA@mail.gmail.com> <b4f8b84c-88f4-0b03-40c8-7fa07a496e26@metricspace.net> <CANCZdfq8UZWXdd9fc3yDTETPrCOYYojKyAzyjywrkG=d8OA6Jg@mail.gmail.com> <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> <CAPzS-cK0A4EmQR18cCje+S8jppNFBC-FAvTQE6LC_prYvKjAyw@mail.gmail.com> In-Reply-To: <CAPzS-cK0A4EmQR18cCje+S8jppNFBC-FAvTQE6LC_prYvKjAyw@mail.gmail.com> --VvDKQxWj1LBLDsO8kW6mDydav7SWPi8CE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. --VvDKQxWj1LBLDsO8kW6mDydav7SWPi8CE-- --V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iIsEARYIADMWIQTp6hWnRH4nHb9/QN/kI/o6qzq6mAUCWlBeaBUcZXJpY0BtZXRy aWNzcGFjZS5uZXQACgkQ5CP6Oqs6upjzSwEA70zkEBdc+WWD+OWW3GqXtw8rTZPs 3wEP+wuiThvhsoQBAKVcbCgztidemCIOCnlMO8QEyeZnG7v9YBjSnoeXeowN =czOH -----END PGP SIGNATURE----- --V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fa86303f-8fd0-e830-523f-94a55aba71ee>