<re_irc>
<jessebraham> burrbull: Great, thank you so much! I'll take a look tomorrow
Rahix has joined #rust-embedded
starblue has joined #rust-embedded
<re_irc>
<pacrat (@pacrat:matrix.org)> Is a fully rust-based OS for networking on embedded hardware realisitic? I'm thinking that all the good foss firewalls are either Linux or Freebsd based but suffer from the same issues of memory allocation. This seems like an difficulet thing to do because of the various architectures and drivers needed to run network hardware.
<re_irc>
<newam> I'm not sure what you mean by networking, but I have done a number of personal projects with Ethernet entirely in rust (and asm)
<re_irc>
<pacrat (@pacrat:matrix.org)> I mean to say its a ton of work, and would need alot of community support.
<re_irc>
<newam> work, yes, but that's part of the fun 🙃
<re_irc>
<pacrat (@pacrat:matrix.org)> newam: I see projects like pfsense and opnsense, which use freebsd, but those systems are riddled with funky stuff like python, php, C-code, and legacy goop.
<re_irc>
<newam> Ahhh, so higher level software for a layer 3 networking appliance
<re_irc>
<pacrat (@pacrat:matrix.org)> Many corporate types turn their nose up to those firewall projects, but some consider them to be way better than the corporate poop that gets extruded by the big-boys..
<re_irc>
<pacrat (@pacrat:matrix.org)> Yes, but also low levels too. All layers, hardware, as well.
<re_irc>
<newam> What's the motivation with doing bare metal for a project like that?
<re_irc>
Most of those appliances have rather large CPUs that can run a full OS
<re_irc>
<pacrat (@pacrat:matrix.org)> Rust can do it all from what I see, from layer 0 to presentation
<re_irc>
<pacrat (@pacrat:matrix.org)> Motivation: security mainly. Getting rid of C (over time )
<re_irc>
<newam> Mmmm, it could, but you are right about the "lots of work". Starting with linux or freebsd gives you all the drivers for "free".
<re_irc>
There is also this fully rust OS, I don't know a ton about it but if you want a full-rust solution it might be a good starting point: https://www.redox-os.org/
<re_irc>
<newam> Huh, it just uses smoltcp under the hood for networking, neat!
<re_irc>
<pacrat (@pacrat:matrix.org)> Sounds nice.. Looking at it..
GenTooMan has joined #rust-embedded
<re_irc>
<pacrat (@pacrat:matrix.org)> The big problem I see is that many individuals and businesses use commodity firewalls that are easy to hack, and offer little security, ... If there was an embedded rust os that could work on vendor hardware, then that would tempt them to use it.
<re_irc>
<pacrat (@pacrat:matrix.org)> * they (vendors) would be tempted to use it.and support
<re_irc>
<pacrat (@pacrat:matrix.org)> Of course support means $$$.
<re_irc>
<pacrat (@pacrat:matrix.org)> * $$$ for developers.
<re_irc>
<newam> Redox did get a $200k donation recently
<Shellhound>
it wouldn't tempt them to use it. if they cared, they would use pfsense/etc, which are all-in-all fine.
<re_irc>
<pacrat (@pacrat:matrix.org)> But pfsense only really works on x86-ish hardware. So it would still be some work to port it, and its inherent flaws will still be baked in.
<re_irc>
<pacrat (@pacrat:matrix.org)> Looks like arm, risc-v, risc appliances are getting popular.
<re_irc>
<pacrat (@pacrat:matrix.org)> Shellhound: Yea, sorta agree with you. Someone has to make them care. Certain governmental objectives need to focus on it.
<Shellhound>
you can buy a pfsense box for sub-$500 straight from the pfsense website. if the companies who are using a dodgy ISP-supplied router cared, they would've bought one. the problem here isn't really the technical side, it's pretty much entirely working out how to make people care.
<re_irc>
<pacrat (@pacrat:matrix.org)> There is some activity in that area in US , but at least business should care, they are getting hammerd by hackers, and many utilities are 20 years in the past technologically. Of courrse tey need more than just a firewall, the entire infrastructure is rotten.
<Shellhound>
yup.
<re_irc>
<pacrat (@pacrat:matrix.org)> Shellhound: You can't make normal people care.. That will never work, but you can make companies care by various means and making their default firewalls meet a minimum level of quality.
<Shellhound>
sure. point is mostly, it's not a technical problem by far. :)
<re_irc>
<pacrat (@pacrat:matrix.org)> Yes, everything is political.
<re_irc>
<newam> Making companies care is also difficult. A client at work still doesn't use TLS certs for services they expose to the internet even though they're free from lets encrypt now :|
<re_irc>
<newam> I offered to help them out, but they just did not care
<re_irc>
<pacrat (@pacrat:matrix.org)> Assume we had all the $$$ and political leveraged to make it happen, how many man-years do you think it would take to fully produce a working OS that targets all major embedded systems that are used for SMB commercial firewalls?
<re_irc>
<pacrat (@pacrat:matrix.org)> +I mean an embedded OS+firewall + OS+switching too.
<re_irc>
<K900> Why is the goal building this in Rust again?
<re_irc>
<K900> Like, it feels like you're trying to frame the problem in terms of "let's do X but in Rust"
<re_irc>
<K900> When that's unlikely to be the actual problem
<re_irc>
<K900> Memory security against what? What's your threat model?
<re_irc>
<pacrat (@pacrat:matrix.org)> You don't think memory issues are exploitable?
<re_irc>
<K900> I don't think _all_ memory issues are, and I also don't think Rust prevents every possible memory issue
<re_irc>
<pacrat (@pacrat:matrix.org)> There are all sorts of documented tcp buffer overflows and memory issues. Many are undiscovered . To sit around and wait until they are found isn't a good plan in my book.
<re_irc>
<K900> Especially in a kernel, where there will be lots and lots of unsafe code
<Shellhound>
frankly, companies do not normally get broken into because they had a buggy firewall for their office.
<re_irc>
<K900> TCP buffer overflows in kernel code? I don't think I've seen one in a very long time
<re_irc>
<pacrat (@pacrat:matrix.org)> True that rust doen't prevent all memory (or other issues) but its a good foundation.
<re_irc>
<K900> I mean if you have at least a couple person-decades to spend on this
<re_irc>
<K900> Then sure, maybe rewriting everything in Rust is a good idea
<re_irc>
<pacrat (@pacrat:matrix.org)> Shellhound: true, but there is a lot of DOS and DDOS, and limited firewall hacking that affects the internet as a whole.
<re_irc>
<K900> But that's unrealistic
<re_irc>
<K900> And Rust can't prevent DoS or DDoS
<Shellhound>
so you're going to go up to a Government and tell them what, they can solve the dozen or so cases a year of office firewall hacking by mandating that all companies buy your router? :)
<re_irc>
<pacrat (@pacrat:matrix.org)> Thats why I mentioned switching as well, DDOS is a distributed problem that needs a distributed solution.
<Shellhound>
ok, let me know when you have a distributed solution to DDoS. (hint: it doesn't involve rewriting things in Rust.)
<re_irc>
<K900> Nothing can solve DDoS
<re_irc>
<K900> That's kind of the point
<re_irc>
<K900> The best you can do is mitigate it
<re_irc>
<K900> But if you have a huge pile of things sending you data, you need to handle that data somehow
<re_irc>
<K900> And Rust won't help you not have to do that
<re_irc>
<pacrat (@pacrat:matrix.org)> You can reduce the number of infected systems, which isn't a firewall issue, then you can mitigate, bu that is another issue.
<re_irc>
<pacrat (@pacrat:matrix.org)> DDOS is mitigated by companies now, otherwise they would never stop.
<re_irc>
<pacrat (@pacrat:matrix.org)> Those solutions exist, and not perfect, but they work.
<re_irc>
<K900> Honestly, I don't think this argument is going anywhere
<re_irc>
<K900> If you really want to rewrite pfSense in Rust, it's a matter of person-decades
<re_irc>
<K900> And the number of people does not scale proportionally to the number of decades
<re_irc>
<pacrat (@pacrat:matrix.org)> I agree, its probably more.
<Shellhound>
it'd take you person-decades to get to supporting one specific piece of real-world routing hardware, tbh.
<re_irc>
<pacrat (@pacrat:matrix.org)> BTW: Im not propose re-writing pfsense/etc ... This would be new, using modern ideas .
<re_irc>
<K900> There aren't exactly many "modern ideas" left in networking
<re_irc>
<pacrat (@pacrat:matrix.org)> +And targeting more embedded hw.
<re_irc>
<K900> Most things are already done in Linux and/or BSD
<re_irc>
<pacrat (@pacrat:matrix.org)> They said that when they invented the wheel.
<re_irc>
<K900> And hardware is becoming _less_ embedded, not more
<re_irc>
<K900> Well, do you have any specific "modern ideas" that Linux or FreeBSD aren't doing?
<re_irc>
<pacrat (@pacrat:matrix.org)> As long as there is new mathematics and technology there will be new ideas. That is the nature of technology.
<re_irc>
<K900> So you want "new ideas" but you don't know what those ideas are?
<re_irc>
<K900> Which kinda brings me back to the whole solution in search of a problem thing
<Shellhound>
generally speaking, most new ideas in networking wind up in Linux or FreeBSD (usually accompanied by a research paper), and if they're any good they wind up in both.
<re_irc>
<pacrat (@pacrat:matrix.org)> So what is your solution for the future?
<re_irc>
<James Munns> totally not following the conversation
<re_irc>
<James Munns> but
<re_irc>
<James Munns> in repeated studies, 70% of CVEs are related to memory safety
<re_irc>
<James Munns> chrome, macos, firefox, adobe flash, some more I can't remember
<re_irc>
<James Munns> the BEST project I've seen with a documented study was curl
<re_irc>
<James Munns> where 50% of CVEs were memory safety, IIRC.
<re_irc>
<James Munns> oh, all microsoft products like 2006-current was another study
<re_irc>
<James Munns> (also roughly 70% CVEs from memory safety)
<re_irc>
<mattjperez> I remember that Microsoft one from Levitt's presentation. 70%
<re_irc>
<James Munns> (I was at Ferrous Systems for about 3 years, I've given the "rust pitch" like 100 times, including writing a lot of slides, AMA)
<re_irc>
<James Munns> wow, that's a lot of chat. not gunna chime in on that. hope my irrelevant was at least interesting for someone out there :)
<re_irc>
<monacoprinsen> Hi,
<re_irc>
Do any of you know any good flight controllers that you can program in rust?
<re_irc>
<monacoprinsen> Thinking about making a small drone
<re_irc>
<James Munns> * statistics were
<re_irc>
<therealprof> monacoprinsen: Uhm, STM even offers a drone kit which is Rustable... _A lot_ of flight controllers are built around STM32 MCUs...
dc740 has quit [Remote host closed the connection]
creich has joined #rust-embedded
<re_irc>
<firefrommoonlight> Yo I have a pretty extensive Rust drone project
<re_irc>
<firefrommoonlight> I'm targetting custom G4 and H7 boards
<re_irc>
<firefrommoonlight> G4 for cheaper one with 20mm/30mm mountings. H7 with 30mm mountings, more busses broken out, dedicated 10V line, more power filtering etc
<re_irc>
<firefrommoonlight> Have found no rust-related roadblocks, but bear in mind a full FC firmware has a lot of components!
<re_irc>
<firefrommoonlight> And needs some care re project structure and complexity management to keep it organized
<re_irc>
<firefrommoonlight> You could probably program any off-the-shelf STM32 FC using Rust; ideally one with broken-out SWD pins
<re_irc>
<firefrommoonlight> * SWD pads
<re_irc>
<firefrommoonlight> Also of note, you can share a surprising amount of code and hardware between quads and fixed-wing
<re_irc>
<monacoprinsen> Interesting, will look into those boards.
<re_irc>
In regards to Hal support, which one is better?
<re_irc>
Might try to get the G4 to get started
<re_irc>
Or are they all well supported.
creich has quit [Quit: Leaving]
<re_irc>
<therealprof> I'm not up-to-date wrt STM32G support, sorry.
<re_irc>
<monacoprinsen> therealprof: No prob, tnx anyways!
<re_irc>
<monacoprinsen> firefrommoonlight: How do you handle video feed?
<re_irc>
<firefrommoonlight> My design doesn't support analog video - the DJI or HDZero cam and transmitter handle the video itself. I have a pin header for this purpose. OSD is handled using MSP Displayport over UART, which DJI goggles etc support. Ideally I'd like a pixel-buffer-based API, but that's not possible with current VTXs. (Could do a lot of interesting things with that, like overlay points onto the real world, like a base point, steerpoints etc)
<re_irc>
<monacoprinsen> firefrommoonlight: Great, thanks for sharing!