[HN Gopher] Bringing Stack Clash Protection to Clang / x86
___________________________________________________________________
Bringing Stack Clash Protection to Clang / x86
Author : fcambus
Score : 40 points
Date : 2021-01-31 08:25 UTC (14 hours ago)
(HTM) web link (blog.llvm.org)
(TXT) w3m dump (blog.llvm.org)
| saagarjha wrote:
| This is a surprisingly deep look at what went into a fairly
| simple feature.
| codeflo wrote:
| > Support for this flag landed in Clang in 2020 only for X86,
| SystemZ and PowerPC.
|
| How relevant is x86 code in terms of security? Genuine question.
| I thought Firefox defaults to x86_64 now even Windows. And in
| open source land, wouldn't any OS components that could be
| compiled with Clang be x86_64 as well?
| invokestatic wrote:
| I do believe x86 in this case encompasses x86_64 (I checked
| this on the llvm phabricator to be sure).
| codeflo wrote:
| Oh? That's great then. Not the kind of sloppiness I'd have
| expected in a compiler blog though. Especially since it deep
| dives into calling conventions, which differ quite a bit
| between the two.
| invokestatic wrote:
| In the LLVM project, x86_64 is handled inside the x86
| namespace. To a compiler, there's quite a lot of overlap
| between x86 and the 64-bit extensions that it makes sense
| to keep them together.
|
| In the source, where the difference matters, you'll see the
| prefix X86_32 and X86_64.
| jdsully wrote:
| MSVC had this for as long as I can remember. I was a little
| surprised the major Linux compilers didn't have code to trigger
| guard pages on large allocations. It's not totally unreasonable
| to access a large buffer from the top down.
___________________________________________________________________
(page generated 2021-01-31 23:03 UTC)