Thu, Dec 12
Here are changes for gcry_md_open and its friends.
My idea in https://dev.gnupg.org/T7338#195529 doesn't work well when a function call is done multiple times.
Assuming SUCCESS, and marking all non-compliant places in the code works, and it would be good because libgcrypt so far maintains non-compliant path with rejection.
Mon, Dec 9
Pushed the change for adding hash tests in rC7faf542f1573: fips,tests: Add t-digest.
Fri, Dec 6
It seems that the internal API is not enough.
Now, we have _gcry_md_hash_buffer function with the new FIPS service indicator.
It's used for public key crypto, too.
The compliance for hash function is a part of public key crypto, but not all.
A change for gcry_md_hash_* functions are pushed by rC3478caac62c7: fips,md: Implement new FIPS service indicator for gcry_md_hash_*..
It doesn't have tests with FIPS service indicator yet.
Thu, Dec 5
New external API is by GCRYCTL_FIPS_SERVICE_INDICATOR and/or the new macro gcry_get_fips_service_indicator.
This change is pushed by rCf51f4e98930e: fips: Introduce GCRYCTL_FIPS_SERVICE_INDICATOR and the macro.
New internal API is introduced with T7340 by the commit rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.
Change is pushed by rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.
Wed, Dec 4
Nov 14 2024
Nov 4 2024
Oct 24 2024
I created a branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/
Oct 16 2024
Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html
Oct 15 2024
Sep 17 2024
Sep 12 2024
Sep 6 2024
Sep 4 2024
Sep 2 2024
Use --enable-large-data-tests with configure and go out for a real long lunch
Aug 30 2024
As far as I know the practice to have separate -dev packages is very common among Linux distributions.
I wonder how common this practice of splitting development material into a separate file might be? It is in place at Alpine, since the file libgpg-error-dev exists. Once the related component is instaled, these messages/strings are printed:; output filtered:
checking for GPG Error - version >= 1.49... expr: warning: '^x-L': using '^' as the first character of a basic regular expression is not portable; it is ignored yes (1.49)
Aug 29 2024
Does alpine split the development files of libgpg-error into a separate *-devel (or similar) package like most other distros? If yes, then you need to install this development package.
Aug 28 2024
Thanks. Test works in my nightly builds now.
Aug 26 2024
That's my badness.
I noticed by the CI at https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror
Aug 22 2024
Aug 7 2024
I do not have Aarch64 machine at hand so what I did was building the package with changes on the build system with previous patches and checking the correct flag are in place (previously in RHEL10, but now in Fedora):
Do you have any way to test PAC/BTI on actual HW that support these extensions?
Aug 6 2024
Aug 5 2024
Thanks! Verified this builds on aarch64 correctly and generates the right flags on the output:
Hardened: /builddir/build/BUILDROOT/libgcrypt-1.11.0-3.el10.aarch64/usr/lib64/libgcrypt.so.20.5.0: Overall: PASS.
This excludes 32-bit ARM assembly from Aarch64 builds:
Tested in our build environment and indeed, just this patch does not solve the issue for aarch64.
Aug 4 2024
Here's patch:
This patch should fix the issue:
Ok, so aarch64 assembly would need PAC and BTI support. As far as I have understood these, is that PAC instructions are not needed with current assembly as none of those is storing/loading LR register (all aarch64 assembly functions are leaf functions). So only BTI is needed and that is basically same modification as CET on x86.
This already shows with 9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which initially added ec-inline.h. (Reproducing with old versions like this one requires cherry-picking 693ffa145378682229473b0e811a9cea7c4d307a since otherwise NEON support is disabled at configure time due to implicit functions.)
Jul 29 2024
Recent changes fixed the issue for the x86_64 builds, but I see similar symptoms in the aarch64 build now. Annocheck reports the following failures:
Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-dynamic-tags.html Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: property-note test because properly formatted .note.gnu.property not found (it is needed for branch protection support) Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-property-note.html
I do not have aarch64 machine at hand now to investigate this further, but this sounds like orthogonal functionality to the CET on Intel.
Jul 28 2024
Jul 27 2024
Thank you. With this patch the IBT flags are present on the shared object and CF protection test passes.
"rijndael-vaes-avx2-i386.S" should not be build for x86-64 but until now that has not had any affect as #ifdefs in that source file result empty object file on x86-64.