linux-kernel - Re: [PATCH v2] Documentation: dt: Add bindings for Secure-only devices

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, 12 Nov 2015 21:42:07 +0000
From:	Peter Maydell <peter.maydell@...aro.org>
To:	Rob Herring <robh@...nel.org>
Cc:	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roy Franz <roy.franz@...aro.org>,
	arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
	Kumar Gala <galak@...eaurora.org>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH v2] Documentation: dt: Add bindings for Secure-only devices

On 12 November 2015 at 21:33, Rob Herring <robh@...nel.org> wrote:
> On Thu, Nov 12, 2015 at 04:24:50PM +0000, Peter Maydell wrote:
>> The existing device tree bindings assume that we are only trying to
>> describe a single address space with a device tree (for ARM, either
>> the Normal or the Secure world). Some uses for device tree need to
>> describe both Normal and Secure worlds in a single device tree. Add
>> documentation of how to do this, by adding extra properties which
>> describe when a device appears differently in the two worlds or when
>> it only appears in one of them.
>>
>> The binding describes the general principles for adding new
>> properties describing the secure world, but for now we only need a
>> single new property, "secure-status", which can be used to annotate
>> devices to indicate that they are only visible in one of the two
>> worlds.
>>
>> The primary expected use of this binding is for a virtual machine
>> like QEMU to describe the VM layout to a TrustZone aware firmware
>> (which would then use the secure-only devices itself, and pass the DT
>> on to a kernel running in the non-secure world, which ignores the
>> secure-only devices and uses the rest).
>>
>> Signed-off-by: Peter Maydell <peter.maydell@...aro.org>
>
> I'd specifically like Mark's ack on this one.
>
>> ---
>> This binding doesn't affect the kernel itself, but the kernel
>> Documentation/ tree is the de-facto current place where all DT
>> bindings are documented, so Grant suggested this was the right
>> place to send a doc patch.
>>
>> Changes v1->v2:
>>  * list all the status/secure-status combinations explicitly
>>  * use /* */ comment syntax, not //
>>
>>  Documentation/devicetree/bindings/arm/secure.txt | 51 ++++++++++++++++++++++++
>>  1 file changed, 51 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/secure.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
>> new file mode 100644
>> index 0000000..7ed5ed6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/secure.txt
>> @@ -0,0 +1,51 @@
>> +* ARM Secure world bindings
>> +
>> +ARM CPUs with TrustZone support have two distinct address spaces,
>> +"Normal" and "Secure". Most devicetree consumers (including the Linux
>> +kernel) are not TrustZone aware and run entirely in either the Normal
>> +world or the Secure world. However some devicetree consumers are
>> +TrustZone aware and need to be able to determine whether devices are
>> +visible only in the Secure address space, only in the Normal address
>> +space, or visible in both. (One example of that situation would be a
>> +virtual machine which boots Secure firmware and wants to tell the
>> +firmware about the layout of the machine via devicetree.)
>> +
>> +The general principle of the naming scheme for Secure world bindings
>> +is that any property that needs a different value in the Secure world
>> +can be supported by prefixing the property name with "secure-". So for
>> +instance "secure-reg" would override "reg". If there is no "secure-"
>
> I'd prefer this be "secure-foo" and "foo", rather than reg given I
> specifically have a differing opinion on how to support reg.
>
> Also, would it be secure-vendor,foo or vendor,secure-foo for properties
> with vendor prefix? The latter looks more correct to me, but the former
> would be easier to search for both variants of the property. I'd lean
> towards the latter.

OK, so how about making that para read:

+ The general principle of the naming scheme for Secure world bindings
+ is that any property that needs a different value in the Secure world
+ can be supported by prefixing the property name with "secure-". So for
+ instance "secure-foo" would override "foo". For property names with
+ a vendor prefix, the Secure variant of "vendor,foo" would be
+ "vendor,secure-foo". If there is no "secure-" property then the Secure
+ world value is the same as specified for the Normal world by the
+ non-prefixed property. However, only the properties listed below may
+ validly have "secure-" versions; this list will be enlarged on a
+ case-by-case basis.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/