Uncategorized

LUV gets telemetrics

Megha Dey of Intel just submitted a 4-part patch to LUV, adding telemetrics. Below is slightly-edited comments from patch, some build instructions omitted. For full text see email, URL at end.

[Luv] [PATCH V1 0/4] Introduce telemetrics feature in LUV

This patchset consists of all the patches needed to enable the telemetrics feature in LUV. LUV brings together multiple separate upstream test suites into a cohesive and easy-to-use product and validates UEFI firmware at critical levels of the software stack. It may be possible that one of the test suites crashes while running. It may be even possible that a kernel panic is observed. Under these scenarios, it would be useful for LUV to call home and submit forensic data to analyze and address the problem. The telemetrics feature will do just this.  Of course, this will be an opt-in feature(command line argument telemetrics.opt-in) and users will get clear indication that data is being collected. We have used the telemetrics-client code developed by the clear-linux team and tried to incorporate it in LUV. It has support for crashprobe (invoked whenever a core dump is created), oopsprobe(invoked when there is a kernel oops observed) and pstore-probe(invoked when there is a kernel panic and system reboots). In any of these scenarios, telemetrics records will be sent to the server, currently residing at(one used by clear linux):
 http://rnesius-tmdev.jf.intel.com/telemetryui/
The build ID 122122 can be used to filter the LUV telemetrics records which can be further analysed. In due course, we will have to implement a server of our own to handle this. For telemetrics to work in LUV, the following changes were needed:

1. Migrate to SystemD: LUV currently uses the SystemV init manager but since telemetrics-client repo and the latest yocto have updated on to SystemD, LUV also needs to migrate to SystemD. Since Systemd will not work with the existing psplash graphical manager, we have disabled the splash screen

2.    Migrate to Plymouth: LUV currently uses the psplash graphical manager, but since SystemD is compatible with only Plymouth graphical manager, we have migrated to Plymouth. PLEASE NOTE: Before migrating to plymouth, we have to merge the morty branch of the meta-oe layer provided by open embedded into the LUV repo and add the meta-oe layer to the build/conf/bblayers.conf file. Here are the steps to do this: <omitted> The loglevel has been set to 0 else there are lots of kernel messages overwriting the plymouth screen. Hence, details about the individual tests in the testsuites will not appear when the splash screen is set to false when using plymouth. If the user wants the test details to be shown, they would have to remove the ‘quiet’ and ‘loglevel=0’ kernel command line parameters.

3. Enable networking: After shifting to systemD, the LUV image is not being assigned an IP on boot. This is because it is still using a systemV startup script to do the same. Since systemD names its interfaces differently, we could not see any interfaces with a valid IP. This patch adds the networkd package, introduces a network config file which starts dhcp by default for all interfaces whose names start with en(pci devices which get renamed by udev) or eth(backward compatible) and a service file (networking.service) which will bring up the network and make sure an IP is assigned during boot. It refers:
    https://wiki.archlinux.org/index.php/systemd-networkd

4. Enable telemetrics in LUV: A yocto recipe which fetches the clear-linux telemetrics-client repo, builds it and installs all the necessary service files, daemons and probes has been added. Also, Add a kernel line parameter which lets the user opt-in to the telemetrics feature (telemetrics.opt-in). By default, this feature is disabled. Currently, the telemetrics records can be found here: http://rnesius-tmdev.jf.intel.com/telemetryui/

Full announcement and patch:
https://lists.01.org/mailman/listinfo/luv

Standard
Uncategorized

LUV 2.0 released!

The Intel LUV team, at least including: Gayatri Kammela (12), Megha Dey (12), Naresh Bhat (1), and Ricardo Neri (46) have released 2.0 of LUV, the Linux UEFI Validation Project.

These are the highlights of the release:

*Different types of image available (i386 and x86_x64)
*Logging and debugging via network (or serial)
*Tests for persistent memory (NVDIMM)
*Support for i386
*Booting LUV via network (PXE, HTTP boot later)
*Miscellaneous updates (BITS perf improvements, Linux 4.4 kernel, …)
*Dropped support for fido (focus is on Jethro)
*Known issues and limitations (Debugging works only over Ethernet, not WiFi, …)

Read the full announcement, there are pages of details not included here.

One new feature is i386 support. LUV 1.x was x64-centric, now we hopefully also use LUV 2.0 for testing x86 systems! But signed shim is still only available for 64-bit, so Secure Boot is not enabled for 32-bit support [yet?]. Quoting the release notes:  “At the last minute we faced a kernel issue when booting on a i386-based system. We are debugging. Once this is cleared, a bootable image will be uploaded (issue #76 on [3])”

Full announcement:
https://lists.01.org/pipermail/luv/2016-April/001035.html
https://download.01.org/linux-uefi-validation/v2.0
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc
[1]. https://github.com/01org/luv-yocto/tree/master/meta-luv
[2]. https://github.com/pmem/ndctl
[3]. https://github.com/01org/luv-yocto

Standard
Uncategorized

NTCTL (NFIT Defined Control) tests added to LUV

Megha Dey of Intel just checked in a 5-part patch to the LUV project, adding a new NDCTL (NFIT Defined Control) test suite to LUV.

This patchset adds the NDCTL(NFIT Defined Control) test suite to LUV. Apart from the recipe, it updates the Linux kernel headers, adds the related binaries and a parser to the final LUV image.It addresses issue 58. We also compile and install the required kernel modules for running the  NDCTL test suite and add the configurations needed by the NDCTL testsuite as config fragments to the default config values from v4.4 kernel. A Non-Volatile DIMM (NVDIMM), is a module that can be integrated into the main memory of a compute platform, perform workloads at DRAM speeds, yet be persistent & provide data retention in the event of a power failure or system crash. The LIBNVDIMM subsystem provides block device drivers for three types of NVDIMMs namely nd_pmem (NFIT enabled version of existing ‘pmem’ driver), nd_blk (mmio aperture method for accessing persistent storage) and nd_btt(give persistent memory disk semantics)that can simultaneously support both PMEM and BLK mode access. The NVDIMM Firmware Interface Table (NFIT) numerates persistent memory ranges, memory-mapped-I/O apertures, physical memory devices (DIMMs), and their associated properties. Prior to the arrival of the NFIT, non-volatile memory was described to a system only using a single system-physical-address range where writes are expected to be durable after a system power loss. Now, the NFIT specification standardizes not only the description of PMEM, but also BLK and platform message-passing entry points for control and configuration. The NDCTL test suite has 5 tests in total divided into 2 sets of tests: One uses the manufactured NFIT (NVDIMM Firmware Interface Table) to build the nfit_test module as an external module and arrange for the external module replacements of nfit, libnvdimm, nd_pmem, and nd_blk and the other which has the actual *destructive* tests that create namespaces and perform I/O tests on them.

  luv: NDCTL:  Update the linux kernel headers
  core-image-efi-initramfs: Add NDCTL binaries
  luv-test-manager: Add stderr output to LUV parser
  luv : NDCTL: Add NDCTL test suite
  linux-efi-yocto-test: build NDCTL test suite

More info:
https://github.com/01org/luv-yocto/issues/58
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
https://github.com/pmem/ndctl
http://permalink.gmane.org/gmane.linux.kernel.commits.head/535671
https://lists.01.org/mailman/listinfo/luv
https://lwn.net/Articles/640891/

Standard
Uncategorized

LUV/BITS/CHIPSEC ported from x64 to x86!!

Get ready to test your Intel x86 systems!

Megha Dey of Intel submitted an 8-part patch to LUV that enables it to build on x86.

LUV has been useful for 64-bit x64 systems, and now is getting useful for 32-bit x86 systems!

Including 32-bit versions of BITS and CHIPSEC!

Is this the first time that pre-compiled binaries of CHIPSEC for x86 systems have been available? Not sure. Anyway, if you build from source you can start now, otherwise, look for the LUV-live binary download site to start having 32- and 64-bit versions, hopefully

Excerpt from part 0 of the patch:

[PATCH 0/8] Build and run LUV on 32 bit platforms

Currently LUV can be built only for 64 bit target platforms. This patchset contains patches which make sure that LUV can be compiled and run on both 32 as well as 64 bit target platforms. This required reworking of the PE header checks, adding call wrappers used by the shim bootloader to store and restore context, making sure chainloader.c compiled for 32 bit systems, adding support to ensure correct direct directory structure for 32 bit case and removing bugs in chipsec so that it could build without any erros on 32 bit systems. Also, the bits recipe is updated to build the grub EFI image only for target builds.This patchset addresses the following issue:
https://github.com/01org/luv-yocto/issues/57

grub: chainloader: shim: rework PE header checks
grub: shim: Add call wrappers for 32 bit systems
grub: shim: compile chainloader.c for 32bit system
luv : Correct directory structure for 32 bit case
luv: Add the ARCH parameter to chipsec Makefile
luv: chipsec : compile for 32 bit systems
bits: only build grub EFI image for target builds
bits: grub: specify location of images and modules for mkimage

More information:

https://lists.01.org/mailman/listinfo/luv

Standard
Uncategorized

Intel 01.org mailing lists

It is sometimes funny to watch a company do open source. Intel’s 01.org, for Open Source projects, has a mailing list server with multiple lists:
https://lists.01.org/

There are lists for LUV and CHIPSEC. These work fine!
https://lists.01.org/mailman/listinfo/chipsec
https://lists.01.org/mailman/listinfo/luv

There is a list for Thunderbolt Software. …but it is a closed list, with no public archives. 😦
https://lists.01.org/mailman/listinfo/thunderbolt-software

The text that it is a closed list:
“This is a hidden list, which means that the list of members is available only to the list administrator.”

There’s a list for Intel Kernel Guard Technology (KGT). It also is a closed list, with the same text as the Thunderbolt list. BUT, their archives are publicly-available.
https://lists.01.org/mailman/listinfo/intel-kgt
https://lists.01.org/pipermail/intel-kgt/

There’s a list for BIOS Implementation Test Suite (BITS)!
But there are no archives, perhaps a closed list, or just broken archives?
https://lists.01.org/mailman/listinfo/bits

I rather wish Intel used intel.com or 01.com for closed lists, and kept the Open Source-centric 01.0rg’s list all public, with working archives. 😦

Standard
Uncategorized

LUV-live 2.0-RC4 released

Ricardo Neri of Intel announced Linux UEFI Validation (LUV) v2.0-rc4 release, with lots of changes, new versions of CHIPSEC, BITS, FWTS, and multiple UEFI improvements in LUV. IMO, one of the most important features it that LUV-live’s CHIPSEC should properly log results now! Excerpts from Ricardo’s announcement:

This release touches many areas. Here are some highlights:

Naresh Bhat implemented changes to build from Linus’ tree when building LUV for ARM. While doing this, he got rid of the leg-kernel recipe. Now the kernel is built from linux-yocto-efi-test for all architectures. Also, he took the opportunity to remove some of the LUV-specific changes we had in the meta layer (i.e., our genericarmv8 machine). It always good to restrict ourselves to the meta-luv layer, unless we plan to upstream to the Yocto Project. Now LUV for aarch64 is built using qemuarm64.

It was reported that CHIPSEC was not running correctly in LUV due to missing configuration files and Python modules. This release includes a major rework of CHIPSEC integration into LUV. It ran correctly on all the systems in which we tested. Also, we bumped to v1.2.2; the CHIPSEC latest release.

This release includes new functionality to build BITS from its source rather than just deploying its binaries. BITS is a challenging piece of software when it comes to integration into a bitbake recipe. The build process was broken into several steps. This work help for future work to customize BITS for other CPU architectures and netboot.

The UEFI specification v2.5 includes a Properties Table for the memory map. Under this feature, it is possible to split into separate memory sections the code and data regions of the PE/COFF image. Unfortunately, kernels previous to v4.3 crash if this features is enabled. We have backported a fix pushed to Linux v4.3. We will be bumping the kernel for x86 to 4.3 in our next release.

The EFI stub feature in the kernel allows to run the kernel as an EFI application. Also, it allows the kernel to parse the memory map directly from the firmware rather than taking the map from the bootloader. This is clearly advantageous in case of bugs in the bootloader.

Now that LUV support storing the results of multiple bots, it may happen that disk runs out of space. Gayatri Kammela made updates to increase the size of the results partition and issue a warning when available space runs below 2MB.

Finally, keeping up with the latest changes in the Yocto Project has paid off handsomely. This release is based on Jethro, the latest version of the Yocto Project. Rebasing to this new version as done with very little effort. In the LUV tree you can find the jethro and jethro-next branches; the bases of this release. The fido and fido-next branches are still maintained.

We have bumped the following test suite versions:

 *FTWS is now V15.12.00
 *CHIPSEC is now v1.2.2
 *BITS is 2005

Time to update your LUV-live images! It is a Release Candidate, so please help the LUV team by testing it out and pointing out any issues on the LUV mailing list. This version of CHIPSEC includes VMM tests, so time to test LUV-luv in your virtual machines, not just on bare-metal boxes.

Many people contributed to this release, including: Ricardo Neri, Naresh Bhat, Darren Bilby, Megha Dey, Gayatri Kammela, John Loucaides, Sai Praneeth Prakhya, and Thiebaud Weksteen. It was nice to see the LUV and CHIPSEC teams work together in this release!

More information:
https://lists.01.org/pipermail/luv/2015-December/000745.html
https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc4.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc

https://01.org/linux-uefi-validation/

Standard
Uncategorized

Netconsole added to LUV

Gayatri Kammela of Intel posted a new feature patch to LUV: the netconsole. From the patch’s comments:

This is about adding a Linux feature called Netconsole in Linux* UEFI Validation. In LUV netconsole feature is enabled only for the test suites that run once  the Linux takes control over and BITS test suite will be excluded from  having this kind of support.

Why this feature: Netconsole in LUV help us debug the kernel panics or system hangs by  sending not only kernel messages but also information regarding the running tests simultaneously on to the remote machine via ethernet. Now the remote machine can  be on same subnet or different subnet with respective to the local machine  ( machine you are trying to boot LUV). To enable netconsole feature in LUV, changes are made in various files to include kernel modules like netconsole  and different network utilites that can send messages  via ethernet.Besides these changes are made to luv-test-manger to make all the  running tests information sent to dmesg to make the debugging more easy.

How this feature works: Liberty is given to user to choose the ip address and port number where he/she wants all messages to sent to. once decided , user can replace the dummy ip address given  in grub.cfg as @,64001@10.11.12.13/ with the destined address and port number.  The same information is mentioned in README file , so that user can get  to know the usage of netconsole.

Requirements for this feature: Not many changes are required for this feature , except enabling some of the kernel config options. Luv kernel has config optons enabled that are  obsolutely necessary for the image and to keep the kernel size as low as possible. Since netconsole require lot of options enabled related to TCP/IP , IPV4 , IPV6 and  filesystem related options. These information can be overwhelming and just for the sake of clarity some of the important options that needs to enabled are given below […]

See checkin post for full comment and sources:
https://lists.01.org/mailman/listinfo/luv

Standard