-
Notifications
You must be signed in to change notification settings - Fork 18k
crypto/internal/fips140: segfault from hmac memmove #70880
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Does this repeat easily/often? |
@golang/openbsd |
I confirm it is reproducible, both on the laptop and on an older NUC running openbsd-stable.
[edited to correct earlier version of comment; I hadn't waited long enough on the NUC then]
…On Tue, Dec 17, 2024, 10:46 David Chase ***@***.***> wrote:
Does this repeat easily/often?
|
It's segfaulting when trying to read sections from the binary to hash them, which is an unfortunate FIPS requirement. I seem to remember OpenBSD was moving to make executable pages unreadable, which would be consistent with this. We might have to just declare OpenBSD incompatible with FIPS 140 mode. Unclear why the builders don't catch this. |
Fine with me if Go says any OS using the security mitigation of "--execute-only" in the ELF linker from LLVM is ineligible for FIPS 140 mode. I'm no expert, but I gather that in addition to OpenBSD this includes some configurations of Android and Fuchsia. There is continuing debate whether all the security mitigations that OpenBSD turns on are ultimately worth it. I like simplicity myself so wish it weren't so, but for some years I have voted with my feet: based on the evidence of real-world compromises, the machines I trust only run bare-bones OpenBSD. I wonder if NIST will hold to that requirement of reading the text page if confronted with the incompatibility with extreme-security-configuration? |
(I started raising an issue for this a few weeks back, only now managing to get back to it)
This is correct - OpenBSD runs with non-readable (execute-only) text segments on many architectures, since OpenBSD 7.3. For Go supported architectures this includes amd64, arm64, ppc64 and riscv64 - this gets more complex since the Go internal linker does not currently produce read-only text, which means failures only show up with external linking. Additionally, the code generated by Go's arm64 assembler still loads some constants from text (rather than rodata). As such, we currently disable execute-only when external linking on openbsd/arm64.
I think there are two options - one is to declare OpenBSD incompatible with FIPS 140 mode, the other is to somehow know if FIPS mode is enabled when linking, in which case we can compile with
Unfortunately the https://build.golang.org/log/3c069cafb6d5d2659ecefc9d8ef47bdf5cc59d92 |
Thank you @4a6f656c, that all makes sense. FIPS 140 mode is selected at runtime, so there is no way to enable We're not validating the module on OpenBSD, at least for now, so it's fine to just mark it unsupported, and we can reassess in the future in case.
Various objections to the integrity check requirement have been raised, and so far they have all failed to change anything. Last I heard, NIST was claiming they are not responsible for it because it's in the ISO standard (although they can and do waive requirements in SP 800-140 or IG documents). If anyone wants to give this a shot, I'd support it. |
Change https://go.dev/cl/639337 mentions this issue: |
I had a (horrible) thought, from my checkered past. The signal handler could check for reads from executable pages, and if FIPS mode is enabled and the address is in the range of the FIPS code, then temporarily remap that page, make a copy, and in the future redirect reads from that page to the copy. The shadow page could even be pre-allocated by the linker. |
Go version
go version go1.24rc1 openbsd/amd64
Output of
go env
in your module/workspace:What did you do?
On a Lenovo Carbon X1 running openbsd-current Dec 13,
What did you see happen?
What did you expect to see?
normal successful build
The text was updated successfully, but these errors were encountered: