TamaGo – bare metal Go for ARM SoCs | Hacker News Reader

TamaGo – bare metal Go for ARM SoCs

github.com

184 pointsdgellow28 comments

This blog article from February of this year gives some context: https://labs.f-secure.com/blog/tamago/

> TamaGo reduces the attack surface of embedded systems firmware by removing any run time dependency on C code and inherently complex Operating Systems.

> It does so with minimal changes to the Go run time and a set of packages to provide drivers for supported boards.

Ok so it removes the C surface of attack, but does it not introduce the Go one? What makes it superior when it comes to security?

For starters:

- Bounds checking for strings and arrays

- Proper strings

- No implicit type conversions

- Unsafe code requires use of unsafe package, thus very easy to track down in code reviews

- No need for pointer arithmetic everywhere, using fat pointers instead (slices)

- For "generic" code interface{} is type safe, whereas void* can be anything

- No use-after-free thanks GC

Thank you! Are you aware of any surfaces of attack against Go that do no exist in C?

Only stuff that might exploit bugs in the standard library, or runtime implementation.

As everything, even formal specification based languages might have logical bugs in them.

What C gets on top of that are memory corruption bugs and optimization bugs caused by optimizers taking advantage of UB.

Naturally that can also happen in unsafe code blocks in other languages, the big difference in C is due to its strings and arrays, almost every line of code manipulates pointers without bounds checking, and exploits ensue.

Last year I discovered TinyGo (tinygo.org). Looking at the list of supported hardware I see quite a few ARM SoCs there. I also believe Google supports the TinyGo project in some shape or form.

So why does TamaGo exists? (No snark, just curious)

I quickly looked up TinyGo and it seems to have a larger scope than TamaGo. For example it supports several Atmel microcontrollers that are not ARM based. TamaGos scope is smaller as they only support ARM.

I'm sure there are more differences.

Edit: They answer the question in their faq https://github.com/f-secure-foundry/tamago/wiki/Frequently-A...

Thanks.

So, for other who are curious. TamaGo is focused on certain ARM SoCs. So CPUs rather than microcontrollers. TamaGo is more or less a fully fledged go running on bare metal.

Pretty cool, actually.

Also there's gokrazy[0]: "a pure-Go userland for your Raspberry Pi 3 or 4 appliances"

[0] https://github.com/gokrazy/gokrazy

gokrazy is not bare metal as it bundles a Linux kernel, so it's basically a mini-Linux distro and therefore quite different.

This looks great! Thanks for sharing.

TinyGo is a re-implementation (in progress) of Go (mostly from the ground up), and using LLVM as the backend for code generation.

TamaGo appears to be standard Go, forked to add support for specific boards.

The TamaGo logo is the Golang Gopher in an egg. Tamago (卵) means egg in Japanese. I'm guessing this was intentional :)

Yup, probably a reference to the Tamagotchi. For the younger readers out there: https://en.m.wikipedia.org/wiki/Tamagotchi

No, that's a separate coinage. "Tamagotchi" is a portmanteau of "tamago" (egg) and "uotchi" (watch).

This is why I love hacker news.

Now I feel old for thinking Tamagotchi was common knowledge.

Random trivia: "tamago" can also be written as 玉子, which means something like "round child". 卵 is used for any kind of egg, 玉子 mostly for cooked chicken eggs.

> Well, you might be surprised to know that there is not a single line of C involved in serving this connection as well as the underlying terminal and functionality.

I was quite dubious of this. Surely the Go runtime is written in C? Turns out that no, Go is self-hosting. The runtime for Go is written in Go. So if you remove the OS, which they did, you have reinvented the wheel! A rounder wheel, this time, to be sure.

The previous wheels I'm referring to are Pascal, Java, Lisp, Forth, Prolog machines. This wheel is a different shape because those others are dedicated, purpose-built hardware, that can only execute those languages.

I wonder can the same (as Tamago, not Pascal et al.) be done for Rust?

https://randoc.wordpress.com/2014/05/01/western-digital-pasc...

I don’t really see the application for bare metal Go. If you’re creating a bare metal application you’re most likely doing it in order to achieve real time computation, something which a garbage collected language can’t offer.

Real-time has very little to do with the motivation behind this project or writing on bare metal.

We are writing on bare metal to get rid of hundreds of dependencies and millions of lines of unnecessary code to run single-purpose firmware applications.

As an example, if you want to write a cryptocurrency wallet using Go crypto and web libraries, wouldn't it better to do so without the burden of an entire Linux kernel, its userspace and a complex bootloader?

Please check this presentation for more background on motivations behind this project:

https://www.youtube.com/watch?v=4QircrJjEtQ

A good intro to tamago: https://media.ccc.de/v/36c3-10597-tamago_-_bare_metal_go_fra...

Can someone ELI5 the meaning of "bare metal" in this context?

TamaGo takes the place of the operating system and it's drivers, so it is between the use application and the hardware.

Could this potentially be used to compile something like k8s (obv with a custom container engine) so that you could run k8s right on a SoC and no OS getting in your way?

This is cool as heck. Are there any examples of real use cases that are feasible at TamaGo's current stage of development?

Example #1: https://github.com/f-secure-foundry/GoKey

Example #2: https://twitter.com/AndreaBarisani/status/130368998099743949...

(which runs, on the USB armory Mk II, a modified version of https://github.com/f-secure-foundry/armory-ums)

Does anyone know if there’s potential support for newer Pi’s?

Reply on news.ycombinator.com