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
>
>

-- 
Pedro Falcato