Jordan Hand

> What about we set the stack protector for all ethreads to the same non-zero value? Is there value doing so? IMO from a security perspective, no. My suggestion would...

When you (an lthread) get scheduled on an ethread you could set %fs:0x28 to some value you hold in the lthread struct. Then on context switch, the next lthread would...

> Note that the lthread scheduler switches %fs on every context switch between lthreads, so if their thread area has a different stack canary value then this will be preserved....

I meant without usermode tls. > or allocate a small itls segment for each, with a different canary value That would be my preference. This would avoid changing the ethread's...

As someone who is fairly new to oreboot, I think the best way to answer this question is to answer "what does oreboot do that is not board specific?". And...

If this is something we're still interested in, I would be happy to look into this once we've settled some of the FSP stuff on upxtreme.

Thanks! It's worth noting that since https://github.com/oreboot/oreboot/issues/504 was resolved, oreboot assembly no longer uses rpp to insert macros. Apologies for not updating this issue. That says, rpp is still fun...

No problem :smile: I might move rpp into it's own repo/crate at some point.

I considered something with string replace, along the lines of sample.asm ``` function: {asm_to_include} ... ret ``` extras.inc ``` movq ..., ... ``` main.rs ``` global_asm!(include_str!("sample.asm"), asm_to_include = include_str!("extras.inc")); ```...

Oh also this is a decent option so we have something in rust rather than calling the C preprocessor as a subprocess: https://docs.rs/gpp/0.6.0/gpp/