From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754409AbbFKQfH (ORCPT ); Thu, 11 Jun 2015 12:35:07 -0400 Received: from down.free-electrons.com ([37.187.137.238]:57786 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752864AbbFKQfD (ORCPT ); Thu, 11 Jun 2015 12:35:03 -0400 Date: Thu, 11 Jun 2015 18:33:37 +0200 From: Maxime Ripard To: Chen-Yu Tsai Cc: Nicolas Pitre , Dave Martin , linux-arm-kernel , linux-kernel , linux-sunxi , Heiko =?iso-8859-1?Q?St=FCbner?= Subject: Re: [linux-sunxi] Re: [RFC 7/7] ARM: dts: sun9i: Add secure SRAM node used for MCPM SMP hotplug Message-ID: <20150611163337.GL19653@lukather> References: <1431583811-25780-1-git-send-email-wens@csie.org> <1431583811-25780-8-git-send-email-wens@csie.org> <20150520100831.GE4004@lukather> <20150525212419.GO8557@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oYAXToTM8kn9Ra/9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --oYAXToTM8kn9Ra/9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2015 at 12:47:49AM +0800, Chen-Yu Tsai wrote: > On Tue, May 26, 2015 at 5:24 AM, Maxime Ripard > wrote: > > On Sun, May 24, 2015 at 11:55:22PM +0800, Chen-Yu Tsai wrote: > >> On Wed, May 20, 2015 at 6:08 PM, Maxime Ripard > >> wrote: > >> > On Thu, May 14, 2015 at 02:10:11PM +0800, Chen-Yu Tsai wrote: > >> >> The A80 stores some magic flags in a portion of the secure SRAM. The > >> >> BROM jumps directly to the software entry point set by the SMP code > >> >> if the flags are set. This is required for CPU0 hotplugging. > >> >> > >> >> Signed-off-by: Chen-Yu Tsai > >> >> --- > >> >> arch/arm/boot/dts/sun9i-a80.dtsi | 20 ++++++++++++++++++++ > >> >> 1 file changed, 20 insertions(+) > >> >> > >> >> diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/s= un9i-a80.dtsi > >> >> index 1507bd2a88f0..0695215634d4 100644 > >> >> --- a/arch/arm/boot/dts/sun9i-a80.dtsi > >> >> +++ b/arch/arm/boot/dts/sun9i-a80.dtsi > >> >> @@ -366,6 +366,26 @@ > >> >> */ > >> >> ranges =3D <0 0 0 0x20000000>; > >> >> > >> >> + sram_b: sram@00020000 { > >> >> + /* 256 KiB secure SRAM at 0x20000 */ > >> >> + compatible =3D "mmio-sram"; > >> >> + reg =3D <0x00020000 0x40000>; > >> >> + > >> > > >> > We should probably add a property to that SRAM to tell the driver not > >> > to access it if we're not booted in secure mode. > >> > >> (CC-ing Heiko...) > >> > >> That kind of puts architecture (ARM) dependent code into a platform > >> driver. Furthermore, AFAIK there isn't a safe way to check if we're > >> in secure mode or not. Checking SCR raises an undefined instruction > >> exception in non-secure mode. Can the kernel handle that? I really > >> don't understand this bit well. > > > > That's a very good question. I'm pretty sure the kernel can know that, > > since it actually prints the execution mode, and must be able to know > > whether it can use the virtualization extensions or not I assume. >=20 > What you are referring to is HYP vs SVC mode. IIUC, this is not the > same as secure vs non-secure. The kernel can be booted into non-secure > SVC mode. Just disable CONFIG_CPU_V7_HAS_VIRT on mainline u-boot for > sun7i, and you get a system booted in non-secure mode. The architected > timer's non-secure interrupt firing is proof. >=20 > Which brings us back to my original question. Is there a way the kernel > can reliably detect whether it is in secure mode or not? Apparently, none at the architecture level. You might have some hints at the SoC level (like we do by writing to the secure RAM and read it back), but other SoCs might behave differently (like an abort, if we follow the same example). So one way might be to simply add a machine hook to determine whether we are in secure or not. > >> > Otherwise, bad things might happen. > >> > >> The kernel (or rather the bootloader) boots in secure mode by default, > >> and we don't have any bootloader support to boot into non-secure mode > >> ATM. > > > > That's not really true. We do have some U-Boot patches, and U-Boot > > might very well be setup to boot into HYP, even though it doesn't do > > anything else. >=20 > Same thing can be done for sun6i/sun8i. I should probably test this > and see if it has any impact on the current SMP bring-up. That's true, even though now we do have PSCI ;) > > And even so, the fact that we have no implementation yet doesn't mean > > that we won't have one in a few month. So just sweeping it under the > > carpet doesn't seem to be a very good solution. > > > >> Couldn't we have the bootloader mark the SRAM as disabled when > >> booting into non-secure when we add that support? > > > > It actually changes the kernel requirements to be able to > > boot. Changing that is not an option, especially since it's something > > that: 1) isn't dynamic in any way, 2) will possibly break the kernel > > if not done, 3) require synchronisation between the bootloader and the > > kernel when a new secure SRAM is added to the DT, and require an > > upgrade of the bootloader, 4) we might not be able to replace the > > bootloader in the first place. > > > > All of these issues make it look like a rather bad solution :/ >=20 > I think the discussions here depends on the question I asked earlier. > If the bootloader left the kernel in non-secure without any way to > signal this fact, then SMP probably won't work either. >=20 > Looking at the diagram on page 291 of the user manual, many critical > hardware blocks are marked as trusted (probably secure?), I don't > think we can boot Linux non-secure with the same DT... Maybe not, but our current way of working doesn't really care about that. I haven't really seen other platforms taking that into account either... Maybe adding a generic property to signal that a particular device is accessible in secure mode only would fix that? Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --oYAXToTM8kn9Ra/9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVebhhAAoJEBx+YmzsjxAgvtkP/167QN7L6wBY9QI20bn0r6Lu o9p+PUdNcJQKmFjyxogj8j3jHRcQFrIl1N4ysn2V2TyiM78Oz+T2/KDR0X9pQRJh wM8r3tshIU00TbsUpsAHvaHyhILDJupEuikOYDUE2wWWRomV0EUk2ACgrZWv3ghj HGTzUQ3wr56GlKL4TYGWnlOjh7bKPKScsGr1IUDDVfjk5lFN3xoxk6+D/NsRIu7J jgL6KRaFoikRwVwq0vI0n+u/+qt0fyP+p7ur5bIRcvQOUI9j2MTK2buZJcSKjqSf RUrZ6i+e0L2EHCdX6CJqXxLvgWI4v6ckZycpiVhFjYdwktT3ysuJZ1LQSmu2I6pj 6zFDe0wZopMffbwWXfH8TrsdnBnek+al64Iml1GMcjQr/DGYUY2gtDIeFRpKre/z H5UhMGussJZga2W2EhhqQH5lT1xZVSxtz/yi+RZJPbkZWt0LP7lxU/KkGzUDbmgU 8Q4HmosefoVSkblfuz/HtTjjTXTQuNyISQNx+jZxroWz0HKFMt+45tLoTfBBFhai Y6KPl4uhskYR7EUVGaXBUDS9YwR9F7PoBq+F/n3SoF0A0EWBHhB0FASFWFT7vL3C eIwX5bJDaz27knWNKbY7qeDWzKNkKc7OHL2Ojl/Qz3HxDjo5SfOw5FLmgokCf4sG CxoocbHQuR/uED6kf2qp =oOTn -----END PGP SIGNATURE----- --oYAXToTM8kn9Ra/9-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: maxime.ripard@free-electrons.com (Maxime Ripard) Date: Thu, 11 Jun 2015 18:33:37 +0200 Subject: [linux-sunxi] Re: [RFC 7/7] ARM: dts: sun9i: Add secure SRAM node used for MCPM SMP hotplug In-Reply-To: References: <1431583811-25780-1-git-send-email-wens@csie.org> <1431583811-25780-8-git-send-email-wens@csie.org> <20150520100831.GE4004@lukather> <20150525212419.GO8557@lukather> Message-ID: <20150611163337.GL19653@lukather> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, May 27, 2015 at 12:47:49AM +0800, Chen-Yu Tsai wrote: > On Tue, May 26, 2015 at 5:24 AM, Maxime Ripard > wrote: > > On Sun, May 24, 2015 at 11:55:22PM +0800, Chen-Yu Tsai wrote: > >> On Wed, May 20, 2015 at 6:08 PM, Maxime Ripard > >> wrote: > >> > On Thu, May 14, 2015 at 02:10:11PM +0800, Chen-Yu Tsai wrote: > >> >> The A80 stores some magic flags in a portion of the secure SRAM. The > >> >> BROM jumps directly to the software entry point set by the SMP code > >> >> if the flags are set. This is required for CPU0 hotplugging. > >> >> > >> >> Signed-off-by: Chen-Yu Tsai > >> >> --- > >> >> arch/arm/boot/dts/sun9i-a80.dtsi | 20 ++++++++++++++++++++ > >> >> 1 file changed, 20 insertions(+) > >> >> > >> >> diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi > >> >> index 1507bd2a88f0..0695215634d4 100644 > >> >> --- a/arch/arm/boot/dts/sun9i-a80.dtsi > >> >> +++ b/arch/arm/boot/dts/sun9i-a80.dtsi > >> >> @@ -366,6 +366,26 @@ > >> >> */ > >> >> ranges = <0 0 0 0x20000000>; > >> >> > >> >> + sram_b: sram at 00020000 { > >> >> + /* 256 KiB secure SRAM at 0x20000 */ > >> >> + compatible = "mmio-sram"; > >> >> + reg = <0x00020000 0x40000>; > >> >> + > >> > > >> > We should probably add a property to that SRAM to tell the driver not > >> > to access it if we're not booted in secure mode. > >> > >> (CC-ing Heiko...) > >> > >> That kind of puts architecture (ARM) dependent code into a platform > >> driver. Furthermore, AFAIK there isn't a safe way to check if we're > >> in secure mode or not. Checking SCR raises an undefined instruction > >> exception in non-secure mode. Can the kernel handle that? I really > >> don't understand this bit well. > > > > That's a very good question. I'm pretty sure the kernel can know that, > > since it actually prints the execution mode, and must be able to know > > whether it can use the virtualization extensions or not I assume. > > What you are referring to is HYP vs SVC mode. IIUC, this is not the > same as secure vs non-secure. The kernel can be booted into non-secure > SVC mode. Just disable CONFIG_CPU_V7_HAS_VIRT on mainline u-boot for > sun7i, and you get a system booted in non-secure mode. The architected > timer's non-secure interrupt firing is proof. > > Which brings us back to my original question. Is there a way the kernel > can reliably detect whether it is in secure mode or not? Apparently, none at the architecture level. You might have some hints at the SoC level (like we do by writing to the secure RAM and read it back), but other SoCs might behave differently (like an abort, if we follow the same example). So one way might be to simply add a machine hook to determine whether we are in secure or not. > >> > Otherwise, bad things might happen. > >> > >> The kernel (or rather the bootloader) boots in secure mode by default, > >> and we don't have any bootloader support to boot into non-secure mode > >> ATM. > > > > That's not really true. We do have some U-Boot patches, and U-Boot > > might very well be setup to boot into HYP, even though it doesn't do > > anything else. > > Same thing can be done for sun6i/sun8i. I should probably test this > and see if it has any impact on the current SMP bring-up. That's true, even though now we do have PSCI ;) > > And even so, the fact that we have no implementation yet doesn't mean > > that we won't have one in a few month. So just sweeping it under the > > carpet doesn't seem to be a very good solution. > > > >> Couldn't we have the bootloader mark the SRAM as disabled when > >> booting into non-secure when we add that support? > > > > It actually changes the kernel requirements to be able to > > boot. Changing that is not an option, especially since it's something > > that: 1) isn't dynamic in any way, 2) will possibly break the kernel > > if not done, 3) require synchronisation between the bootloader and the > > kernel when a new secure SRAM is added to the DT, and require an > > upgrade of the bootloader, 4) we might not be able to replace the > > bootloader in the first place. > > > > All of these issues make it look like a rather bad solution :/ > > I think the discussions here depends on the question I asked earlier. > If the bootloader left the kernel in non-secure without any way to > signal this fact, then SMP probably won't work either. > > Looking at the diagram on page 291 of the user manual, many critical > hardware blocks are marked as trusted (probably secure?), I don't > think we can boot Linux non-secure with the same DT... Maybe not, but our current way of working doesn't really care about that. I haven't really seen other platforms taking that into account either... Maybe adding a generic property to signal that a particular device is accessible in secure mode only would fix that? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: