01:56 <re_irc> <@thalesfragoso:matrix.org> dirbaio: https://github.com/rust-lang/rust/issues/85434 classic `mem::forget`

11:09 <re_irc> <@gauteh:matrix.org> adamgreig: https://github.com/stm32-rs/svdtools ? it is not stm32 specific?

11:10 <re_irc> <@dirbaio:matrix.org> it's not stm32-specific but the major user is the stm32 pacs

11:11 <re_irc> <@dirbaio:matrix.org> it's also used in the rp2040 (raspberry pi pico) pac, and maybe others

11:17 <re_irc> <@adamgreig:matrix.org> I think also esp32 and lpc55? And some others, maybe imxrt

12:42 <Lumpio-> Even though some of the tools say "stm32", SVD files and PAC crates are pretty much platform agnostic

12:43 <Lumpio-> You might not be able to find prewritten SVD files for non-ARM devices though. But you could feasibly convert from some other format to it, for instance.

12:43 <Lumpio-> I should say the PAC crate generators are platform agnostic, the crates themselves are just about as platform specific as it gets

12:45 <re_irc> <@9names:matrix.org> you definitely can find prewritten SVDs for a couple of riscv targets now

12:46 <re_irc> <@9names:matrix.org> i haven't used svdtools against them but I don't expect any major issues

13:12 <re_irc> <@gauteh:matrix.org> 👍️

15:25 <re_irc> <@disasm-ewg:matrix.org> I believe we use svdtools to patch fu740 and gd32vf103 SVDs

19:32 <re_irc> <@dirbaio:matrix.org> are hosts supposed to update the ARP cache when receiving non-ARP packets?

19:32 <re_irc> <@dirbaio:matrix.org> ie when receiving any random packet with src_mac=X, src_ip=Y, set arp_cache[X]=Y

19:34 <re_irc> <@dirbaio:matrix.org> smoltcp does, but lwip doesn't, uIP has code for it commented out, Linux seems not to

19:35 <re_irc> <@dirbaio:matrix.org> I have one device in teh field that fails due to this (arguably because broken router behavior, but they won't fix it because PCs work fine...)

20:08 <re_irc> <@adamgreig:matrix.org> Ugh

20:09 <re_irc> <@adamgreig:matrix.org> I don't think anything is "supposed" to but are allowed to?

20:09 <re_irc> <@adamgreig:matrix.org> How's it making it break?

20:09 <re_irc> <@dirbaio:matrix.org> router has mac xx.03, ip 192.168.1.1

20:09 <re_irc> <@adamgreig:matrix.org> A miracle any network devices ever work tbh

20:10 <re_irc> <@dirbaio:matrix.org> but every 1 min it sends some random UDP broadcast with src_mac xx.02, src_ip 192.168.1.1, some "mikrotik discovery" bullshit

20:10 <re_irc> <@adamgreig:matrix.org> I feel like most switches will add macs to switching tables for any traffic

20:10 <re_irc> <@dirbaio:matrix.org> which poisons the cache, and my device starts sending everything to xx.02

20:10 <re_irc> <@adamgreig:matrix.org> But it's just macs per port so wouldn't poison the list

20:10 <re_irc> <@dirbaio:matrix.org> which of course goes nowhere

20:11 <re_irc> <@adamgreig:matrix.org> Urgh wow wtf

20:11 <re_irc> <@dirbaio:matrix.org> and the arp cache lifetime is set to 1min, so effectively it's most of the time poisoned 💀

20:11 <re_irc> <@adamgreig:matrix.org> Why send it from the wrong Mac and the right ip, that's awful

20:11 <re_irc> <@dirbaio:matrix.org> yeah

20:11 <re_irc> <@dirbaio:matrix.org> it's the same mac except :02 instead of :03, so I guess it uses the mac from a wrong interface or something

20:12 <re_irc> <@dirbaio:matrix.org> it's so broken

20:12 <re_irc> <@dirbaio:matrix.org> but windows, macos, android, linux etc still work perfectly

20:12 <re_irc> <@dirbaio:matrix.org> all I can think of is "don't populate the cache from random packets, just ARP replies"

20:13 <re_irc> <@dirbaio:matrix.org> but holy shit are routers so broken

20:14 <re_irc> <@caspinol:matrix.org> maybe this device has some logical interfaces configured

20:16 <re_irc> <@dirbaio:matrix.org> yeah but it should use mac :02 on one interface, and mac :03 on the other... not mix them

20:16 <re_irc> <@caspinol:matrix.org> well yeas unless those logical interfaces are bound to one phisical one

20:17 <re_irc> <@caspinol:matrix.org> like bond

20:17 <re_irc> <@dirbaio:matrix.org> hmm I don't think that's the case.. packets going to :02 just get blackholed...

20:41 <re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: Pretty sure ARP cache isn't *supposed* to be updated other than from explicit ARP requests, to avoid deliberate poisoning. Linux has a setting to ignore courteous ARP response packets to help harden against ARP poisoning MITM attacks IIRC.

20:41 <re_irc> <@oddstr13:matrix.org> Been a while since I played with that stuff.

20:42 <re_irc> <@dirbaio:matrix.org> 🤔

20:44 <re_irc> <@dirbaio:matrix.org> security is another reason to not to that, I guess

20:45 <re_irc> <@dirbaio:matrix.org> other than reliabilty vs broken routers 👌

20:47 <re_irc> <@dirbaio:matrix.org> smoltcp currently updates the addr from any arp response, but also from arp requests lol

20:47 <re_irc> <@dirbaio:matrix.org> not sure whether that's another reliability concern, lolol

20:55 <re_irc> <@adamgreig:matrix.org> Can't you spoof an ARP response just as easily?

20:56 <re_irc> <@dirbaio:matrix.org> the idea is ARP responses would only be accepted if we have sent an ARP request, so the time window where you can poison one is much smaller

20:56 <re_irc> <@adamgreig:matrix.org> But yea if all the big OSs are only using responses probably makes sense to do the same... it's not much of a loss except sometimes needing to do an arp req to reply to someone?

20:56 <re_irc> <@dirbaio:matrix.org> but it's still a lost cause

20:57 <re_irc> <@dirbaio:matrix.org> ethernet is security swiss cheese

20:57 <re_irc> <@dirbaio:matrix.org> there's still sooo much bad shit you can do to an Ethernet network with physical access :D

21:01 <re_irc> <@jannic:matrix.org> It's not designed to be secure. Would you expect an SPI or I²C bus to be secure against bad actors with physical access? Why should Ethernet be different?

21:02 <re_irc> <@dirbaio:matrix.org> it's switched, you're not on a shared wire with everyone else

21:03 <re_irc> <@dirbaio:matrix.org> but it used to, and today's switches emulate that for compatibility, so we're now stuck with it

21:04 <re_irc> <@dirbaio:matrix.org> and vendors love it, so that they can sell you fancy "L3 switches" that do per-port IP filtering and DHCP snooping and stuff for HUGE amounts of money

21:08 <re_irc> <@jannic:matrix.org> Exactly. Good switches can add a layer of security, mainly by filtering out many unexpected things, but because it's been added retroactively it's extremely complex and difficult to make water tight.

21:09 <re_irc> <@dirbaio:matrix.org> it's not secure because vendors have no incentive to make it secure :P

21:11 <re_irc> <@dirbaio:matrix.org> switches could be just "routers with lots of ports", routing everything based on IP

21:12 <re_irc> <@dirbaio:matrix.org> 1 ip = 1 port. No spoofing possible!

21:19 <re_irc> <@dirbaio:matrix.org> it would be cheaper, faster, better, simpler

21:19 <re_irc> <@dirbaio:matrix.org> no need for ARP at all

21:19 <re_irc> <@dirbaio:matrix.org> no need for switches to maintain a table of MAC addrs in the network

22:16 <re_irc> <@monacoprinsen:matrix.org> Hey Guys,

22:16 <re_irc> <@monacoprinsen:matrix.org> Are there any good Real time os resources for Rust at the moment?

22:29 <re_irc> <@dirbaio:matrix.org> here's a nice list https://arewertosyet.com/

23:03 <re_irc> <@monacoprinsen:matrix.org> So not RTOS yet :(

23:04 <re_irc> <@dirbaio:matrix.org> many are prduction ready

23:04 <re_irc> <@dirbaio:matrix.org> I'm shipping thousands of devices with embassy, others are doing so with RTIC too

23:06 <re_irc> <@pinealservo:matrix.org> Not sure all the columns on that page are up-to-date either.

23:06 <re_irc> <@dirbaio:matrix.org> (IMO embassy, rtic aren't RTOSs in the traditional sense as in having threads and context-switching)

23:07 <re_irc> <@dirbaio:matrix.org> also, there's lots of holes in C that C RTOSs fill that Rust simply doesn't have

23:08 <re_irc> <@dirbaio:matrix.org> such as RTOS HALs for writing portable drivers. C doesn't have traits/interfaces but Rust does :)

23:08 <re_irc> <@dirbaio:matrix.org> so there's `embedded-hal`

23:14 <re_irc> <@dirbaio:matrix.org> https://twitter.com/bitshiftmask/status/1242407354026659840

23:15 <re_irc> <@pinealservo:matrix.org> Tock is kind of an odd one in that it's an RTOS written in Rust that primarily supports C userspace applications. And it's on release 2.0, but the support for userspace Rust code seems to be held up by llvm support for generating position-independent code. Or at least that's what the github issues seem to be saying.

23:17 <re_irc> <@9names:matrix.org> We might get that gcc back-end before we get decent PIC in llvm

23:18 <re_irc> <@dirbaio:matrix.org> The missing bits for ropi/rwpi pic are in rustc, not llvm. the gcc backend won't solve that either

23:19 <re_irc> <@dirbaio:matrix.org> uh but do you really need dynamically-loadable hardware-independent *without recompiling* apps like tock's?

23:19 <re_irc> <@dirbaio:matrix.org> that's a super rare requirement IMO

23:20 <re_irc> <@dirbaio:matrix.org> and the cost of getting that is *massive complexity*

23:21 <re_irc> <@pinealservo:matrix.org> I worked on an automotive product using a C++ automotive-oriented RTOS that was not much more complex than RTIC and seemed to be based on a similar premise. Worked pretty well for our use case, anyway. I think that style of OS is used in a lot of the smaller CAN-based controllers in cars.

23:23 <re_irc> <@adamgreig:matrix.org> dirbaio:matrix.org: Really? I don't think llvm can do ropi/rwpi either, even if rust also needs work

23:24 <re_irc> <@adamgreig:matrix.org> Arm had some patches for it but they weren't merged as too involved and stayed in keil's armcc iirc

23:24 <re_irc> <@dirbaio:matrix.org> these were clang patches

23:24 <re_irc> <@dirbaio:matrix.org> I think the llvm side is upstreamed

23:24 <re_irc> <@dirbaio:matrix.org> the equivalent of these patches is what would rustc need

23:25 <re_irc> <@adamgreig:matrix.org> hm, I thought llvm also needed more work but don't have links handy atm

23:25 <re_irc> <@dirbaio:matrix.org> don't quote me on that though lol

23:25 <re_irc> <@adamgreig:matrix.org> clang can do ropi/rwpi for C iirc, but vtables and various other bits don't work so no c++?

23:26 <re_irc> <@adamgreig:matrix.org> Yea same, I'd have to dig the links out

23:26 <re_irc> <@dirbaio:matrix.org> I think in C statics whose initial value points to another static are also broken

23:26 <re_irc> <@dirbaio:matrix.org> vtables are also the same issue in the end

23:27 <re_irc> <@dirbaio:matrix.org> statics that point to other statics, or to .text

23:27 <re_irc> <@9names:matrix.org> people did like being able to install apps on their pebble smartwatches. It is a niche use-case though

23:30 <re_irc> <@adamgreig:matrix.org> rip my pebble watch

23:30 <re_irc> <@adamgreig:matrix.org> A few days before my masters thesis was due I got the original one and instead of starting my thesis I made an app for it that showed how many hours were left to the deadline

23:30 <re_irc> <@adamgreig:matrix.org> The app worked at least

23:31 <re_irc> <@dirbaio:matrix.org> LOL