Subject: [Teep] Hardware for hackathons

From: Dave Thaler <[email-masked]>
Date: Tue, 19 Nov 2019 02:16:04 +0000

During the WG session today, in the discussion of potential hardware for future hackathons, I recommended the Grapeboard:
https://www.grapeboard.com/
This is an NXP Cortex A53 based board.

That's the board that's used in the commercial Scalys Trustbox routers:
https://scalys.com/trustbox-home-router/
which is the device that got the cybersecurity innovation award at CES 2019:
https://www.techrepublic.com/article/ces-2019-innovation-awards-honoree-trustbox-iot-security-router/

Dave

---

From: Akira Tsukamoto <[email-masked]>
Date: Tue, 19 Nov 2019 11:30:58 +0800

Hi Dave and Hannes,

The Grapeboard has more speed (single CortexA53, 64bit, 1GHz) compare to
STM32MP157C-DK2 (dual CortexA7, 32bit, 650Mhz).

The STM has 32-Gbit eMMC for rootfs while Grapeboard have to use SD
card for rootfs.

The Grapeboard have commonly used rootfs such as, Ubuntu and Yocto based Linux.

I will look into them.

-Akira

On Tue, Nov 19, 2019 at 10:16 AM Dave Thaler
<dthaler=[email-masked]> wrote:
> That’s the board that’s used in the commercial Scalys Trustbox routers:
>
> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep

---

From: Akira Tsukamoto <[email-masked]>
Date: Wed, 27 Nov 2019 18:53:36 +0900

Hi Dave, Hannes and Isobe-san,

For the further discussion for the future hackathon, I searched
information of Grapeboard and STM32MP157C-DK2 (which is STM CortexA7
devboard, I will abbreviate as StmA7board).

It is not mandatory but it would be nice to have/use unified
programing software stacks for the TEEP development on both TAM and
TEEP device.
I briefly mentioned about it on page 14 in the slide at IETF106.
https://datatracker.ietf.org/meeting/106/materials/slides-106-teep-sessb-teep-hackathon-report

Also, I looked inside the Dave`s OTrP over http implementation.
https://github.com/dthaler/OTrP

I have listed items for a discussion of the choices which were based
on what we used at the ietf106 hackathon.
Dave and Isobe-san, please correct me if I am wrong. :)

*) JSON stack:
(1) jansson, which Dave is using
https://github.com/akheron/jansson
(2) node.js, Isobe-san`s TAM
(3) json parser in libwebsockets, which my prototype is using
https://github.com/warmcat/libwebsockets/tree/master/lib/jose

*) JOSE stack:
(1) latchset/jose, which Dave is using
https://github.com/latchset/jose
(2) node.js?, Isobe-san`s TAM
(3) libwebsockets

*) HTTP stack:
(1) from scratch?, In Dave`s
https://github.com/dthaler/OTrP/blob/master/TeepTamBrokerLib/HttpServer.cpp
(2) libwebsockets, In mine

*) Crypto-tsl stack:
(1) openssl, Dave`s
(2) mbedtls, mine
Other than above, might good to use smaller libs, wolfSSL or s2n on
the device side?

*) rootfs
(1) Ubuntu?, Dave`s
(2) buildroot, mine

The default rootfs of dev boards introduced by Dave and Hannes.
*) Grapeboard
Ubuntu, customizable to Yocto/OE, OpenWRT and etc
*) StmA7board
Yocto/OE (OpenSTLinux)

Also, we have to consider the hardware requirements of SGX, ARM
TrustZone and RISC-V too.
The SGX is pretty handy since it could use simulation mode on any pc.
The op-tee is able to run on qemu too.

For the dev board, cross compiling is used so what to do on host pc,
Linux pc with ubuntu, win and etc.

And it would be really nice to have docker image for the dev
environment which includes necessary software stacks for developing
teep/otrp at least for developing TAM side.

The TAM and TEEP device do not have to be using the same software
stacks listed above.

I honestly do not have any preference listed above. I was late on the
boat and did not know what others have done in the past.

We do not have so much engineering resources at the moment, so I
thought it would be good to work on similar environment as possible to
able to focus on teep stack.

Akira

---

From: Akira Tsukamoto <[email-masked]>
Date: Wed, 27 Nov 2019 21:41:05 +0900

Hi,

I forgot to include about the CBOR parser.
I personally prefer to using CBOR parser at the next hackathon.

Isobe-san,
Do you mind looping Takita-san who had his CBOR parser at the
hackathon some time ago?
(BTW, should I be start using the first name instead of last name?)

-Akira

---

From: Dave Thaler <[email-masked]>
Date: Wed, 27 Nov 2019 19:54:47 +0000

Akira Tsukamoto <[email-masked]>  wrote:

[…]

*) HTTP stack:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdthaler%2FOTrP%2Fblob%2Fmaster%2FTeepTamBrokerLib%2FHttpServer.cpp&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C0a3d41fc466544f35b3c08d7731fb6ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637104452361234419&amp;sdata=okuidyiDF9gQA2chX325jS%2FG8bsH0VFhsDlX8jARpp0%3D&amp;reserved=0

It’s not from scratch, it’s calling the Windows HTTP APIs.   As currently written, that part of the code is Windows specific.  The other files shouldn’t be, so someone could create a non-Windows version of just that file.

Dave

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Nov 2019 08:18:27 +0100

> programing software stacks for the TEEP development on both TAM and

I will admit that I'm struggling a bit to understand the value of an interop
hackathon where everyone is using the same software.  I see the point for a
tutorial on a particular stack.  (I also come at this from the RATS point of
view, of soft TPMs running in TEEs, and also TEEs attesting to relying
parties rather than other TEE applications)

I also see a point in helping people who are building other components in the
ecosystem to learn how to bring up the things that they are intending to
interoperate with.

    > (2) buildroot, mine

This is a wide variety of options, and this is great!
I think that many these are TAM code though?

    > The op-tee is able to run on qemu too.

op-tee seems like it should be a default tutorial choice.

    > able to focus on teep stack.

I guess it is this last part which caused me to reply and comment above.
I think that we need to also consider that we might want to figure out the
different roles and make a table that way.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-