Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mandatory enforcement of indirect branch targets

undeadly.org

Post reply on HN
Print view View original

41–50 of 134 posts

Re: Mandatory enforcement of indirect branch targets

#41

Post by selectodude »

rkangel wrote: post #17
Joker_vD wrote: post #13

Earlier quoted context omitted.

That's the problem with many brilliant people: what they perceive as their interlocutors being deliberately obtuse on some completely obvious point is actually their interlocutors being just as smart as they always are on some point that is not obvious at all to them.

Perception of relative intelligence or sensible decision making is irrelevant. Just because you think you're doing a better job doesn't mean you need to shit on the other person. You could not mention Linux at all, or you could even say "we think this is better than Linux's approach because of X" and it would be a great improvement. I have always found it interesting that Rust purposefully avoided doing language comp…

I think parent agrees with you.

Re: Mandatory enforcement of indirect branch targets

#42

Post by whoopdedo »

brynet wrote: post #21
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…

It's an important comparison of the mechanisms, even in 2023, you can still find binaries on modern Linux distributions with executable stacks due to the fail-open design, 20 years later. The fact that Linux hasn't learned the right lessons in 20 years, and has chosen to "double down" in respect to IBT/BTI, does not inspire confidence that they will ever fix it. I'd say his 20 year estimate was in fact being pretty g…

It's the price you pay for never-break-userspace. OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules. The answer to that is to recompile because you've still got the source, and if not, well, tough cookies.

Re: Mandatory enforcement of indirect branch targets

#43

Post by derefr »

josephcsible wrote: post #28
codedokode wrote: post #15

Earlier quoted context omitted.

Why should every function start with endbr64 command? Aren't functions usually called directly? Also, is it required to insert endbr64 command after function calls (for return address)?

> Why should every function start with endbr64 command? Aren't functions usually called directly? They're usually called directly, but unless the compiler can prove that they always are (e.g., if they're static and nothing in the same file takes the address), endbr64 is required. > Also, is it required to insert endbr64 command after function calls (for return address)? No, IBT is only for jmp and call. SS is the equ…

> but unless the compiler can prove that they always are (e.g., if they're static and nothing in the same file takes the address), endbr64 is required

Then why not just have the compiler break down every non-static function into two blocks: a static function that contains all the logic, and a non-static function that just contains an IBT and a direct jump to the static function? (Or, better yet, place the non-static label just before the static one, and have the non-static fall through into the body of the static.) Then the static direct callsites won't have to pay the overhead of executing the IBT NOP.

Re: Mandatory enforcement of indirect branch targets

#44

Post by PrimeMcFly »

binkHN wrote: post #38
PrimeMcFly wrote: post #22

Earlier quoted context omitted.

I don't really buy their approach to security honestly. Trying to fix all bugs is great, but they provide little to prevent unknown bugs bing exploited (pledge is nice for software that opts in to use it, but otherwise not so much). I'd love to see them implement something like AppArmor with their approach, it would probably be amazing. I actually think NetBSD is a pretty interesting alternative, it has some nice sec…

I think in the past they tried to fix all the bugs, and realized they couldn't, so they started to build all sorts of mitigations in the same vein as the one you see posted here today. As for pledge, and the related mitigations, yes, they're not useful if you don't use them, but I see this as them innovating in the space and giving application developers more tools to build hardened applications. I see tools like App…

> I see tools like AppArmor as band-aids to fix problems that shouldn't exist in the first place.

I fundamentally disagree on that. I think tools like that are amazing at protecting against unknown threats/exploits. They let you lock down software and protect against future unknown exploits, badly behaving software, malicious employees etc. I think something similar should be a part of any OS claiming to be security focused. Basic DAC is woefully insufficient.

On the other hand, the industry has largely found other solutions like sandboxing, but I still think MAC or RBAC or whichever has a place, certainly as art of a defense in depth strategy.

Re: Mandatory enforcement of indirect branch targets

#45

Post by tremon »

josephcsible wrote: post #31
ntfAX wrote: post #27

A software solution provided by the OS or language can make this hardware solution irrelevant.

You've got it backwards: this hardware solution makes the software solutions irrelevant.

It's only irrelevant if the hardware solution is available on all the supported architectures/systems. As long as it's not, the software version must be maintained anyway, and might suffer from bitrot if it's no longer exercised on the major architectures.

Re: Mandatory enforcement of indirect branch targets

#46

Post by loeg »

whoopdedo wrote: post #42
brynet wrote: post #21

Earlier quoted context omitted.

It's an important comparison of the mechanisms, even in 2023, you can still find binaries on modern Linux distributions with executable stacks due to the fail-open design, 20 years later. The fact that Linux hasn't learned the right lessons in 20 years, and has chosen to "double down" in respect to IBT/BTI, does not inspire confidence that they will ever fix it. I'd say his 20 year estimate was in fact being pretty g…

It's the price you pay for never-break-userspace. OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules. The answer to that is to recompile because you've still got the source, and if not, well, tough cookies.

> OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules.

To clarify slightly, OpenBSD is fine with the very high probability that an executable will fail under new rules. Otherwise, yes.

Re: Mandatory enforcement of indirect branch targets

#47

Post by tialaramex »

josephcsible wrote: post #31
ntfAX wrote: post #27

A software solution provided by the OS or language can make this hardware solution irrelevant.

You've got it backwards: this hardware solution makes the software solutions irrelevant.

Nope. Here's the actual problem, in these crappy languages it's really easy for mistakes to result in a stack smash, so, these types of hacks aim to make it harder for the bad guys to turn that into arbitrary remote code execution. Not impossible, just harder. Specifically in this case the idea is that they won't be able to abuse arbitrary bits of function without calling the whole function, at a cost of some hardware changes and emitting unnecessary code. So maybe they can't find a whole function which works for them and they give up.

Using better languages makes the entire problem disappear. You don't get a stack smash, the resulting opportunities for remote code execution disappear.

It suggests that maybe the "C magically shouldn't have Undefined Behaviour" people were onto something after all. Maybe C programmers really are so wedded to this awful language that just being much slower than Python wouldn't deter them. There is still the problem that none of them can agree how this should work, but if they'll fund it maybe it's worth pursuing to find out how much they will put up with to keep writing C.

Re: Mandatory enforcement of indirect branch targets

#48

Post by ndesaulniers »

whoopdedo wrote: post #42
brynet wrote: post #21

Earlier quoted context omitted.

It's an important comparison of the mechanisms, even in 2023, you can still find binaries on modern Linux distributions with executable stacks due to the fail-open design, 20 years later. The fact that Linux hasn't learned the right lessons in 20 years, and has chosen to "double down" in respect to IBT/BTI, does not inspire confidence that they will ever fix it. I'd say his 20 year estimate was in fact being pretty g…

It's the price you pay for never-break-userspace. OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules. The answer to that is to recompile because you've still got the source, and if not, well, tough cookies.

> the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules

Isn't it any indirect branch in any program that will trip BTI/IBT? So most programs? I guess I disagree with the `small probability ` part.

Re: Mandatory enforcement of indirect branch targets

#49

Post by josephg »

messe wrote: post #30
Joker_vD wrote: post #26

Earlier quoted context omitted.

Well, if the function is marked "static", the compiler can actually check whether the function's address is taken in the current compilation unit or not and omit/emit ENDBR64 accordingly (passing pointers to static functions to code in another compilation units is legal, and should still work).

Good catch. Yeah, as long as the functions address is never taken the compiler has a lot of leeway with static functions; it can even avoid emitting code for them entirely if it can prove they're never called or if it's able to compute their results at compile-time.

Yep. Or inline them at every call site if that makes sense to do based on the optimization level and flags.

Re: Mandatory enforcement of indirect branch targets

#50

Post by jeffbee »

messe wrote: post #9
rollcat wrote: post #8

Earlier quoted context omitted.

Various architectures do other interesting things with NOPs, IIRC one convention on PowerPC had something vaguely related to debugging or tracing (I can't remember the details or find any references right now).

Not just architectures, but different OSes and ABIs have found ways to repurpose no-ops. One example[1] is Windows using the 2-byte "MOV EDI, EDI" as a hot-patch point: it gets replaced by a "JMP $-5" instruction which jumps 5 bytes before the start of a function into a spot reserved for patching. That 5 bytes is enough to contain a full jump instruction that can then jump wherever you need it to. ## Why do Windows f…

Interesting, thanks for pointing this out! Just yesterday I was gazing at some program containing two consecutive xor rax, rax. I thought what’s the point? But as you point out it might be a NOP sled designed to be that specific length.
Post reply on HN