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.
> 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.
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.
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.
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?
> 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?
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:
31 comments
[ 3.0 ms ] story [ 57.5 ms ] thread> 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.
- 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
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.
So why does TamaGo exists? (No snark, just curious)
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...
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.
[0] https://github.com/gokrazy/gokrazy
TamaGo appears to be standard Go, forked to add support for specific boards.
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)
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...
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