linux-kernel - Re: [linux-sunxi] Re: [PATCH] nvmem: sunxi-sid: add support for A64/H5's SID controller

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:   Tue, 19 Sep 2017 20:19:01 +0800
From:   icenowy@...c.io
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Chen-Yu Tsai <wens@...e.org>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...glegroups.com
Subject: Re: [linux-sunxi] Re: [PATCH] nvmem: sunxi-sid: add support for
 A64/H5's SID controller

在 2017-09-19 19:55，Maxime Ripard 写道：
> On Tue, Sep 19, 2017 at 04:23:14PM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2017年9月19日 GMT+08:00 下午4:20:19, Maxime Ripard 
>> <maxime.ripard@...e-electrons.com> 写到:
>> >On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote:
>> >> Allwinner A64/H5 SoCs come with a SID controller like the one in H3,
>> >but
>> >> without the silicon bug that makes the initial value at 0x200 wrong,
>> >so
>> >> the value at 0x200 can be directly read.
>> >>
>> >> Add support for this kind of SID controller.
>> >>
>> >> Signed-off-by: Icenowy Zheng <icenowy@...c.io>
>> >> ---
>> >>  Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1
>> >+
>> >>  drivers/nvmem/sunxi_sid.c                                       | 6
>> >++++++
>> >>  2 files changed, 7 insertions(+)
>> >>
>> >> diff --git
>> >a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
>> >b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
>> >> index ef06d061913c..6ea0836939ee 100644
>> >> --- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
>> >> +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
>> >> @@ -5,6 +5,7 @@ Required properties:
>> >>    "allwinner,sun4i-a10-sid"
>> >>    "allwinner,sun7i-a20-sid"
>> >>    "allwinner,sun8i-h3-sid"
>> >> +  "allwinner,sun50i-a64-sid"
>> >>
>> >>  - reg: Should contain registers location and length
>> >>
>> >> diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
>> >> index 0d6648be93b8..3c9fd4fb9207 100644
>> >> --- a/drivers/nvmem/sunxi_sid.c
>> >> +++ b/drivers/nvmem/sunxi_sid.c
>> >> @@ -199,10 +199,16 @@ static const struct sunxi_sid_cfg sun8i_h3_cfg
>> >= {
>> >>  	.need_register_readout = true,
>> >>  };
>> >>
>> >> +static const struct sunxi_sid_cfg sun50i_a64_cfg = {
>> >> +	.value_offset = 0x200,
>> >> +	.size = 0x100,
>> >> +};
>> >> +
>> >
>> >How did you get those values?
>> 
>> In the BSP U-Boot headers.
> 
> This should be mentionned in your commit log then.

P.S. the 0x200 offset is not in the header, but as a proven experience
on new generation SID controllers.

> 
>> >Also, it's reported that the SID can only be accessed in secure
>> >mode, did you test it?
>> 
>> Yes, however the secure is broken again, and this only
>> happen if Secure Boot bit is burned.
> 
> Is broken again, meaning?
> 
> As far as I know, the only breakage we've had is on the A80 / A83T,
> but we don't have anything like it on the A64, do we?

A80/A83T is not the *only* breakage, but the *most serious* breakage,
which affected correctly using SMP in non-secure.

Newer Allwinner SoCs doesn't have the GIC broken, but the TZPC still
doesn't work when not Secure Boot, which means that all peripherals
set to secure-only can still be accessed. Affected SoCs are at least
H3, H5, A64.

It seems that the registers marked as secure-only inside PRCM still
works -- however this still has no meaningful secure/non-secure
seperation, as the secure setting register in PRCM is not
secure-only at least on SoCs without SB enabled.

> 
>> If it's really burned, we will have no clean way to access SID.
> 
> Well, in such a case we shouldn't access it either, so..

We will need the THS calibration data.

Maybe a custom call to ATF can be created, but I consider it dirty.

> 
> Maxime