Received: by 10.223.176.5 with SMTP id f5csp818wra; Tue, 6 Feb 2018 15:52:05 -0800 (PST) X-Google-Smtp-Source: AH8x225VsmFr6E76Zb1Fbj1Z7CsikJ4HaTsGK6aCe64IU6tBseuKyjP5XIw5ThSxRSTB/9JayKCq X-Received: by 10.98.65.13 with SMTP id o13mr3946791pfa.97.1517961125547; Tue, 06 Feb 2018 15:52:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517961125; cv=none; d=google.com; s=arc-20160816; b=AOdBcZJbHXzeaJ8Fql9qpimYEpt0lgAaptBJ/PQ2Lyn2/aJF+8BG9sdSVYwytmODUg 9lWt7pvjxpQ4O3eV1961RDE6+xXAH4J4HAMabNlVs3ycxIn1HkwcAUduFcQYa0C9s0Am 5NqYJCFBu/J3kH/dx3HsxEIbqucricvhOmypTJK4PvzABN33sIASDWhoNjvS77RKgkzj pBqCc4Wg/5fLrvejZhfy5mQlR47udJRefS8zvCciPm4FIIxn+M7CwfuM03TJPJ8Uvjom 8MdIciv9KhTgF/YTrJo3LEoJbQh3xpJYf0c7Ru+P0dJ5XyeZc1R60TogZJU5C8qTYSiJ m/vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=RK/jeEmPhxjWITqFEoItCXw4XaYBRHeI0/A0IDcro8c=; b=RHv1GCtLUu4SnhgliRVh1dghi6o2dh+VBASIn7jSwIn84dek40NvIb+yNLnwtMSiht RePP5v6E2E+1oAnp6RCDuKmRlyKh8L9QdqkE4qtb656q7xbDqhs5Ge4ALFaYBIyAjifM GeytKADtsHLoe5T0VxYN0xxbnHUZmORk/QFP4CLTCem1TgNVAEzArQ1nU0K33qXHuRw0 WhJePwfjq8U2qwIUfvMJlJXWLkL8qags3AB7ScHGGoJm5R65xoEu67wT7Hz+n79GJXgr 3+l9NG4ka7ZUCfVeNkSPetbl5QSTslA6DcFabEX7cmMemDLmsMYO+2HTL9HBsUc3oj0W b2sQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f31-v6si97740plb.685.2018.02.06.15.51.42; Tue, 06 Feb 2018 15:52:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754229AbeBFXth (ORCPT + 99 others); Tue, 6 Feb 2018 18:49:37 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50100 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753346AbeBFXtg (ORCPT ); Tue, 6 Feb 2018 18:49:36 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60A8E40EC7E1; Tue, 6 Feb 2018 23:49:35 +0000 (UTC) Received: from treble (ovpn-122-204.rdu2.redhat.com [10.10.122.204]) by smtp.corp.redhat.com (Postfix) with ESMTP id 989E5AB58E; Tue, 6 Feb 2018 23:49:32 +0000 (UTC) Date: Tue, 6 Feb 2018 17:49:32 -0600 From: Josh Poimboeuf To: David Woodhouse Cc: Borislav Petkov , X86 ML , LKML , tim.c.chen@linux.intel.com, pjt@google.com, jikos@kernel.org, gregkh@linux-foundation.org, dave.hansen@intel.com, riel@redhat.com, luto@amacapital.net, torvalds@linux-foundation.org, ak@linux.intel.com, keescook@google.com, peterz@infradead.org Subject: Re: [PATCH 2/2] x86/speculation: Simplify indirect_branch_prediction_barrier() Message-ID: <20180206234932.jlctz3u5ybq6gunz@treble> References: <20180126121139.31959-4-bp@alien8.de> <1516970011.30244.223.camel@infradead.org> <20180126132431.fsbd3c3g2yreazy6@pd.tnic> <1516983879.30244.236.camel@infradead.org> <20180126164746.dpo7dswid5tjk2tz@pd.tnic> <20180126200616.5xfn244uzeu7ptyo@pd.tnic> <20180126200813.cignvfovk2dhlzbh@pd.tnic> <1517946292.3677.22.camel@infradead.org> <20180206232514.qcy4y3dzfkjo3xdg@treble> <1517959878.3677.54.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1517959878.3677.54.camel@infradead.org> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 06 Feb 2018 23:49:35 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 06 Feb 2018 23:49:35 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jpoimboe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 11:31:18PM +0000, David Woodhouse wrote: > > > On Tue, 2018-02-06 at 17:25 -0600, Josh Poimboeuf wrote: > > On Tue, Feb 06, 2018 at 07:44:52PM +0000, David Woodhouse wrote: > > > > > > On Fri, 2018-01-26 at 21:08 +0100, Borislav Petkov wrote: > > > > > > > > Make it all a function which does the WRMSR instead of having a hairy > > > > inline asm. > > > ... > > > > > > > > > > > + alternative_input("", > > > > +  "call __ibp_barrier", > > > > +  X86_FEATURE_IBPB, > > > > +  ASM_NO_INPUT_CLOBBER("eax", "ecx", "edx", "memory")); > > > >  } > > > Dammit. I know the best time to comment is *before* I add my own sign- > > > off to it and before Linus has merged it but... I think this is broken. > > > > > > If you're calling a C function then you have to mark *all* the call- > > > clobbered registers as, well, clobbered. > > > > > > If you really really really want to *call* something out of line, then > > > it would need to be implemented in asm. > > > > Hm.  In theory I agree this seems like a bug.  On x86_64 I believe we > > would need to mark the following registers as clobbered: r8-r11, ax, cx, > > dx, si, di, plus "memory" and "cc". > > > > But I'm scratching my head a bit, because we seem to have this bug all > > over the kernel.  (Grep for ASM_CALL_CONSTRAINT to see them.) > > > > Many of those inline asm calls have been around a long time.  So why > > hasn't it ever bitten us? > > How many are actually calling C functions, not asm or other special > cases like firmware entry points? I think many, and maybe even most, are calling normal C functions. -- Josh