Looks great. I'd love to use it. How is the GPIO/PWM support?
Have a look at https://periph.io/.
In case any of periph.io’s features require changes to the kernel configuration, I’m happy to change it accordingly.
Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
61–70 of 90 posts
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#62Earlier quoted context omitted.
What is it about Linux that doesn't keep your stuff chugging along?
You have to keep it up to date because of all the security issues in other apps that are installed. If the system only contains the Linux kernel and your software you only have to worry about your security issues (unavoidable) and Linux security issues (also difficult to avoid - too much work to write a new kernel too, plus remote Linux vulnerabilities are quite rare).
So why not just create a stripped down Linux distribution instead of reinventing the wheel and creating a new userland from scratch (with probably a few brand new and undiscovered security issues already)?
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#63Earlier quoted context omitted.
You have to keep it up to date because of all the security issues in other apps that are installed. If the system only contains the Linux kernel and your software you only have to worry about your security issues (unavoidable) and Linux security issues (also difficult to avoid - too much work to write a new kernel too, plus remote Linux vulnerabilities are quite rare).
So why not just create a stripped down Linux distribution instead of reinventing the wheel and creating a new userland from scratch (with probably a few brand new and undiscovered security issues already)?
I tried: I have used debootstrap to create minimal Debian images in the past.
A big part of the motivation for gokrazy is to use a safe, high-level programming language.
This allows us to re-implement the userland with small amounts of code, see e.g. the NTP client at https://github.com/gokrazy/gokrazy/blob/master/cmd/ntp/ntp.g...
Replacing the implementation language eliminates whole classes of attacks, while stripping down an existing Linux distribution can only go so far. Plus, it’s not clear to me how one would maintain such a stripped-down distribution in a way that isn’t a lot of effort.
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#64Super nice. Glad to see A/B partiton updating scheme, that is the way to go on appliance / embedded device. Want something like this for one of the languages that I know... Node.js, Python or Rust. I'd include C++11, though for this kind of deployment method I think one needs packages easily available in a way separate from Linux distro (since there is none).
The A/B updating scheme is a massive waste of space in most implementations... In many hardware devices, flash storage space for the OS is actually one of the most expensive components, and one of the main reasons that many devices run little hard-to-program embedded OS's rather than linux or something else high level.
Instead, a filesystem like btrfs should be used which can give the appearance of multiple versions, yet only use actual storage space where versions differ.
I'd prefer the root filesystem to be something using a FUSE-like layer which can store format specific binary diff/patches between versions, and then transparently apply (and cache) them on access.
Taking it a step further, I wish desktop linux distros had a package-manager-fs, which is a readonly virtual filesystem which displayed all the files installed by all packages, but the underlying real filesystem only contained all the original compressed packages and a cache of recently used files.
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#65Earlier quoted context omitted.
I don't see why it's a different definition, though. What's he's saying is that it's very easy to break Go's bounds checking with race conditions, and produce memory corruption . This isn't true of languages traditionally considered as memory safe - e.g. Java or Python.
A crash on out of bounds will always happen, unless unsafe package is being used to subvert memory accesses.
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.
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#66Earlier quoted context omitted.
A crash on out of bounds will always happen, unless unsafe package is being used to subvert memory accesses.
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.
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#67Earlier quoted context omitted.
So it's a distribution ? ... that will have security issues, require updates, distribution maintenance, and all that stuff they claim is unacceptable ?
It’s not a full-blown distribution; it doesn’t distribute third-party software. Instead, it allows application authors to build their own distribution (at which point “appliance” is a more fitting word than “distribution”). Updates are easy to fully automate with gokrazy (and I’ve been using that mechanism for a year at this point) because assembling a new image and installing it over the network is just one simple c…
Forgive me if this sounds dumb, but if the image just contains the firmware + kernel + a light layer for managing processes, do this mean it doesn't include stuff like SSHD?
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#68Earlier quoted context omitted.
So why not just create a stripped down Linux distribution instead of reinventing the wheel and creating a new userland from scratch (with probably a few brand new and undiscovered security issues already)?
I tried: I have used debootstrap to create minimal Debian images in the past. A big part of the motivation for gokrazy is to use a safe, high-level programming language. This allows us to re-implement the userland with small amounts of code, see e.g. the NTP client at https://github.com/gokrazy/gokrazy/blob/master/cmd/ntp/ntp.g... Replacing the implementation language eliminates whole classes of attacks, while stripp…
I still find this effort odd. You already have a well tested and widely used userland, even if it is written in a non memory safe language.
The easiest solution to me seems to be to grab the tools you need from the existing userland, instead of reimplementing them in Go. Currently you have reimplemented some of the userland, and packaged it up into a distro. So you have to maintain a stripped down distribution and the tools that you reimplemented. If you just took existing tools you would only have to do the latter. Am I missing something here?
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#69Earlier quoted context omitted.
It’s not a full-blown distribution; it doesn’t distribute third-party software. Instead, it allows application authors to build their own distribution (at which point “appliance” is a more fitting word than “distribution”). Updates are easy to fully automate with gokrazy (and I’ve been using that mechanism for a year at this point) because assembling a new image and installing it over the network is just one simple c…
Forgive me if this sounds dumb, but if the image just contains the firmware + kernel + a light layer for managing processes, do this mean it doesn't include stuff like SSHD?
That’s correct: there is no SSH daemon by default. You can optionally include https://github.com/gokrazy/breakglass, though, which is an SSH daemon that can be started on demand to facilitate interactive debugging.
Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances
#70Super nice. Glad to see A/B partiton updating scheme, that is the way to go on appliance / embedded device. Want something like this for one of the languages that I know... Node.js, Python or Rust. I'd include C++11, though for this kind of deployment method I think one needs packages easily available in a way separate from Linux distro (since there is none).
The A/B updating scheme is a massive waste of space in most implementations... In many hardware devices, flash storage space for the OS is actually one of the most expensive components, and one of the main reasons that many devices run little hard-to-program embedded OS's rather than linux or something else high level. Instead, a filesystem like btrfs should be used which can give the appearance of multiple versions,…
Sure it is quite inefficient. Both in storage and in transmission of updates.
But it is very simple and robust. What one tests pre rollout is identical to what will go on production devices, down to the byte. Each device with same version is identical. It can be cryptographically verified easily. Automatic rollback can be performed on update fail, including self-checks.
This approach of shipping a custom userland without any of the generic Linux userland should drastically bring down the size.