On Wed, Jan 21, 2015 at 7:01 PM, Greg Bellows <greg.bellows@xxxxxxxxxx> wrote: > Thanks Mark, comments inline. > > On Wed, Jan 21, 2015 at 10:29 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >> On Tue, Jan 20, 2015 at 07:15:51PM +0000, Greg Bellows wrote: >>> The addition of ARM security extension (TrustZone) support to QEMU has >>> exposed the issue of how secure resources are communicated to secure >>> software responsible for booting the HLOS. The natural choice for >>> communicating these details is the device tree. >>> >>> In the case of real hardware, the device tree supplied to the HLOS >>> only needs to describe non-secure resources as secure software can >>> rely on static knowledge about the hardware. This also holds true for >>> QEMU machines modeled after actual fixed hardware configurations. >>> However, this is not the case with QEMU's virtual machine models, such >>> as machvirt, where the hardware configuration can change over time. >> >> When you say this changes over time, I assume you mean for the lifetime >> of the project, as opposed to the lifetime of a running instance? i.e. >> non-probeable devices are not dynamically injected to a running system. >> > > Correct, the project. The QEMU machvirt device can be adapted over > time to include additional resources. > >>> In this case, secure software is dependent on QEMU's dynamically >>> constructed device tree to describe the hardware, making it impossible >>> for secure software to know ahead of time what is secure, non-secure, >>> or both. >>> >>> Two possible approaches for handling this particular case are: >>> >>> 1) Create two device tree blobs; one describing the non-secure >>> configuration and the other the full configuration. This would allow >>> secure software to see the full hardware picture including secure >>> resources while the non-secure world would only see the non-secure >>> device tree configuration. The QEMU virt machine would be responsible >>> for producing the device tree blobs. >>> >>> The drawbacks to this approach are: >>> * There are 2 device trees to manage >>> * The two DTBs will typically be almost identical. >>> * Not possible to identify whether a device is shared or not between >>> the secure and non-secure worlds. >>> * Identifying device available only to the secure world require >>> cumbersome comparison of the two device trees. >> >> I'm not sure I follow why such identification is necessary? >> > > Identifying secure resources would be necessary in cases where secure > resources are removed prior to passing to the next level. In some > cases, it may also be an indicator that the resource needs > initialization by secure SW. > >>> * A mechanism would be needed to pass an additional device tree. >>> >>> 2) Modify the standard device tree blob to include annotations or >>> modifications to describe which resources are secure or not. In this >>> case, secure software would use the single device tree to identify the >>> secure resources. The added information could be used by secure >>> software to trim the device tree before passing it. Alternatively, >>> the information could be passed on to non-secure software with the >>> expectation that it would honor the device security. It would be >>> crucial that any data added to the device tree adhere to existing >>> conventions or expectations. >> >> This approach assumes assumes that the secure and non-secure physical >> address spaces are identical bar some portions being masked out on the >> non-secure side. This is not necessarily the case. >> >> Architecturally the secure and non-secure physical address spaces are >> entiorely separate, and do not necessarily mirror each other. >> > > Considering that the secure world can access both the secure and > non-secure address spaces, it seems imperative that the resource > include information on whether it is secure or non-secure so the > correct address can be used. > >> It's entirely valid for some devices/RAM to only exist in one of the >> address spaces (we typically see secure-only devices, but >> non-secure-only devices are also possible). It's also entirely valid for >> the same device to be mapped at different addresses in each address >> space (e.g. the same UART could be mapped at both S:0xffff0000 and also >> at NS:0xcccc0000 and nowhere else in either address space). >> > > This certainly throws a wrench into things. Short of adding a > parallel "non-secure" indicator, approach #2 would fall short. > >> So approach (2) does not fit the architecture generally. From what I >> recall of previous discussions, we eventually figured out that you >> either need separate trees or a higher level container to address the >> secure vs nonsecure split. > > I was unaware of past discussions but it sounds like the two DT > approach was decidedly more preferable. It also sounds like the 2 DT > approach must include 2 full DTs rather than a secure-only and > non-secure only. The latter approach would not allow non-secure only > resources to be distinguishable from shared non-secure resources. > Using separate DTs, would there be any way for secure firmware to identify a device mapped at S:0xFOO and NS:0xBAR as being actually the same device? -Christoffer -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
