cmd/asm,cmd/compile: add support for control flow integrity #66054
Comments
gopherbot
added
the
compiler/runtime
|
Change https://go.dev/cl/568435 mentions this issue: |
|
How much good enough are you asking for this to be ? For comparison don't even enable ASLR by default. (and |
mknyszek
added
the
NeedsInvestigation
…nbsd OpenBSD enables Indirect Branch Tracking (IBT) on amd64 and Branch Target Identification (BTI) on arm64, where hardware permits. Since Go generated binaries do not currently support IBT or BTI, temporarily mark them with PT_OPENBSD_NOBTCFI which prevents branch target CFI from being enforced on execution. This should be removed as soon asn IBT and BTI support are available. Fixes #66040 Updates #66054 Change-Id: I91ac05736e6942c54502bef4b8815eb8740d2d5e Reviewed-on: https://go-review.googlesource.com/c/go/+/568435 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Josh Rickmar <jrick@zettaport.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
|
BTCFU is a palliative for C and C++ which allow ROP due to their deficient design and allowance for undefined behavior. If one doesn't use unsafe, then ROP should not be possible in Go. This might negatively affect the performance of Go programs and is another example of how non C programming languages have to pay "C taxes" as it were. This should certainly remain optional. Furthermore I think it is crazy that now we have to introduce a "come from" assembly instruction just because of the critical design flaws of C. Rather, we should be working on getting rid of C everywhere, including in OS. |
Modern CPUs provide support for branch tracking control flow integrity (BTCFI) in the form of Intel's Indirect Branch Tracking (IBT) and AARCH64's Branch Tracking Identification (BTI). BTCFI helps to mitigate flow control based exploits, such as those achieved via Return Oriented Programming (ROP).
Some operating systems (for example, OpenBSD 7.4 onwards) are starting to enforce IBT and BTI on hardware where it is available (Intel Tigerlake onwards, Apple's M2, etc). Go binaries need to be marked with
PT_OPENBSD_NOBTCFIin order to allow them to execute. Other operating systems have varying levels of support (Linux enables IBT in the kernel, but not userland AIUI - https://lwn.net/Articles/889475/).Go should ideally support BTCFI - in the IBT/BTI case it is effectively a matter of providing a "landing pad" instruction (
endbr64onamd64andbti conarm64), at function entry points and any other locations where control flow is expected to land. On machines that do not support these instructions (or have BTCFI enabled/enforced in userland), they are effectively a no-ops. This does potentially impact code where it is intentional to jump into a function at some offset - for example, duff devices (DUFFCOPY,DUFFZERO) and jump tables. This would also need landing pads at each potential entry point, or revisiting/disabling.The text was updated successfully, but these errors were encountered: