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 46C1CCD68FE for ; Tue, 10 Oct 2023 08:30:18 +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=AjSy3GlP3RCuHCxus8SmzbSldklr6a+p0C4eJdLL3DQ=; b=B6SHxUmUueJVoq 0IKOk8Js5NN3LVQezKIs6pG3wjA7CT//kYinzlwP0pzgG0nmzbz4fzFnVKQuWtKnF6LelFdJ2xkjR JbQl2EWgho1mFMjqIRap1B7Q8YXlCeUu2QOyFxm6GbvAYGxmvwuAotdGRqGDW1T87wXPDk6CmeJ3F uQjja+FizndnA08uMZ030j8vY2pqR+F82qFBrQ1ra9TLN0lkDWQSlmy1meg6/YEb/dtaTBrAOkLU+ Nl1RvWf+yguBCNn/gw+h9A/DkfeeyceAbDk2Shy2ctglYHChPlHvPIYAV9hEAF2NdrIaMe5PkEdJB whjvHqiZUrrm901+SIpg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qq87k-00CqBd-0t; Tue, 10 Oct 2023 08:29:52 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qq87g-00CqAw-3D for linux-arm-kernel@lists.infradead.org; Tue, 10 Oct 2023 08:29:51 +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 9959F1FB; Tue, 10 Oct 2023 01:30:27 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 744003F7A6; Tue, 10 Oct 2023 01:29:45 -0700 (PDT) Date: Tue, 10 Oct 2023 09:29:39 +0100 From: Cristian Marussi To: Peng Fan Cc: "Peng Fan (OSS)" , "sudeep.holla@arm.com" , "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ranjani Vaidyanathan , Glen G Wienecke , "souvik.chakravarty@arm.com" , Chuck Cannon Subject: Re: [RFC] firmware: arm_scmi: clock: add fixed clock attribute support Message-ID: References: <20231010022911.4106863-1-peng.fan@oss.nxp.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-20231010_012949_129499_FFF8284B X-CRM114-Status: GOOD ( 40.26 ) 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, Oct 10, 2023 at 08:08:01AM +0000, Peng Fan wrote: > > Subject: Re: [RFC] firmware: arm_scmi: clock: add fixed clock attribute > > support > > > > On Tue, Oct 10, 2023 at 10:29:11AM +0800, Peng Fan (OSS) wrote: > > > From: Peng Fan > > > > > > There are clocks: > > > system critical, not allow linux to disable, change rate allow linux > > > to get rate, because some periphals will use the frequency to > > > configure periphals. > > > > > > So introduce an attribute to indicated FIXED clock > > > > > > > Hi, > > > > (CCed souvik.chakravarty@arm.com) > > > > so AFAIU here you are describing a clock that really is NOT fixed in general, it > > is just that the Linux SCMI Agent cannot touch it, but other SCMI agents on > > the system CAN change it and so, on one side, you keep the ability for the > > Linux agent to read back the current rate with > > recalc_rate() and remove all the Clk frameworks callbacks needed to modify > > its state, am I right ? > > Right. > > > > > In this scenario, it is really the SCMI platform fw (server) that has to > > implement the checks and simply DENY the requests coming from an agent > > that is not supposed to touch that clock, while allowing the current rate to be > > retrieved. > > Linux will try to enable, get rate, runtime disable the clock. > But the server does not allow enable/disable the clock, so the driver probe > will fail. > Which driver probe ? I have just double checked and when clk-scmi driver is loaded there are a bunch of SCMI queries to the server BUT no *_SET command is issued during the clk-scmi probe; indeed JUNO had never had any issue despite having access to a bunch of CLKs which are visibile BUT not modifiable from Linux. > The SCMI server could bypass enable/disable and only allow get rate, > But this introduces heavy RPC, so just wanna whether it is ok to register > fixed clock and avoid RPC. > > > > > JUNO/SCP is an example of how the CPUs clocks are visible to Linux BUT > > cannot be touched directly via Clock protocol by Linux since in the SCMI > > world you are supposed to use the Perf protocol instead to change the OPPs > > when you want to modify the performance level of the runnning CPU. > > > > This kind of server-side permissions checks, meant to filter access to resources > > based on the requesting agent, are part of the SCMI declared aim to push the > > responsibility of such controls out of the kernel into the platform fw in order > > to avoid attacks like CLOCK_SCREW by letting the SCMI firmware be the one > > and only final arbiter on the requests coming from the agents; you can ask > > teh server whatever you like as an agent but your request can be DENIED or > > silently ignored (in case of shared resources) at the will of the platform which > > has the final say and it is implemented in a physically distinct code-base. > > > > It seems to me that this patch and the possible associated SCMI specification > > change would give back the control to the Linux agent and could allow the > > implementation of an SCMI Server that does NOT perform any of these > > permission checks. > > > > So, IMO, while this change, on one side, could be certainly useful by removing > > a bunch of unused/uneeded callbacks from the CLK SCMI driver when a fixed > > clock is identified, it could open the door to a bad implementation like the > > one mentioned above which does NOT perform any agent-based permission > > check. > > Thanks for detailed information, let me check whether our SCMI firmware > could do more on the permission side. But if RPC could be removed, > it could save some time. > Avoiding to issue SCMI requests destined to fail would be certainly good, even though it could lead to just quietly implementing a server with no-checks at all, but why these unneeded calls happen in first place ? I have never observed anything like that in my setups. Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel