From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35655)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1acwy6-0007DZ-Em
	for qemu-devel@nongnu.org; Mon, 07 Mar 2016 10:21:13 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1acwy2-0006CD-Ge
	for qemu-devel@nongnu.org; Mon, 07 Mar 2016 10:21:10 -0500
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
References: <1455288361-30117-1-git-send-email-peter.maydell@linaro.org>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <56DD9C58.7050306@redhat.com>
Date: Mon, 7 Mar 2016 16:20:56 +0100
MIME-Version: 1.0
In-Reply-To: <1455288361-30117-1-git-send-email-peter.maydell@linaro.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and
	first flash
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org, Markus Armbruster <armbru@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>



On 12/02/2016 15:45, Peter Maydell wrote:
> This patchset adds some more secure-only devices to the virt board:
>  (1) a 16MB secure-only RAM
>  (2) the first flash device is secure-only
> 
> The second of these is strictly speaking a breaking change, but I don't
> expect it in practice to break anybody:
>  (a) there's not much use of the secure support in virt yet
>  (b) anything booting a rom image from that flash if TZ is enabled
>   will be booting it in Secure mode anyway so will be able to access
>   the code -- the only thing that would stop working would be if the
>   guest flipped to NS and still expected to be able to access the flash
> 
> The second flash device remains NS-accessible (with the expectation that
> it will be used for NS UEFI environment variable storage).

I think that, if UEFI secure boot is in use, the UEFI environment
variables should also be only accessible from TrustZone, because they
store the key database.  At least that's how it works on x86, where both
pflash devices have the secure=on flag.

Paolo