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=-5.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 7298DC433EC for ; Fri, 17 Jul 2020 18:02:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 42DF0206BE for ; Fri, 17 Jul 2020 18:02:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Gbgctdff"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="R/HdDOsh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42DF0206BE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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=g6pF4Tj4s+OmHrddNNNqJXNYJWakJSHMgpjdvWM66OY=; b=GbgctdffHfirpBJZcJLaS/k4n lQj5kGZ9tSYTiXZEjLKUm6mbLVV85bCXfXVI1De+1StNA9FXypK40F4MvaAmmTjTnERZrX5pz781K EPgKEwo1Lg65q3yBmcD/lmEyqsq/QDDYrv3P80NGIIq/k0kLw7VoCkddCsP4H/xD700v2dxhR+wPF agZcZ9dJKZ0OH8vW80LpZpIYRyvlSwwxYCnk6Ea5C+aduXCblA38GRh+KxY4kOptYTxYgbnJBr4go I9xSgXvGfowE6Y+gT+bjgah35GsPDIv7hXREBDmuOm3TFK4xl5FQ6wvYnuqstNQdPIEX4pMDbvCDW 9z7XgDLgw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwUfk-0001Dl-Bd; Fri, 17 Jul 2020 18:01:24 +0000 Received: from mail-pj1-x1044.google.com ([2607:f8b0:4864:20::1044]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwUfi-0001CA-2a for linux-arm-kernel@lists.infradead.org; Fri, 17 Jul 2020 18:01:23 +0000 Received: by mail-pj1-x1044.google.com with SMTP id mn17so6916180pjb.4 for ; Fri, 17 Jul 2020 11:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VL238xlzE0uThNd8yw3z5huUTHioHBP8n+FhWhde0QQ=; b=R/HdDOsh3SNE89aT+fxmoojuDw1sCd0hX3T4xZhEzvX6qhKsQCOUWq2QqB4wzy6kbv ieX+loghMB4LL4K5thbiV0rXahs4FCPHz115AEXf9uL9pwDzZ8dCb8bGdh5S9L209vI6 Vh3pEgtmyuy7VWsheZlEVt+U+izK7omWQyf2hR+mDoLzRLM+3OrouvVqj1lqeLQR3LPL 76cHS5mpmyzwNdxqxKN3YBY5iR4ctzoH81J6Jhi6EIUZkX5XPgSYB3faLcodnZpkQtXd hZIpZ9uNmqOZprTml6CmvPZGsVyjrHt4NsWJ5Ukf/WZmyZ8tWbINOnfH/GWcTL+Eo0RW Bb6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VL238xlzE0uThNd8yw3z5huUTHioHBP8n+FhWhde0QQ=; b=BPaHg3CIbaOOCkzp7NvhaTsfJEqZWwG6xwc4/7aBqJF958x0lNq/fbc6MxWSbSPR/I EUJTWyX5qK88VUd4nCpUKikLGnMqTimXiBbYz81GR2LnTT7p0ZU2w0uT7Nt5+LFC89w8 KREystwoi4r+z+ZIstKPCyKpwJufDPa+zIHOJ8Mi9lo71/wncMypkHpdEprY74lhxRe1 pI1dnFWc2xAwwM+AVOK8dXOUSAij48p3QHSZgdfuJHOwYc3aKGRT2FLxzyoupafNmYag gSuasnQgSXo56Ie3BM6mt0N2GKmRvG8jAt0IUR6BJUSA57hHq0oilln8C2X95OdimSBr wqoQ== X-Gm-Message-State: AOAM530s0Br9P21fF1GZscYFYWuraDHNBGA9amkMikzK7ZW+TS813Uvi SlUBTdMvV68q3+dOeDtHcRw= X-Google-Smtp-Source: ABdhPJwQBChusqU0m9hhRZGXsSSAwKKD+iMeLeYTuNQxzKk76Bvli6co32p1Y4fVKVHh1RsYOB7gzw== X-Received: by 2002:a17:902:c206:: with SMTP id 6mr8986437pll.30.1595008878209; Fri, 17 Jul 2020 11:01:18 -0700 (PDT) Received: from [10.230.30.107] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id d65sm8098061pfc.97.2020.07.17.11.01.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 11:01:17 -0700 (PDT) Subject: Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call To: Sudeep Holla References: <20200715165518.57558-1-daniele.alessandrelli@linux.intel.com> <5f74221b-aec7-7715-19d1-5cbb406f1bdc@gmail.com> <20200717094555.GA24501@bogus> From: Florian Fainelli Message-ID: Date: Fri, 17 Jul 2020 11:01:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200717094555.GA24501@bogus> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200717_140122_178602_D0CDE64D X-CRM114-Status: GOOD ( 29.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , "Paul J. Murphy" , linux-kernel@vger.kernel.org, "Paul J. Murphy" , Daniele Alessandrelli , Daniele Alessandrelli , 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+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 7/17/2020 2:45 AM, Sudeep Holla wrote: > On Wed, Jul 15, 2020 at 03:43:24PM -0700, Florian Fainelli wrote: >> >> >> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote: >>> From: Daniele Alessandrelli >>> >>> Currently, when SMC/HVC is used as transport, the base address of the >>> shared memory used for communication is not passed to the SMCCC call. >>> This means that such an address must be hard-coded into the bootloader. >>> >>> In order to increase flexibility and allow the memory layout to be >>> changed without modifying the bootloader, this patch adds the shared >>> memory base address to the a1 argument of the SMCCC call. >>> >>> On the Secure Monitor side, the service call implementation can >>> therefore read the a1 argument in order to know the location of the >>> shared memory to use. This change is backward compatible to existing >>> service call implementations as long as they don't check for a1 to be >>> zero. >> >> resource_size_t being defined after phys_addr_t, its size is different >> between 32-bit, 32-bit with PAE and 64-bit so it would probably make >> more sense to define an physical address alignment, or maybe an address >> that is in multiple of 4KBytes so you can address up to 36-bits of >> physical address even on a 32-bit only system? >> > > Good point, I had forgotten about LPAE. Thanks for pointing it out. > >> What discovery mechanism does the OS have that the specified address >> within the SMCCC call has been accepted by the firmware given the return >> value of that SMCCC call does not appear to be used or checked? Do we >> just expect a timeout initializing the SCMI subsystem? >> > > Agreed, we need to add the check for proper return value then and > definitely document it very clearly as we are trying to standardise > a call to vendor SiP FID space of SMCCC. > >> Given that the kernel must somehow reserve this memory as a shared >> memory area for obvious reasons, and the trusted firmware must also >> ensure it treats this memory region with specific permissions in its >> translation regime, does it really make sense to give that much flexibility? >> > > I expect so and this comes as shmem property from DT already. We are > just passing the value obtained from there as is. This is just to help > TFA or the firmware to identify the specific channel/shmem as SMC/HVC > otherwise has no way to do so. OK, that is fair enough. > >> If your boot loader has FDT patching capability, maybe it can also do a >> SMC call to provide the address to your trusted firmware, prior to >> loading the Linux kernel, and then they both agree, prior to boot about >> the shared memory address? >> > > Yes, but we definitely can't rely on such mechanism in the kernel. It is > more a platform choice as they run different bootloaders. > That argument can be be used the other way too if this is a platform choice, the platform boot loader can ensure that both ends of the SMC agree on the shared memory region. I do see an advantage to the approach being suggested here that the shared memory does not necessarily need to be mapped by the TF prior to Linux booting, but it can be deferred until when Linux makes the first SMC call but that may require more complexity on the TF side to issue an appropriate MMU update, so maybe from a security perspective this is more dangerous.. Alright, I am convinced now this is useful :) -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel