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 81613C48BF6 for ; Wed, 21 Feb 2024 09:49:02 +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:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RD/Fq/2wOlRrBdAtrr6SpY8OZ2EmA+ISQXvlMiN8Ni4=; b=PfvrsXVOGZ43Vx 4/wvESi8a6aPfRghDtyUw0VCmC+as4wtE3ckK50w+uNO5tyXXlwEWi050UUX+OizcJZMeXdpX09h7 qWBS5nPNtG90YEXjTYU5GbJ/PDh0LHTb/MzR3CYrcfNeEa3H04uOFMSToDO141j0Jweh3Cj6jSGXw Q5UymaTdX2JrHmEfVD+8dLCKRlS3hgyElIMtANIMG5ec3XlkQIGcSd7D2KoaeAIikPl6DOg17PGD5 bUOY3rAFNSloA2KeDa1XN48QXMf8LW98gLoeALeck6H2AFpGj+vxPVnoSsfphAL0WnZfbGnpjizDE ty9A9cPG2pzI6Sj9kkLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcjDY-00000000Kki-2j7T; Wed, 21 Feb 2024 09:48:44 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcjDV-00000000KkJ-1Ly1 for linux-arm-kernel@lists.infradead.org; Wed, 21 Feb 2024 09:48:43 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 2719432001AB; Wed, 21 Feb 2024 04:48:35 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Wed, 21 Feb 2024 04:48:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1708508914; x=1708595314; bh=Fw9lSJoYft ih2HH5DSoXI7rUStJLYAI4RgfN/FK3Rx8=; b=2gNEAT4pin6JGIAnt8bwDF8i/y dxEN6bb4iHtQoqbP3lVzUxytZUW00tT3+JjWU4qg5fqI1guNgjRy68mUGWNgV+C1 1xsIejWLV5OQjEbNMzcU9ggp2RXzud15v35SiCS5UfBcpIi54yCe5dWmJzkIL9rL a85RIpRD6ZPv8sumhAKtm/SjOdRGS9qDJHCplrWv0KxQtQxIHRBgoh8JkG3gGMlF l3rZp8xOBpMN514u8tm8+XqwkMeHYVD6/TiJ1fIT+4bMBiVJBFg4ubv0kBt9unFi zyiKRdecuT7mGCXTG+ndxo47a1cBssKpv2IL+4/fXQ3YbJUnlv4N3DXldFPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1708508914; x=1708595314; bh=Fw9lSJoYftih2HH5DSoXI7rUStJL YAI4RgfN/FK3Rx8=; b=Y+jJlUhwn2Xxw5axMqBCkm6M4C2Y/yBLWAoNSy1RShLI rH+TmCdFjkJZdQGKN3t5GMVXjg2YsNhOTxq/QE5OClC0Q78aNRlYT9fitKY4qjNh 7HdM9Zsn5R8FHlfPhM51nE3duHAaqeQFDsewCNZKoTC0jIqwE2OMZkzuso39OsBc HX7mT5kCvkWZWLq2vqUV6m7nhKZ5rNn/vDmB4snjDXQTD2/m1kvDgPB9cLTx86YH zMWH0YCJjC1c+Nmmcu67f7jfPAPR8fIakBOo40agc+LrYMynVH4lTuFuW3ZVIHJU 8db1OhMLygnZ7OzdKAjFPmg24CGKNskQTeZiovWsPA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 29F20B6008D; Wed, 21 Feb 2024 04:48:34 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848 MIME-Version: 1.0 Message-Id: <938f3418-fd88-476d-b67f-3f7ada98e444@app.fastmail.com> In-Reply-To: <20240221020258.1210148-1-jeremy.linton@arm.com> References: <20240221020258.1210148-1-jeremy.linton@arm.com> Date: Wed, 21 Feb 2024 10:48:12 +0100 From: "Arnd Bergmann" To: "Jeremy Linton" , linux-arm-kernel@lists.infradead.org Cc: "Catalin Marinas" , "Will Deacon" , "Kees Cook" , "Gustavo A. R. Silva" , "Mark Rutland" , "Steven Rostedt" , "Mark Brown" , "Guo Hui" , Manoj.Iyer@arm.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, "James Yang" , "Shiyou Huang" Subject: Re: [RFC] arm64: syscall: Direct PRNG kstack randomization X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240221_014841_702726_D3DCAB7B X-CRM114-Status: GOOD ( 24.14 ) 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 Wed, Feb 21, 2024, at 03:02, Jeremy Linton wrote: > The existing arm64 stack randomization uses the kernel rng to acquire > 5 bits of address space randomization. This is problematic because it > creates non determinism in the syscall path when the rng needs to be > generated or reseeded. This shows up as large tail latencies in some > benchmarks and directly affects the minimum RT latencies as seen by > cyclictest. Hi Jeremy, I think from your description it's clear that reseeding the rng is a problem for predictable RT latencies, but at the same time we have too many things going on to fix this by special-casing kstack randomization on one architecture: - if reseeding latency is a problem, can we be sure that none of the other ~500 files containing a call to get_random_{bytes,long,u8,u16,u32,u64} are in an equally critical path for RT? Maybe those are just harder to hit? - CONFIG_RANDOMIZE_KSTACK_OFFSET can already be disabled at compile or at at boot time to avoid the overhead entirely, which may be the right thing to do for users that care more deeply about syscall latencies than the fairly weak stack randomization. Most architectures don't implement it at all. - It looks like the unpredictable latency from reseeding started with f5b98461cb81 ("random: use chacha20 for get_random_int/long"), which was intended to make get_random() faster and better, but it could be seen as regression for real-time latency guarantees. If this turns out to be a general problem for RT workloads, the answer might be to bring back an option to make get_random() have predictable overhead everywhere rather than special-casing the stack randomization. > Other architectures are using timers/cycle counters for this function, > which is sketchy from a randomization perspective because it should be > possible to estimate this value from knowledge of the syscall return > time, and from reading the current value of the timer/counters. > > So, a poor rng should be better than the cycle counter if it is hard > to extract the stack offsets sufficiently to be able to detect the > PRNG's period. I'm not convinced by the argument that the implementation you have here is less predictable than the cycle counter, but I have not done any particular research here and would rely on others to take a closer look. The 32 bit global state variable does appear weak, and I know that OTOH if we can show that a particular implementation is in fact better than a cycle counter, I strongly think we should use the same one across all architectures that currently use the cycle counter. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel