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 kra...@redhat.com <kra...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86157): https://edk2.groups.io/g/devel/message/86157 Mute This Topic: https://groups.io/mt/87479913/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
