go on bare metal https://github.com/golang/go/issues/37503

[ron minnich]

I'd like to add my support for
https://github.com/golang/go/issues/37503. I'm bringing this
discussion here because someone said we should bring it here :)

I work on code that runs before boot, specifically code like coreboot.
The "small linux shim" ideas advanced in the discussion of this issue
won't work; there is no linux, by definition, before you boot linux
:-)

We've been looking at rust-based firmware for 2 years now, see
github.com/oreboot, and it's not as great a fit as I first thought,
because Rust by design has no runtime, which in turn means no
concurrency, no convenient IPC, and so on.

We've tried to bring in various Rust packages for concurrency, but
they always fail because they always want to pull in kernel
dependencies.

The beauty of the tamago work is that it makes goroutines and channels
available in a pre-boot environment -- something we've experimented
with for years in coreboot, and which have always failed due to lack
of language support (coreboot is written in C).

There are a lot of Go idioms that are proving very handy in the
experiments I'm doing with tamago. Further, the name on this issue is
misleading: it would work just as well on RISC-V as far as I can tell.

This work allows us to run code in PL1 on ARM that would be otherwise
impossible. If there is some way to reduce its size, I think it would
be nice if it could go in.

Thanks

[David Chase]

When you say "reduce its size", how much do you mean?

Binary size came up in discussions of register ABI and which-platforms; arm64, early benchmarks show a 7% reduction in text over 1.17.

It seems plausible that we could get savings for arm-32 as well, and we weren't even paying attention to text size, it just happened.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAP6exYK%3DGhL2Ao%3DheJwpRzeHRR6x_3C6V_1oY_%3D5-q7d%3Du7zPA%40mail.gmail.com.

[ron minnich]

sorry I was not clear, David: by 'reduce its size' I meant the lines
of code in the PR. People seemed concerned about the # lines of code.
It has been pointed out to me that the biggest bits of it are also
there in wasm, but still ... I was wondering if making the PR smaller
might make people worry less about it.

In terms of impact, if you think of the small devices such as the
https://inversepath.com/usbarmory, the scale of the deployment of
these types of devices could grow the number of Go users by a large
factor. I can tell you from having worked with tamago these last two
weeks, and having seen how easily I could integrate u-root into this
system, that it has a huge impact on ease of development of these tiny
devices. There is simply no way to get to where I've gotten with any
other language. It's also very nice to be able to run heavily tested
Go code (u-root) on bare metal in this way. Normally, any time you
drop to bare metal, you have to reimplement all your libraries. It's
very painful.

But this PR is mostly adding the name tamago as a GOOS value to test
for. It's eye-opening and a testament to how well Go has abstracted
runtime from the target system.

I think this work could be very significant and I'd like to help get
it upstream if I can.

[David Chase]

It sounds useful to me, but I lack the cycles to contribute.

One question, from a security POV, do you think someone's better off running their app (assuming it is standalone) and running it on bare metal/container, or with a Linux underneath?

It's sort of a second-layer of protection vs all the potentially subvertable stuff you don't need in the second layer -- years ago a friend of mine worked for a startup that got acquired I think by Cisco, and one thing they did that was a big win was that they had put a lot of work into configuring a Linux that had only what their app needed to run, and not one thing more.  Not only did it make the total footprint of the app much smaller, it meant that several of the canned attacks in the default penetration test found themselves unable to even talk to the app box, never mind attack it.

Or is this only about boot time, platform control, and reduced footprint?

[ron minnich]

On Fri, Jun 11, 2021 at 12:29 PM David Chase <drc...@google.com> wrote:
>
> It sounds useful to me, but I lack the cycles to contribute.
>
> One question, from a security POV, do you think someone's better off running their app (assuming it is standalone) and running it on bare metal/container, or with a Linux underneath?

well, that's part of what makes this interesting to me: aside from
being a pretty good pre-boot environment, Go apps using tamago might
also be a good thing to be persistent. My next step is to see if a
perkeep client will fit. All this is being done with the gobusybox
(github.com/u-root/gobusybox), which does source-to-source
transformation and then compiles it all into one binary. Again, the
surprise to me was just how easy and effective Go was for bare metal
with code never envisioned for it.

Simple question: does the protection linux brings outweigh the
vulnerabilities that come from the combination of linux and go
applications? Simple answer: I have no clue.

At Google and other places, we put linux in flash (linuxboot.org)
because we need what it does: chipset tweaks, drivers, file systems,
and so on. It also tremendously improves on the security picture as
compared to UEFI.

But on a simple enough platform, like the usbarmory, one can make a
case that adding Linux is a net decrease in security. I'll leave that
to f-secure to tell us :-)

But, further, tamago brings smaller footprint, instant boot (important
in such devices), probably lower power, and very fast iteration: build
a go app, not a kernel and a go app.

And, as mentioned, the impact on the Go code base is small, the
potential for addition of a new and large user community (little USB
devices for security) is significant.

[ron minnich]

The Harvey-OS (plan 9 fork) 9p server builds just fine into the tamago
environment. This means one could plug in a usbarmory, mount it via
9p, and access its resources as files.

Lots of possibilities here ...

[ron minnich]

I should probably explain a bit more about why the 9p export from
tamago matters. On the usbarmory/imx.6, we can represent devices as
files in /dev, with simple read/write commands to make things happen
(this is done today). With the harvey-os 9p file server (just another
Go app), I can export those files via 9p to be mounted on Linux or
Plan 9. From there, I can do driver development/testing with new Go
code, and other programs, that can be *native to the system which did
the mount*; e.g., on an x86 laptop, with a usbarmory, I can develop a
driver on the x86 (GOOS=linux GOARCH=amd64), and have it manipulate
the devices on the board by reading/writing files mounted via 9p.

Once I'm happy with the driver I can simply build it into tamago with
the gobusybox (GOOS=tamago GOARCH=arm) and reflash the board. The
ability to do cross-platform driver development this way can greatly
speed up driver development, and reduce board reflashes. Because of
the mechanical manipulation of the boards needed for reflash, which
can in turn break boards, reducing reflash cycles is a big deal.

This development model is all old news if you're used to Plan 9, but
it's nice to see I can use the model in other contexts, on other
kernels.

So I'd still argue that this CL is well worth upstreaming, and if
support is an issue, I'm happy to sign up with f-secure to help. It's
a small change with a potentially very large growth in Go usage -- if
you want volume nowadays, you want to go with IoT and embedded ...

[Christopher Nielsen]

Ron,

This is all very exciting. I don't have a lot of time to contribute, but I would love to help out where I can. My personal projects these days are primarily embedded, and I have a fair bit of experience with Plan 9.

I'd be interested and excited to see this upstreamed.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAP6exY%2BZmijWj3%3DQ_%3DeAOqOZQBEu%3DUH0JCHqQz9DEpmQ3aG%3DEg%40mail.gmail.com.

[lcar...@gmail.com]

Hello everyone and thanks for the interest in TamaGo!

As further evidence to what Go can bring on the bare metal we now have the following public firmware projects available:

  * GoKey - an OpenPGP/U2F token smartcard implementation (https://github.com/f-secure-foundry/GoKey)

  * GoTEE - a Trusted Execution Environment with TrustZone (https://github.com/f-secure-foundry/GoTEE)

  * Armory Drive - an Encrypted Drive solution (https://github.com/f-secure-foundry/armory-drive)

  * armory-boot - a primary secure bootloader (https://github.com/f-secure-foundry/armory-boot)

I'd also like to emphasize that as of https://github.com/golang/go/issues/37503#issuecomment-817561764 we have removed most of the ARMv7 specific code out of

our TamaGo patch. This practically removes every hardware/architecture dependent modification to the Go distribution, making GOOS=tamago modifications to standard Go

runtime essentially a basic template for bare metal execution. It was probably my mistake to comment on the same issue rather than opening a new one (but I was unsure

on what was the correct etiquette there).

We are having many OSS, as well as bespoke firmware for our commercial customers, success stories with TamaGo and we see so much advantage in writing such

firmware in pure Go, without an RTOS or full blown OS.

We would also volunteer to maintain and test this support if it ever arrives to upstream (probably renamed with a better GOOS name than tamago).

Cheers

[ron minnich]

Just to close this out: it lives:

rminnich@t510:~/tamago/t9$ sudo mount -o version=9p2000 -t 9p 10.0.0.1 /mnt
rminnich@t510:~/tamago/t9$ ls -l /mnt
total 29
dr-xr-xr-x 1 4294967294 4294967294 1918 Jan 1 1970 dev
drwx------ 1 4294967294 4294967294 822 Jan 1 1970 dir
-rw------- 1 4294967294 4294967294 286 Jan 1 1970 index.html
-rw------- 1 4294967294 4294967294 24710 Jan 1 1970 tamago.log
drwxrwxrwx 1 4294967294 4294967294 548 Jan 1 1970 tmp
rminnich@t510:~/tamago/t9$

The bits and pieces:
Board:
https://www.digikey.com/catalog/en/partgroup/i-mx-6ull-evaluation-kit/64900?utm_adgroup=xGeneral&utm_source=google&utm_medium=cpc&utm_campaign=Dynamic%20Search_EN_Product&utm_term=&utm_content=xGeneral&gclid=CjwKCAjwwqaGBhBKEiwAMk-FtFt6x7bKIeIZZnLyNvo9NbpWVBYy6GpI34q39FHVUMW3jO__XuS_7hoCi98QAvD_BwE

OTG cable used for the 10.x network.

building the image with my fork of tamago-example, which uses
gobusybox: (github.com/u-root/gobusybox)
harvey ninep: https://github.com/harvey-os/ninep # a long-ago fork of
lionkov/mirtchovski ninep with major surgery. Supporting harvey for 6
years now.
bits and pieces of gvisor (gvisor.dev/gvisor/pkg/tcpip)

current only issue is that linux 9p has diverged a bit from standard
and ninep will have to deal with that.

I think the f-secure work is well worth upstreaming, and hope there is
some way I can help. We might of course run Linux on this board, and
then run all this code on it, as suggested, but consider this: the Go
toolchain and this code create binaries with a certain defect density,
Adding the 100x larger code base of Linux is not going to make things
better. In other words, throwing millions of lines of C code at the
problem, to add capabilities we don't need, is not guaranteed to make
things better. We might use Linux as it would provide, e.g., an IP
stack, but we already have one in tamago. These ARM systems are so
simple I'm not sure I want a kernel, if I can run with this bare metal
model. There's a very real question here as to whether Linux would
make this system less, rather than more, reliable, just on the
statistics.

Of course f-secure has done far more than what I'm discussing here:
They've got a full TEE (Trusted Execution Environment) and that is
something I've only started to understand.

Go already runs in a sort-of baremetal environment today: that's what
gvisor is, fundamentally: a kernel running in x86 guest ring 0. So all
we're really asking is to add another type of bare metal environment.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/9576efc3-ef58-4c1c-9f2a-28b9649b55cfn%40googlegroups.com.

[Alberto Donizetti]

> It was probably my mistake to comment on the same issue rather than
> opening a new one (but I was unsure on what was the correct
> etiquette there).

In general, closed issues are not monitored, so we discourage
commenting on them (unless your issue was quickly closed by mistake
e.g. as invalid, and you just want to point that out).

If you'd like for a decision to be reconsidered, because you believe
the circumstances that led to the decision changed significantly, it's
better to open a new issue. Of course you'd link back to the old
thread, clearly explaining what did change, and how that addresses
points that were raised in the first round.

Alberto

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/9576efc3-ef58-4c1c-9f2a-28b9649b55cfn%40googlegroups.com.

[lcar...@gmail.com]

On Wednesday, June 16, 2021 at 6:31:25 PM UTC+2 Alberto Donizetti wrote:

> It was probably my mistake to comment on the same issue rather than
> opening a new one (but I was unsure on what was the correct
> etiquette there).

In general, closed issues are not monitored, so we discourage
commenting on them (unless your issue was quickly closed by mistake
e.g. as invalid, and you just want to point that out).

If you'd like for a decision to be reconsidered, because you believe
the circumstances that led to the decision changed significantly, it's
better to open a new issue. Of course you'd link back to the old
thread, clearly explaining what did change, and how that addresses
points that were raised in the first round.

Thanks for suggesting this, I wasn't sure if this was the case or not.

I will open a new issue for consideration in the next days.

Cheers

[Ian Lance Taylor]

On Wed, Jun 16, 2021 at 12:57 PM lcar...@gmail.com <lcar...@gmail.com> wrote:
>
> On Wednesday, June 16, 2021 at 6:31:25 PM UTC+2 Alberto Donizetti wrote:
>>
>> > It was probably my mistake to comment on the same issue rather than
>> > opening a new one (but I was unsure on what was the correct
>> > etiquette there).
>>
>> In general, closed issues are not monitored, so we discourage
>> commenting on them (unless your issue was quickly closed by mistake
>> e.g. as invalid, and you just want to point that out).
>>
>> If you'd like for a decision to be reconsidered, because you believe
>> the circumstances that led to the decision changed significantly, it's
>> better to open a new issue. Of course you'd link back to the old
>> thread, clearly explaining what did change, and how that addresses
>> points that were raised in the first round.
>>
>
> Thanks for suggesting this, I wasn't sure if this was the case or not.
>
> I will open a new issue for consideration in the next days.

Thanks. In order for a new issue to succeed, it must 1) refer to the
old issue; 2) provide new information that was not considered when
closing the old issue. Thanks.

Ian

[lcar...@gmail.com]

FYI I created a new issue as suggested: https://github.com/golang/go/issues/46802

Cheers