[U-Boot] [PATCH 00/10] AVB using OP-TEE

[Simon Glass <sjg@chromium.org>]

Hi Jens,

On 23 August 2018 at 05:23, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> Hi Simon,
>
> On Thu, Aug 23, 2018 at 12:45 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jens,
>>
>> On 13 August 2018 at 09:53, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>>> Hi,
>>>
>>> This adds support for storing AVB rollback indexes in the RPMB partition.
>>> The RPMB partition (content and key) is managed by OP-TEE
>>> (https://www.op-tee.org/) which is a secure OS leveraging ARM TrustZone.
>>>
>>> The Linux kernel can already support OP-TEE with reading and updating
>>> rollback indexes in the RPMB partition, the catch is that this is needed
>>> before the kernel has booted.
>>>
>>> The design here is the same as what is in the Linux kernel, with the
>>> exception that the user space daemon tee-supplicant is integrated in the
>>> OP-TEE driver here (drivers/tee/optee/supplicant.c) instead. A new uclass
>>> (UCLASS_TEE) is introduced to provide an abstraction for interfacing with a
>>> Trusted Execution Environment (TEE). There's also the OP-TEE driver using
>>> UCLASS_TEE for registration.
>>>
>>> A Trusted Application (TA) interface is added to be used by the AVB verify
>>> functions which are updated accordingly. The TA is managed by OP-TEE and is
>>> executed in a secure TrustZone protected environment.
>>>
>>> The header files drivers/tee/optee/optee_{msg,msg_supplicant,smc}.h and
>>> include/tee/optee_ta_avb.h are copied from
>>> https://github.com/OP-TEE/optee_os/tree/master more or less unmodified.
>>> They may need to be updated from time to time in order to support new
>>> features.
>>>
>>> In MMC there's a new function, mmc_rpmb_route_frames(), which as the name
>>> suggests is used to route RPMB frames to/from the MMC. This saves OP-TEE
>>> from implementing an MMC driver which would need to share resources with
>>> its counterpart here in U-boot.
>>>
>>> This was tested on a Hikey (Kirin 620) board.
>>>
>>> I've added myself as maintainer of the TEE stuff.
>>>
>>> Thanks,
>>> Jens
>>>
>>> Jens Wiklander (10):
>>>   dm: fdt: scan for devices under /firmware too
>>>   cmd: avb read_rb: print rb_idx in hexadecimal
>>>   mmc: rpmb: add mmc_rpmb_route_frames()
>>>   Add UCLASS_TEE for Trusted Execution Environment
>>>   dt/bindings: add bindings for optee
>>>   tee: add OP-TEE driver
>>>   arm: dt: hikey: Add optee node
>>>   optee: support routing of rpmb data frames to mmc
>>>   tee: optee: support AVB trusted application
>>>   avb_verify: support using OP-TEE TA AVB
>>>
>>>  MAINTAINERS                                   |   7 +
>>>  arch/arm/dts/hi6220-hikey.dts                 |   7 +
>>>  cmd/avb.c                                     |   2 +-
>>>  common/avb_verify.c                           | 132 +++-
>>>  .../firmware/linaro,optee-tz.txt              |  31 +
>>>  drivers/Kconfig                               |   2 +
>>>  drivers/Makefile                              |   1 +
>>>  drivers/core/root.c                           |  15 +-
>>>  drivers/mmc/rpmb.c                            | 160 +++++
>>>  drivers/tee/Kconfig                           |  18 +
>>>  drivers/tee/Makefile                          |   4 +
>>>  drivers/tee/optee/Kconfig                     |  23 +
>>>  drivers/tee/optee/Makefile                    |   5 +
>>>  drivers/tee/optee/core.c                      | 622 ++++++++++++++++++
>>>  drivers/tee/optee/optee_msg.h                 | 423 ++++++++++++
>>>  drivers/tee/optee/optee_msg_supplicant.h      | 234 +++++++
>>>  drivers/tee/optee/optee_private.h             |  41 ++
>>>  drivers/tee/optee/optee_smc.h                 | 444 +++++++++++++
>>>  drivers/tee/optee/rpmb.c                      | 184 ++++++
>>>  drivers/tee/optee/supplicant.c                |  92 +++
>>>  drivers/tee/tee-uclass.c                      | 180 +++++
>>>  include/avb_verify.h                          |   4 +
>>>  include/dm/uclass-id.h                        |   1 +
>>>  include/mmc.h                                 |   2 +
>>>  include/tee.h                                 | 141 ++++
>>>  include/tee/optee_ta_avb.h                    |  48 ++
>>>  26 files changed, 2816 insertions(+), 7 deletions(-)
>>>  create mode 100644 doc/device-tree-bindings/firmware/linaro,optee-tz.txt
>>>  create mode 100644 drivers/tee/Kconfig
>>>  create mode 100644 drivers/tee/Makefile
>>>  create mode 100644 drivers/tee/optee/Kconfig
>>>  create mode 100644 drivers/tee/optee/Makefile
>>>  create mode 100644 drivers/tee/optee/core.c
>>>  create mode 100644 drivers/tee/optee/optee_msg.h
>>>  create mode 100644 drivers/tee/optee/optee_msg_supplicant.h
>>>  create mode 100644 drivers/tee/optee/optee_private.h
>>>  create mode 100644 drivers/tee/optee/optee_smc.h
>>>  create mode 100644 drivers/tee/optee/rpmb.c
>>>  create mode 100644 drivers/tee/optee/supplicant.c
>>>  create mode 100644 drivers/tee/tee-uclass.c
>>>  create mode 100644 include/tee.h
>>>  create mode 100644 include/tee/optee_ta_avb.h
>>>
>>> --
>>> 2.17.1
>>>
>>
>> I missed the Android Verified Boot stuff going in. I did see the v1
>> patch but not the v2.
>>
>> Was there discussion of coding style for lib/libavb?
>
> I don't know. It was Igor who posted that.
>
>>
>> Also, how is this stuff tested in U-Boot? I don't see any tests.
>
> This depends on OP-TEE running in secure world.
> The tests are a bit destructive since we're writing in RPMB and also
> need to have a specific key programmed.
>
> Before posting the V2 patch set I did some final manual testing:
>
> => avb init 1
> => avb read_rb 0
> I/TC:  Dynamic shared memory is enabled
> Rollback index: 0
> => avb read_rb 1
> Rollback index: 0
> => avb read_rb 3
> Rollback index: 0
> => avb read_rb 4
> Rollback index: 0
> => avb read_rb 5
> Rollback index: 34
> => avb write_rb 5 3
> Failed to write rollback index
> => avb write_rb 5 35
> => avb write_rb 5 3
> Failed to write rollback index
> => avb read_rb 5
> Rollback index: 35

OK, I wonder if that can be converted into a simple test in test/py?

Better would be to have a fake sandbox OP-TEE implementation that we
can use to write a test of all the code. Does that sound feasible?

>
>
>>
>> For the uclass, please add a sandbox driver and test even if there are
>> no other tests.
>
> I've added that in the V2 patch set.

OK great.

Regards,
Simon