While fixing https://github.com/tianocore/edk2/pull/6092 (the
fact that some OvmfPkg and ArmVirtPkg platforms included residual
NetworkPkg components even when compiled with -D NETWORK_ENABLE=0),
it was noted that OvmfPkg/Include/*/Shell*.inc files which apply
the required fix logic are available and already used in some
OvmfPkg platforms.
A previous commit applied these files consistently within OvmfPkg.
This commit applies these files within ArmVirtPkg.
This has the side effect that some platforms now include one or
more of HttpDynamicCommand, VariablePolicyDynamicCommand and
LinuxInitrdDynamicShellCommand when they previously did not.
It is believed that in all cases these changes are neutral (i.e.
not necessarily needed, but not harmful, and with the benefit of
now using shared code) or positive (i.e. they fix unintentional
drift between platforms, and provide additional shell commands
which may be useful in some cases).
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
While fixing https://github.com/tianocore/edk2/pull/6092 (the
fact that some OvmfPkg and ArmVirtPkg platforms included residual
NetworkPkg components even when compiled with -D NETWORK_ENABLE=0),
it was noted that OvmfPkg/Include/*/Shell*.inc files which apply
the required fix logic are available and already used in some
OvmfPkg platforms.
This commit applies these files consistently within OvmfPkg.
This has the side effect that some platforms now include one or
more of HttpDynamicCommand, VariablePolicyDynamicCommand and
LinuxInitrdDynamicShellCommand when they previously did not.
It is believed that in all cases these changes are neutral (i.e.
not necessarily needed, but not harmful, and with the benefit of
now using shared code) or positive (i.e. they fix unintentional
drift between platforms, and provide additional shell commands
which may be useful in some cases).
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Place the EFI shell as EFI/BOOT/BOOT{ARCH}.EFI on the virtual drive.
This allows the "Run to shell" CI test case to work even in case the
shell is not included in the firmware image.
This is needed because a follow up patch will exclude the shell from
secure boot enabled firmware images.
The same update was previously applied to OvmfPkg by
6862b9d538d96363635677198899e1669e591259.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
This issue showed up when addressing
https://bugzilla.tianocore.org/show_bug.cgi?id=4829
in https://github.com/tianocore/edk2/pull/6087 .
Various OvmfPkg and ArmVirtPkg platforms include some residual NetworkPkg
components when compiled with -D NETWORK_ENABLE=0, even though they use
NetworkPkg includes intended to allow all NetworkPkg components to be
disabled on this flag.
For the OvmfPkg Intel platforms only, commit
d933ec115bdf9be1d8dfe6a818414a14973cc0d3 started
the change of not including these residual NetworkPkg
components, and commit
7f17a155640a2a9e1f7b0f3522628ee2c6f62624 completed it.
This commit rolls these changes out to the ArmVirtPkg platforms where
they make sense in the same way.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
This issue showed up when addressing
https://bugzilla.tianocore.org/show_bug.cgi?id=4829
in https://github.com/tianocore/edk2/pull/6087 .
Various OvmfPkg and ArmVirtPkg platforms include some residual NetworkPkg
components when compiled with -D NETWORK_ENABLE=0, even though they use
NetworkPkg includes intended to allow all NetworkPkg components to be
disabled on this flag.
For the OvmfPkg Intel platforms only, commit
d933ec115bdf9be1d8dfe6a818414a14973cc0d3 started
the change of not including these residual NetworkPkg
components, and commit
7f17a155640a2a9e1f7b0f3522628ee2c6f62624 completed it.
This commit rolls these changes out to the remaining OvmfPkg platforms
where they make sense in the same way.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Note: this must be combined with flag /wd4324 added to MSFT:*_CC_FLAGS
to avoid spurious warnings when the macro is working as intended.
Update comment since alignment in all architectures can be used to align
structure member or variable definition.
Under normal operation, some 30 or so of these lines logged as DEBUG_INFO
on first transmit.
This is not relevant information for users of the driver, so convert these
messages to VERBOSE.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Add OvmfRng include snippets with the random number generator
configuration for OVMF. Include RngDxe, build with BaseRngLib,
so the rdrand instruction is used (if available).
Also move VirtioRng to the include snippets.
Use the new include snippets for OVMF builds.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Check whenever RngLib actually returns random numbers, only return
a non-zero number of Algorithms if that is the case.
This has the effect that RndDxe loads and installs EFI_RNG_PROTOCOL
only in case it can actually deliver random numbers.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
RDRAND has notoriously been broken many times over its lifespan.
Add a smoketest to RDRAND, in order to better sniff out potential
security concerns.
Also add a proper CPUID test in order to support older CPUs which may
not have it; it was previously being tested but then promptly ignored.
Testing algorithm inspired by linux's arch/x86/kernel/cpu/rdrand.c
:x86_init_rdrand() per commit 049f9ae9..
Many thanks to Jason Donenfeld for relicensing his linux RDRAND detection
code to MIT and the public domain.
>On Tue, Nov 22, 2022 at 2:21 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
<..>
> I (re)wrote that function in Linux. I hereby relicense it as MIT, and
> also place it into public domain. Do with it what you will now.
>
> Jason
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4163
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Add dsc + fdf include files to add the MorLock drivers to the build.
Add the include files to OVMF build configurations.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit 6862b9d538d96363635677198899e1669e591259 makes
more explicit the previous logic of the code anyway, which is that
it is (and was) only a fatal error if all secure algorithms fail.
However the comment updated by this commit seems somewhat
incompatible with that change, and even with the previous code
(which operated as now, just logging different error messages).
This updates the comment to be more compatible with how the
code operates.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
There is a list of allowed rng algorithms, if /one/ of them is not
supported this is not a problem, only /all/ of them failing is an
error condition.
Downgrade the message for a single unsupported algorithm from ERROR to
VERBOSE. Add an error message in case we finish the loop without
finding a supported algorithm.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4829
7f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
This problem also applies in the ArmVirtPkg
platforms which are modified here, but is currently
masked by another issue, namely that these platforms
incorrectly still include some network packages when
most are disabled. (A fix for this was previously applied,
for OvmfPkg Intel platforms only, by
d933ec1 followed by
7f17a15 .)
This commit was created at the same time as the
commits resolving this issue in NetworkPkg and
OvmfPkg. It makes conditional the Pcd references
in ArmVirtPkg platforms which will become references to
undefined Pcds as and when the other issue mentioned
above is fixed.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4829
7f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
The problem applies in Intel OvmfPkg platforms.
Additionally, it applies in various other OvmfPkg
platforms, but is masked buy another issue; namely
that these platforms incorrectly still include some
network packages when most are disabled.
(A fix for that issue has previously been
made, in OvmfPkg Intel platforms only, by
d933ec1 followed by
7f17a15 .)
This commit conditionally removes the undefined Pcd references
in all OvmfPkg platforms which are now affected by this
issue, and in all those which would be affected as and
when the other issue mentioned above is fixed.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4829
7f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
This commit conditionally removes the undefined Pcd reference in
NetworkPkg which is part of this issue.
Similar changes are needed in separate commits for
OvmfPkg (and for ArmVirtPkg, since the issue also
exists there, although masked by another issue).
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
This is already worked around by the alternative version
of MDEPKG_NDEBUG DEBUG() for __clang__ which is provided
in MdePkg DebugLib.h, therefore the reason why this flag
was added in EDK-II no longer applies.
