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 D2095C636D4 for ; Tue, 31 Jan 2023 15:39:30 +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=9QN4UFOcyoYHmQ0FtRBRkXJE6penln7TdbfBGTjEcaM=; b=SqULht0l7XT/Cg FnWhGSQNt5pyidT4uCvLv+K5lSmvMnMPSGWnzuTt2v4cUXVbtfAnewq0Lw8JZBz4LzT81OOJ0nISK mgMl8lyUbTCJOB1Sl9RVdww4XTvi7Urx85kMG0/yLCp34Ne6n4zs6sXQLxJMKqirfltGyNoekxdYF /TV0N1b9EIjw280GwqkuCE2FWO4z305ErE8hd8v4qfMfh0rrVp5HZXNCR85Zo6VK2CDjEOM81EmPP KqWf9uaPMY9jvWpEVYUipOXHjIVBZKHNekg/66eKX/usKIVwXJ5MvL6LpPeELEHNQOnwnuvsLZvUU AnUdnMPw9jUyNRDBqUbA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMsiV-008YID-SS; Tue, 31 Jan 2023 15:38:39 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMsiI-008YCR-Io for linux-arm-kernel@lists.infradead.org; Tue, 31 Jan 2023 15:38:28 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 6E505CE1EF5; Tue, 31 Jan 2023 15:38:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E766C4339E; Tue, 31 Jan 2023 15:38:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675179501; bh=JOJOT+dxC37NT2M/AJqQ1MByxjCpME4HBG9QuRUBGbA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f7jdyTCWhHEgfbVkZp8EPxVb5wxo15WRUN9VaE/kyFfeYrmgc/b3KArn6r7mKeEJd z6GfDmlKAOJ4gCRsfF/KNIGjfCnvqX4u+XeIAMiKUS+NWc+SZiz/nEnYbX0Z98UQMG juUBEtUwNUeJAzDIPcjAjWaTdBEko1o0mloBWuDJ9PcYiMLqZV0jC6epcmwWgHBp4l X2Fx3fizCntIq/E8cbbGAenlC0/9H55p6sbz4To0dOHPfm2mf3r9e4SqSOViWhfKRw ckYwx1rVamHb48NyjFT64c3MBFElmI4nNK4Hq47aiEzTly/lyIdCqQUnquoYl99Xo2 v34ZBKxS6XCxQ== Date: Tue, 31 Jan 2023 15:38:16 +0000 From: Will Deacon To: Catalin Marinas Cc: Mark Brown , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/6] arm64/signal: Signal handling cleanups Message-ID: <20230131153816.GA2646@willie-the-truck> References: <20221212-arm64-signal-cleanup-v2-0-14a8f3e088b7@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230131_073826_836532_31B1BB71 X-CRM114-Status: GOOD ( 23.82 ) 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, Jan 31, 2023 at 12:51:33PM +0000, Catalin Marinas wrote: > Hi Mark, > > On Tue, Jan 03, 2023 at 08:25:15PM +0000, Mark Brown wrote: > > This series collects a number of small cleanups to the signal handling > > code which removes redundant validation of size information and avoids > > reading the same data from userspace twice. > > > > There are some overlaps with both the TPIDR2 signal handling and SME2 > > serieses which are also in flight, applying this will require > > adjustments in those serieses and vice versa. > [...] > > Mark Brown (6): > > arm64/signal: Don't redundantly verify FPSIMD magic > > arm64/signal: Remove redundant size validation from parse_user_sigframe() > > arm64/signal: Make interface for restore_fpsimd_context() consistent > > I'm fine with the first three patches, they seem correct and make the > frame checking more consistent. > > > arm64/signal: Avoid rereading context frame sizes > > arm64/signal: Only read new data when parsing the SVE context > > arm64/signal: Only read new data when parsing the ZA context > > I'm not sure these add much to the code readability (and the performance > improvement I guess is negligible). We avoid some copy_from_user() into > the context structures but rely on data read previously or some > get_user() into local variables. Personally I'd make the > restore_fpsimd_context() also do a copy_from_user() for consistency with > the current sve and za frames restoring. > > Personal preference, not sure whether Will has the same view. That main thing I'm worried about is the potential for ToCToU bugs if we read userdata more than once. For example, if we end up splitting checks between the two reads, then an attacker could update the value in the middle and potential cause us issues. If we just read the stuff once, we don't have to worry about that. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel