From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225RD2ei1InXCGgI6pNhEhQkums985nZyyuHELAsNhrFCBfIfhGhv1bfM9tpIYwTcpMFbDWq ARC-Seal: i=1; a=rsa-sha256; t=1516565990; cv=none; d=google.com; s=arc-20160816; b=LTclQWYNhG7CLE49VF/V9eEoZhfP1iXkrLuVfGedp4+yX1+nKkiitSFFjVr7w2e7mM R2Epv0u57G5kPG5TK+23l9XyRSx2TF8K1fnsknMcmahvcAQSYgTp3/+Xkuq7atBx6Q4X 3J3VuULveF/N+i0+b1czxpzVv9zNrv/TyVg8QkfKvW5+cDw2/4F2CBJS784jAVMlvNe2 f1nI1JnbpkoZPmdnsFzfezmV/RneBWRrYG+l3ULL+eQ3JziI4qgpdt5SLSE3zaWC/80K 0flXrAUMuvWq7Np6R1dFYx3dKt6beFWbhUtbHyPH4yaizHs2KHiDVl55FAz4Kzs9I4GS V9Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:content-language:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject:arc-authentication-results; bh=OSWvYjWwRzClVoIkhpZyGDvtk3TfFFLeZLgX1wSN0jo=; b=CFsyK9MwebQwLMUiA2o09w2mgwjwHKQEavi1gby8/8nmBXlfs3l6RtRMhtY0Xut3iz ktErfutKgTbOdTa7nU094alO16bc6MlMLZZXsffW5EWxph5+VdrMVnTqjFNr6a0xJVCk 6CDRVwYXqLBqR+ih5ubnYwaPM2g5kQlx2r6oLsIqi9OBrYrhZvkS53b0h6tkcGzw1SIY azMU4XR6PTWGspb4h2Jdq5QQf/Ua22fpovlnZilFO2vPkKo8DPwusiRlYnlT9pA2RuBy fqs7llOmFfIRaXrjku/SkA0Yuew9TyaAqeBqxj7zsP+S+F1034cDfg8nAWopr44LHmcW 5IQQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of amc96@hermes.cam.ac.uk designates 131.111.8.131 as permitted sender) smtp.mailfrom=amc96@hermes.cam.ac.uk Authentication-Results: mx.google.com; spf=pass (google.com: domain of amc96@hermes.cam.ac.uk designates 131.111.8.131 as permitted sender) smtp.mailfrom=amc96@hermes.cam.ac.uk X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Subject: Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB To: David Woodhouse , Borislav Petkov , KarimAllah Ahmed Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, peterz@infradead.org, pbonzini@redhat.com, ak@linux.intel.com, torvalds@linux-foundation.org, gregkh@linux-foundation.org References: <1516528149-9370-1-git-send-email-dwmw@amazon.co.uk> <1516528149-9370-6-git-send-email-dwmw@amazon.co.uk> <20180121180621.ufmc5m7nr6v4tjvc@pd.tnic> <31c52131-5f7a-8af0-3092-5fc9e322a734@amazon.com> <20180121190145.uuk3xizxejckth5s@pd.tnic> <1516563060.9814.52.camel@infradead.org> <1516565047.9814.59.camel@infradead.org> From: Andrew Cooper Message-ID: <648c29c2-eeda-f34b-e7ea-1be59b60a6e5@citrix.com> Date: Sun, 21 Jan 2018 20:19:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1516565047.9814.59.camel@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Sender: Andrew Cooper X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590195048808685762?= X-GMAIL-MSGID: =?utf-8?q?1590234700344875607?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 21/01/2018 20:04, David Woodhouse wrote: > On Sun, 2018-01-21 at 19:37 +0000, Andrew Cooper wrote: >> It doesn't matter if an attacker can use SP1 to try and skip the IBPB. >> >> Exits to userspace/guest are serialising (with some retroactive updates >> to the architecture spec coming), so an attacker can't cause victim code >> to be executed before speculation has caught up and noticed that the >> IBPB did need to happen. > For the specific case of IBPB, knowing what we do about non- > architectural behaviour, that's probably true. > > In the early patch sets in both Xen and Linux, we did have a > conditional branch on {sys,hyper}call entry that blithely let the CPU > speculate all the way to the {sys,hyper}call table jump. No exit to > userspace/guest there. Right, but that is a different situation.  That is an attacker trying to attack the kernel/hypervisor directly using SP2, which is mitigated with retpoline/lfence+jmp/IBRS (as appropriate). This IBPB case is an attacker trying to attack a new piece of userspace using SP2, and furthermore, trying to use SP1 to skip the IBPB. It is an inherent property of all these issues that an attacker can't cause the misdirected basic blocks to be retired, which means they can't change the actual behaviour of execution in supervisor context. As the exit to user/guest context is serialising, the only thing the attacker can usefully do is tickle a speculatively-leaky block. > Which is why I've been saying I want call sites to have an *explicit* > comment saying why they're safe to use conditional branches without > taking extra steps to be safe, like the 'else lfence'. And why I'd > really like the underlying primitives to *support* being fixed at > runtime. I'm afraid that, by this logic, every conditional branch needs a comment, and that is impractical.  I don't see what is special about this conditional branch vs every other conditional branch in the codebase, and calling it out in isolation feels wrong. ~Andrew