From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudeep Holla Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family Date: Wed, 17 Apr 2019 14:33:05 +0100 Message-ID: <68aaace3-f66e-b4b8-30a0-57b8b66a7524@arm.com> References: <20190417053211.2195-1-ping.bai@nxp.com> <1555503195.2317.19.camel@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Leonard Crestez , Lucas Stach , Jacky Bai , Peng Fan Cc: Aisheng Dong , "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "festevam@gmail.com" , "s.hauer@pengutronix.de" , =?UTF-8?Q?Cl=c3=a9ment_Faure?= , "robh+dt@kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , Sudeep Holla , Silvano Di Ninno , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org On 17/04/2019 13:40, Leonard Crestez wrote: > On 4/17/2019 3:13 PM, Lucas Stach wrote: [...] >> >> I don't yet buy the security argument. There are many more shared parts >> on the SoC, like the clock controller, that would need to be taken away >> from the non-secure world if one would want to run an untrusted OS >> kernel on a i.MX8M system. >> >> To properly implement security on any i.MX8M based system the firmware >> would need to grow something like a full ARM SCPI implementation, so >> all shared critical peripherals are solely under firmware control. > > It might be possible to rework this to use some form of SCMI-over-SMC > instead of vendor-specific SMCCC SIP calls > Sounds feasible and good if all the custom IDs/calls/..etc are well hidden in the firmware(TF-A in this case) behind the existing abstraction in Linux kernel. > +SCMI maintainer > Thanks for including. >> I agree that it might make sense to move some parts into the firmware >> and have much simpler OS level drivers, but I don't agree on the >> implementation direction taken here. Growing custom PSCI extension >> interfaces will only get us so far, without solving the system security >> issue in a holistic way. It is my strong believe that only a complete >> rearchitecture of the OS support on top of a ARM SCPI firmware >> interface can solve this properly. +1 again, just to re-iterate the emphasis on the above and the degree to which I align with it. > Hiding everything critical for security (especially CCM) behind a SCMI > interface would be a large amount of work but introducing SCMI > incrementally (starting with imx8mm power) would be useful by itself > because it simplifies OS implementation. > Agreed, but not at the expense of introducing and maintaining *random* *one-off* *custom* SMC extensions. Sorry, that's not open to debate. > Many at NXP have attempted to evaluate SCMI and their conclusion has > always been that "many extensions are required". > I would like to hear the evaluation. Don't assume that you need to implement something similar to ARM SCMI reference design. All OSPM like Linux kernel cares is conformance to the interface, what/how you implement on the other side is left to you. -- Regards, Sudeep 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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_TVD_FUZZY_SECURITIES,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E6F5C282DA for ; Wed, 17 Apr 2019 13:33:18 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 0C5402177B for ; Wed, 17 Apr 2019 13:33:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="H1QoHjwg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0C5402177B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KqpY8EBiktf8qU9nu2TGhX0oKTtWWwe4DELDwofBH3M=; b=H1QoHjwgETABQn Nn/ri22ZxjwKlZS2RPi0n15/bkmmkdNTfQQY2dWsG3Y+Kq2cAzvbbptO87cy/TFiqXMELKELglgTE TDj0uYS3fvXRvoB0h7jXoUJSSo/n4C1U5aSrs/b30XW8oTtuxFPgzFcOglXzrJ547DZ6hCrgrDc3Q 6tcZfRRKd/ui79x1/ZRb1SUgJJ3MU4j5O5yXRMgUdBWhqyhkqPZZZxGpM14Gx09povEzuShGxy0fi m2hE0eyu9/dtsZwfzWEYlH/nvHpH9nE3LZ4ppqcwqq7FeTBQF7an5S5hLYygmaHkkmBk8r0kcwOzO Qloq7ueuYVOgdbujQ1Uw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGkgb-0004NQ-DA; Wed, 17 Apr 2019 13:33:13 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGkgY-0004N2-EN for linux-arm-kernel@lists.infradead.org; Wed, 17 Apr 2019 13:33:11 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D32D5374; Wed, 17 Apr 2019 06:33:09 -0700 (PDT) Received: from [10.1.196.42] (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 070AC3F690; Wed, 17 Apr 2019 06:33:06 -0700 (PDT) Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family To: Leonard Crestez , Lucas Stach , Jacky Bai , Peng Fan References: <20190417053211.2195-1-ping.bai@nxp.com> <1555503195.2317.19.camel@pengutronix.de> From: Sudeep Holla Organization: ARM Message-ID: <68aaace3-f66e-b4b8-30a0-57b8b66a7524@arm.com> Date: Wed, 17 Apr 2019 14:33:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190417_063310_493597_B5488FD0 X-CRM114-Status: GOOD ( 18.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aisheng Dong , "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "festevam@gmail.com" , "s.hauer@pengutronix.de" , =?UTF-8?Q?Cl=c3=a9ment_Faure?= , "robh+dt@kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , Sudeep Holla , Silvano Di Ninno , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 17/04/2019 13:40, Leonard Crestez wrote: > On 4/17/2019 3:13 PM, Lucas Stach wrote: [...] >> >> I don't yet buy the security argument. There are many more shared parts >> on the SoC, like the clock controller, that would need to be taken away >> from the non-secure world if one would want to run an untrusted OS >> kernel on a i.MX8M system. >> >> To properly implement security on any i.MX8M based system the firmware >> would need to grow something like a full ARM SCPI implementation, so >> all shared critical peripherals are solely under firmware control. > > It might be possible to rework this to use some form of SCMI-over-SMC > instead of vendor-specific SMCCC SIP calls > Sounds feasible and good if all the custom IDs/calls/..etc are well hidden in the firmware(TF-A in this case) behind the existing abstraction in Linux kernel. > +SCMI maintainer > Thanks for including. >> I agree that it might make sense to move some parts into the firmware >> and have much simpler OS level drivers, but I don't agree on the >> implementation direction taken here. Growing custom PSCI extension >> interfaces will only get us so far, without solving the system security >> issue in a holistic way. It is my strong believe that only a complete >> rearchitecture of the OS support on top of a ARM SCPI firmware >> interface can solve this properly. +1 again, just to re-iterate the emphasis on the above and the degree to which I align with it. > Hiding everything critical for security (especially CCM) behind a SCMI > interface would be a large amount of work but introducing SCMI > incrementally (starting with imx8mm power) would be useful by itself > because it simplifies OS implementation. > Agreed, but not at the expense of introducing and maintaining *random* *one-off* *custom* SMC extensions. Sorry, that's not open to debate. > Many at NXP have attempted to evaluate SCMI and their conclusion has > always been that "many extensions are required". > I would like to hear the evaluation. Don't assume that you need to implement something similar to ARM SCMI reference design. All OSPM like Linux kernel cares is conformance to the interface, what/how you implement on the other side is left to you. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel