User Details
- User Since
- Jan 6 2021, 10:04 AM (204 w, 11 h)
- Availability
- Available
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):
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.
Tested in our build environment and indeed, just this patch does not solve the issue for aarch64.
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 27 2024
Thank you. With this patch the IBT flags are present on the shared object and CF protection test passes.
Jul 26 2024
Thank you for having a look into this!
Jul 25 2024
Jul 24 2024
Jul 15 2024
Jul 4 2024
Jun 21 2024
Oh, I did not notice the change as I clicked to the patch from mail notification. Trying now with the updated one:
Running scratch build on s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=119376728 with the proposed change. The failure is now:
Jun 20 2024
Thank you for having a look into that. If I see right, Fedora has a real s390 hardware for builders so I can verify the fix when available.
Jun 19 2024
May 29 2024
I left review comments in gitlab.
May 28 2024
Fair enough. This is more theoretical and could happen only on huge reads. Using ssize_t for read() return value is safe option, but really does not make sense to adhere to it in cases where the reads must be smaller.
May 21 2024
Right, thats my understanding from reading of the RFC that the padding should be strictly < 8B. We can reword though.
The report went like this
Error: OVERRUN (CWE-119): libgcrypt-1.10.3/cipher/cipher-aeswrap.c:303: cond_at_most: Checking "plen > 8U" implies that "plen" may be up to 8 on the false branch. libgcrypt-1.10.3/cipher/cipher-aeswrap.c:305: cond_between: Checking "plen" implies that "plen" is between 1 and 8 (inclusive) on the true branch. libgcrypt-1.10.3/cipher/cipher-aeswrap.c:309: assignment: Assigning: "i" = "0". libgcrypt-1.10.3/cipher/cipher-aeswrap.c:310: overrun-local: Overrunning array "t" of 16 bytes at byte offset 16 using index "8U + plen + i" (which evaluates to 16). # 308| # 309| for (i = 0; i < 16 - (8+plen); i++) # 310|-> if (t[8+plen+i]) # 311| { # 312| err = GPG_ERR_CHECKSUM;
but looking again, it is wrong as it did not reflect the end condition for the cycle, which obviously means the cycle does not run. Sorry for the noise.
Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.
May 20 2024
May 7 2024
I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.
Apr 26 2024
Mar 28 2024
For the reference, for now i just did the dummy install in the Fedora spec file:
Feb 12 2024
Jan 31 2024
Nov 27 2023
Nope, The gpgconf --kill keyboxd hangs too, if I see right, while waiting for agent:
$ strace gpgconf --kill keyboxd [...] clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2d74fe2a10) = 3244 wait4(3244, 0x7ffc9836e364, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
Nov 24 2023
Aug 29 2023
Jun 27 2023
From the FIPS 186-5 there are some limitations to use the SHAKE in FIPS Mode that we will have to reflect:
Jun 20 2023
Thank you for having a look into that! The proposed patch looks good. Should we have this change also in master?
Jun 15 2023
Jun 13 2023
Another approach would be having "non-hash" algo for gcry_md_open.
Jun 12 2023
FYI, while going through the licenses again I noticed one of the pinentry files have even older address that so if you would do sed, this would not be matched:
Jun 1 2023
Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:
May 31 2023
May 30 2023
Mar 30 2023
Mar 20 2023
Mar 6 2023
Actually, the same issue is in the mac case, which I missed on first couple of reviews:
- enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos); + enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_mac_algos);
We discussed this further with the lab and there are more problematic flags that we need to "cut" and we can not do that always in the code as for example the RFC6979 (deterministic ECDSA signatures) are not allowed in the current version of the FIPS documents, but it is used in the selftests (which is weirdly enough allowed) so we just need to mark it unapproved. Lets discuss this further tomorrow.
Going through the code once more, there is one typo to be fixed:
+_gcry_fips_indicator_md (va_list arg_ptr) +{ + enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);
should say
+_gcry_fips_indicator_md (va_list arg_ptr) +{ + enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_md_algos);
otherwise ack.
Mar 2 2023
Mar 1 2023
We came to the same conclusion -- the SHAKE digests are not usable for sign/verify operations the way how it is implemented now. But it would be more clear if we would have explicit allow-list.
Nov 30 2022
Nov 10 2022
Oct 20 2022
In regards to this issue, we were also notified that the MD API using gcry_md_setkey() can be used to calculate HMACs and it does not have the needed input key length limitation. From the discussion here I read that we would like to keep the internal usage still available so my proposal would be to to add similar check as in gcry_mac_setkey() into the above function. Together with the revert, it is available in the following merge request:
Oct 18 2022
Oct 7 2022
One more nit regarding to the test is the format string for size_t which was using %d instead of %zu. This is fixed by the attached patch:
Oct 5 2022
I tried to clarify the comment in the following merge request. Feel free to pull it from there or adjust if it is too verbose or missing some points:
Oct 4 2022
Sep 30 2022
One nit that I overlooked initially is the memory leak, which is fixed with the following patch:
Sep 27 2022
The specs https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf page 10 says specifically:
Sep 26 2022
The test looks good. I hope I changed the API in all the hw optimized implementations.
Sep 23 2022
This still did not seem to help me in making the tests working on Fedora with git master. I am still getting wrong paths to the gpgconf
gpgscm: error running '/root/gnupg/tests/tools/gpgconf': probably not installed
There is a full reproducer and more complete log in https://bugzilla.redhat.com/show_bug.cgi?id=2089075#c11
Sep 19 2022
Aug 23 2022
Thank you for your work on the proposal. I have two comments:
- Do we have some test vector, which can be used in the testsute to test the new API?
- We need to mention the new API in the documentation.
Aug 18 2022
For the record, the changeset in the attached merge request is final and waiting for reviews.
Aug 9 2022
Aug 1 2022
The provided change does not look like fixing the problem for me. The path to gpgconf is still wrong and I am getting the same error both with master and with the patched tarballs:
make[2]: Entering directory '/home/jjelen/devel/gnupg/tests/tpm2dtests' LC_ALL=C EXEEXT= PATH="../gpgscm:/home/jjelen/.local/bin:/home/jjelen/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin" abs_top_srcdir="/home/jjelen/devel/gnupg" objdir="/home/jjelen/devel/gnupg" TPMSERVER="" SWTPM="/bin/swtpm" SWTPM_IOCTL="/bin/swtpm_ioctl" GNUPG_BUILD_ROOT="/home/jjelen/devel/gnupg/tests" GPGSCM_PATH="/home/jjelen/devel/gnupg/tests/gpgscm" /home/jjelen/devel/gnupg/tests/gpgscm/gpgscm \ /home/jjelen/devel/gnupg/tests/tpm2dtests/run-tests.scm gpgscm: error running '/home/jjelen/devel/gnupg/tests/tools/gpgconf': probably not installed (wait-process "/home/jjelen/devel/gnupg/tests/tools/gpgconf" 2693795 #t): Configuration error
Jul 4 2022
Jun 7 2022
May 30 2022
AFAIK the above case has a lot of wiggle room to fit one PID and the surrounded string into 400 bytes and even if it would need to truncate, it would write terminating character, at least on Linux:
May 13 2022
Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.
May 12 2022
May 11 2022
May 4 2022
Apr 13 2022
Apr 11 2022
I was pointed by Daiki to the following patch in Fedora binutils, which allows listing the fdo packaging metadata, but it does not list any other unknown objects and unfortunately fails hard:
Apr 8 2022
I have one follow-up is that the readelf chokes on the integrity note for some reason:
$ readelf -n /usr/lib64/libgcrypt.so.20.4.1 Displaying notes found in: .note.fdo.integrity Owner Data size Description FDO 0x00000020 Unknown note type: (0x8e2afeca)
I assume this is just because the readelf does not know this type. I see this type was initially proposed by Daiki, but I did not find any other sources for this magic number so before filling bugs for readelf, do we have some doc why the 0xcafe2a8e is used?
Apr 5 2022
Mar 29 2022
Mar 21 2022
Adding
GPG_TTY=$(tty) export GPG_TTY
makes this working so thank you for the pointer.
Mar 18 2022
the -v does not show more useful info on the gpg side:
# gpg2 --quick-gen-key admin About to create a key for: "admin"
Mar 8 2022
You are combining two concepts here -- the KDF and the AEAD cipher itself (at least from the FIPS terminology). I would like to avoid mixing these two together in the new API. If you would like to implement the SSH/TLS KDF, I would suggest to use the kdf API you already have. Then we are here left only with a new geniv API to implement. In the T4873 I mentioned example how it is now used in libssh using libgcrypt, which implements the iv increment outside of the libgcrypt:
Mar 7 2022
The mails from these days still contain the following header:
List-Post: <mailto:gnupg-devel@lists.gnupg.org>
which is probably causing the mail client directing the mails to this address. Is there a way to change or or make it an alias so it is easier for people to use the mailing list without finding this issue?
Mar 3 2022
I think this is not urgent as we are able to FIPS certify libgcrypt without that, but the modern protocols and algorithm use this and if we want to use libgcrypt to implement these in FIPS compliant way, we certainly need something like that.
Feb 24 2022
Feb 2 2022
Jan 25 2022
For the record, there is a new report on the mailing list about this module on MacOS:
Jan 24 2022
Thanks. Looks good to me.
Jan 17 2022
Jan 11 2022
I went through the documentation related to FIPS and updated some wording to match reality. It will probably require still some more work.
This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.