Hyperthreading is a risk factor for spectre/meltdown
and other attacks.
Disabling it is a best practise. Those who need it
can always turn this option back on. Otherwise, disabling
it by default is a simply courtesy to the average user,
in the interest of security.
Signed-off-by: Leah Rowe <leah@libreboot.org>
SeaBIOS was lagging a lot, on startup and when executing
almost any payload, especially when doing anything in the
ESC menu.
I set the debug level to *21*, and thoroughly analysed the
logs. I found entries such as this:
Checking for bootsplash
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_StirRandom = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_GetRandom = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_HierarchyChangeAuth = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc16e
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc1c5
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc211
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc25d
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc2a9
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc2f5
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc341
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc38d
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc3d9
Searching bootorder for: HALT
Mapping hd drive 0x000f49e0 to 0
I'm not quite certain what the problem is, but disabling TPM2
made the problem go away; SeaBIOS is snappy again.
TPM is security threatre anyway.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
see patch for rationale. this should prevent instability caused
when the nvme randomly replugs under linux. sometimes e.g. nvme0n1
becomes nvme0n2 while the system is running.
in my case, that caused my raid1 to become unsynced every few days.
this issue was fixed on t480 by disabling pcie hotplug for its nvme
device, so the same fix has been applied for dell optiplex 3050 micro.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was done with the following command:
./mk -u coreboot t480s_fsp_16mb t480_fsp_16mb
it was set to 256 but should be 512. the SPD is what
contains configuration data for raminit, which training
code uses so that the timings will be correct. if the SPD
size is wrong, the machine won't boot
in practise, lbmk always runs "make oldconfig" on
a coreboot config, before building it, so this was
already being corrected automatically at build time.
however, if that fact ever changes in the future, this
wrong configuration would cause the machines not to boot.
therefore, this can be considered a preventative or perhaps
pre-emptive bug fix.
this fix does not need to be applied to the 20241206 release,
because of the behaviour described above. the final ROM images
do have the spd size set correctly to 512, because of this
design feature in lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Nope! Bootflow menu is cursed on this machine.
Too many issues in U-Boot on this machine. I did however
boot a Debian installer after it booted, using bootflow.
The installed system wouldn't boot with bootflow, but I could
then boot it with "bootefi bootmgr".
I'll rig up a uart on the T480 when I get round to it and
start investigating U-Boot bugs on this board.
I don't want people flashing something that doesn't work.
GRUB and SeaBIOS work, so ship those, and don't ship U-Boot.
This reverts commit 19ec440a6f.
u-boot does work after a few reboots. it just boot loops.
let it run. it should be able to boot from nvme. sata still needs
some work (sata only works in grub, on this machine)
This reverts commit cd9baca5d6.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Patchset 20 from:
https://review.coreboot.org/c/coreboot/+/83274/18..20
Updated to that. A bunch of changes I made locally have been
copied here, thus removed from lbmk.
The previous setup in lbmk was to have only the DIMM slot work,
on the ThinkPad T480S, without setting up SPD for the onboard RAM>
Mate Kukri reverse engineered the scheme by which the SPDs are
chosen at boot, based on the wiring of the board. This should
just about match the way Lenovo did it in their firmware.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This fixes an error where nvme disappears and gets renamed
on s3 resume. Mate Kukri told me to test that and it worked.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I also enabled this on T480S, because otherwise SeaBIOS hung.
Enabling it shouldn't cause any harm on the T480, though Mate
did say that his machine seemed to work with my setup.
However, I believe that was when I gave him the ones that lbmk
built with the VGA ROM. Now it builds with libgfxinit, because
Mate was able to fix libgfxinit on this machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Added t480s delta to deguard, for MFS config.
Updated coreboot/next to latest t480 patch set,
which includes t480s. This porting was done by
Mate Kukri.
also includes experimental t480s support
Also added a data.vbt file (not in the gerrit patch)
for the T480s.
I had to turn on 8254 legacy timer on t480s, otherwise
SeaBIOS would hang. Same issue I saw on OptiPlex 3050 Micro.
Minor issue:
On S3 resume, nvme0n1 for example got renamed to nvme0n2.
This caused a crash if running Linux from the nvme. I confirmed
this via live USB distro. So this port will need some tweaking
before it can be considered stable.
Also uses libgfxinit, which Mate recently fixed. I'm
going to enable libgfxinit on regular T480 next.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This uses the excellent deguard utility, written by
the excellent Mate Kukri.
A few bugs but it mostly works. Documentation to come
shortly, in lbwww.git.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This uses the "normal" config. Previous changes prevent
U-Boot images being built for this anyway, but it does
yield a warning message.
Remove the warning at the source.
Signed-off-by: Leah Rowe <leah@libreboot.org>
It's really buggy on hardware. Disable for now.
I've contacted Simon Glass on IRC, asking about hardware.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Currently seems to stall when booted from the GRUB
payload, but works when booted from the SeaBIOS menu.
I also tested it as a standalone payload and it seems
to boot. Will test on hardware next, and start adding
it to more mainboards.
Signed-off-by: Leah Rowe <leah@libreboot.org>
coreboot/dell7 is now part of coreboot/next, which in turn
has been updated, to accomodate 3050 micro patchset 18:
https://review.coreboot.org/c/coreboot/+/82053/18
It incorporates my Verb/VBT patches, which are therefore
no longer included separately.
Mate has fixed the USB config; see diff for details.
The configuration of USB ports was wrong, before.
Signed-off-by: Leah Rowe <leah@libreboot.org>
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:
OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1
Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for lbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.
The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.
I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).
It's only enabled in QEMU for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
There were a lot of unnecessary patches, such as the VRAM
patches; as Nicholas Chin has explained to me, the drivers
for these machines will just allocate what RAM they want
anyway, so in a lot of cases the extra allocated Video RAM
simply reduces the total amount of memory for other uses.
In general, we have a lot of patches that have existed for
years. A much more aggressive sweep will be done in the next
major audit, especially when the revisions are updated again.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Thanks go to Nicholas Chin and Lorenzo Aloe for working on
and testing this code. Based on the 780 MT port.
Signed-off-by: Leah Rowe <leah@libreboot.org>
pin mod needed (soldering) but according to mate, you
can use some coffeelake CPUs on these machines, despite
them being intel 7th gen. this includes 8-core chips.
this patch enables the software configuration in coreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is for blanking the ME region on release builds.
This is required for lbmk when doing Libreboot releases,
on images that use an Intel ME region.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Remove what is now unnecessary bloat, for ensuring that
GRUB is the primary payload; SeaGRUB is the only preference,
as per lbmk design.
The SeaBIOS hanging issue was fixed, so SeaGRUB is OK now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Again, I'm adapting the config to be as close to the
coreboot one as possible. I compiled directly from coreboot
earlier, and got SeaBIOS to work on my 3050.
I'm matching the setup as closely as possible. Once it works,
I can use that in a Libreboot release but then debug why the
old config wasn't working.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I'm eliminating as many differences as possible between lbmk's
setup, and the setup that is default when simply building from
the gerrit patch, directly in coreboot, by just picking the
mainboard; in this way, coreboot picks SeaBIOS as payload. I
already changed the SeaBIOS configs, in the previous patch.
Upon testing, this seems to have fixed the SeaBIOS hanging. I
need to have both of these options selected, or SeaBIOS hangs
just after it says "Press ESC" for the boot menu.
With this config change, SeaBIOS does not hang; instead, it shows
the list of devices as normal, and boots your machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
- Update the MEC5035 S3 patches to the versions that were sent upstream
to prevent conflicts with subsequent patches for that EC.
- Update the patch that enables the S3 SMI handler in mainboard code so
that all Latitudes use the handler.
- Add a new patch that tells the EC to route power button events to the
host so that the OS can decide what to do. Without it, the EC powers
off the system without letting the OS cleanly shut down.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Specifically, use the same revision that Mate used in patchset 15.
This will ensure that any issues are *not* caused by the coreboot
revision; this is being done, because the old coreboot revision was
from July, but patchset 15 from Mate is based on a September revision
of coreboot.
I've been eliminating as many variables as possible, trying to fix
SeaBIOS payload on this machine, because it hangs in Libreboot, but
not when building from gerrit directly, which means the coreboot
revision may be a factor (since I'm using his patches on an older
revision so upstream might have made some changes since then that
the port relies on).
For this, a new coreboot tree is used, called "dell7", referring to
the fact that Kabylake is Intel's 7th generation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Use patchset 15 instead of 14:
config/coreboot/default/patches/0061-WIP-OptiPlex-3050-Micro-port.patch
Rebase the verb patch; patchset 15 modified the Makefile:
config/coreboot/default/patches/0064-dell-optiplex_3050-add-hda_verb.c.patch
We were using patchset 14 for the 3050 micro:
https://review.coreboot.org/c/coreboot/+/82053/14
Now we use patchset 15:
https://review.coreboot.org/c/coreboot/+/82053/15
Without this patch, the fans are always on a low setting, on
the Dell OptiPlex 3050 Micro, even under stress conditions. With
this patch, the fans change speed according to CPU temperature.
I had to rebase my verb patch, because Mate modified the Makefile
to add his sch5555 handler, on the same line where I add hda_verb.
Mate tells me he will merge my verb and vbt patches into a further
patchset later on. For now, I've simply rebased these patches on
top of Mate's newer work; I've told him he can use them in his port.
I'm probably going to now issue a new revision ROM image for
Libreboot 20241008, so that users can get this fix sooner.
Signed-off-by: Leah Rowe <leah@libreboot.org>
on 3050micro, we disable seabios as a primary payload,
making grub a pribary payload instead.
the way it worked, the roms were still named seagrub
and the seabios rom would be compiled, but with the wrong
path, so seabios wouldn't be executed; seabios would hang
anyway, on this board.
instead, engineer it in such a way as to disable seabios_
images on this board. also, rename seagrub_ to grub_.
i normally only permit seagrub, and not grub, but i make an
exception for 3050micro because we know grub works, but seabios
currently hangs on this board (which means no bsd).
Signed-off-by: Leah Rowe <leah@libreboot.org>
SeaBIOS is known to hang on this board. It is being investigated.
Add two variable options for target.cfg files:
* seabiosname
* grubname
This string defines where it would be located in CBFS.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is using Mate Kukri's port, which was added in
previous lbmk revisions. I've added an IFD that sets
the HAP bit, and unlocks regions as standard.
vcfg is set to 3050micro, which defines downloading
of the MEv11 image and it will run deguard automatically.
I made a small adjustment to vendor.sh, because the hotpatch
logic for deguard uses -C in git, and when doing that, the
specified directory path is relative to that Git repository;
the .patch path has been adjusted accordingly.
Also add 3rdparty/fsp to coreboot/default modules.
This board requires the ifdtool option: -p sklkbl
The -p option tells flashrom what quirks are present in a
given IFD. We don't normally need this on other Libreboot
targets that we currently support. The -p option was needed
for creating this modified IFD, and it is therefore needed in
the inject script. Therefore, an "IFD_platform" option is
specified in a given board's target.cfg file. If this is set,
another variable is set that makes -p be used.
In this case, 3050's target.cfg says:
IFD_platform="sklkbl"
This option enables quirks for skylake/kabylake descriptors,
as required when using ifdtool.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe