From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 19 Nov 2019 18:28:05 -0000 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120] helo=us-smtp-1.mimecast.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iX8EN-0000pY-OQ for speck@linutronix.de; Tue, 19 Nov 2019 19:28:04 +0100 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4E33B109545F for ; Tue, 19 Nov 2019 18:27:55 +0000 (UTC) Received: from treble (ovpn-124-31.rdu2.redhat.com [10.10.124.31]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EF7FD627DE for ; Tue, 19 Nov 2019 18:27:54 +0000 (UTC) Date: Tue, 19 Nov 2019 12:27:52 -0600 From: Josh Poimboeuf Subject: [MODERATED] Re: LVI Message-ID: <20191119182752.xh5e6x733nnhjwo5@treble> References: <20191119174008.7dbymix2eo4mrv57@treble> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" To: speck@linutronix.de List-ID: Content-Transfer-Encoding: 8bit On Tue, Nov 19, 2019 at 05:51:40PM +0000, speck for Andrew Cooper wrote: > On 19/11/2019 17:40, speck for Josh Poimboeuf wrote: > > Hi, > > > > What kernel changes (if any) are needed for LVI? I haven't seen any > > discussion here. > > I have similar questions when it comes to virt.  For one, EPT A/D bits > undermine any action the guest kernel takes to protect itself. > > Given various pieces of academic literature on gaming the paging-out > algorithm, I'm not inclined to take the bet that an attacker couldn't > control EPT A/D bits to their advantage. Hm, so IIUC, that would open up every load in the guest to a potential attack, if it has gadgets after it? That does sound bad... If the A/D bit control is feasible then it sounds like we'd need an L1TF-like flushing mitigation after vmexit? That would protect the host kernel too. For L1TF-affected systems would it be feasible to move the vmenter flushing to vmexit? Or would we need both? -- Josh