[PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[Jerome Forissier]

Some platforms may use a single device tree to describe two address
spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
for Secure-only devices"). We extend the use of the secure- prefix to
the stdout-path property, so that the Secure firmware may use a
different console device than the one used by the kernel.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
---
 Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
index e31303f..558c9a1 100644
--- a/Documentation/devicetree/bindings/arm/secure.txt
+++ b/Documentation/devicetree/bindings/arm/secure.txt
@@ -51,3 +51,8 @@ Valid Secure world properties:
    status = "disabled"; secure-status = "okay";     /* S-only */
    status = "disabled";                             /* disabled in both */
    status = "disabled"; secure-status = "disabled"; /* disabled in both */
+
+- secure-stdout-path (/chosen node): specifies the device to be used
+for console output by Secure firmware. The syntax is the same as for
+"stdout-path". If "secure-stdout-path" is not specified it defaults to
+the same value as "stdout-path".
-- 
2.7.4

Re: [PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[Rob Herring]

On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
<jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Some platforms may use a single device tree to describe two address
> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
> for Secure-only devices"). We extend the use of the secure- prefix to
> the stdout-path property, so that the Secure firmware may use a
> different console device than the one used by the kernel.
>
> Signed-off-by: Jerome Forissier <jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
> index e31303f..558c9a1 100644
> --- a/Documentation/devicetree/bindings/arm/secure.txt
> +++ b/Documentation/devicetree/bindings/arm/secure.txt
> @@ -51,3 +51,8 @@ Valid Secure world properties:
>     status = "disabled"; secure-status = "okay";     /* S-only */
>     status = "disabled";                             /* disabled in both */
>     status = "disabled"; secure-status = "disabled"; /* disabled in both */
> +
> +- secure-stdout-path (/chosen node): specifies the device to be used
> +for console output by Secure firmware. The syntax is the same as for
> +"stdout-path". If "secure-stdout-path" is not specified it defaults to
> +the same value as "stdout-path".

I'm not all that enthusiastic about this. This alone is okay, but
continued additions of secure-* properties doesn't seem very scalable.
Is this it or do you have other needs? What happens when we have 3
modes/address spaces?

Maybe we should allow stdout-path to have multiple strings and secure
fw grabs the first one and updates the DT removing it (perhaps only if
the device is secure only). Might be nice to have multiple ones
supported anyway (like we can do on the kernel command line:
"console=ttyS0 console=ttyS1").

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[Jerome Forissier]

On 03/01/2017 03:50 PM, Rob Herring wrote:
> On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
> <jerome.forissier@linaro.org> wrote:
>> Some platforms may use a single device tree to describe two address
>> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
>> for Secure-only devices"). We extend the use of the secure- prefix to
>> the stdout-path property, so that the Secure firmware may use a
>> different console device than the one used by the kernel.
>>
>> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
>> ---
>>  Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
>> index e31303f..558c9a1 100644
>> --- a/Documentation/devicetree/bindings/arm/secure.txt
>> +++ b/Documentation/devicetree/bindings/arm/secure.txt
>> @@ -51,3 +51,8 @@ Valid Secure world properties:
>>     status = "disabled"; secure-status = "okay";     /* S-only */
>>     status = "disabled";                             /* disabled in both */
>>     status = "disabled"; secure-status = "disabled"; /* disabled in both */
>> +
>> +- secure-stdout-path (/chosen node): specifies the device to be used
>> +for console output by Secure firmware. The syntax is the same as for
>> +"stdout-path". If "secure-stdout-path" is not specified it defaults to
>> +the same value as "stdout-path".
> 
> I'm not all that enthusiastic about this. This alone is okay, but
> continued additions of secure-* properties doesn't seem very scalable.
> Is this it or do you have other needs? What happens when we have 3
> modes/address spaces?

How is this different from status/secure-status?
I have no other needs for the moment. I'm experimenting with the
introduction of DT in OP-TEE. The secure-status property (or lack
thereof) already allows me to know if a device can be used by the secure
OS and how it should be mapped (secure vs. non-secure). This extension
allows me to reuse the same TEE binary and change the console, which is
a simple use case to demonstrate the advantage of using the DT in the
secure FW.

> Maybe we should allow stdout-path to have multiple strings and secure
> fw grabs the first one and updates the DT removing it (perhaps only if
> the device is secure only). Might be nice to have multiple ones
> supported anyway (like we can do on the kernel command line:
> "console=ttyS0 console=ttyS1").

The problem I see with removing entries is that the secure firmware may
have multiple stages (say, ARM Trusted Firmware plus a secure OS such as
OP-TEE).

Thanks,
-- 
Jerome

Re: [PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[Rob Herring]

On Wed, Mar 1, 2017 at 9:04 AM, Jerome Forissier <jerome.forissier@linaro.org> wrote:
>
>
> On 03/01/2017 03:50 PM, Rob Herring wrote:
>> On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
>> <jerome.forissier@linaro.org> wrote:
>>> Some platforms may use a single device tree to describe two address
>>> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
>>> for Secure-only devices"). We extend the use of the secure- prefix to
>>> the stdout-path property, so that the Secure firmware may use a
>>> different console device than the one used by the kernel.
>>>
>>> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
>>> index e31303f..558c9a1 100644
>>> --- a/Documentation/devicetree/bindings/arm/secure.txt
>>> +++ b/Documentation/devicetree/bindings/arm/secure.txt
>>> @@ -51,3 +51,8 @@ Valid Secure world properties:
>>>     status = "disabled"; secure-status = "okay";     /* S-only */
>>>     status = "disabled";                             /* disabled in both */
>>>     status = "disabled"; secure-status = "disabled"; /* disabled in both */
>>> +
>>> +- secure-stdout-path (/chosen node): specifies the device to be used
>>> +for console output by Secure firmware. The syntax is the same as for
>>> +"stdout-path". If "secure-stdout-path" is not specified it defaults to
>>> +the same value as "stdout-path".
>>
>> I'm not all that enthusiastic about this. This alone is okay, but
>> continued additions of secure-* properties doesn't seem very scalable.
>> Is this it or do you have other needs? What happens when we have 3
>> modes/address spaces?
>
> How is this different from status/secure-status?

It is not really, but I had concerns about the proliferation of secure-* properties then as well. That's why it says:

"However, only the properties listed below may validly have "secure-" versions; this list will be enlarged on a case-by-case basis."

> I have no other needs for the moment. I'm experimenting with the
> introduction of DT in OP-TEE. The secure-status property (or lack
> thereof) already allows me to know if a device can be used by the secure
> OS and how it should be mapped (secure vs. non-secure). This extension
> allows me to reuse the same TEE binary and change the console, which is
> a simple use case to demonstrate the advantage of using the DT in the
> secure FW.
>
>> Maybe we should allow stdout-path to have multiple strings and secure
>> fw grabs the first one and updates the DT removing it (perhaps only if
>> the device is secure only). Might be nice to have multiple ones
>> supported anyway (like we can do on the kernel command line:
>> "console=ttyS0 console=ttyS1").
>
> The problem I see with removing entries is that the secure firmware may
> have multiple stages (say, ARM Trusted Firmware plus a secure OS such as
> OP-TEE).

The only way you can have a shared console is if things are sequential.



Rob

Re: [PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[Robin Murphy]

On 01/03/17 15:04, Jerome Forissier wrote:
> 
> 
> On 03/01/2017 03:50 PM, Rob Herring wrote:
>> On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
>> <jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> Some platforms may use a single device tree to describe two address
>>> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
>>> for Secure-only devices"). We extend the use of the secure- prefix to
>>> the stdout-path property, so that the Secure firmware may use a
>>> different console device than the one used by the kernel.
>>>
>>> Signed-off-by: Jerome Forissier <jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
>>> index e31303f..558c9a1 100644
>>> --- a/Documentation/devicetree/bindings/arm/secure.txt
>>> +++ b/Documentation/devicetree/bindings/arm/secure.txt
>>> @@ -51,3 +51,8 @@ Valid Secure world properties:
>>>     status = "disabled"; secure-status = "okay";     /* S-only */
>>>     status = "disabled";                             /* disabled in both */
>>>     status = "disabled"; secure-status = "disabled"; /* disabled in both */
>>> +
>>> +- secure-stdout-path (/chosen node): specifies the device to be used
>>> +for console output by Secure firmware. The syntax is the same as for
>>> +"stdout-path". If "secure-stdout-path" is not specified it defaults to
>>> +the same value as "stdout-path".
>>
>> I'm not all that enthusiastic about this. This alone is okay, but
>> continued additions of secure-* properties doesn't seem very scalable.
>> Is this it or do you have other needs? What happens when we have 3
>> modes/address spaces?
> 
> How is this different from status/secure-status?
> I have no other needs for the moment. I'm experimenting with the
> introduction of DT in OP-TEE. The secure-status property (or lack
> thereof) already allows me to know if a device can be used by the secure
> OS and how it should be mapped (secure vs. non-secure). This extension
> allows me to reuse the same TEE binary and change the console, which is
> a simple use case to demonstrate the advantage of using the DT in the
> secure FW.

Once you start using DT in the secure OS, it doesn't seem too big a leap
for folks to want to start passing arguments, so I'd consider
secure-bootargs to be almost inevitable at *some* point down this road.

Perhaps we should consider a /secure-chosen node containing standard
properties instead...

>> Maybe we should allow stdout-path to have multiple strings and secure
>> fw grabs the first one and updates the DT removing it (perhaps only if
>> the device is secure only). Might be nice to have multiple ones
>> supported anyway (like we can do on the kernel command line:
>> "console=ttyS0 console=ttyS1").
> 
> The problem I see with removing entries is that the secure firmware may
> have multiple stages (say, ARM Trusted Firmware plus a secure OS such as
> OP-TEE).

...which different elements of firmware would in theory have a lot more
freedom to mangle between boot stages without the risk of disrupting the
regular /chosen properties.

Robin.

> 
> Thanks,
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[Jerome Forissier]

On 03/01/2017 04:20 PM, Robin Murphy wrote:
> On 01/03/17 15:04, Jerome Forissier wrote:
>>
>>
>> On 03/01/2017 03:50 PM, Rob Herring wrote:
>>> On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
>>> <jerome.forissier@linaro.org> wrote:
>>>> Some platforms may use a single device tree to describe two address
>>>> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
>>>> for Secure-only devices"). We extend the use of the secure- prefix to
>>>> the stdout-path property, so that the Secure firmware may use a
>>>> different console device than the one used by the kernel.
>>>>
>>>> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
>>>> index e31303f..558c9a1 100644
>>>> --- a/Documentation/devicetree/bindings/arm/secure.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/secure.txt
>>>> @@ -51,3 +51,8 @@ Valid Secure world properties:
>>>>     status = "disabled"; secure-status = "okay";     /* S-only */
>>>>     status = "disabled";                             /* disabled in both */
>>>>     status = "disabled"; secure-status = "disabled"; /* disabled in both */
>>>> +
>>>> +- secure-stdout-path (/chosen node): specifies the device to be used
>>>> +for console output by Secure firmware. The syntax is the same as for
>>>> +"stdout-path". If "secure-stdout-path" is not specified it defaults to
>>>> +the same value as "stdout-path".
>>>
>>> I'm not all that enthusiastic about this. This alone is okay, but
>>> continued additions of secure-* properties doesn't seem very scalable.
>>> Is this it or do you have other needs? What happens when we have 3
>>> modes/address spaces?
>>
>> How is this different from status/secure-status?
>> I have no other needs for the moment. I'm experimenting with the
>> introduction of DT in OP-TEE. The secure-status property (or lack
>> thereof) already allows me to know if a device can be used by the secure
>> OS and how it should be mapped (secure vs. non-secure). This extension
>> allows me to reuse the same TEE binary and change the console, which is
>> a simple use case to demonstrate the advantage of using the DT in the
>> secure FW.
> 
> Once you start using DT in the secure OS, it doesn't seem too big a leap
> for folks to want to start passing arguments, so I'd consider
> secure-bootargs to be almost inevitable at *some* point down this road.
> 
> Perhaps we should consider a /secure-chosen node containing standard
> properties instead...

Fine with me. I'll send a new patch.

>>> Maybe we should allow stdout-path to have multiple strings and secure
>>> fw grabs the first one and updates the DT removing it (perhaps only if
>>> the device is secure only). Might be nice to have multiple ones
>>> supported anyway (like we can do on the kernel command line:
>>> "console=ttyS0 console=ttyS1").
>>
>> The problem I see with removing entries is that the secure firmware may
>> have multiple stages (say, ARM Trusted Firmware plus a secure OS such as
>> OP-TEE).
> 
> ...which different elements of firmware would in theory have a lot more
> freedom to mangle between boot stages without the risk of disrupting the
> regular /chosen properties.