14 ms·

This is great! I think it could have uses far beyond the Raspberry Pi. As someone who's worked in the consumer electronics industry for years, I think we desp

This is great! I think it could have uses far beyond the Raspberry Pi. As someone who's worked in the consumer electronics industry for years, I think we desperately need to rethink our approach to Linux-based electronics with respect to both the userland and the primary application. A legacy-free framework written in a safe language could go a long way to improving our currently lousy reputation with respect to security and reliability. (Yes, fresh code will have fresh bugs even in a safe language -- but it's a start!) I'm also keeping my eyes open for similar ideas using Rust.

hugelgupf 9y ago
Shameless self-promotion: also take a look at https://github.com/u-root/u-root https://github.com/u-root/u-root :) (The gokrazy and u-root people all work at Google, I just contacted them to see if we can help each other. Not a competing project.)
- thisacctforreal 9y ago
  Any relation to https://github.com/u-boot/u-boot https://github.com/u-boot/u-boot ?
  - sigjuice 9y ago
    Doesn't look like it. U-boot is a boot loader for PowerPC/ARM/MIPS/<other CPUs> boards. A typical Linux-based embedded system would consist of U-Boot, the Linux Kernel and a filesystem. u-root would be one of the many ways to construct this filesystem.
  - hugelgupf 9y ago
    No, what sigjuice said is right. The name was derived off u-boot, though, and u-root can be used (and is in use) with LinuxBoot.
pjmlp 9y ago
Yeah, the idea is great. There are a few Basic, Pascal, Oberon and Java (not Android related) options available, but only a minority cares for them. Still, big enough to keep those vendors doing business. Having a minimal bare metal runtime for Go would also be nice, but it is a gigantic effort to make it portable across all types of hardware.
fulafel 9y ago
A large portion of the recent widely exploited NAT box / IP camera vulnerabilities and malware are exploiting logic bugs, backdoors and default passwods - instead of memory safety bugs. I agree memory safe systems are needed, but nontechnical changes are also needed to fix the widespread IoT vendor negligence.
- secure 9y ago
  Agreed. gokrazy generates strong passwords by default and listens only on private IP addresses by default to reduce the attack surface.
elcritch 9y ago
Exactly, the security in legacy systems is non-existent. I've been pretty pleased moving systems to the nerves-project [1] (which like GoKrazy has an A/B root file-system) to replace deprecated and ancient firmware systems. One of those setups required a Windows XP machine to flash the particular MCU that's obsolete now, a huge pain. It was almost impossible to update / patch. Nerves is based on a Buildroot core but most of the system is built with Elixir and BEAM/OTP. It's fantastic having a high level language built for robustness and reasonable security. Still, I have dreams of porting BEAM to Redox OS one day [2] and replacing the C userland-bits with Rust-bits. Especially if you could represent the micro-kernel services as actors. That would be amazing! 1: https://nerves-project.org/ https://nerves-project.org/ 2: https://github.com/redox-os/redox https://github.com/redox-os/redox
kfihihc 9y ago
Maybe you should look at TockOS[1]. [1]: https://www.tockos.org/ https://www.tockos.org/
josteink 9y ago
> As someone who's worked in the consumer electronics industry for years, I think we desperately need to rethink our approach to Linux-based electronics with respect to both the userland and the primary application. Google has created a stack called NERF (Non-Extensible Reduced Firmware) for this: https://firmwaresecurity.com/2017/07/23/google-nerf-non-extensible-reduced-firmware/ https://firmwaresecurity.com/2017/07/23/google-nerf-non-exte... There's a presentation about it on youtube: https://www.youtube.com/watch?v=iffTJ1vPCSo https://www.youtube.com/watch?v=iffTJ1vPCSo

hugelgupf 9y ago

Shameless self-promotion: also take a look at https://github.com/u-root/u-root https://github.com/u-root/u-root :) (The gokrazy and u-root people all work at Google, I just contacted them to see if we can help each other. Not a competing project.)

thisacctforreal 9y ago
Any relation to https://github.com/u-boot/u-boot https://github.com/u-boot/u-boot ?
- sigjuice 9y ago
  Doesn't look like it. U-boot is a boot loader for PowerPC/ARM/MIPS/<other CPUs> boards. A typical Linux-based embedded system would consist of U-Boot, the Linux Kernel and a filesystem. u-root would be one of the many ways to construct this filesystem.
- hugelgupf 9y ago
  No, what sigjuice said is right. The name was derived off u-boot, though, and u-root can be used (and is in use) with LinuxBoot.

pjmlp 9y ago

Yeah, the idea is great. There are a few Basic, Pascal, Oberon and Java (not Android related) options available, but only a minority cares for them. Still, big enough to keep those vendors doing business. Having a minimal bare metal runtime for Go would also be nice, but it is a gigantic effort to make it portable across all types of hardware.

fulafel 9y ago

A large portion of the recent widely exploited NAT box / IP camera vulnerabilities and malware are exploiting logic bugs, backdoors and default passwods - instead of memory safety bugs. I agree memory safe systems are needed, but nontechnical changes are also needed to fix the widespread IoT vendor negligence.

secure 9y ago
Agreed. gokrazy generates strong passwords by default and listens only on private IP addresses by default to reduce the attack surface.

elcritch 9y ago

Exactly, the security in legacy systems is non-existent. I've been pretty pleased moving systems to the nerves-project [1] (which like GoKrazy has an A/B root file-system) to replace deprecated and ancient firmware systems. One of those setups required a Windows XP machine to flash the particular MCU that's obsolete now, a huge pain. It was almost impossible to update / patch. Nerves is based on a Buildroot core but most of the system is built with Elixir and BEAM/OTP. It's fantastic having a high level language built for robustness and reasonable security. Still, I have dreams of porting BEAM to Redox OS one day [2] and replacing the C userland-bits with Rust-bits. Especially if you could represent the micro-kernel services as actors. That would be amazing! 1: https://nerves-project.org/ https://nerves-project.org/ 2: https://github.com/redox-os/redox https://github.com/redox-os/redox

kfihihc 9y ago

Maybe you should look at TockOS[1]. [1]: https://www.tockos.org/ https://www.tockos.org/

josteink 9y ago

> As someone who's worked in the consumer electronics industry for years, I think we desperately need to rethink our approach to Linux-based electronics with respect to both the userland and the primary application. Google has created a stack called NERF (Non-Extensible Reduced Firmware) for this: https://firmwaresecurity.com/2017/07/23/google-nerf-non-extensible-reduced-firmware/ https://firmwaresecurity.com/2017/07/23/google-nerf-non-exte... There's a presentation about it on youtube: https://www.youtube.com/watch?v=iffTJ1vPCSo https://www.youtube.com/watch?v=iffTJ1vPCSo