From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753161AbdLYVWZ (ORCPT ); Mon, 25 Dec 2017 16:22:25 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:55026 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752812AbdLYVWW (ORCPT ); Mon, 25 Dec 2017 16:22:22 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3943E6071B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=tzeng@codeaurora.org Subject: Re: [GIT PULL] tee dynamic shm for v4.16 To: Arnd Bergmann , Jens Wiklander Cc: arm-soc , Linux Kernel Mailing List , zkong@codeaurora.org, bmanohar@qti.qualcomm.com, chenroid@codeaurora.org, Linux ARM References: <20171215132057.ang2xawtpzp5eb6o@jax> From: thomas zeng Message-ID: <6acdbda2-d1b1-127c-a6e4-df30dc5e200b@codeaurora.org> Date: Mon, 25 Dec 2017 13:22:18 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017年12月21日 08:30, Arnd Bergmann wrote: > On Fri, Dec 15, 2017 at 2:21 PM, Jens Wiklander > wrote: >> Hello arm-soc maintainers, >> >> Please pull these tee driver changes. This implements support for dynamic >> shared memory support in OP-TEE. More specifically is enables mapping of >> user space memory in secure world to be used as shared memory. >> >> This has been reviewed and refined by the OP-TEE community at various >> places on Github during the last year. An earlier version of this pull >> request is used in the latest OP-TEE release (2.6.0). This has also been >> reviewed recently at the kernel mailing lists, with all comments from >> Mark Rutland and Yury Norov >> addressed as far as I can tell. >> >> This isn't a bugfix so I'm aiming for the next merge window. > Given that Mark and Yury reviewed this, I'm assuming this is all > good and have now merged it. However I missed the entire discussion > about it, so I have one question about the implementation: > > What happens when user space passes a buffer that is not > backed by regular memory but instead is something it has itself > mapped from a device with special page attributes or physical > properties? Could this be inconsistent when optee and user > space disagree on the caching attributes? Can you get into > trouble if you pass an area from a device that is read-only > in user space but writable from secure world? Just recently, we have started to kick the tires of these "shm" related Gen Tee Driver patches.  And we have in the past encountered real world scenarios requiring some of the shared memory regions to be marked as "normal IC=0 and OC=0" in EL2 or SEL1, or else HW would misbehave. We worked around by hacking the boot code but that works if the regions are pre-allocated. Since now these regions can also be managed dynamically, we definitely agree with Arnd Bergmann that the dynamic registration SMC commands, and potention the SHM IOCTL commands, must convey cache intentions. Is it possible to take this requirement into consideration, in this iteration or the follow on? > > Arnd > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel