[edk2] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

On 02/24/16 13:05, David Woodhouse wrote:
> On Tue, 2016-02-23 at 21:57 +0100, Laszlo Ersek wrote:

>> First of all, I built it for:

>> - OvmfPkg/OvmfIa32.dsc

>> - OvmfPkg/OvmfIa32X64.dsc

>> - OvmfPkg/OvmfX64.dsc

>> - ArmVirtPkg/ArmVirtQemu.dsc (AARCH64 architecture)

>>

>> The builds complete for the first three DSC files, but it fails for the last one:

>>

>>> .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC48/AARCH64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(poly1305.obj): In function `poly1305_blocks':

>>> .../CryptoPkg/Library/OpensslLib/openssl/crypto/poly1305/poly1305.c:194: undefined reference to `__multi3'

>>> .../CryptoPkg/Library/OpensslLib/openssl/crypto/poly1305/poly1305.c:195: undefined reference to `__multi3'

>>> .../CryptoPkg/Library/OpensslLib/openssl/crypto/poly1305/poly1305.c:196: undefined reference to `__multi3'

>>> .../CryptoPkg/Library/OpensslLib/openssl/crypto/poly1305/poly1305.c:197: undefined reference to `__multi3'

> 

> That's easily fixed by adding no-poly1305 to my process_files.sh

> script. I've pushed a new version to my edk2.git tree with that change.

Yes, with your master branch @ 55eb3465c077, the ArmVirtQemu build
completes as well. Thanks.

(By the way, do you think that your series should revert, or at least
customize, the following commit:

commit ffbb1b25402c38d25cbbfb059139e76900bdc843
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Tue Jun 16 15:09:19 2015 +0000

    CryptoPkg: add .gitignore for OpenSSL source files
)

>> Anyway, for runtime testing, I used the OvmfIa32X64 build:

>>

>>> (1a) Enroll keys, and confirm SB being active in the Fedora guest,

>>>       using my current build.

>>> (1b) Rebuild the firmware binary with your patches & instructions. Do

>>>       not touch the VM's varstore.

>>> (1c) Confirm SB is still active in the Fedora guest.

>>

>> This step failed, with the OVMF debug output ending with:

>>

>>> Booting Fedora

>>> FSOpen: Open '\EFI\fedora\shim.efi' Success

>>>  

>>> ASSERT_EFI_ERROR (Status = Invalid Parameter)

>>> ASSERT .../MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c(819): !EFI_ERROR (Status)

>>

>> I didn't continue testing after this point.

> 

> OK, thanks very much for testing this.

> 

> It sounds like there's a new issue in OpenSSL HEAD that needs fixing,

> and I'm going to need to reproduce that myself to see what's going on.

> 

> Would you mind talking me through the setup above, please? To enroll

> keys, I assume I need to start with a version of qemu that can support

> running OVMF from a writeable flash chip, so it can store NV vars? 

> 

> Also, if you could test just the antepenultimate commit a35e4359d in

> what I've just pushed — which is all the build system improvements but

> still using OpenSSL 1.0.2f — that would also be very much appreciated.

Interestingly, the failure reproduces even when I build OVMF at your
commit a35e4359d; with identical symptoms.

Please find the repro steps below. (Sorry that it took so long to write
them up, but generally I use libvirt, and I had to create these
instructions on the spot, and I also tested them.)

(01) Set up the edk2 tree for building with OpenSSL, using the current
     upstream (master @ b38ec3cd2fcc11435d7fe4d90298c68368a5747b)
     instructions. That is, not your series.

(02) On a branch forked off the above state, please apply the attached
     patch, with

     git am --keep-cr

     (This patch is downstream only, but it is not "secret", it is
     publicly available in <https://www.kraxel.org/repos/> for example.)

(03) On the same branch, please edit the "OvmfPkg/OvmfPkgX64.dsc" file:
     locate "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", and
     replace its value with 0x8040004F.

     This will enable EFI_D_VERBOSE debug messages in the OVMF debug
     log.

     It's simplest to commit this change too, as a separate patch.

(04) Build OVMF as follows (assuming you have gcc-4.8):

     source edksetup.sh

     make -C "$EDK_TOOLS_PATH"

     build \
       -a X64 \
       -p OvmfPkg/OvmfPkgX64.dsc \
       -b DEBUG \
       -t GCC48 \
       -n $(getconf _NPROCESSORS_ONLN) \
       --report-file=/tmp/build.ovmf.report \
       --log=/tmp/build.ovmf.log \
       -D SECURE_BOOT_ENABLE \
       -D HTTP_BOOT_ENABLE

(05) Once the build completes, create a directory for testing, and stash
     the build output files there. We'll mark the OVMF binary as
     "upstream", in the file name.

     TESTDIR=$HOME/ovmf-test

     mkdir -p -v -- "$TESTDIR"

     cp -a -v -- \
       Build/OvmfX64/DEBUG_GCC*/FV/OVMF_CODE.fd \
       "$TESTDIR"/OVMF_CODE.upstream.fd

     cp -a -v -- \
       Build/OvmfX64/DEBUG_GCC*/FV/OVMF_VARS.fd \
       Build/OvmfX64/DEBUG_GCC*/X64/EnrollDefaultKeys.efi \
       "$TESTDIR"

(06) In the test directory, download the Fedora ISO that I used for
     testing. Also create an empty disk image for the virtual machine,
     and instantiate an actual varstore file for the virtual machine,
     from the varstore template:

     cd -- "$TESTDIR"

     wget -- https://download.fedoraproject.org/pub/fedora/linux/releases/22/Workstation/x86_64/iso/Fedora-Live-Workstation-x86_64-22-3.iso

     qemu-img create \
       -f qcow2 \
       -o compat=1.1 \
       -o preallocation=metadata \
       -o lazy_refcounts=on \
       fedora22.qcow2 \
       10G

     cp -a -v -- OVMF_VARS.fd fedora22.vars

(07) Create a raw disk image with a FAT filesystem, with the
     EnrollDefaultKeys.efi binary on it:

     rm -f -- EnrollDefaultKeys.raw

     mkdosfs -C EnrollDefaultKeys.raw -- 3072

     mcopy -i EnrollDefaultKeys.raw -- EnrollDefaultKeys.efi ::

(08) Start the virtual machine for the first time. (All future
     invocations of QEMU will use the exact same command line, except
     you will have to change the value of the OVMF_BINARY variable.)

     During this very first boot, please interrupt the boot process, by
     pressing ESC when the TianoCore splash screen appears (or at the
     progress bar after it). You will have five seconds for this. In
     later invocations, you can speed up the wait by pressing Enter at
     the progress bar.

     The commands are:

     OVMF_BINARY=OVMF_CODE.upstream.fd

     qemu-system-x86_64 \
       -machine accel=kvm \
       -smp cpus=2 \
       -m 2048 \
       \
       -monitor stdio \
       \
       -boot menu=on,splash-time=5000 \
       \
       -debugcon file:ovmf.debug.log \
       -global isa-debugcon.iobase=0x402 \
       \
       -device qxl-vga \
       \
       -net none \
       \
       -usbdevice tablet \
       \
       -drive if=pflash,format=raw,unit=0,readonly,file=$OVMF_BINARY \
       -drive if=pflash,format=raw,unit=1,file=fedora22.vars \
       \
       -device virtio-scsi-pci,id=scsi0 \
       \
       -drive id=cdrom,if=none,readonly,format=raw,file=Fedora-Live-Workstation-x86_64-22-3.iso \
       -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=1 \
       \
       -drive id=main_disk,if=none,format=qcow2,cache=writethrough,file=fedora22.qcow2 \
       -device virtio-blk-pci,drive=main_disk,bootindex=0 \
       \
       -drive id=enroller_disk,if=none,readonly,format=raw,file=EnrollDefaultKeys.raw \
       -device virtio-blk-pci,drive=enroller_disk

(09) You should be standing in the UEFI setup utility now. Please
     navigate to

     Boot Manager | EFI Internal Shell

     Once the shell is running, please issue the following commands at
     the prompt (verify that the first command prints "info: success"):

     EnrollDefaultKeys
     reset -s

(10) Start the VM again with the command in step (08). This time you
     should let it boot uninterrupted (or, again, just press Enter at
     the progress bar, to skip the wait). Fedora Live should boot.

     On the Welcome screen, click Try Fedora.

(11) Please verify that Secure Boot is active: open a terminal, and
     enter

     dmesg | grep -i secure

     After this, install Fedora to the disk (Activities | Install to
     Hard Drive). Verify that the installed guest reboots correctly,
     then shut down the guest.

(12) Return to your edk2 directory. Run

     git clean -fdx

     Then *rebase* the branch you created in steps (02) and (03) to your
     own SSL branch. Set up the tree as necessary (according to your new
     instructions) for building OpenSSL.

     Rebuild the tree as written in step (04).

(13) Save the new OVMF binary under a different name:

     cp -a -v -- \
       Build/OvmfX64/DEBUG_GCC*/FV/OVMF_CODE.fd \
       "$TESTDIR"/OVMF_CODE.dwmw2.fd

(14) Boot your guest with the new firmware binary:

     cd -- "$TESTDIR"
     OVMF_BINARY=OVMF_CODE.dwmw2.fd

     Then repeat the rest of step (08).

(15) The boot process will hang at some point, and the assertion failure
     can be seen in the file "ovmf.debug.log".

     The expected result would be a successful boot, and

     dmesg | grep -i secure

     in the guest should again confirm secure boot.

(16) For debugging purposes, you can use DEBUG() calls; they will show
     up in "ovmf.debug.log".

Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

Commit Message

Comments

Patch