Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754697Ab3FGIwO (ORCPT ); Fri, 7 Jun 2013 04:52:14 -0400 Received: from mail-pd0-f179.google.com ([209.85.192.179]:48917 "EHLO mail-pd0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754631Ab3FGIwJ (ORCPT ); Fri, 7 Jun 2013 04:52:09 -0400 MIME-Version: 1.0 In-Reply-To: References: <1370503687-17767-1-git-send-email-acourbot@nvidia.com> Date: Fri, 7 Jun 2013 14:22:08 +0530 Message-ID: Subject: Re: [PATCH] ARM: tegra: add basic SecureOS support From: Jassi Brar To: Alexandre Courbot Cc: Alexandre Courbot , Stephen Warren , Joseph Lo , Karan Jhavar , Varun Wadekar , Chris Johnson , Matthew Longnecker , "devicetree-discuss@lists.ozlabs.org" , Linux Kernel Mailing List , "linux-tegra@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2312 Lines: 49 On Fri, Jun 7, 2013 at 12:43 PM, Alexandre Courbot wrote: > On Thu, Jun 6, 2013 at 9:26 PM, Jassi Brar wrote: >> On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot wrote: >>> Boot loaders on some Tegra devices can be unlocked but do not let the >>> system operate without SecureOS. SecureOS prevents access to some >>> registers and requires the operating system to perform certain >>> operations through Secure Monitor Calls instead of directly accessing >>> the hardware. >>> >> IOW, some critical h/w controls on Tegra are accessible only from >> Secure mode (not unusual). So if we(Linux) run in NS mode we need to >> make calls to the SecureOS, over SMC, to do things for us? > > Exactly. > OK so this just an instance of a situation that is going to be more common in future - most modern cpus (CortexA based at least) support TrustZone and it's a matter of device functionality before a board designer chucks the Linux kernel (that we usually run in Secure mode while development) into NS mode and have some SecureOS/TrustedOS/Hypervisor et al control access to the secure peripherals from Secure Mode. >>> This patch introduces basic SecureOS support for Tegra. SecureOS support >>> can be enabled by adding a "nvidia,secure-os" property to the "chosen" >>> node of the device tree. >>> >> Probably just a nit, but shouldn't it be "nvidia,nonsecure-os" >> instead, denoting the mode Linux is going to run? (and then I wonder >> if we could detect the mode (S or NS) at runtime and avoid this flag >> at all). > > Detection of the secure mode at runtime would only solve half of the > issue: we would know that we are running in non-secure mode, but we > would still not know what monitor is operating. Detecting that part is > impossible AFAIK, so I'm afraid we need to pass that information > through the DT here. > Yes, Stephen's suggestion is far more generally applicable. We should go for it, just bearing in mind that ABI need and type is going to be board specific. Cheers, -Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/