Just to clarify, I understand *why* we need crypto, I just don't understand why we're pulling such a huge library instead of picking something smaller or cutting down OpenSSL (or Libre/Boring, which seem a good bit smaller than the original OpenSSL).

While typing this I also found mbed TLS which seems to be part-maintained by ARM and explicitly handles all 64-bit division cases.

I think limiting all EFI code imports to smaller libraries that were designed with embedded in mind would both solve our issues and would be a better technical solution.

Thanks,
Pedro

On Fri, Jan 28, 2022 at 10:14 AM kraxel@redhat.com <kraxel@redhat.com> wrote:

Hi,

> I think that maybe "Why are we bringing in so much third-party code to
> firmware?" is a way better question than "is it feasible to implement all
> the required builtins?". Why can my firmware speak TLS, and why does it
> have a whole copy of *OpenSSL*, which is a huge library with a big attack
> surface and was never written to be run in a firmware/kernel/bare metal
> environment like UEFI.

crypto is needed for:
(1) network boot (tls for https)
(2) iscsi (tls too).
(3) secure boot.
(4) tpm support.
(5) secure firmware updates.

And possibly more.

> Note: If there's a big need for something like internal TLS I would
> recommend BearSSL as a very small TLS implementation that was actually
> written for embedded systems.

Well, that doesn't look like an actively maintained project. One commit
in 2021. Four commits in 2020. Features like TLS-1.3 support on the
TODO-List but apparently nobody working on it.

take care,
Gerd