From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 850F2C63797 for ; Fri, 3 Feb 2023 19:44:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232180AbjBCTo1 (ORCPT ); Fri, 3 Feb 2023 14:44:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229853AbjBCTo0 (ORCPT ); Fri, 3 Feb 2023 14:44:26 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A44B39DCB3; Fri, 3 Feb 2023 11:44:25 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 30CE51EC050B; Fri, 3 Feb 2023 20:44:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1675453464; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=Aawd1Ae416cyoOlyUnwX/vsr0DPMmD0L5HLCQmlorYw=; b=Yw/nyWbPDsXI1pcZe7prJu7pg191XIQbuN4noeqgHgrl7hN4Y0WSj41wuH1q0Nf72djV/U 3JCyy3RBcRldDMC8zylW4+u6JZRWwSl56OG6QmFQMZjMxbeVXD2+VY8n5AZoHpQinTiHHI Hr0nGS0ONG4GHznX84tW9AA6HshKxIA= Date: Fri, 3 Feb 2023 20:44:20 +0100 From: Borislav Petkov To: "Edgecombe, Rick P" Cc: "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Yu, Yu-cheng" , "dave.hansen@linux.intel.com" , "kirill.shutemov@linux.intel.com" , "Eranian, Stephane" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "pavel@ucw.cz" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "Yang, Weijiang" , "Lutomirski, Andy" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "akpm@linux-foundation.org" , "jamorris@linux.microsoft.com" , "john.allen@amd.com" , "rppt@kernel.org" , "andrew.cooper3@citrix.com" , "mingo@redhat.com" , "mtk.manpages@gmail.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" Subject: Re: [PATCH v5 07/39] x86: Add user control-protection fault handler Message-ID: References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-8-rick.p.edgecombe@intel.com> <393a03d063dee5831af93ca67636df75a76481c3.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <393a03d063dee5831af93ca67636df75a76481c3.camel@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Fri, Feb 03, 2023 at 07:24:08PM +0000, Edgecombe, Rick P wrote: > The name seems better, but this is actually from the existing kernel > IBT control protection exception code. So it seems like an separate > change. Would you like to see it snuck into the user shadow stack > handler, or could we leave this for future cleanups? > > Kees pointed out that adding to the handler and moving it in the same > patch makes it difficult to see where the changes are. I'm splitting > this one into two patches for the next version. Yap, that's the right way to do it. > I think we have to read it before we enable interrupts or use > fpregs_lock(). So reading it before saves disabling preemption later. So I'm a bit confused - there's that cond_local_irq_enable() which will enable interrupts if they were enabled before. So if they were enabled before and you reenable them here, then that current could be the wrong one if we schedule in between, right? IOW, shouldn't those two lines be swapped so that it says: tsk = current; cond_local_irq_enable(regs); and you can be sure that tsk is always the right current which caused the #CP? Or am I way off again? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette