| Age | Commit message (Collapse) | Author |
|---|
|
Things don't work across the board right now, anyhow. People have even
experienced hangs, and there's no way we can diagnose those hangs
without displaying the test log on the screen.
It's not ideal, and going forward we definitely need to satisfy both
requirements (easy debugging and pretty graphics), but if need to pick
one or the other, easy debugging wins every time.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
We've no need to turn a data structure on the stack into a pointer and
use get_user() on a kernel address, and in fact, doing so is likely to
return -EFAULT, because the argument isn't a valid user address.
This bug was introduced in commit c2268a9b23a9 ("fwts: Copied the
structure from userland locally in kernel space"), and causes a
uefirttime failure.
Cc: Pradeep Gaddam <pradeep.r.gaddam@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
A recent fix to change a securebootcert failure into an info message was
merged into upstream fwts. We're hitting this false positive on a number
of machines.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This patch was merged in V14.07.00 of fwts but we're currently on
V14.03.01.
We're seeing microcode test failures on a number of Haswell machines,
which shouldn't really be failures. This patch from upstream fixes that.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
1090 is the lastest release of the BIOS Implementation Test
Suite (BITS). These are the changes as per BITS relase notes:
*Update to ACPICA version 20140325
*Backport GRUB2 commit 4e42521d8c9232b6ee9eac7d8b4945a7479de781
to preserve 16-byte alignment of the stack on EFI calls
* python: Support the csv module
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Rather than hardcoding the package version, utilize the PV variable
to define the configure path. This will prevent build issues
when moving to a newer version.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
LuvOS is intended to be an automated testing tool. Thus, it does really
require much interaction from the user other than inserting the bootable
media, and removing it when tests are complete. Thus, we inform better
to the user what to do when the tests are complete.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
The tool cannot be built without this patch. We don't really need
the man pages in this project.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
sbsigntool is a useful utility for cryptographically signing binaries
for use in UEFI systems.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
For luvOS we need to install more than one boot loader, plus a variety
of files to do boot time tests.
Roll our own class which gives us much more control over the
installation process and creation of the grub config.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Provide a luv splash screen for grub's use, which informs the user that
we're currently running boot tests.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Doing so will garble any image displayed by the main boot loader.
We're directly patching the python code as shipped in the bits release
zip file. This means that we need to regenerate the .pyc files, which
are required for bits to execute properly.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Curiously, the checksums have become invalid for bits-1084.zip. Update
them.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
When we've finished running the bits tests we need to return control to
the luvOS bootloader, so that we can run further tests, like booting a
Linux kernel.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Without the header the bits runtime complains like so,
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/boot/python/init.py", line 69, in init
bitsconfig.init()
File "/boot/python/bitsconfig.py", line 42, in init
config.read("/boot/bits-cfg.txt")
File "/boot/python/lib/ConfigParser.py", line 305, in read
self._read(fp, filename)
File "/boot/python/lib/ConfigParser.py", line 512, in _read
raise MissingSectionHeaderError(fpname, lineno, line)
ConfigParser.MissingSectionHeaderError: File contains no section headers.
file: /boot/bits-cfg.txt, line: 3
'batch = test acpi smbios\n'
Include a [bits] header and make sure we actually install the config
file.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
bits comes with its own version of the grub bootloader, with custom
modules installed as part of the grub image, for example a python module
to interpret the python tests.
We must install this boot loader alongside our default one, along with
the necessary parsers and test runners to extract the results of the
bits tests from userland.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
In order to display images from the boot menu we're going to need to
load gfxmenu, gfxterm and other grub modules. Turn them on in our
luvOS-specific bbappend.
Also include the chainloader module which is how we're going to execute
the bits tests.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Make sure kernel-efi-warnings is included in the ramfs filesystem.
kerne-efi-warnings is a simple script that analyzes the kernel
messages to search for warnings that the kernel might issue if/when
it finds potential bugs in the UEFI firmware.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Add a recipe to install kernel-efi-warnings. As it inherits from
luv-test, it also takes care of installing the luv-parser.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
In order for the LuvOS test manager to take the rest results of
kernel-efi-warnings, we need a parser that presents the results in
a format that it can understand.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>sdfsdf
|
|
The Linux kernel provides lots of information about its errands
with the UEFI firmware at boot time. However, such information is
buried inside the dmesg buffer. Automated test resources, such as
LuvOS, need automated tools to find, parse and format such
information.
kernel-efi-warnings rely on the dmesg buffer to find specific
expressions. The absence or presence of such expressions are treated
as a test pass/fail.
For now, the scripts only looks for the warnings that the kernel
issues if it detects illegal accesses to the EFI_BOOT_SERVICES_*
memory regions.
The script is intended to grow as mroe kernel tests become available.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
It's very useful to know if the firmware makes illegal accesses to the
EFI boot services regions. Enable CONFIG_EFI_BOOT_SERVICES_WARN which
prints a warning if such an access occurs.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Using the default values.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
When we have structures that contain pointers, we cannot just do double
dereference on it as in struct->pointer->value. This will end up as a
Page Fault. To fix this problem, I changed efi_runtime kernel module to
first fetch the entire structure into a local copy on stack and use that
to reference the other data members of the struct.
Signed-off-by: Pradeep Gaddam <Pradeep.r.Gaddam@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This SVN revision has a fix for build failures under GCC 4.9 for x86_64
targets. This will ease eventual upstreaming of the OVMF recipe to Yocto
master, which uses GCC 4.9.
The bug is described on the EDK2 mailing list here:
http://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg07451.html
GCC 4.9 changed an alignment from 32 bytes to 64 bytes when building for a 64-
bit target, whereas OVMF was built with the expectation that the alignment
would be 32 bytes. This mismatch caused a build failure that looked like this:
GenFw: ERROR 3000: Invalid
Unsupported section alignment.
SVN revision 15699 of EDK2 includes a fix for this issue by the upstream EDK2
developers. When compiling with GCC 4.9 for a 64-bit target, the build OVMF
build configuration now anticipates a 64-byte alignment.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This fixes an issue where the OVMF recipe always built an x86_64 firmware
regardless of the target architecture or target machine. This issue manifested
itself when qemu-system-i386 was used on an OVMF firmware image-- QEMU would
exit immediately rather than proceeding with the boot process.
The x86_64 firmware was unaffected by this issue.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
While EDK2 has many components that support ARM, OVMF is not one of them. This
should be reflected in the BitBake recipe for OVMF.
This is accomplished by adding a COMPATIBLE_HOST annotation to ovmf_git.bb.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
In order to enable netbooting and transfer of required files using tftp,
efinet and tftp modules are required.
Signed-off-by: Pradeep Gaddam <Pradeep.r.gaddam@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Technically the bios used by qemu isn't a native package, so we
shouldn't depend on it. Instead require the regular version of ovmf.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The build.sh build script in OvmfPkg allows us to optionally specify a
toolchain identifer, which we're currently not doing. By not passing a
toolchain ID directly build.sh invokes the build machine's compiler to
figure it out.
The important point in all of this is that the version identifier is
used in the ovmf build path, which means that if build machine's
compiler is upgraded/downgraded we can end up with multiple ovmf build
directories.
Pass the target's gcc version to build.sh instead.
Reported-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
edk2 does not lend itself to cross-compiling in any form. Instead of
trying to play nice and override ${CC}, etc via the usual methods, just
write our toolchain variables directly in the necessary Makefiles.
The upside is that we get to drop a couple of patches we were carrying.
The downside is that this is a terrible hack and will likely break when
we move forward to newer edk2 versions.
Until such time that BaseTools supports proper configuration of a build
toolchain, this is the best we can do.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The dmesg buffer can provide valuable information to determine
the causes of a kernel crash. When the systems boots to
runlevel 3, the luv-crash-handler uses vmcore-dmesg to recover
the dmesg buffer from the vmcore dump and saves it to the LuvOS
test results partition.
This information can then be sent to the developers to investigate
further on the causes of the crash.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The waiting is done already by the luv-crash-handler. Thus, there
is not need to repeat the waiting here.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Change
commit 0c91196fcbb953393b3e2f5623b1edc5b40aa445
Author: Andrea Adami <andrea.adami@gmail.com>
Date: Mon Jan 9 23:46:13 2012 +0100
explicitly splits the packages for kexec and kdump. Thus, rather
than generically install kexec-tools. State explicitly which
tools need to be installed.
kexec is needed to reboot a Linux kernel from Linux. vmcore-dmesg
is needed to extract the dmesg buffer from the /proc/vmcore dump
file.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
All these patches have been merged into the most recent version
of kexec-tools. Thus, we do not need them anymore.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This recipe will help to run the bios tests suites, supported by
biosbits in auto mode, the recipe also contains a configuration file
which allows the tests to run in automated mode.
Signed-off-by: Rakesh Seethamsetty <rakeshsv@gmail.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This reverts commit fcdb6a8c43159704ba16fe1c56a045fa53053180.
The chipsec tests cause one of my test machines to lockup. It's highly
likely that other people will experience similar issues.
The fact that the tests cause lockup isn't the biggest problem, it's
that there's absolutely zero diagnostic information provided to the
user, so they've no data to report other than "my machine freezes".
Disable the tests for now until we can provide useful ways of diagnosing
lockups.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
LuvOS is used to validate UEFI firmware implementations. Such implemen-
tations may be at different levels of maturity. Thus, they could pose
stability threats to the Linx kernel. It could also be possibly that
the kernel itself may have an undiscovered bug.
The crash handler aims to handle such situations in a gracefully manner.
During a regular boot, at runlevel 5, the handler uses kexec to prepare
the system for an eventual crash so that the system can be rebooted to
a usable state. In such recovery boot, memory dumps can be made to perform
analyses on what caused the crash.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
In order to provide more useful information in case of a kernel crash,
compile the kernel with debug info. Even though the kernel proper will
increase it size significantly (~7-fold), the debug information will
be valuable for analysis.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Add the crashkernel parameter to indicate the kernel to reserve memory
for the kernel and initrd images that will be used in the event of a
crash.
Currently our vmlinux binary created from piggy.o is ~80MB and the
initrd image is ~30MB. This could be accomodated on 128MB. Space is
doubled to allow for future growth.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
In order to uniquely identify the partition at runtime, specify
a known volume-id.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Include the chipsec test suite in this image.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Instead of managing our own luv package just add the auto-generated
files to FILES_${PN} to avoid QA warnings.
In the future we could do our own luv package, but let's keep thing
simple for now.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Integrate chipsec into the test manager infrastructure and add a parser
to capture test results and write them to stdout in the luv-test-manager
compatible format.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
CHIPSEC is a platform security assessment framework for analyzing the
security of PC platforms. It includes a number of tests and also
provides forensic capabilities for firmware.
Of particular use are the UEFI secure boot variable tests and BIOS flash
write-protect tests.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Now that we've got a recipe for iasl add it as an explicit dependency
for ovmf. Previously the host system was required to have the iasl
package installed, which isn't very clean as our build should be
completely self-contained and not using the host's packages.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Import iasl recipe from the meta-virtualization layer.
This recipe is required for ovmf, which is currently relying on the
host's installed iasl package.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
efilinux is a minimal reference UEFI bootloader. It doesn't include
graphics or a complex configuration syntax, just the bear minimum
necessary to boot a Linux kernel.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Add functionality to save the test results to non-volatile media. The
non-volatile media is expected to be a disk identified by its UUID. The
disk is mounted using the UUID to avoid writing inadvertently writing to
any other disk present in the system.
Clearly, this implementation requires the presence of a disk with the
UUID specified by the script. Thus, it is required to utilize such UUID
when creating the filesystem.
Also, disks in some systems take a while to be ready for mount and may
not be ready when the LUV test manager runs. Thus, a delay of 5 seconds
is introduced in order to increase the likelihood of finding the
intended disk.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
Matt Fleming
Ricardo Neri
Pradeep Gaddam
Max Eliaser
Rakesh Seethamsetty