From owner-freebsd-arch@freebsd.org Sat Jan 6 05:28:10 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9056DEBC597; Sat, 6 Jan 2018 05:28:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 56F3274F06; Sat, 6 Jan 2018 05:28:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6235F8BCD; Sat, 6 Jan 2018 05:28:09 +0000 (UTC) Subject: Re: A more general possible meltdown/spectre countermeasure To: Nathan Dautenhahn Cc: Warner Losh , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> From: Eric McCorkle Message-ID: Date: Sat, 6 Jan 2018 00:28:08 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 05:28:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V9KkvxoWVZPOhkSqZbg4YYxT3k6ucNyKb Content-Type: multipart/mixed; boundary="VvDKQxWj1LBLDsO8kW6mDydav7SWPi8CE"; protected-headers="v1" From: Eric McCorkle To: Nathan Dautenhahn Cc: Warner Losh , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Message-ID: Subject: Re: A more general possible meltdown/spectre countermeasure References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <4ec1f3b1-f4b0-80ab-0e68-0dd679dd9e37@metricspace.net> <72f6097e-c71e-b53f-6885-cfe5a5a56586@metricspace.net> <9268C1F8-AD68-4B20-94D7-96B5FD6589B5@metricspace.net> In-Reply-To: --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--