RISC-V with Linux 6.7 Gains Optimized TLB Flushing, Software Shadow Call Stacks | Hacker News Reader

RISC-V with Linux 6.7 Gains Optimized TLB Flushing, Software Shadow Call Stacks

phoronix.com

154 pointsrbanffy10 comments

Is this lack of comments what I think it is?

I upvoted because I think it sounds important and cool but I have no clue what it means :-)

A shadow stack is a separate stack that is only maintained by making function calls and returning according to what the CPU actually did. In theory you can't trample the stack, so it's both a security feature and a way to avoid weird GDB sessions.

I'm not sure but I think shadow stack makes assumptions about how you use the ISA. For example, it's a completely legitimate program to just execute forward 10 million instructions, and use the stack pointer for other things. Or use another register. RISC-V made JAL take any register, but then no compiler that I've ever seen will use anything but RA. But it's also pretty harmless! What isn't an assumption is how Linux uses the stack, so we can at least say that it makes Linux more reliable.

Fun fact: Golang doesn't use GP as a global pointer to data. It doesn't even use the register, maybe to be compatible with C?

Looking at the front page, I think the lack of comments is partly caused by Thanksgiving week and a lot of US people not being at their desk.

this is an interesting theory to keep in mind when it’s actually thanksgiving week.

Thanksgiving is next week. I just don't know what any of this means.

When will I be able to buy a RISC-V Laptop and will it be mine or actually belong to any of the three-letter-organisations?

I wonder why RISC-V wasn't designed from the ground up to use separate stacks for data and subroutines. x86 and ARM have the excuse of maintaining compatibility with legacy design decisions, but RISC-V is less than 10 years old. Were there other implementation constraints that prevented such a design?

I don't think you're forced to do it a certain way. The most mature RISC-V toolchain is the GNU toolchain, which is binutils + GCC + glibc/newlib/musl. Clang, GCC and all the libc's which are the foundation of most everything else have the assumption that you have one stack.

It gets worse when you consider that modern languages often depend on glibc too. Example: https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kerne...

But, you can always go the golang route of depending on nothing but yourself. Then you get to decide!

It's not designed as an "exciting" architecture, just a boring but free standard architecture.

Having said that, you can easily assign two registers as stack pointers (instead of the normal one) and decide to use one to save link registers and the other to store stack frames, so you could do this if you wanted (and with many other arches too, definitely Power and Arm would support this, although not x86).

> I wonder why RISC-V wasn't designed from the ground up to use separate stacks for data and subroutines.

Nothing in the ISA precludes this. It's all about the software stack, and what the compilers do. All you need to do is assign another register the role of data stack pointer and define the ABI to use it.

Even the stack pointer is just a convention in RISC V

Reply on news.ycombinator.com