Mandatory enforcement of indirect branch targets • Hacker News Board

Re: Mandatory enforcement of indirect branch targets

#131

Post by insanitybit » Sat, Jul 15, 2023, 5:00 PM UTC

SoftTalker wrote: post #10

Theo had to get his digs in against Linux in that announcement. Why not just focus on what OpenBSD is doing, and maybe contrast it to what Linux does without the speculation that they will still be doing the same thing in 20 years. He's unquestionably brilliant, but I've had a few encounters with him on the mailing lists and he is so quick to take offense where none was meant and drop into name-calling and insults. I…

I think it's great that he's calling Linux's choices out. TBH Theo's attitude is borne of Linux's culture - most older school sec people have learned that this is the only way to get things to improve.

Re: Mandatory enforcement of indirect branch targets

#132

Post by monocasa » Sat, Jul 15, 2023, 5:42 PM UTC

rollcat wrote: post #88

monocasa wrote: post #29

Earlier quoted context omitted.

RISC-V has a whole HINT space that's basically just morphs of load immediate into zero register. AArch64 has a similar space: https://developer.arm.com/documentation/ddi0596/2020-12/Base... And yes, PowerPC has a similar space as well holding hints like 'give priority to the other hardware threads on this core' and the like. https://utcc.utoronto.ca/~cks/space/blog/tech/PowerPCInstruc...

I was wondering where did I read about PowerPC, and this is exactly the article! So, it was for thread priority. Strikes me as an odd design choice, this probably should've been something to be managed by the OS more explicitly.

I think the idea of exposing it to user space is to better handle concurrency before trapping into the kernel.

So consider the case of a standard mutex in the contended case. Normally the code will spin for a little bit before informing the kernel scheduler on the off chance that the thread that owns the lock is currently scheduled on another hardware thread. In that case it's in the best interest of the thread trying to grab the lock to shift most of the intracore priority to any other hardware threads so that it can potentially help the other hardware thread holding the lock get to a point where it gives up the lock quicker.

Re: Mandatory enforcement of indirect branch targets

#133

Post by saagarjha » Sun, Jul 16, 2023, 4:41 AM UTC

PrimeMcFly wrote: post #130

saagarjha wrote: post #129

Earlier quoted context omitted.

Those seem to be of the category of “I have a program and I want to restrict what it does” which seems like a sandbox to me. The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.

It's not a sandbox though, because it's a different type of technology. You can say it's a type of sandbox in concept, and you could make an argument, but referring to it as a sandbox in a technical discussion simply isn't correct. > The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party…

I mean the typical term used for such things is “mandatory access control” but they always get used to implement a sandbox so that’s what I call them.

Also, watching a program to see what it does is exactly the issue I’m talking about. You’re stuck with whatever behaviors you tested and everything else that you didn’t hit will fail (loudly if you’re lucky, silently if you’re not). There are platforms that do exactly what you’re talking about and believe me working on these rules is miserable. You’ll have reports on your desk like “the profiler doesn’t work anymore” (nobody tested this) or “on desktop controls don’t render anymore” (someone changed the implementation and it needs something you didn’t include in your rules). Again, this is when you control the stack, doing this for arbitrary programs is an order of magnitude harder.

Re: Mandatory enforcement of indirect branch targets

#134

Post by PrimeMcFly » Sun, Jul 16, 2023, 4:52 AM UTC

saagarjha wrote: post #133

PrimeMcFly wrote: post #130

Earlier quoted context omitted.

It's not a sandbox though, because it's a different type of technology. You can say it's a type of sandbox in concept, and you could make an argument, but referring to it as a sandbox in a technical discussion simply isn't correct. > The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party…

I mean the typical term used for such things is “mandatory access control” but they always get used to implement a sandbox so that’s what I call them. Also, watching a program to see what it does is exactly the issue I’m talking about. You’re stuck with whatever behaviors you tested and everything else that you didn’t hit will fail (loudly if you’re lucky, silently if you’re not). There are platforms that do exactly…

Some implement role based access control or other access control paradigms as well. I just don't think sandbox is a good term, but I see where you're coming from.

I agree initial setup can be cumbersome, but I think it's worthwhile. I'm a fan of RSBAC personally, it's as powerful as SELinux but a lot simpler. If people run in permissive mode and test properly, not just run it and do a few things, but test every function exhaustively before setting up permissions, it should be good.

Really, it only has to be done once, and I think it's a worthwhile investment given the security gained.

That's what I was saying higher up in the thread though. OpenBSD is known for having good, simple implementations of complex stuff like this, so if they ever were itnerested in implementing a version, it would probably be amazing.