On Wed, Jan 21, 2015 at 4:21 PM, Rob Herring <robherring2@xxxxxxxxx> wrote: > On Tue, Jan 20, 2015 at 1:15 PM, Greg Bellows <greg.bellows@xxxxxxxxxx> wrote: >> 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. > > You could also do this w/o dts changes. You could start with a full > description and the knowledge of what to filter out resides in the > secure OS or bootloader. It depends where you want to put the > partitioning decisions. > > I think there's 2 main cases to consider. Full nodes that are assigned > to one side and Trustzone aware nodes. The first could potentially > re-use status property adding just a "secure" setting or we just add a > new "secure" property. This should probably be inherited by child > nodes. The secure firmware would then need to remove or set status to > disabled for those nodes. For the latter case, I don't think we can > avoid having the firmware having specific knowledge of the bindings. > We'll have to filter out the secure only details as I think so far we > have only been creating bindings which describe the non-secure view. I > don't think this is a big deal as the peripheral set would be pretty > limited AFAIK. This is close to what Greg and I discussed in a private thread. It would be just fine to use something like status="secure-okay" for the nodes that are secure world only. Secure world code would need to understand the new status value, but the existing kernel will do the correct thing. Only nodes with status="okay" or ="ok" will be used. There is no need to modify the tree at all in this scenario. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
