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

111–120 of 134 posts

Re: Mandatory enforcement of indirect branch targets

#111

Post by saagarjha »

andersa wrote: post #52
wongarsu wrote: post #23

Earlier quoted context omitted.

Interesting. Seems like enforcement on Intel CPUs is supported since Tiger Lake (so ~2020). Windows has basically the same feature implemented in software since 2015, called Control Flow Guard [1]. I wonder what the story there is, and if Windows has any plans to (get everyone to) switch to the hardware version once those CPUs have sufficient market share. 1: https://learn.microsoft.com/en-us/windows/win32/secbp/cont…

Windows also recently implemented a far better version of this called Extended Flow Guard (XFG) that not only checks whether the location is a valid destination, but also whether it's a valid destination for that specific source. For example, for any virtual function call or function pointer call, the destination must have a correct tag with the hash of the arguments. It's much more secure, and also faster, since loa…

ARM does it!

Re: Mandatory enforcement of indirect branch targets

#112

Post by saagarjha »

derefr wrote: post #43
josephcsible wrote: post #28

Earlier quoted context omitted.

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

That sounds a lot like “add a prefix to the function with an endbr64 instruction”.

Re: Mandatory enforcement of indirect branch targets

#113

Post by saagarjha »

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…

> He may have some deep insecurities.

Explains why he spends all his time developing mitigations

Re: Mandatory enforcement of indirect branch targets

#114

Post by LexiMax »

NoZebra120vClip wrote: post #76
Ericson2314 wrote: post #60

Earlier quoted context omitted.

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

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

The problem is that for every Linus, Theo, or RMS, you have a dozen tactless buffoons who aren't a tenth as talented as any one of these individuals, are a chore to work with, and couldn't manage their way out of a paper bag. I've even seen some developers defend their lack of social skills by drawing comparisons to people like Linus and Theo.

That's why Linus shows an incredible amount of insight and maturity by purposefully and vocally trying to distance himself from that image and set a better example. He might be able to make being abrasive work, but most people can't.

Re: Mandatory enforcement of indirect branch targets

#115

Post by dundarious »

tialaramex wrote: post #107
dundarious wrote: post #100

Earlier quoted context omitted.

True, when writing my comment I wanted to qualify it to the same effect, but thought it would be an unnecessary subtlety to the general thrust of my point. That is, we can ignore this kind of "undefined behavior in the machine itself" for the purposes of this particular discussion.

I don't see how to ignore it though. If we're defining the behaviour but then our "definition" just doesn't specify the actual behaviour because it's specified in terms of hardware with no clearly defined behaviour for that situation then it's just word play, we're not really doing what I set out.

If for the purposes of this discussion we can't ignore it at the machine level (because we're assuming higher level languages, crappy or otherwise, are unlikely to generate machine instructions that exhibit undefined behavior), then why were we discussing higher level languages and their crappiness at all? I'm not saying this to be snarky, I just mean that I really think the likelihood of machine undefined behavior being an issue is on the order of likelihood for cosmic rays to flip bits -- happens, and can't be ignored (buy ECC memory), but more interesting to talk about the things that we are many orders of magnitude more likely to experience, e.g., bugs in C programs, bugs in unsafe Rust, bugs in managed language runtimes, etc. I think those things are not all equally likely, but could all benefit from endbr64 type mechanisms, including in JIT output.

To be clear, unlike the comment root, I don't think this particular hardware mechanism obviates the need/benefits of related software mechanisms. But in terms of cost/benefit/applicability, endbr64 type mechanisms look pretty good all around.

Re: Mandatory enforcement of indirect branch targets

#116

Post by wahern »

NoZebra120vClip wrote: post #76
Ericson2314 wrote: post #60

Earlier quoted context omitted.

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

"Running a successful open source project is just Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights."

-- Byrne Hobart, https://web.archive.org/web/20200909035546/https://diff.subs...

Re: Mandatory enforcement of indirect branch targets

#117

Post by ComputerGuru »

andersa wrote: post #52
wongarsu wrote: post #23

Earlier quoted context omitted.

Interesting. Seems like enforcement on Intel CPUs is supported since Tiger Lake (so ~2020). Windows has basically the same feature implemented in software since 2015, called Control Flow Guard [1]. I wonder what the story there is, and if Windows has any plans to (get everyone to) switch to the hardware version once those CPUs have sufficient market share. 1: https://learn.microsoft.com/en-us/windows/win32/secbp/cont…

Windows also recently implemented a far better version of this called Extended Flow Guard (XFG) that not only checks whether the location is a valid destination, but also whether it's a valid destination for that specific source. For example, for any virtual function call or function pointer call, the destination must have a correct tag with the hash of the arguments. It's much more secure, and also faster, since loa…

There’s a great article on XFG here [0] but it observed that a failed XFG check downgrades to a regular CFG check instead of a denial.. meaning it adds zero extra protection? Perhaps this behavior has changed since the preview they tested, though!

[0]: https://www.offsec.com/offsec/extended-flow-guard/

Re: Mandatory enforcement of indirect branch targets

#119

Post by gizmo686 »

jeffbee wrote: post #50
messe wrote: post #9

Earlier quoted context omitted.

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.

That would be surprising. xor is often used like that to set a register to 0, which is far from a nop. I'm not sure why it would do it twice, but it might be as simple as the compiler being stupid.

Re: Mandatory enforcement of indirect branch targets

#120

Post by PrimeMcFly »

saagarjha wrote: post #110
PrimeMcFly wrote: post #62

Earlier quoted context omitted.

They don't provide any mitigations of the sort I was clearly referencing. Specifically, for restricting malicious code or users that already has access to the system, exploiting insecure software that was not compiled with pledge support.

What kind of mitigations would help here?

SELinux/RSBAC/AppArmor/grsecurity and similar.
Post reply on HN