Porting of TUF Client to embedded C/C++

[Hans Wurst]

Hi there,

I have more a general kind of question regarding the possibility to port the client to run on an embedded device... Has something like this already been done or does it have too many python library dependencies to do so?

I would highly appreciate any comment to help me here.

[Santiago Torres]

Hello Hans,

There are many clients in different languages. I personally would advice
of perhaps looking at rust-tuf/go-tuf to run in an embedded device (I
believe that in fact rust-tuf has been used that way already). I wonder
if you'd want to even use some sort of ffi to call client functions
inside of C code, and save yourself dev time.

Of course, if you decide to re-implement TUF in C or C++ we'd love to
hear about it.

I hope this helps!
-Santiago

> --
> You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/78cc657f-6552-4f06-bb16-5725deb3509an%40googlegroups.com.

[Jussi Kukkonen]

Hi Hans,

Python-TUF does not depend on an overwhelming amount of dependencies. The big ones are requests and securesystemslib (and the crypto dependencies it has) but obviously TUF uses the base library modules quite a lot as python code tends to do. I wouldn't recommend thinking of a C++ (or even C) implementation as a port of python-tuf: Both because It's unlikely that a good python design would be good in those languages but also because the python-tuf design has some issues unrelated to language: you would not want to copy those. Looking at it as a reference could certainly be useful.

Now, I don't what to be "that guy" who recommends a complete different language to a question specifically about a language... but I have to agree with Santiagos comments: Writing new security related components in C (or C++) would not be my first, second or third option in the year 2020. I'd definitely look at the rust ang go TUF implementations that already exist (I'm not familiar with them so not commenting on maturity). Even if I needed a library that I wanted to call from a C application, I'd consider e.g. using a rust library with a C FFI layer on top if needed. I admit I've never actually done that so the last part is just hand waving. 

Hope this helps,

 Jussi

---

From: 'Hans Wurst' via The Update Framework (TUF) <theupdate...@googlegroups.com>
Sent: Monday, 30 November 2020 14.23
To: The Update Framework (TUF) <theupdate...@googlegroups.com>
Subject: [tuf] Porting of TUF Client to embedded C/C++

 

Hi there,

I have more a general kind of question regarding the possibility to port the client to run on an embedded device... Has something like this already been done or does it have too many python library dependencies to do so?

I would highly appreciate any comment to help me here.

[Hans Wurst]

thank you both so much for your replies. I'll checkout the tuf-rust port. The problem is that running any form of interpreter on real-time-embedded devices is often just not possible. Memory handling might also be done by individual real-time-operating systems (e.g. FreeRTOS, embOS, ....). But we're still talking of devices requiring firmware updates. Do you have some kind of a block diagram describing more of the internal structure and required dependencies? Anything would help to estimate the afford of porting.  

[Trishank Kuppusamy]

On Wed, Dec 2, 2020 at 5:47 PM 'Hans Wurst' via The Update Framework (TUF) <theupdate...@googlegroups.com> wrote:

thank you both so much for your replies. I'll checkout the tuf-rust port. The problem is that running any form of interpreter on real-time-embedded devices is often just not possible. Memory handling might also be done by individual real-time-operating systems (e.g. FreeRTOS, embOS, ....). But we're still talking of devices requiring firmware updates. Do you have some kind of a block diagram describing more of the internal structure and required dependencies? Anything would help to estimate the afford of porting.  

You mean for python-tuf? go-tuf or rust-tuf should compile to a single, standalone binary... 

[Tony Arcieri]

rust-tuf and awslabs/tough (also Rust) should both be good candidates.

Neither are written in the embedded-friendly subset of Rust (no_std) , but I think it would be significantly easier to modify one of these to be embedded friendly than it would to be to try to make a new implementation from scratch, as both have considerable work done (by Google and Amazon respectively)

--

Tony Arcieri

[Erick Tryzelaar]

I maintain rust-tuf, and yeah, I think it wouldn't be *that* hard to make a C/C++ wrapper around the rust library. To add on to what Tony said (Hi Tony, It's been too long!), I'm not too familiar with what real time operating systems provide to applications. Do they come with heap allocator support? If not, then it could take quite a bit of work to adapt rust-tuf to that world, since we use a bunch of heap allocated strings, vectors, maps, and etc. We also leverage the rust async infrastructure, which may or may not come with further constraints.

That said, I've toyed around with trying to refactor rust-tuf to extract out the core TUF state machine. It might be possible to make that allocation free. Then we could implement a variety of front ends that handle fetching the metadata. I haven't made that much progress with that yet though.

-Erick

--

You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/CAHOTMV%2BvSx8nqmsnYfxGgsdTuENZiGEa%3DHpwSVsbQgLWG8-WRA%40mail.gmail.com.

[Daniel Kaleja]

Thank you all for your good and valuable information. Now I can estimate the afford I would be facing by implementing rust-tuf (which is still having a version < 1.0) into a c/c++ environment.