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

71–80 of 134 posts

Re: Mandatory enforcement of indirect branch targets

#71

Post by jacquesm »

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.

Tough cookies translates for many people into: OpenBSD is not for me. The 'very small probability' likely approaches '1' for sufficiently old enough stuff. And even if you do have the source, does it still build without substantial work? Backwards compatibility is not something to toss out the window without thinking through the consequences.

Re: Mandatory enforcement of indirect branch targets

#72

Post by jacquesm »

VancouverMan wrote: post #34
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…

That part doesn't look like a "dig" or an insult to me. It seems like a reasonable, relevant, and plausible assessment of how the long-term outcomes may likely differ between OpenBSD's stricter approach versus a looser approach, specifically when it comes to the degree of security offered (which is one of OpenBSD's main focuses), based on a past situation that's similar. How do you know that you aren't being, to use…

> How do you know that you aren't being, to use your words, "quick to take offense where none was meant" in this case?

Past knowledge about Theo?

Re: Mandatory enforcement of indirect branch targets

#73

Post by NoZebra120vClip »

Ericson2314 wrote: post #16
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…

Are Theo and Linux more alike than OpenBSD and Linux?

> Are Theo and Linux more alike than OpenBSD and Linux?

Is a Canadian kernel developer more like a POSIX operating system than a POSIX operating system is like a POSIX operating system?

I'm not sure I understand. Perhaps you meant to write "Linus" since Linus is also a kernel developer? That seems more like apples to apples.

Re: Mandatory enforcement of indirect branch targets

#74

Post by binkHN »

jacquesm wrote: post #69
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…

The funny thing is that this attitude towards breaking changes is one of the reasons why Theo is able to make this comment at all. If he would allow breaking changes then OpenBSD adoption likely would be higher and that in turn would cause him to resist the kind of things that Linux would not be able to get away with. It's clearly different philosophies leading to different outcomes with neither of them clearly bette…

Theo himself considers OpenBSD a “research” OS, so I don’t think he’ll ever consider OpenBSD going mainstream, especially as it allows stuff like this to happen.

Re: Mandatory enforcement of indirect branch targets

#75

Post by MuffinFlavored »

binkHN wrote: post #14

I still run OpenBSD where I can, especially where security is more important. Yes, it's still missing A LOT of functionally compared to other UNIX-like systems, but security bases tend to be well covered.

> Yes, it's still missing A LOT of functionally compared to other UNIX-like systems

Could you give some examples/samples of things you have ran into off the top of your head?

Re: Mandatory enforcement of indirect branch targets

#76

Post by NoZebra120vClip »

Ericson2314 wrote: post #60
LexiMax wrote: post #36

Earlier quoted context omitted.

Linus has been trying to calm down in recent years, in large part because he decided he no longer wanted to be lumped in with the crowd that endlessly complains about political correctness. https://www.bbc.com/news/technology-45664640

Yeah this is good stuff, and why I felt bad about making the comparison. Not saying Theo is in that camp, but Linus is trying to be less abrasive in general, and Theo is not.

Perhaps we're reading into their personalities more than we should, based on public social-media appearances.

Egos tend to become exaggerated when benevolent dictator types make public statements. Their candor and bluntness on a mailing list or Twitter may be completely different than their demeanor and their kindness toward collaborators in private.

Now we have the very public drama that happened between Theo and that "other BSD" team to create the original schism. But have we had any subsequent drama that caused breakups or forks? I don't know. OpenBSD manages to plug away and push releases out the door on schedule, right?

Linus doesn't seem to have a lot of internal contributor drama, judging by the way they also push releases out the door and merge pull requests and add features.

Really, if either Theo or Linus were unreasonable men, their teams would fall apart and they would cease to be leaders of anything. I think their leadership abilities speak for themselves: they've both been committed and dedicated to the same project since decades ago, and they've both built and maintained cohesive teams of contributors who seem to mostly stick around long enough to make a difference.

They are "thought leaders", if you will; perhaps not charismatic ones, but canny businessmen who know how to nurture their pet projects.

Re: Mandatory enforcement of indirect branch targets

#77

Post by wongarsu »

ntfAX wrote: post #27

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

Windows does this in software, since approximately 8 years.

An advantage of the software solution is that you don't need to have the feature compiled into every library for it to work, you just lose protection in those parts. That makes for a much quicker rollout. Also faster iteration times, in the Windows Insider Preview you can get the extended version that also checks that the hashed function signature matches.

1: https://learn.microsoft.com/en-us/windows/win32/secbp/contro...

Re: Mandatory enforcement of indirect branch targets

#78

Post by dundarious »

tialaramex wrote: post #47
josephcsible wrote: post #31

Earlier quoted context omitted.

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 hardwar…

I think one could argue that all the software mitigations that aren't based on compile time proofs result in quite a bit more "emitting unnecessary code", if "unnecessary" is taken to mean "not strictly intrinsic to the task of the program". And undefined behavior is bad, but getting rid of it wouldn't be a silver bullet for this problem in C, I think. All undefined behavior could become "implementation defined" tomorrow, where the C compiler becomes more like a high-level assembler (again), and you could still jump the instruction pointer into arbitrary program text.

Re: Mandatory enforcement of indirect branch targets

#79

Post by jacquesm »

binkHN wrote: post #74
jacquesm wrote: post #69

Earlier quoted context omitted.

The funny thing is that this attitude towards breaking changes is one of the reasons why Theo is able to make this comment at all. If he would allow breaking changes then OpenBSD adoption likely would be higher and that in turn would cause him to resist the kind of things that Linux would not be able to get away with. It's clearly different philosophies leading to different outcomes with neither of them clearly bette…

Theo himself considers OpenBSD a “research” OS, so I don’t think he’ll ever consider OpenBSD going mainstream, especially as it allows stuff like this to happen.

Indeed, so it's apples-to-oranges.

Re: Mandatory enforcement of indirect branch targets

#80

Post by binkHN »

MuffinFlavored wrote: post #75
binkHN wrote: post #14

I still run OpenBSD where I can, especially where security is more important. Yes, it's still missing A LOT of functionally compared to other UNIX-like systems, but security bases tend to be well covered.

> Yes, it's still missing A LOT of functionally compared to other UNIX-like systems Could you give some examples/samples of things you have ran into off the top of your head?

Sure. Poor SMP support (but this has improved heavily over the years), ancient file system, no Bluetooth (not important if you don't need this), reduced performance (due to a lack of optimizations and security mitigations overhead), limited Wi-Fi support (this is for numerous reasons, but it's better than other BSDs)...

I could go on, but, for my needs, it works very well and some of its simplicities are a godsend.

Post reply on HN