proposal: all: add bare metal ARM support

[abarisani]

Hello,

I am unsure if to go directly with a CL (as this has been discussed already on golang-dev) or if to go through this issue first, apologies if I should have done otherwise.

On this golang-dev thread I described the new GOOS=tamago created to support bare metal ARMv7 architectures using the original Go compiler.

The use case for such support is to run native Go applications on Single Board Computers without and underlying Operating System. Currently we are testing this on our own USB armory but we are working on Raspberry PI Zero support as well.

We have working examples of SSH and HTTPS servers running on Ethernet over USB with all USB drivers and stack implemented in pure Go. We are also working on a pure Go OpenPGP card leveraging on this.

We think there is great value in having this kind of support in the Go language as it considerably improves the security and ease of development on embedded systems and allows to purge C, with ease, on otherwise complex firmware efforts.

Our work is split across the following 3 repositories:

• Modified compiler: https://github.com/f-secure-foundry/tamago-go
• NXP i.MX6UL driver support: https://github.com/f-secure-foundry/tamago
• Example application: https://github.com/f-secure-foundry/tamago-example

For upstream consideration only the first repository matters, we intentionally kept the compiler changes separate from SoC specific drivers and ensure that Go applications can run mostly unencumbered and with a single import required for the board package.

You can find the following resources to understand more about our effort:

• 36c3 presentation video and slides.
• Wiki: https://github.com/f-secure-foundry/tamago/wiki
• Internals: https://github.com/f-secure-foundry/tamago/wiki/Internals
• FAQ: https://github.com/f-secure-foundry/tamago/wiki/Frequently-Asked-Questions-(FAQ)

Our compiler modification approach tries to be as minimal and clean as possible, respecting or reusing existing Go runtime code. A new GOOS=tamago is added only for GOARCH=arm, you can see the changes here.

We are committed in maintaining the required patches long term, we also understand that any potential upstream inclusion would require renaming tamago to something more suited (others have been using noos in other proposals), which is totally fine.

The patches should also be easy to revert if necessary.

To further prove the maintainability and isolation of this new GOOS from the existing code base, we began our work on go1.12, then rebased it to go1.13. Bumping it to 14.1 only took a small effort.

We built GOOS=tamago specifically to make it upstream friendly and have the minimum possible set of changes as our focus is trust for security applications and maintainability without reinventing
or adding too much code to the existing runtime.

We would much like to start a conversation to have these changes accepted upstream and take responsibility to maintain them.

Thanks

[ALTree]

From Requirements for a new port:

A developer must be named (and agree) to maintain the builder, the machine trying each git revision and providing data for https://build.golang.org

How is the builder story?

[randall77]

I'm confused. You say you needed to modify the compiler. But when I look at the diff between f-secure-foundry/tamago-go and go tip, there don't appear to be any changes to cmd/compile.
I wouldn't expect any changes to the compiler would be needed.
Do you mean runtime or linker instead?

[eliasnaur]

Related to #35956. I'd be very interested in the amd64 port of GOOS=none/noos/tamago, even if it only supports virtual machines.

[abarisani]

I'm confused. You say you needed to modify the compiler. But when I look at the diff between f-secure-foundry/tamago-go and go tip, there don't appear to be any changes to cmd/compile.
I wouldn't expect any changes to the compiler would be needed.
Do you mean runtime or linker instead?

You are correct, my bad. We don't modify cmd/compile at all. We modify mainly the runtime, stdlib packages (mostly for stubs and build flags) and the dist and link commands to add the additional GOOS.

[abarisani]

Related to #35956. I'd be very interested in the amd64 port of GOOS=none/noos/tamago, even if it only supports virtual machines.

We have an internal working amd64 port which runs under qemu, but it's not our focus and quite invasive. For this reason we propose only an ARM port as our target is ARM based embedded systems.

Having said that this might pave the future, if accepted, for future similar efforts on other architectures.

[abarisani]

From Requirements for a new port:

A developer must be named (and agree) to maintain the builder, the machine trying each git revision and providing data for https://build.golang.org

How is the builder story?

Thanks, I'll look into it.

[eliasnaur]

Related to #35956. I'd be very interested in the amd64 port of GOOS=none/noos/tamago, even if it only supports virtual machines.

We have an internal working amd64 port which runs under qemu, but it's not our focus and quite invasive. For this reason we propose only an ARM port as our target is ARM based embedded systems.

Interesting. Are you able to share the implementation? I'd also like to know what makes the amd64 port more invasive than the arm port.
Thanks.

[abarisani]

Related to #35956. I'd be very interested in the amd64 port of GOOS=none/noos/tamago, even if it only supports virtual machines.

We have an internal working amd64 port which runs under qemu, but it's not our focus and quite invasive. For this reason we propose only an ARM port as our target is ARM based embedded systems.

Interesting. Are you able to share the implementation? I'd also like to know what makes the amd64 port more invasive than the arm port.
Thanks.

Unfortunately we are not confident in sharing this implementation, our focus is just the ARM version for now. The amd64 port is more invasive due to the way the MMU needs to be managed, additionally multi-core support requires to add a thread scheduler in the runtime which is something we don't require for single-core ARM environments.

So given the complexity and lack of interest on our side we used this prototype only to initially validate the concept and then move over to ARM.

There are other efforts that implemented an amd64 port but they have been implemented in a way which I think it makes it too invasive for upstream adoption, see here and here.

As our goal is to run embedded firmware without C we don't focus on hypervisor support (as the hypervisor is in C anyway) and running without one on amd64 is very challenging given the amount of drivers required imho.

Not saying it's not doable ;), just not our focus.

[abarisani]

From Requirements for a new port:

A developer must be named (and agree) to maintain the builder, the machine trying each git revision and providing data for https://build.golang.org

How is the builder story?

Thanks, I'll look into it.

I checked docs. Ee would have no issues in providing a builder for this and maintain it.

[abarisani]

As mentioned in my initial issue message, I am quite sure that "tamago" needs to be changed for adoption as it's catchy ;) but too specific.

Therefore in the spirit of #35956 I think we should settle on GOOS=none.

I can ensure that the proposed changes only kick in with GOOS=none, GOARCH=arm and GOARM=7 which is what this code currently targets.

[FiloSottile]

I am not qualified to comment on the runtime and linker changes, but from the security point of view, this would enable fantastic applications for embedded deployments. Easy to write, fully memory-safe firmware on consumer hardware would not only replace a lot of HSMs, but make hardware security available to many more projects. For example, I'd make use of it immediately in age, and I'm sure a lot of people would have more creative uses for it.

Secure elements and trusted hardware provide security properties that are simply impossible to replicate in software, like defending low-entropy passcodes from brute force.

I am truly looking forward to this being a mature and robust target, which is why I'd love to see it supported in the main tree.

[rsc]

This proposal seems like an exact duplicate of #35956.
See my comments starting at #35956 (comment).
Is this situation different somehow (other than ARM vs x86)?