[openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled

[David Woodhouse]

On Mon, 2015-08-10 at 16:11 +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> 
> >You seem to be suggesting that we build in some cryptographic
> >functionality that we admit we have no *idea* how we could sensibly use
> >it, and also build in various extended math library routines that are
> >currently unneeded but would need a whole bunch of pain for different
> >GCC/MSVC/LLVM toolchains and ABIs... just in case we one day work out how
> >we might use it.
> 
> All that for just one attribute? Of a certificate that you already have to
> deal with? I’m missing something, or you’re not correct.

Yes, really all that for just one attribute. The real pain point here
is the 64-bit division. That's why we disable SCT, instead of just
ignoring it like we do various other attributes which are irrelevant to
us and will never be seen on certificates we care about.

If you do division on a uint64_t in 32-bit mode, GCC will emit out-of
-line calls to functions such as __udivdi3(), which are provided by
libgcc. Even if you're building with -ffreestanding.

Those functions do not exist, because libgcc is not linked into the
final UEFI image (and is not even suitable to be so linked).

The situation is the same (with slightly different functions) for
building with MSVC. I haven't even looked at the clang/llvm build.

It would be quite painful to have to provide these functions in the
UEFI image. We'd basically end up having to lift copies of those
functions (or reimplement them, if necessary for licensing reasons) and
copy them into the UEFI package for OpenSSL. And then cope with the
fact that we need *different* functions, or different versions of them,
depending on which toolchain we build with. And depending on whether
we're building with the MS ABI as the default or not.

So yes. All that "whole bunch of pain", for just one attribute.

FWIW the Linux kernel had a similar issue, on the many platforms where
libgcc.a is *not* included into the kernel. There we avoid 64-bit
division and instead have a 'do_div()' macro which divides a 64-bit
integer by a 32-bit one and returns both the dividend and the
remainder.

OpenSSL just goes ahead and does 64-bit division.

The reason I've submitted patches to disable SCRYPT and SCT, which are
the two offending locations in OpenSSL, is because the Linux 'do_div()'
solution requires inline assembly, and we can't necessary assume that
we have inline assembly in OpenSSL. And because we actively do not care
about losing those pieces of functionality.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150812/9efa0cb5/attachment.bin>