update openssl to 3.2.x

[kraxel]

• CrtLibSupport: add sleep()
• CrtLibSupport: fix gettimeofday()
• CrtLibSupport: factor out EFI_TIME -> time_t calculation to new function
• CrtLibSupport: add mktime()
• CrtLibSupport: add timezone
• openssl: update submodule to 3.2.2
• openssl: update generated files
• CryptoPkg: CI: update OpensslGen file list
• openssl: add Library/OpensslLib/openssl to includes, drop e_os.h hack
• openssl: adapt stubs to openssl 3.2.x
• openssl: add more stubs for openssl 3.2.x

Description

• add a bunch of time-related tweaks to CrtLibSupport
• update openssl submodule to openssl 3.2.2
• apply a number of build fixes (mostly in stubs).

The second part of the series (all 'openssl:' prefixed patches) is not
bisectable, all patches are needed to make edk2 build again. The only
way to fix that would be to squash them all together. That would make
review rather hard though, especially due to the large "update generated
files" patch.

How This Was Tested

• Regression testing with OVMF (verify secure boot and https network boot).
• Run CryptoPkgHostUnitTest

Integration Instructions

N/A

[kraxel]

/cc @jyao1,@Wenxing-hou,@liyi77

[liyi77]

Is there any special reason to upgrade to 3.2? If you don't need the new features in 3.2, 3.0 is probably a better choice.
the 3.2 series supported until 23rd November 2025, the 3.1 series supported until 14th March 2025, and the 3.0 series which is a Long Term Support (LTS) version and is supported until 7th September 2026.

[kraxel]

Is there any special reason to upgrade to 3.2?

Mostly that others (Fedora distro for example) moved from 3.0 to 3.2 too.

[liyi77]

Then I prefer to stay at LTS version due to no new features needed by EDK2.
Hi @jyao1, do you have comments on this?

[jyao1]

Usually, I am OK to upgrade, as long as there is no much size difference.
@kraxel , do you have any data for the size difference?

Also, as @liyi77 mentioned,
is there any concern: the 3.2 series supported until 23rd November 2025,
the 3.1 series supported until 14th March 2025,
and the 3.0 series which is a Long Term Support (LTS) version and is supported until 7th September 2026.

@kraxel , do you want to go back to 3.0 after November 2025?

[kraxel]

Usually, I am OK to upgrade, as long as there is no much size difference. @kraxel , do you have any data for the size difference?

ovmf pei firmware volume does not change in size.
ovmf dxe firmware volume is slightly larger (secure boot drivers and tlsdxe):

-          volume=guid:Ffs offset=0x0 size=0xe80000 hlen=0x48 xoff=0x60 rev=2 blocks=232*65536 used=50.1% name=guid:OvmfDxeFv
+          volume=guid:Ffs offset=0x0 size=0xe80000 hlen=0x48 xoff=0x60 rev=2 blocks=232*65536 used=51.5% name=guid:OvmfDxeFv

Also, as @liyi77 mentioned, is there any concern: the 3.2 series supported until 23rd November 2025, the 3.1 series supported until 14th March 2025, and the 3.0 series which is a Long Term Support (LTS) version and is supported until 7th September 2026.

@kraxel , do you want to go back to 3.0 after November 2025?

openssl started to do two releases per year, in april and november. Since I've started working on this 3.3 has been released, which will be supported until April 2026. Moving to 3.3 seems to work fine (builds on linux without additional changes, did not try CI yet).

3.4 should follow later this year, will supported until november 2026 (maybe even longer should it become an LTS release), which is beyond the 3.0 LTS EOL date. So there clearly is no need to go back to 3.0

[kraxel]

aarch64 switching to asm acceleration breaks the build with openssl 3.2 (also 3.3 and 3.4) due to an openssl bug.
openssl/openssl#25419

[kraxel]

Downgraded this to draft for now, waiting for the openssl fix to land upstream.

Moved the version-independent changes to a new PR (#6185),
this for the most part carries CrtLibSupport updates needed for 3.2 + 3.3 + 3.4 versions.

[jyao1]

It seems the size delta is acceptable. Thanks @kraxel.

I feel we should always use the LTS branch.
In this case, can we just bump to 3.4 once it comes out later this year?

[kraxel]

I feel we should always use the LTS branch. In this case, can we just bump to 3.4 once it comes out later this year?

Yes, we can also jump to 3.4. It is not clear whenever it will become an LTS release, but even in case that does not happen the EOL date will be after 3.0-LTS goes EOL.

[github-actions]

This PR has been automatically marked as stale because it has not had activity in 60 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[mergify]

PR can not be merged due to conflict. Please rebase and resubmit

[kraxel]

closing, working on 3.4.x update instead.