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 57D16C54E64 for ; Fri, 22 Mar 2024 23:41:20 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=idlZsVLM0Oh/WFxQkTll1+OxeH0qmelfCpGhfVonDXc=; b=FJJKXY8K4I0Wds MQzKrDEoWPuQFfNWsIcwfTpxCk42wh9HBvgwW52uRld6RwVdqvf7kEJf2MKSu32sQy17cF4RcyPKB 5C/sEFyXTA9D0TMGMrNQrXd0niNZf7DH5DJXhvP4+89BleBMnRhob3s5agKwfcf39ImleiI+PhVnO qqK03W3z2RZQNL98wFu8Qca7rj5KclMpcdgO1kN3ZS2NPuDjd4htA0NaZK46Zgfev7qow6RHEG2oS FLxOsJTTJGqpLkzWZppZHngIKea0l7g+054w2hL5vSxtezlGTzxlv9UlFiSUwKYplVncyT2+oTZwn QXVhLraiXmjb/dkUKklg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnoVa-00000008wgi-2Pap; Fri, 22 Mar 2024 23:41:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnoVU-00000008wdv-1it7 for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2024 23:41:09 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 56537DA7; Fri, 22 Mar 2024 16:41:30 -0700 (PDT) Received: from [172.27.42.98] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 202903F762; Fri, 22 Mar 2024 16:40:55 -0700 (PDT) Message-ID: <2ebe2ea5-b107-4020-8e60-ff8cf43a3aab@arm.com> Date: Fri, 22 Mar 2024 18:40:54 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization Content-Language: en-US To: Arnd Bergmann , Kees Cook Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , "Jason A . Donenfeld" , "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 References: <20240305221824.3300322-1-jeremy.linton@arm.com> <20240305221824.3300322-2-jeremy.linton@arm.com> <202403051526.0BE26F99E@keescook> <34351804-ad1d-498f-932a-c1844b78589f@app.fastmail.com> <38f9541b-dd88-4d49-af3b-bc7880a4e2f4@arm.com> From: Jeremy Linton In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_164104_529411_9A748441 X-CRM114-Status: GOOD ( 16.15 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, Sorry about the delay here, PTO and I actually wanted to verify my assumptions. On 3/8/24 14:29, Arnd Bergmann wrote: > On Fri, Mar 8, 2024, at 17:49, Jeremy Linton wrote: >> On 3/7/24 05:10, Arnd Bergmann wrote: >>> >>> I'm not sure I understand the logic. Do you mean that accessing >>> CNTVCT itself is slow, or that reseeding based on CNTVCT is slow >>> because of the overhead of reseeding? >> >> Slow, as in, its running at a much lower frequency than a cycle counter. > > Ok, I see. Would it be possible to use PMEVCNTR0 instead? So, I presume you actually mean PMCCNTR_EL0 because I don't see the point of a dedicated event, although maybe... So, the first and maybe largest problem is the PMxxx registers are all optional because the PMU is optional! Although, they are strongly recommended and most (AFAIK) machines do implement them. So, maybe if its just using a cycle counter to dump some entropy into rnd_state it becomes a statement that kstack randomization is slower or unsupported if there isn't a PMU? But then we have to basically enable the PMU cycle counter globally, which requires reworking how it works, because the cycle counter is enabled/disabled and reset on the fly depending on whether the user is trying to profile something. So, I have hacked that up, and it appears to be working, although i'm not sure what kind of interaction will happen with KVM yet. But I guess the larger question is whether its worth changing the PMU behavior for this? Thanks, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel