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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B0D0CC433F5 for ; Wed, 11 May 2022 03:07:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Jl3F3EMf2DgirRphxWZbnYwYqagKeTWcRr3yeEWdbyA=; b=aVTedEPf0BfyRx LCZz8aW+YmHvwVNZ6LkGRZvvfZ/1Hd6FxowGNrZWrzzuPSKxdB6l+aAVpMBQyY0kUkYMZ+RutB/bk 8n2cMwmPfZ7wS7v5rF/ngmsJC2tKveblaWMeABzbOTLUVPjS/gjCWBwwoNT+kNHRKWrWJy+MZPW5Z DWX7FhpwZRf662oY9a5uQLemskN9jrDPcyEV9onoPZK60XjUWDAPgzro6x9ka0vlZiFY/DBMVJShm lMKSuXoktLQPq+hnztqzo0WqIxRDkL9f5jnJH1NsU3ixlcZjT6e0q5SCVYOhK1kBTx1HdLXU2OZsz hC6kQGyD/PK8q5EidXYA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nocft-004w1f-Fs; Wed, 11 May 2022 03:06:05 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nocfq-004vyp-CR for linux-arm-kernel@lists.infradead.org; Wed, 11 May 2022 03:06:03 +0000 Received: by mail-pj1-x1029.google.com with SMTP id x88so987015pjj.1 for ; Tue, 10 May 2022 20:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zeXQEtR41vW8oV0uB8lf+EcTnJUokpOmF2JIIH/qaxo=; b=MQ8A09vGXiI6pmL3YaUyeC5Oqv1jMNQWEZ8p2FpvrjTyzhUK2OhV196QHRtaU9G1Z8 6vcc6nMoCKaCDu+yGcqz1uEFPpi2sFW9cEuy7seO2OtcoXI2GWopNAsnDWk2330MWATX tKmnG9iUTpFc5bbNu/Zo+puitiblgj1awr/jY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zeXQEtR41vW8oV0uB8lf+EcTnJUokpOmF2JIIH/qaxo=; b=BXMd89synYdKOgns1FrT9P1E+HA4Bt12bhbvpFYwTYiCJNYinLcLy1J4CRjkgSZwDR Z1eEg146FBt3anVIoCsKyT+xXqt3IOiOrxRzOYpOY6wWapdtYPi+1rTkOsgqQ0auW2UU z17OY9glpB5caV27ehdnvV4zyMJ5A8NFS1G6sUOOAuFFCvmqwiuwDaVTLnwkgI4GCQsh r9MD8J/Lad9g+ZXkgnjfFlzlmeuWVfZIS6y92t7pglTSH2PADScmTneKGLGjI2/I6kRu RnbmzHhuRQmV8vGZnyEkh0SNJegyu7Pah2tlcs1YmwOgS9E0iq3gATMZBEZohJ8B4mbC uFDg== X-Gm-Message-State: AOAM532Ad03Rz0aQInFWu1iyOq3+v7FIExGNqVwvyrZH7iVOlSAd0VqS XLwUEK39p4GmvnlrV+7FAbcECcwWfXN3hw== X-Google-Smtp-Source: ABdhPJxLwv6ESDyVK2tUjxF2N76LlATJd4VPEY3UK/13lQBjg60uUZ5/EhmzInRXXzPNiEDUhotLmQ== X-Received: by 2002:a17:903:230e:b0:15e:d0a1:922f with SMTP id d14-20020a170903230e00b0015ed0a1922fmr23587196plh.75.1652238359188; Tue, 10 May 2022 20:05:59 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id v6-20020a1709029a0600b0015e8d4eb201sm372188plp.75.2022.05.10.20.05.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 20:05:58 -0700 (PDT) Date: Tue, 10 May 2022 20:05:58 -0700 From: Kees Cook To: Mark Rutland Cc: Alexander Popov , linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, luto@kernel.org, will@kernel.org Subject: Re: [PATCH v2 05/13] stackleak: clarify variable names Message-ID: <202205102001.7EB50CBE18@keescook> References: <20220427173128.2603085-1-mark.rutland@arm.com> <20220427173128.2603085-6-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220510_200602_482268_92E65B1F X-CRM114-Status: GOOD ( 22.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 10, 2022 at 02:01:49PM +0100, Mark Rutland wrote: > On Sun, May 08, 2022 at 11:49:46PM +0300, Alexander Popov wrote: > > On 27.04.2022 20:31, Mark Rutland wrote: > > > The logic within __stackleak_erase() can be a little hard to follow, as > > > `boundary` switches from being the low bound to the high bound mid way > > > through the function, and `kstack_ptr` is used to represent the start of > > > the region to erase while `boundary` represents the end of the region to > > > erase. > > > > > > Make this a little clearer by consistently using clearer variable names. > > > The `boundary` variable is removed, the bounds of the region to erase > > > are described by `erase_low` and `erase_high`, and bounds of the task > > > stack are described by `task_stack_low` and `task_stck_high`. > > > > A typo here in `task_stck_high`. > > Ah; whoops. No worries; I fixed this when I took the patch. > > That was also the main reason why I reused the 'boundary' variable: I wanted > > the compiler to allocate it in the register and I avoided creating many > > local variables. > > > > Mark, did your refactoring make the compiler allocate local variables on the > > stack instead of the registers? > > Considering the whole series, testing with GCC 11.1.0: > > * On arm64: > before: stackleak_erase() uses 48 bytes of stack > after: stackleak_erase() uses 0 bytes of stack > > Note: this is entirely due to patch 1; arm64 has enough GPRs that it > doesn't need to use the stack. > > * On x86_64: > before: stackleak_erase() uses 0 bytes of stack > after: stackleak_erase() uses 0 bytes of stack > > * On i386 > before: stackleak_erase() uses 8 bytes of stach > after: stackleak_erase() uses 16 bytes of stack > > The i386 case isn't ideal, but given that those bytes will easily be used by > the entry triage code before getting to any syscall handling, I don't believe > that's an issue in practice. I am biased and totally fine with choosing a solution where 64-bit improvement comes at a 32-bit cost. -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel