lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 Dec 2017 17:30:06 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Jens Wiklander <jens.wiklander@...aro.org>
Cc:     arm-soc <arm@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [GIT PULL] tee dynamic shm for v4.16

On Fri, Dec 15, 2017 at 2:21 PM, Jens Wiklander
<jens.wiklander@...aro.org> 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 <mark.rutland@....com> and Yury Norov
> <ynorov@...iumnetworks.com> 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?

      Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ