CC @agl @FiloSottile

BoringSSL supports FIPS on ARM, but only in shared-library mode, which isn't really suitable for Go. Static linking support is complicated and would only be added if Google had a business case for it. However, no details nor timeline would be shared publicly about such internal matters I'm afraid.

So, if it happens to get built for other reasons, Go could use it. But we've no comment about if or when that might happen.

Is this something Apple could potentially help with? macOS is a big user of BoringSSL these days. Watching the keynote yesterday, Apple is contributing changes to many FOSS projects to add ARM support (ex Blender).

Apple has their own crypto library with SecureTransport and I'm not aware of any FIPS effort at Apple, so I would be surprised if they did anything with BoringCrypto:
https://developer.apple.com/documentation/security/secure_transport

There would be a better chance of AWS contributing since they are pushing for ARM and they have dedicated FIPS endpoints:
https://aws.amazon.com/compliance/fips/

Deleted my original post after researching more:

1. The FIPS go version shipping with RHEL is basically just the Boringcrypto branch just pointing to openssl. The code is hosted on https://pagure.io/go.
2. The RHEL version is also not enabling may not be enabling OpenSSL support for ARM when building.
3. As far as I know Boring's FIPS cert does not cover ARM currently, but OpenSSL's does.

Is there any progress on this?

@FiloSottile I do not know if you can share any information on the topic, but we are interested in switching our kubernetes instances to ARM and the main thing holding us back is the lack of FIPS support. Having a rough idea of the status for this to know if it is being considered or completely unlikely would help plan longer term.

Thank you.

Having a rough idea of the status for this to know if it is being considered or completely unlikely would help plan longer term.

It is being considered. However, even if it were to occur, our last CMVP submission spent nearly a year in processing so the timeline to a certificate being issued is long.

Would the module associated with this certificate be usable for this case? It is BoringCrypto and it is for ARM. Although it is technically for Android, it seems like this would probably still work based on this paragraph.

https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3753

As per FIPS 140-2 Implementation Guidance G.5, compliance is maintained for other versions of the
respective operational environments where the module binary is unchanged.

I was informed by the good folks at Rancher that ARM support for Rancher Kubernetes Engine 2 (rancher/rke2) hinges on this issue. I would also like to move my k8s workloads to ARM on AWS's Graviton2 instance types, so progress on this issue would be great.

Good news, I was able to create a proof of concept arm64 goboring build with this change: https://github.com/golang/go/compare/dev.boringcrypto.go1.16...erikwilson:goboring-fips-20210429?expand=1

It updates boringssl to the newest fips-20210429 tag in the process, which includes commits from fips-android-20191020 which is used in that android cert.

Not sure about the need for a custom __umodti3 replacement that goboring is currently using, right now I am just letting alpine use libgcc for defining that symbol. The signature stuff also needs updating, would be nice if we could avoid using assembly in the goboring code.

Updating boringssl versions also required patching out weak symbol creation. The change is small and a better fix should probably be made upstream in boringssl, as far as I know there is not a good way to provide null values for those weak symbols in a static compilation.

With some experimentation I was able to update the C/XXFLAGS to undefine __ELF__ for boringssl compilation and create the same effect my patch would have of removing weak symbols. More importantly that change would probably be compatible with any Installation Instructions that are being developed for a new Security Policy to NIST certify the boringssl fips-20210429 stuff.

Would anyone happen to know if a draft of the new Installation Instructions or Security Policy is available, or if it might be possible to influence its contents? cc @agl @FiloSottile

Would anyone happen to know if a draft of the new Installation Instructions or Security Policy is available, or if it might be possible to influence its contents?

No draft available, and it's likely too late to change at this point. However, as your patch notes, mem.c isn't in the module so can be changed at will. Likewise with -fPIC if that's needed.

Is there any update on plans to merge Erik's patch?
Our org would also like to be able to use use GoBoring on ARM-based servers with a NIST certified crypto module, in order to still satisfy FIPS-140-2.

@agl Erik is no longer on our team, but if someone else were to pick up his work, is it likely to be accepted?

Before the change can be accepted I think BoringSSL should have an updated validation and security policy listed for 2021-04-29 or later.

Is there any update on this? Thank you

@brandond & @erikwilson: Does the recertification of BoringCrypto on an ARM CPU have to be a blocker to accepting this? ARM users would be no worse off than today in the interim, and arguably would be better, since they could make the case to their ATO that it's an acceptable risk in the meantime. Without including these changes there's not even the option of running it, precluding any Golang services running on an ARM platform (such as AWS graviton servers).

The main downside I can see would be if folk incorrectly assumed that just because this is merged it means that ARM usage is NIST certified, but I think that could be addressed with a clear disclaimer in the documentation. It doesn't look like there's currently any claims of any of the builds being NIST certified in the readme.md here, but a disclaimer could explicitly call out the ARM case if we wanted to be even more clear.

Rather than recertification of ARM for an already certified version this is certification for a newer release of BoringCrypto.

One of the potential issues with just moving forward with a PR like this before a certification is released is the impact on the x86_64 distribution. It may be that Google will not want to move forward until a certification exists that includes both x86_64 and arm64 hardware.

In the meantime if you are in the interesting position of being required to use BoringCrypto but do not need a certified version then you could always create your own release using the changes provided in this thread.

Just seeing this issue, but BoringCrypto ARM64 support is pending in go.dev/cl/423362.

Note, however, that we are making no claims about BoringCrypto whatsoever, nor GOEXPERIMENT=boringcrypto, nor are either supported by Google.

Small off topic...
Any plans for Windows and Darwin?

@Shnitzelil I tested on Drawin with Go 1.19 and the new GOEXPERIMENT=boringcrypto flag and confirmed that it used boring crypto by running goversion --crypto on the resulting binaries. It even works for cross compiling: we can build linux binaries with boring crypto directly from macOS, as long as there are no C libraries linked.

I have not tested Windows.

@rsc would it be possible for the GoLang project to document what is possible to compile with GOEXPERIMENT=boringcrypto as well as getting the FIPS certification made more explicit ? This is an important topic for some of the business users of Golang.

closing as https://go.dev/cl/423362 was merged.

https://go.dev/cl/423362 was merged, but that version of BoringCrypto has still not been approved by NIST. If NIST hasn't approved it by the go1.20 release date, anyone that depends on "FIPS approved" cryptography using boringcrypto will be unable to build using go1.20 since it will be using this module where approval is "pending".

Is the Go team depending on NIST approving before the go1.20 release date? Should there be a backup plan in case approval hasn't occurred by that date?

@wadey I don't know the answer to those questions, but I don't think a closed issue that is specific to arm64 support is a good place to discuss them. Want to ask on golang-dev or open a new issue? Thanks.

@wadey I don't know the answer to those questions, but I don't think a closed issue that is specific to arm64 support is a good place to discuss them. Want to ask on golang-dev or open a new issue? Thanks.

Good point, I started a conversation here: https://groups.google.com/d/msgid/golang-dev/1f6c6a1b-fc32-4df8-b172-4631c39a6bd1n%40googlegroups.com

Thanks!

Sorry to bump a closed issue, I'm not a Go developer. I saw that 423362 was merged and that this issue was closed. Does this mean that boringcrypto+arm64 is available in Go? If so, what version of Go? 1.20? Thanks!

@lmarchione-r7 In general see https://go.dev/wiki/Questions for good places to ask questions.

For boringcrypto in particular see https://go.googlesource.com/go/+/refs/heads/dev.boringcrypto/README.boringcrypto.md