From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mx.groups.io with SMTP id smtpd.web11.2304.1675472919014406387 for ; Fri, 03 Feb 2023 17:08:39 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=EHxbgYXG; spf=pass (domain: gmail.com, ip: 209.85.216.54, mailfrom: pedro.falcato@gmail.com) Received: by mail-pj1-f54.google.com with SMTP id pj3so6690416pjb.1 for ; Fri, 03 Feb 2023 17:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0xUjieLXC59rc31R7/PJiDUsJP69+JmiMVkkb5CNKOk=; b=EHxbgYXGpgZIi+LIzRi4DJGMBFC26lD0QbPRP2NMc7McsmyMx1N8ns7cDGEqixTtcN UaU8mBc1rz7dusbMKGQVj7pPEmU4Ja/E40tWFPes2OmQ72QO5WyydcQf9UFPlNOdLm5M 8xg6RyxOeczpqpbnCxrMpmMTXswrVTIkNqziDaSh1a9H8bVH62QSRJ4LFCKGXJ8ODkxT vGnhUFe95SyKgBSGX/iGMSY59POSPdOhX/gnaIy4hDlFdPpsVI9IKkd1PLbVUtMc5+9g Qw842ZviarkVo05c4dFJ9K7QW7K/8cTJCz8bEl2JJmLdgsHWEMsDh3AqLyR3pfbzqo8q HLqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0xUjieLXC59rc31R7/PJiDUsJP69+JmiMVkkb5CNKOk=; b=1r1z/4cG9/Mqn9a81LpJFTP7ZxNn2F5qUMhTEvUZKV4ybzHUQUnbVQuGSQ82v7StSF y9ghvdDR/J3ENIqgck9R78hZqnqdqkByQ2oBNciwe/SlQKAMX3tf0elda5StC/HE7Em3 ZtoxuroCOZH9i5kDK4b5R7RNKU3DpXZQfCVG786crWH6JnNV8oNLiqKvRlp0o+5R7AuL MVuyDI0dbloSm/nQVhoGDyrukgqTY9g1dJ/iLDqZlC7cV1PkyrdmFvXvd0pPes0TLIbt IzGUWN+RMlWPzE7rzunJlIH1K9IR1IeGgWWUWUVpWZ6LYzcWxgDTPpDnhCoKESHbZf36 If4Q== X-Gm-Message-State: AO0yUKVIV1UBOe8GSWZCw0cgFIap65LgY/WoRBSvAGfpaIGdOft0VqJi c2ltyqJbgXfKjc+2ZJEHuPZrmdaPcYSPACdHAOM= X-Google-Smtp-Source: AK7set9mpob4VMRKWo9GeISoI69GqrVV3xQUKnhtjS0oLjxovQMaxghxfxWiFXOmpm3XriNLd7UGCcJvfukkLNSsh3o= X-Received: by 2002:a17:902:ba87:b0:198:e13d:a05d with SMTP id k7-20020a170902ba8700b00198e13da05dmr815777pls.12.1675472918300; Fri, 03 Feb 2023 17:08:38 -0800 (PST) MIME-Version: 1.0 References: <20230203132806.2275708-1-kraxel@redhat.com> <20230203153654.pyutijc54a66pe6e@sirius.home.kraxel.org> <20230203162844.gailv3rz3ia3jdpe@sirius.home.kraxel.org> In-Reply-To: From: "Pedro Falcato" Date: Sat, 4 Feb 2023 01:08:26 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH 00/11] OvmfPkg: add Crypto Driver support To: Ard Biesheuvel Cc: devel@edk2.groups.io, kraxel@redhat.com, Min Xu , Michael Roth , Jiewen Yao , Jian J Wang , Jordan Justen , Pawel Polawski , Oliver Steffen , Tom Lendacky , Xiaoyu Lu , Erdem Aktas , Guomin Jiang , James Bottomley Content-Type: text/plain; charset="UTF-8" On Fri, Feb 3, 2023 at 11:25 PM Ard Biesheuvel wrote: > > On Fri, 3 Feb 2023 at 20:45, Pedro Falcato wrote: > > > > On Fri, Feb 3, 2023 at 4:28 PM Gerd Hoffmann wrote: > > > > > > Hi, > > > > > > > > Unfortunately it is not a clear size win everywhere. > > > > > > > > > > PEI jumps up in size even though I'm using the min_pei config for > > > > > CryptoPei, seems it *still* has way too much bits compiled in > > > > > (didn't look into tweaking the config yet, hints are welcome). > > > > > > > > > > - 17530 TcgPei > > > > > + 17146 TcgPei > > > > > + 34362 Tcg2Pei > > > > > - 51066 Tcg2Pei > > > > > + 333950 CryptoPei > > > > > > > > Why would we use this for PEI if the size increases? > > > > > > When using the crypto driver I'd prefer to do it everywhere and > > > don't mix+match things. > > > > > > Background is that I'm hoping the crypto driver abstraction can also > > > help to have alternative drivers using other crypto libraries without > > > creating a huge mess in CryptoPkg. Specifically add openssl-3 as an > > > option. openssl-11 goes EOL later this year (Nov IIRC). Switch to > > > openssl-3 unconditionally has been vetoed by Intel due to the size > > > increase v3 brings. So I'm looking for options here ... > > > > Seriously? > > > > Intel is blocking UP TO DATE NOT VULNERABLE OPENSSL because it doesn't > > fit their flash due to all the cra- value add? > > This is insane by many standards. Your freaking *CRYPTO LIBRARY* goes > > EOL and people are still concerned about size. > > > > Stellar job, Intel. Hopefully everyone gets their horrific custom > > network stack heartbled to death. Or someone finds yet another Secure > > Boot exploit. > > > > This is uncalled for. Please keep it civil and on topic. You (nor I) > have any context about this, and if you want to start a shouting match > on a public mailing list, I suggest you first get informed about what > the actual reasoning is behind such a decision (which, according to > the above, is the decision to keep OpenSSL 1.1 and 3 available side by > side). And please start another thread for this - I have no interest > in being part of this type of discussion. Sorry everyone, that was a ...passionate speech. I recognize I'm on the wrong here. Vendors and CryptoPkg people, please consider upgrading to OpenSSL 3. 1.1 is going EOL and security for crypto related activities (especially for a project like OpenSSL with such a CVE-full life) should be paramount. Surely there are other ways you can cut on flash space. As for the patches themselves, big +1 if they help decouple TLS libraries. I've been thinking about trying another TLS lib like mbedtls ever since the problems with OpenSSL and compiler intrinsics came along, some time ago. Probably smaller too. -- Pedro