tamago VS totally-safe-transmute

There's two major production-ready Go-based operating system(-ish) projects:

- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article)

- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs)

Both of these are security-focused with a clear trade off: sacrifice some performance for memory safe and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.

[1]: https://github.com/google/gvisor

[2]: https://github.com/usbarmory/tamago

Of course it can, there are companies shipping products written in bare metal Go.

https://www.withsecure.com/en/solutions/innovative-security-...

https://github.com/usbarmory/tamago

For comparison, what are the differences in goals and approach with Tamago? https://github.com/usbarmory/tamago

I've been keeping an eye on TinyGo (Go compiler that targets microcontrollers and uses LLVM) and also TamaGo (allows you to run Go on bare metal, without any C dependency).

If you want to go deeper, there is also bare-metal Go runtime for rpi (among others): https://github.com/f-secure-foundry/tamago

> just proves your lack of knowledge

Tone is not needed.

For TamaGo, it seems to allow developers run their application, not build an OS on the hardware. But I have not played with it, you are right.

> TamaGo is a framework that enables compilation and execution of unencumbered Go applications on bare metal

The environment does not seem to allow building a generic operating system [1]. F-Secure ported the runtime itself to boot natively. But please correct me.

> There is no thread support

The environment you run in is specifically curated for Go applications, such as the memory layout. I'd call this an "appliance" rather than enabling Go to be used for full-fledged generic operating system implementations.

[1] https://github.com/f-secure-foundry/tamago/wiki/Internals

For example, there is this (pure safe Rust) code: https://github.com/ben0x539/totally-safe-transmute/blob/main... which accesses external resources (/proc/self/mem) in order to violate the safety guarantees.

The first is the totally_safe_transmute crate. I mean, who wouldn't love library code that has .expect("welp") and .expect("oof") as its error handling? But that's not even the really scary part. Issue #2 ("i hate this") remains open to this day, but for obvious reasons there's no chance of resolution. This post has some context and a line-by-line explanation of how it works.

You mean like this?

You can also do that in rust on linux: https://github.com/ben0x539/totally-safe-transmute/blob/master/src/lib.rs

I want to correct this statement: Rust can be safer, but not if a library you use contains unsound code. Unsoundness is most often caused by unsafe code, but not always (totally_safe_transmute, anyone?). There is a misconception that unsafe code blocks are always unsound and should be avoided at all costs, but they're completely fine if the safety contracts are upheld. In fact, unsafe blocks isolate the potential issues to make it easier to identify where undefined behavior may be occurring. unsafe code blocks are a feature of the language, and their usage should not be viewed as opting out of any safety the language provides, imo.

Just reimplement totally_safe_transmute in Zig. No need for unsafe.

Why transmute() when you can totally_safe_transmute()?

Well, there is always the totally-safe-transmute.

They should use https://github.com/ben0x539/totally-safe-transmute