<wassasin[m]>
Might be relevant for this audience: I made a tool to lint on occurances of panic (or any other blacklisted function) on monomorphized MIR. Allows for whitelisting specific parts to allow panics there, so is more finegrained than say a linker-based detection approach or ELF debug info analysis and also works with panic=abort. Should work nicely with embedded projects. You can find it here
<OlivierCornu[m]>
* now, fixing it is unfortunately
<OlivierCornu[m]>
About the name itself: i've considered `is_rtr()` but discarded it to remain coherent with other method names in this trait (like: `is_extended()`, and not: `is_ff()`).
<OlivierCornu[m]>
The philosophy seems to be: short yet descriptive names, that do not require intimate knowledge of every flag of the underlying protocol (fwiw, i believe this is indeed the right level of abstraction for this trait).
<OlivierCornu[m]>
There's just one outlier: `dlc()`. I guess `data_length_code()` is a mouthful breaking the "short" constraint…
<thejpster[m]>
<diondokter[m]> I've seen the development, it's worth checking it out!
<thejpster[m]>
Ferrocene does a similar trick to check whether you have called any non-certified libcore functions - I understand CGA was inspired by that (and this is why the Ferrocene source code is open-source after all)
<diondokter[m]>
Yep
raymondr has joined #rust-embedded
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.7.2]
<thejpster[m]>
oh no - if my non-secure program does a bad thing, I end up in the secure mode hardfault handler. But that looks at the secure-mode MSP, not the non-secure MSP, so my frame is full of nonsense.
<diondokter[m]>
The joys of trustzone :)
<thejpster[m]>
but also our hardfault trampoline not doing a useful thing
<wassasin[m]>
NXP chipsets have the AHBSC which contains a register detailing the security violation and its associated address
<wassasin[m]>
And also which bus master triggered the violation
<wassasin[m]>
But if the SAU or IDAU catches the issue the bus will not even see an access, so depends a bit on what you want to catch
<thejpster[m]>
so, I found the source of the fault
<thejpster[m]>
But it makes no sense.
<thejpster[m]>
The NS app is doing a PUSH, which works, then a POP, which explodes.
<thejpster[m]>
I’m confused as to how one would work but not the other.
<thejpster[m]>
or is there some legit reason I am just failing to grasp about why you'd put a memory address into APSR_nzcvq (aka CPSR_f)?
<diondokter[m]>
Not sure!
<diondokter[m]>
The registers don't have to be 0 though. You just want to write some value to them so you don't leak secrets
<thejpster[m]>
fair ... but still ... weird
<diondokter[m]>
Same with flags I guess. Not sure how much you can leak with that, but in theory...
<thejpster[m]>
but to randomly set the flags based on the memory address?
<diondokter[m]>
I guess it saves an instruction of clearing a register first
<diondokter[m]>
And you know the callee already knows the memory address, so you know you're not leaking anything
<diondokter[m]>
Though this routine does seem to set all float registers to 0. But there you don't have an existing register that is known to have no data it can leak
sroemer has joined #rust-embedded
sroemer has joined #rust-embedded
bandini has quit [Quit: WeeChat 4.9.2]
rainingmessages1 has quit [Quit: bye]
rainingmessages1 has joined #rust-embedded
<thejpster[m]>
<thejpster[m]> But it makes no sense....
<thejpster[m]>
When you find out that illegal access to RAM can give you Read-As-Zero/Write-Ignored (RAZ/WI), then this makes sense.
<thejpster[m]>
Push LR, throw it away. Pop a zero into the program counter. Boom.
<thejpster[m]>
oh right. I assume _ meant "don't touch me"
<thejpster[m]>
like a linker symbol
<dirbaio[m]>
yeah. the public features are nrf54l15-s or nrf54l15-ns
<thejpster[m]>
ah, right
<dirbaio[m]>
adding a feature to svd2rust/chiptool for this would be quite annoying as well. there's no convention in svds or standard metadata for this kind of s/ns mirroring
<dirbaio[m]>
nrf uses FOO_S, FOO_NS
<dirbaio[m]>
stm32 uses FOO, SEC_FOO
<dirbaio[m]>
and it wouldn't surprise me if stm32 is inconsistent across svd's 🤣
<diondokter[m]>
Generally a chip always uses the same offset in addresses. This can change from family to family though.
<thejpster[m]>
Does the stm32-metapac even support the S-mode variants?
<dirbaio[m]>
and i'm not sure what's the best way to add it. Simply duplicating the peripheral won't work because the metadata is used for much more than register access (clock frequency, enable-disable for low power etc.). For those we really need the metadata to say "it's one peripheral but with two address aliases"
raymondr has quit [Remote host closed the connection]
<thejpster[m]>
I guess stm32-rs just duplicates everything (probably because it was duplicated in the SVD file?)
<dirbaio[m]>
yea in svds you typically handle s/ns by simply duplicating the peripherals
glitchy has quit [Ping timeout: 245 seconds]
glitchy has joined #rust-embedded
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
meowie has quit [Remote host closed the connection]
meowie has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.7.2]
dngrs[m] has joined #rust-embedded
<dngrs[m]>
pleased to announce [lowram-ipsum](https://crates.io/crates/lowram-ipsum), a `no_std` utility crate for adding IP addresses in memory constrained environments
<dirbaio[m]>
🤔
<dirbaio[m]>
you could make ipv4+ipv6 addition panic-free if you convert the v4 to v6 instead of the other way around
<dirbaio[m]>
I wonder what the IETF specs say you should do in that case
<dngrs[m]>
I'll consider it
<dirbaio[m]>
much appreciated
<Lumpio->
In what sort of application would one need to add IP addresses
<dirbaio[m]>
it's a core operation underpinning CIDR routing
JonathanKeller[m has joined #rust-embedded
<JonathanKeller[m>
the crate name is a masterpiece