Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

gokrazy.org

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#81

Post by [deleted] »

millstone wrote: post #79
pjmlp wrote: post #66

Earlier quoted context omitted.

As mentioned in that blog post > You'll notice my address() trick to get the address of a function or variable that I used in my previous exploit. We're relying on package fmt and its %p format specifier which is implemented by using the unsafe package, so we don't need to use it ourselves.

unsafe code is not required or used. The exploit constructs a confused interface value, whose vtable refers to a different type than is what is stored. The result is that Go treats an integer as a function and jumps to it. The unsafe address() is used to get the address of a function to store in the int, to demonstrate the potential for shellcode injection. But you could just as easily assign pp := 12345 and produce…

[deleted]

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#82

Post by pjmlp »

millstone wrote: post #79
pjmlp wrote: post #66

Earlier quoted context omitted.

As mentioned in that blog post > You'll notice my address() trick to get the address of a function or variable that I used in my previous exploit. We're relying on package fmt and its %p format specifier which is implemented by using the unsafe package, so we don't need to use it ourselves.

unsafe code is not required or used. The exploit constructs a confused interface value, whose vtable refers to a different type than is what is stored. The result is that Go treats an integer as a function and jumps to it. The unsafe address() is used to get the address of a function to store in the int, to demonstrate the potential for shellcode injection. But you could just as easily assign pp := 12345 and produce…

On the contrary, if Go was unsafe that would just corrupt memory and the program would just carry on without anyone noticing the memory was corrupted until it was too late, in another completely different stack.

The exploit was only possible thanks to using the unsafe package, even if indirectly.

It is exactly because Go is memory safe that a SIGSEGV or SIGILL is produced the exact moment the memory gets corrupted and not 2 hours later in a complete different stack trace.

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#83

Post by pdimitar »

tigeba wrote: post #80

Does anyone know of a good tool for building custom PI distributions based on the Raspbian / Raspbian Lite or other distributions that does not involve forking the official image builder and hacking it up? My ideal tool would allow me to do this with a Dockerfile and just export the image after the configuration is complete.

My answer is most likely out of context and off-topic but have you checked the Nerves Project[0]?

Apologies if this is not helpful.

[0] https://nerves-project.org

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#84

Post by snops »

tigeba wrote: post #80

Does anyone know of a good tool for building custom PI distributions based on the Raspbian / Raspbian Lite or other distributions that does not involve forking the official image builder and hacking it up? My ideal tool would allow me to do this with a Dockerfile and just export the image after the configuration is complete.

http://resin.io is close to this, but also handles updates for you.

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#85

Post by tmzt »

secure wrote: post #54
cjdell wrote: post #51

Could/should one use this to build a touch screen user interface for an RPi as part of a kiosk based application? I really like Go, and suspect a Go app would beat the pants off anything powered by Electron (performance wise).

I’d love to see this, but note that you’ll need to use a pure-Go graphical toolkit (or implement all graphics yourself), and likely interface the touchscreen yourself, too. If you’re not comfortable with this, it might be better to use something else.

Maybe a Flutter port would make sense here?

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#86

Post by sigjuice »

technofiend wrote: post #75
sigjuice wrote: post #11

It is really interesting that Gokrazy uses an upstream kernel (with a couple of minor patches). https://github.com/gokrazy/kernel/blob/3ecdc901da51c2c5b6bf7...

Even the raspberry Pi Zero and Zero W are supported in the latest kernels, and those were the latest Pi boards until the B+ came out.

Thanks! That’s good to know. Perhaps getting gokrazy going on the Pi Zeroes will not be a huge task. 32-bit userland probably already works on the 64-bit Pi 3 kernel.

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#87

Post by burntsushi »

pjmlp wrote: post #66
burntsushi wrote: post #65

Earlier quoted context omitted.

This is only true if you can prove that data races will never cause any bounds checks to be wrong. The blog post linked upthread suggests otherwise, and even appears to provide a counter-example to your claim.

As mentioned in that blog post > You'll notice my address() trick to get the address of a function or variable that I used in my previous exploit. We're relying on package fmt and its %p format specifier which is implemented by using the unsafe package, so we don't need to use it ourselves.

So? The code they wrote doesn't use `unsafe`. So presumably, you need to modify your claim to this then I guess?

> A crash on out of bounds will always happen, unless unsafe package is being used to subvert memory accesses, or if you've used something that exposes details that only the unsafe package exposes, such as fmt's %p specifier.

I mean, you are like, the ultimate pedant, so I figured you'd uniquely appreciate this.

You can't just say, "use unsafe or anything that uses unsafe," because it's turtles all the way down. You've got to draw that line somewhere. If the %p specifier really is required for an exploit and there's nothing else that exposes that (sans unsafe), then that's great news! But is that the whole story?

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#88

Post by secure »

sigjuice wrote: post #86
technofiend wrote: post #75

Earlier quoted context omitted.

Even the raspberry Pi Zero and Zero W are supported in the latest kernels, and those were the latest Pi boards until the B+ came out.

Thanks! That’s good to know. Perhaps getting gokrazy going on the Pi Zeroes will not be a huge task. 32-bit userland probably already works on the 64-bit Pi 3 kernel.

Please see https://github.com/gokrazy/firmware/issues/15

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#89

Post by halbritt »

boromi wrote: post #73
halbritt wrote: post #22

Earlier quoted context omitted.

ResinOS does all that and more. It's container-based. Works super-well on a Pi3.

Thanks. Where would alpine linux fit into this all. It seems like a good candidate for embedded setups.

You could run whatever you like in an alpine container on ResinOS

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#90

Post by zaarn »

millstone wrote: post #77
zaarn wrote: post #55

Earlier quoted context omitted.

You can't access data out of bounds. Go will panic with a runtime exceptions if you do. Memory safety doesn't mean "memory IO errors never happen" it means "if a memory IO error happens, you'll know" If you have an out of bound in C, your program keeps running in 9/10 cases. In Go you'll cause a panic in 10/10 cases which you can either handle and propagate as error or let the program crash entirely, the memory will…

But with Go you CAN access data out of bounds. See the "Exploiting the slice type" section where writing to a slice modifies a function pointer which happens to be stored after the slice. It's an OoB write which does not panic.

an OoB write under a data race in a program that won't occur like this in the wild. The conclusion section of the post you mean contains that statement too.

The %p formatting used to gain access to the pointer of a variable uses the unsafe package, the formatting itself is incredibly rarely use to begin with.

I don't see anybody doing any security-related exploits doing that unless you explicitly write for it.

Go won't do out of bounds, edges cases do happen. You can find the same stuff on Java and Rust (yes, I had OoB in Rust, though on a baremetal environment without OS, even Rust ain't safe.)

Post reply on HN