From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgCAZ-00048L-9f for qemu-devel@nongnu.org; Thu, 09 Apr 2015 09:06:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgCAS-0005OG-Pg for qemu-devel@nongnu.org; Thu, 09 Apr 2015 09:06:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgCAS-0005O5-GX for qemu-devel@nongnu.org; Thu, 09 Apr 2015 09:06:48 -0400 Message-ID: <5526795F.1020802@redhat.com> Date: Thu, 09 Apr 2015 15:06:39 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1428582043-19080-1-git-send-email-pbonzini@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Edgar E. Iglesias" , Peter Crosthwaite , Laszlo Ersek , QEMU Developers , Gerd Hoffmann On 09/04/2015 14:47, Peter Maydell wrote: > On 9 April 2015 at 13:20, Paolo Bonzini wrote: >> This is an example of usage of attributes in a device model. It lets >> you block flash writes unless the CPU is in secure mode. Enabling it >> currently requires a -readconfig file: >> >> [global] >> driver = "cfi.pflash01" >> property = "secure" >> value = "on" >> >> because the driver includes a "."; however, I plan to enable this through >> the command line for the final version of the patches. > > Are real flash devices ever wired up like this? On x86 machines it is almost exactly like this. I'm implementing x86 system management mode, and I'm reusing MEMTXATTRS_SECURE for it. Recent x86 chipsets make this a run-time setting, rather than a static setting, but the idea is the same. It is a run-time setting (chipset register) so that the firmware can do some initial detection of the flash outside system management mode. Then it writes a 1 to the register, and finally it writes a 1 to a "lock" register so that the first register becomes read-only. The above scheme was actually more complicated, and allowed a race that let you bypass the protection. So, even more recent machines have some additional complication, whereby flash accesses are only allowed if _all_ processors are in system management mode. Again, it is a run-time setting. QEMU emulates a slightly older chipset, which is why I'm making it a static property. The static property is also much harder to get wrong and insecure by mistake. Paolo > I would expect boards which want to provide secure-mode > only flash to do so by not giving any access at all to > the device from the non-secure address space. > > (Supporting multiple AddressSpaces for ARM CPUs is the > next thing on my todo list; as well as partitioning the > flash this would allow secure-mode-only RAM and UARTs, > for instance.) > > -- PMM >