Re: [Teep] Hardware for hackathons

[塚本明 <[e-mail]>]

On 2019/11/28 16:18, Michael Richardson wrote:
> 
> Akira Tsukamoto <[e-mail]> wrote:
>      > 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 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.

Of course, it would be more beneficial to have variety of hardware and software
working and ready for interop testing.

At the moment, I really do not have both otrp and teep protocol over http
between TAM side and device side implemented on the real device, at least
at my place. We are still in the middle of developing it.

It would make me helpful to have some kind of consolidation to get to the
point of having working code and reflect the learning to the draft.

And then start porting to their software stacks and devices and having
variety of hardware and software would be really nice.

The objective is the same, I just was thinking of one step forward of
current situation.

> 
>      > *) 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
> 
> This is a wide variety of options, and this is great!
> I think that many these are TAM code though?

Yes, it is great.
My prototype device is on ARM board using op-tee.
It is able to install and delete TA on the device with my own TAM
but the message format is not compliant yet.
Do not use the strings written in the draft yet.

At the IETF 106 hackathon, it was my first time to try connecting to the
Dave's TAM and Isobe-san's TAM.
While I was tweaking the otrp message, I end up most of the time
fixing the http and json parser which is working underneath.

This is the reason I thought it will be good to focus on consolidate
and not have to much fragmentation of developing effort.

> 
>      > 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.
> 
> op-tee seems like it should be a default tutorial choice.

I prefer having reference of all sgx, optee and others but starting from one by one.

-Akira

> 
>      > 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.
> 
> 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 <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> TEEP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teep
>