From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227lMTcfGHD/od0T4M/0uQQUgo7UYIM7qaXIwR5hhyA1sQoaHhLbVUUVkW+oJthOiALMAsWg ARC-Seal: i=1; a=rsa-sha256; t=1517228884; cv=none; d=google.com; s=arc-20160816; b=Lgvt1BG37xX2RhSZ+68rjUZikD9/vbWSDP3h4d9/Y0bLtk8YQXcIi/I8orjo/wRRMK sJ9Whv6lwyO8oDpXni5hEmBQ/OPv4Dq8Bjcy996u/pMGTYAoDJtbksdrwVGPP1Ndhn/V aCJLIQrzIo94lVn/TEuOJrskPG2jlwM03pcwLBtnlF3OqHWPRRR1srJ6/vHJlL9VQroU F1LVXHiGl9D5P9SDlxMQV1JuG2bHjqfONI9gPzcC2J6HdRC+6VxYgOOWA6qCyrdRfaZw cQqTUD2XCVwCSSnv1Ui/soEWa/KmL61oWLzc5sgNLjxXRH5g/doh6YpubuxtWHhB+tz5 GLjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=/r+S3ICMDRpKd7HHaM3fU4MZwcTGvgY80n/joLkwIeQ=; b=zh0uyy42mTRS38He5I2ruqBPxZzcXJQWQ+ub7wSg73NigOVEjCY7O7v48gZLfxG1pZ 4gVOKk5AcQEyL4dssDph0zeobrUb5yJ0ltDLuDPGE80aWFM9mYflQ4rfaXOCVyU+XFDW x7vMbDF0n7q7xA+BKFQyy1pA0SjJCJ2/dLYAYHVWY02VwEVChj4YipfbR3HPBJswmI0n L1oZflZ4p+5nZ9Neqeqw0xoq6SXhzfrEqo0RIqB+TLftVJI4CQZ8xXm37qUOYuWPRuQO plIqlTrphrwPwmG3YJegA7BNNsxpBg2SUgdtUceTJM8xaa5SQM7ZQ76TxvwSkFt0pWIe X90w== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 136.243.71.142 is neither permitted nor denied by best guess record for domain of linux@dominikbrodowski.net) smtp.mailfrom=linux@dominikbrodowski.net Authentication-Results: mx.google.com; spf=neutral (google.com: 136.243.71.142 is neither permitted nor denied by best guess record for domain of linux@dominikbrodowski.net) smtp.mailfrom=linux@dominikbrodowski.net Date: Mon, 29 Jan 2018 13:28:03 +0100 From: Dominik Brodowski To: David Woodhouse 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, bp@alien8.de, peterz@infradead.org, pbonzini@redhat.com, ak@linux.intel.com, torvalds@linux-foundation.org, gregkh@linux-foundation.org, mingo@kernel.org, luto@kernel.org, jcm@redhat.com Subject: Re: [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch Message-ID: <20180129122803.GA23664@isilmar-4.linta.de> References: <1517225608-9153-1-git-send-email-dwmw@amazon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1517225608-9153-1-git-send-email-dwmw@amazon.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590927737453215025?= X-GMAIL-MSGID: =?utf-8?q?1590929795211428178?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 11:33:28AM +0000, David Woodhouse wrote: > From: Tim Chen > > Flush indirect branches when switching into a process that marked itself > non dumpable. This protects high value processes like gpg better, > without having too high performance overhead. > > If done naïvely, we could switch to a kernel idle thread and then back > to the original process, such as: > > process A -> idle -> process A > > In such scenario, we do not have to do IBPB here even though the process > is non-dumpable, as we are switching back to the same process after a > hiatus. > > To avoid the redundant IBPB, which is expensive, we track the last mm > user context ID. The cost is to have an extra u64 mm context id to track > the last mm we were using before switching to the init_mm used by idle. > Avoiding the extra IBPB is probably worth the extra memory for this > common scenario. > > For those cases where tlb_defer_switch_to_init_mm() returns true (non > PCID), lazy tlb will defer switch to init_mm, so we will not be changing > the mm for the process A -> idle -> process A switch. So IBPB will be > skipped for this case. > > Thanks to the reviewers and Andy Lutomirski for the suggestion of > using ctx_id which got rid of the problem of mm pointer recycling. > > Signed-off-by: Tim Chen > Signed-off-by: David Woodhouse > --- > How close are we to done with bikeshedding this one?... The commit message is much more about the A->idle-> improvement than on the basic design decisions to limit this to non-dumpable processes. And that still seems to be under discussion (see, for example, Jon Masters message of today, https://lkml.org/lkml/2018/1/29/34 ). So this design choice should, at least, be more explicit (if not tunable...). > @@ -219,6 +220,25 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next, > } else { > u16 new_asid; > bool need_flush; > + u64 last_ctx_id = this_cpu_read(cpu_tlbstate.last_ctx_id); > + > + /* > + * Avoid user/user BTB poisoning by flushing the branch > + * predictor when switching between processes. This stops > + * one process from doing Spectre-v2 attacks on another. > + * > + * As an optimization, flush indirect branches only when > + * switching into processes that disable dumping. > + * > + * This will not flush branches when switching into kernel > + * threads. It will also not flush if we switch to idle Whitespace damage. And maybe add ", as the kernel depends on retpoline protection instead" after "threads" here -- I think that was the reason why you think kernel threads are safe; or did I misunderstand you? > + * thread and back to the same process. It will flush if we > + * switch to a different non-dumpable process. "process, as that gives additional protection to high value processes like gpg. Other processes are left unprotected here to reduce the overhead of the barrier [... maybe add some rationale here ...]" Thanks, Dominik