[U-Boot] [PATCH 00/10] AVB using OP-TEE
Jens Wiklander
jens.wiklander at linaro.org
Tue Aug 28 06:11:01 UTC 2018
On Thu, Aug 23, 2018 at 6:31 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Jens,
>
> On 23 August 2018 at 05:23, Jens Wiklander <jens.wiklander at linaro.org> wrote:
>> Hi Simon,
>>
>> On Thu, Aug 23, 2018 at 12:45 PM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Jens,
>>>
>>> On 13 August 2018 at 09:53, Jens Wiklander <jens.wiklander at 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?
Good idea, shouldn't be too hard.
Thanks,
Jens
More information about the U-Boot
mailing list