In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU
commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the
host-side TLS cipher suite configuration to OVMF. The purpose is to
control the permitted ciphers in the guest's UEFI HTTPS boot. This
complements the forwarding of the host-side crypto policy from the host to
the guest -- the other facet was the set of CA certificates (for which
p11-kit patches had been upstreamed, on the host side).
Mention the new command line options in "OvmfPkg/README".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200922091827.12617-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The following network build flags changed due to the inclusion of
NetworkPkg/Network.fdf.inc.
HTTP_BOOT_ENABLE -> NETWORK_HTTP_BOOT_ENABLE
TLS_ENABLE -> NETWORK_TLS_ENABLE
This commit also adds NETWORK_ALLOW_HTTP_CONNECTIONS to reflect the
change in OvmfPkg/OvmfPkg*.dsc.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1884
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190610065509.19573-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
We're about to remove BaseTools support for GCC44..GCC47. Reject those gcc
versions cleanly in "OvmfPkg/build.sh". In "OvmfPkg/README", upgrade any
mentions of the same gcc versions to GCC48.
No GCC44..GCC47 references remain under OvmfPkg after this patch.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add the new section for HTTPS Boot.
Changes in v2:
- Fixed the typos
- Added the command for p11-kit based on Laszlo's suggestion
- Also added the efisiglist command
- Elaborated how to create the customized cipher suite list
- Mentioned the changes in QEMU in the future based on Laszlo's
suggestion
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: trivial typo fixes; update-crypto-policies URL fix]
Jiaxin reports that the OvmfPkg/README instructions for downloading the
Intel PROEFI drivers, and the filenames in OvmfPkg/OvmfPkg*.fdf for
incorporating the same in the OVMF binaries, are no longer up to date; the
download link has stopped working.
Additionally, the IA32 driver binary is no more distributed by Intel.
Update OvmfPkg/README with new download instructions, and adapt the OVMF
FDF files.
With this driver in use for QEMU's e1000 NIC, the DH shell command prints,
as Controller Name, "Intel(R) PRO/1000 MT Network Connection". I
successfully tested DHCP and ping from the UEFI shell.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reported-by: Jiaxin Wu <jiaxin.wu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
The "UNIXGCC Debug" section happens to name PlatformBdsLib and
IntelFrameworkModulePkg's BdsDxe as examples. OVMF will soon stop offering
those even as a fallback option.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At the moment, the "UefiCpuPkg/Universal/Acpi/S3Resume2Pei" module doesn't
support S3 resume if the platform has SMM enabled and the PEI phase is
built for X64. We document this in the README, but it is not conspicuous
enough.
Replace the "fine print" in the README with a runtime check in
PlatformPei.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19070 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg forked SecureBootConfigDxe from SecurityPkg in SVN r13635 (git
commit 8c71ec8f). Since then, the original (in
"SecurityPkg/VariableAuthenticated/SecureBootConfigDxe") has diverged
significantly.
The initial diff between the original and the fork, when the fork was made
(ie. at SVN r13635), reads as follows:
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr 2014-08-09 02:40:35.824851626 +0200
> @@ -51,7 +51,7 @@
> questionid = KEY_SECURE_BOOT_ENABLE,
> prompt = STRING_TOKEN(STR_SECURE_BOOT_PROMPT),
> help = STRING_TOKEN(STR_SECURE_BOOT_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
>
> @@ -158,7 +158,7 @@
> questionid = KEY_SECURE_BOOT_DELETE_PK,
> prompt = STRING_TOKEN(STR_DELETE_PK),
> help = STRING_TOKEN(STR_DELETE_PK_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
> endform;
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.577067027 +0200
> @@ -1,5 +1,8 @@
> ## @file
> -# Component name for SecureBoot configuration module.
> +# Component name for SecureBoot configuration module for OVMF.
> +#
> +# Need custom SecureBootConfigDxe for OVMF that does not force
> +# resets after PK changes since OVMF doesn't have persistent variables
> #
> # Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.<BR>
> # This program and the accompanying materials
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.599067153 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.578067033 +0200
> @@ -2559,7 +2559,7 @@
> NULL
> );
> } else {
> - *ActionRequest = EFI_BROWSER_ACTION_REQUEST_RESET;
> + *ActionRequest = EFI_BROWSER_ACTION_REQUEST_SUBMIT;
> }
> break;
The commit message is not overly verbose:
OvmfPkg: Add custom SecureBootConfigDxe that doesn't reset
We don't force a platform reset for OVMF when PK is changed in custom
mode setup.
But the INF file hunk is telling:
Need custom SecureBootConfigDxe for OVMF that does not force resets
after PK changes since OVMF doesn't have persistent variables
We do have persistent variables now. Let's disable the (now obsolete)
OvmfPkg fork, and revert to the (well maintained) SecurityPkg-provided
config driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gary Lin <glin@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16191 6f19259b-4bc3-4df7-8a09-765794883524
The Windows 2008 R2 SP1 (and Windows 7) UEFI guest's default video driver
dereferences the real mode Int10h vector, loads the pointed-to handler
code, and executes what it thinks to be VGA BIOS services in an internal
real-mode emulator. Consequently, video mode switching doesn't work in
Windows 2008 R2 SP1 when it runs on the pure UEFI build of OVMF, making
the guest uninstallable.
This patch adds a VGABIOS "shim" to QemuVideoDxe. For the first stdvga or
QXL card bound, an extremely stripped down VGABIOS imitation is installed
in the C segment. It provides a real implementation for the few services
that are in fact necessary for the win2k8r2sp1 UEFI guest, plus some fakes
that the guest invokes but whose effect is not important.
The C segment is not present in the UEFI memory map prepared by OVMF. We
never add memory space that would cover it (either in PEI, in the form of
memory resource descriptor HOBs, or in DXE, via gDS->AddMemorySpace()).
This way the handler body is invisible to all non-buggy UEFI guests, and
the rest of edk2.
The Int10h real-mode IVT entry is covered with a Boot Services Code page,
making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes
different from the Windows 2008 family can reclaim the page. The Windows
2008 family accesses the page at zero regardless of the allocation type.)
The patch is the result of collaboration:
Initial proof of concept IVT entry installation and handler skeleton (in
NASM) by Jordan Justen.
Service tracing and implementation, data collection/analysis, and C coding
by yours truly.
Last minute changes by Gerd Hoffmann:
- Use OEM mode number (0xf1) instead of standard 800x600 mode (0x143). The
resolution of the OEM mode (0xf1) is not standardized; the guest can't
expect anything from it in advance.
- Use 1024x768 rather than 800x600 for more convenience in the Windows
2008 R2 SP1 guest during OS installation, and after normal boot until
the QXL XDDM guest driver is installed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15540 6f19259b-4bc3-4df7-8a09-765794883524
Remove 'Alpha' status tag. Let's just refer to the OVMF
releases by their revision control version.
Remove 'stabilize UEFI Linux' to-do item.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15039 6f19259b-4bc3-4df7-8a09-765794883524
Also summarize the resultant NIC driver options in the README file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14421 6f19259b-4bc3-4df7-8a09-765794883524
DHCP, PXE, and StdLib socket apps are enabled in OVMF by the sum of:
(a) a UEFI NIC driver,
(b) the generic network stack.
The only choice for (a) used to be the proprietary Intel E1000 driver,
which is cumbersome to obtain and enable.
The iPXE UEFI NIC drivers packaged with qemu-1.5 cover (a) for each NIC
type supported by qemu, and are easy to obtain & configure, even for
earlier qemu versions. Therefore enable (b) per default as well.
This doesn't take up much space; the binaries (b) adds to the firmware
don't seem to need -D FD_SIZE_2MB.
Intel's e1000 driver remains an option, requested by the -D E1000_ENABLE
build flag.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14366 6f19259b-4bc3-4df7-8a09-765794883524
The README is rather extended than trimmed, so that users grepping for the
file name have a pointer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14243 6f19259b-4bc3-4df7-8a09-765794883524
UNIXGCC builds larger images than GCC44, and can have issues
fitting into the FD image. Therefore, when using UNIXGCC,
debug will be disabled by default.
The README file is updated with instructions for selectively
enabling debug for UNIXGCC.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13569 6f19259b-4bc3-4df7-8a09-765794883524
This enables qemu to use OVMF with a single -bios option. Based on
<http://lists.xen.org/archives/html/xen-devel/2012-03/msg01992.html>.
v1->v2:
- move xen-devel link from code to commit message
- cover all three FDF files
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: remove vgabios-cirrus.bin from build.sh/README]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13520 6f19259b-4bc3-4df7-8a09-765794883524
Add a single build.sh to replace build32.sh & build64.sh.
The script watches for various parameters:
-a: allows selecting IA32 or X64 (default)
-b: allows selecting RELEASE or DEBUG (default)
-t: allows selecting the toolchain
When running qemu, the script doesn't always add -hda now.
If the user provides a disk parameter (for example, -fda, -hda
or -cdrom), then -hda will not be added to the qemu command line.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11238 6f19259b-4bc3-4df7-8a09-765794883524
These scripts are similar to those found under DuetPkg & UnixPkg.
The scripts simplify building and running OVMF under systems that
have the bash shell available.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11215 6f19259b-4bc3-4df7-8a09-765794883524
1) Update README describing the QEMU version required for e1000, where to download the UEFI drivers for e1000, and how to enable network drivers in the platform firmware
2) Update DSC/FDF files NETWORK_ENABLE switch to enable e1000 and network driver support
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10697 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
Gary Lin
Shenglei Zhang
Jordan Justen
jljusten
niruiyu
mdkinney