Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp559423pxb; Thu, 2 Sep 2021 09:59:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3+YFuxXB8uEkmuWmHhucSZrgm90uxAQKZXFtZYdUhPlbsYxMW1xALKpGCEmTfgtqAymt5 X-Received: by 2002:a17:906:38ce:: with SMTP id r14mr4732482ejd.268.1630601959345; Thu, 02 Sep 2021 09:59:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630601959; cv=none; d=google.com; s=arc-20160816; b=KYHkq22In46QtJB1/ccOWBKSeh5bJ/DWwhpkt6WzxnBvbKVsTCJqfXb/17RJ302YkP i4NJyUHU7UOZg+SyscxbDpOKcONoZdNLh+xMLDFXJLEEX7po+YdLMZuJC9xWXk3P0Pvu F9CqQdI/tXxh/GCmhT+QT24keLki0RIW+vcl1vZ7+S+QvZRzb5FyuaVb2LWRV86xjfP/ sHOXUbO6yCEzZowRtFxuc0uOoX5MLHHsOrzuw+kc3XmEw0WuvwBDI1wcqLlNa4xGe6V4 /sVlAZRrEdOf7kluY2lzFn8rMpyIgLgpHm9QXCd65xyhgQm51SuL0psPdGPS7eM60uam P6gA== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=642EGsn3CAgugI9d6ee0+b40u3yojON00QOXQhzKqzc=; b=fXjwgHF3Sw7X69kK6cchge89zKYAiBEsVPwChZHZ57qG/yzA7Qu5PpU8A8i7pNDbD7 jvYnzdsxaQv5m1NIH0epf3Gybp9TQX1SF/oAxco4g/is9tWaShemfimiL3r+L8c/Vcgz xeKZuEBuddIyW2R1B3CXtB+enEo3Lqa7guyUq1jorHNmVauA30IYwBXf+XFZ5wSiBucH Ta0TGeLKREzjjPSHd2Ou7hyKiYQMSSYG6+IZDeKllGCRZvgUtxUmvuz/hEt8XRJ2sv4m X8aVd64KYqEjXkHNJZp6HuKIyhQAdssFzaoyh4B9JfUgpvU3ryRCyyczvEKwI/N6p3nL vyyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=vOvAANbU; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k8si2479725edr.262.2021.09.02.09.58.30; Thu, 02 Sep 2021 09:59:19 -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; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=vOvAANbU; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346381AbhIBQzv (ORCPT + 99 others); Thu, 2 Sep 2021 12:55:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234528AbhIBQzu (ORCPT ); Thu, 2 Sep 2021 12:55:50 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31DABC061575 for ; Thu, 2 Sep 2021 09:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=642EGsn3CAgugI9d6ee0+b40u3yojON00QOXQhzKqzc=; b=vOvAANbUzTnwWRDtlQwMjLe1x p8/xFwiZNHd3m06Kua45cHNIcAHKk1RzTHhE6z2uW1CCrBcdgXo36vtOKxz1QPOglPu7ypL+2ZI8n bX7Ri34ModPn2VBbzRwWjKg28zybAeGmJSS2EbMETvbUkl+vNMnM6U8tq+YS+8qej5g5Qk5v6ilP5 A4A4GGDWEUtxn3wGUiH21bI2JBz2WyipHHraJ7/X2FXI9zp7w3wwkqZVI0dJyD3/dddh5KX592Xmv gswVIWf57OyzOEwnqZ17CELp0nJZ5S6gE8umtdJc0+Qw/qRoE2/O2uHIK0IoOqF3d8UMvUnxwb6do ydHB6rwRA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:48094) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mLpyT-0001hN-PU; Thu, 02 Sep 2021 17:54:01 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1mLpyM-000819-0H; Thu, 02 Sep 2021 17:53:54 +0100 Date: Thu, 2 Sep 2021 17:53:53 +0100 From: "Russell King (Oracle)" To: Keith Packard Cc: linux-kernel@vger.kernel.org, Abbott Liu , Alexander Sverdlin , Al Viro , Andrew Morton , Anshuman Khandual , Ard Biesheuvel , Arnd Bergmann , Bjorn Andersson , Florian Fainelli , Geert Uytterhoeven , Hartley Sweeten , Jens Axboe , Jian Cai , Joe Perches , Linus Walleij , linux-arm-kernel@lists.infradead.org, Maninder Singh , Manivannan Sadhasivam , Marc Zyngier , Masahiro Yamada , Mike Rapoport , Nick Desaulniers , Nick Desaulniers , Nicolas Pitre , Peter Zijlstra , Thomas Gleixner , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Valentin Schneider , Vaneet Narang , "Wolfram Sang (Renesas)" , YiFei Zhu , Keith Packard Subject: Re: [PATCH 0/2]: ARM: Enable THREAD_INFO_IN_TASK Message-ID: <20210902165353.GI22278@shell.armlinux.org.uk> References: <20210902155429.3987201-1-keithp@keithp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210902155429.3987201-1-keithp@keithp.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 02, 2021 at 08:54:26AM -0700, Keith Packard wrote: > Placing thread_info in the kernel stack leaves it vulnerable to stack > overflow attacks. This short series addresses that by using the > existing THREAD_INFO_IN_TASK infrastructure. > > As this is my first patch in this part of the kernel, I'm looking for > feedback about the general approach as well as specific comments on > places where I've missed something. > > I've only run this on armhf running under qemu, so while I've tried to > make patches for other code paths, I haven't been able to test those. > > (yes, I know checkpatch.pl complains about whitespace in asm-offsets.c, I > decided to leave the existing whitespace alone) > > Signed-off-by: Keith Packard I think you're introducing a circular dependency with this for certain kernel configurations: E.g. Have you tried running this with CONFIG_CPU_V6 enabled? +#define raw_smp_processor_id() this_cpu_read(cpu_number) +#define __smp_processor_id() __this_cpu_read(cpu_number) + +DECLARE_PER_CPU_READ_MOSTLY(unsigned int, cpu_number); this_cpu_read() is defined as: #define this_cpu_read(pcp) __pcpu_size_call_return(this_cpu_read_, pcp) (which will call this_cpu_read_4) #define this_cpu_read_4(pcp) this_cpu_generic_read(pcp) => __this_cpu_generic_read_nopreempt() => ___ret = READ_ONCE(*raw_cpu_ptr(&(pcp))); #define raw_cpu_ptr(ptr) \ ({ \ __verify_pcpu_ptr(ptr); \ arch_raw_cpu_ptr(ptr); \ }) #ifndef arch_raw_cpu_ptr #define arch_raw_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, __my_cpu_offset) #endif #ifndef __my_cpu_offset #define __my_cpu_offset per_cpu_offset(raw_smp_processor_id()) #endif ... which then leads back to a use of raw_smp_processor_id(), thereby creating a circular loop of preprocessor definitions that the compiler can't resolve. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!