Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1765724ybt; Thu, 2 Jul 2020 13:19:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyflej+oh6XbSCNf7wZQLUcoR3CjZ0F+YFhrGKwpqQzl5zM0FWfpWaVp7m1Czwbi+QtCFdt X-Received: by 2002:a17:906:7b54:: with SMTP id n20mr28571110ejo.144.1593721172389; Thu, 02 Jul 2020 13:19:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593721172; cv=none; d=google.com; s=arc-20160816; b=LEo9Ync7H9RFY0bhzFegLdATK7FwP67WCG5JsO+zCf7h4/WpnZXF1mO/QtQPM15Yqw ld5V3jJMzzlOqa/OhfZ7bkXHYSCwblGXe3agnBJKWiaUXICTq5zeHHqO8sPuO/y2grLR ayvE9OCILiB8Ki6DTAQJC4HTJSKCFxews3lat1bW1Ss3jh2Oaz1HhnvUXDVnbNpfGhvm bXNBKNn4wUkiAjWBd0wjPWgbLr/78YFpIeHtY2aF0+32hgTkpzODSmy6fbe2As4UGR9c oRtdqHeN20NlehXET8jmiQs5dgrZRUiZSs+WRpmekWqbcC+w7DehJryZeeXMS4pbWuhi iUNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=V18EeFi/Nuxs+Ho7DCWkT2ijBNRCITg/psYCHOECmuc=; b=UC479OZOrA0y86aGwBAO4sVEzxdi1dvh3kcjLZatdZixJrdxBBYwNlet81Z6PKD1B6 fIDlQkX97Ceh4iJHffrrnVhYKyGFltTyWHk8ODE0KWxx7k5DZPieaJiXD7E+Q5jbTwh8 AuqoWd3SZoLeSS0z0+KRLljI1aLr6+vzyA0Lq17T1CBm+s7QgIX3nRw/K3WyhrpUFj5J obMk6tkv7AvbcVsvgvBMCqd0JUEY1duVoh6Nbgwf87qvGsWXOuqePH7jZ5RlE8Mcmkoh /iYvMPIXUdnEdG80GsuJjo3qjG/apscrtZLST2cQd6Ns61lX5TNfuMEyJnDVXPN+/m6e klPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r6si1703387ejd.213.2020.07.02.13.19.09; Thu, 02 Jul 2020 13:19:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726298AbgGBUSZ (ORCPT + 99 others); Thu, 2 Jul 2020 16:18:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726032AbgGBUSY (ORCPT ); Thu, 2 Jul 2020 16:18:24 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 936B5C08C5C1 for ; Thu, 2 Jul 2020 13:18:24 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jr5ed-0049VK-MY; Thu, 02 Jul 2020 20:17:55 +0000 Date: Thu, 2 Jul 2020 21:17:55 +0100 From: Al Viro To: Linus Torvalds Cc: Michael Ellerman , Christophe Leroy , Josh Poimboeuf , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List Subject: Re: objtool clac/stac handling change.. Message-ID: <20200702201755.GO2786714@ZenIV.linux.org.uk> References: <20200701184131.GI2786714@ZenIV.linux.org.uk> <20200701195914.GK2786714@ZenIV.linux.org.uk> <87lfk26nx4.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 02, 2020 at 12:52:27PM -0700, Linus Torvalds wrote: > On Thu, Jul 2, 2020 at 6:32 AM Michael Ellerman wrote: > > > > Probably the simplest option for us is to just handle it in our > > unsafe_op_wrap(). I'll try and come up with something tomorrow. > > IMy suggestion was to basically just always handle it in all exception cases. > > And note that IU don't mean the fault handler: obviously page faults > (or unaligned faults or whatever) can happen while in a user access > region. > > But I mean any time fixup_exception() triggers. > > For x86, this is in fact particularly natural: it involves just always > clearing the AC bit in the "struct pt_regs" that fixup_exception() > gets anyway. We can do it without even bothering with checking for > CLAC/STAC support, since without it, AC is meaningless in kernel mode > anyway, but also because doing "user_access_end()" in the exception > would be pointless: AC is restored by the exception routine, so on x86 > you *have* to do it by just modifying the return state. What about static inline int copy_xregs_to_user(struct xregs_state __user *buf) { [...] stac(); XSTATE_OP(XSAVE, buf, -1, -1, err); clac(); where XSTATE_OP() is #define XSTATE_OP(op, st, lmask, hmask, err) \ asm volatile("1:" op "\n\t" \ "xor %[err], %[err]\n" \ "2:\n\t" \ ".pushsection .fixup,\"ax\"\n\t" \ "3: movl $-2,%[err]\n\t" \ "jmp 2b\n\t" \ ".popsection\n\t" \ _ASM_EXTABLE(1b, 3b) \ : [err] "=r" (err) \ : "D" (st), "m" (*st), "a" (lmask), "d" (hmask) \ : "memory") Rely upon objtool not noticing that we have, in effect, clac() in a state where AC is already cleared? We could massage that thing to take a label, but it wouldn't be pretty...