rhboot / fwupdate Goto Github PK

View Code? Open in Web Editor NEW

96.0 96.0 47.0 558 KB

System firmware update support for UEFI machines

fwupdate's People

Contributors

Stargazers

Watchers

fwupdate's Issues

ux-capsule doesn't seem to work on Dell hardware

I have code here: https://github.com/rhboot/fwupdate/tree/ux-capsule
It looks (to me) like it should work, but when I apply an update that includes the UX capsule in the list, the machine just reboots without applying any updates.

@superm1 , can I get a bit of help here?

Bios update fails on Dell 9350 (developper edition)

Hi,
Gnome-softwate offers me to update my bios to the latest version (0.1.4.10 -> 0.1.4.13)
However, nothing happens when I click "install": the button disappear and comes back a few seconds later. Nothing happens on reboot either.

I'm using a freshly installed fedora 25.

How can I help troubleshooting this issue?

Thanks

e3b443d introduces a regression if existing fwupdate status variable

Commit e3b443d introduces a regression if existing variables are around from a previous fwupdate run.

$ ls /sys/firmware/efi/efivars/fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
/sys/firmware/efi/efivars/fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
$ fwupdate -a `cat /sys/firmware/efi/esrt/entries/entry0/fw_class` firmware_0.3.1.cap    // cause a segment fault
$ rm /sys/firmware/efi/efivars/fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
$ fwupdate -a `cat /sys/firmware/efi/esrt/entries/entry0/fw_class` firmware_0.3.1.cap    // successful

fwupdate fails to run due to previously existing fwupdate EFI variable

Trying to use fwupdate on a machine running RHEL, I got:

# fwupdate -a 34578c72-11dc-4378-bc7f-b643866f598c firmware.cap 
Could not set up firmware update: No such file or directory

Using strace to find out which path caused the error:

open("/boot/efi/EFI/fedora/fw/fwupdate-yML5Cm.cap", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0600) = -1 ENOENT (No such file or directory)
write(2, "Could not set up firmware update", 32Could not set up firmware update) = 32

The "/boot/efi/EFI/fedora" path doesn't make much sense since the machine is running RHEL.

There is this fwupdate variable which may be causing the bug since it contains a "fedora" path, likely from an earlier attempt to use fwupdate on this machine.

# hexdump -C /sys/firmware/efi/efivars/fwupdate-34578c72-11dc-4378-bc7f-b643866f598c-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
00000000  07 00 00 00 07 00 00 00  72 8c 57 34 dc 11 78 43  |........r.W4..xC|
00000010  bc 7f b6 43 86 6f 59 8c  00 00 02 00 00 00 00 00  |...C.oY.........|
00000020  00 00 00 00 e1 07 04 0c  11 01 1e 00 00 00 00 00  |................|
00000030  ff 07 00 00 02 00 00 00  04 01 2a 00 01 00 00 00  |..........*.....|
00000040  00 08 00 00 00 00 00 00  00 a0 0f 00 00 00 00 00  |................|
00000050  92 a4 82 63 f4 d9 af 42  a7 9d 9a ed 2b 49 4b 8b  |...c...B....+IK.|
00000060  02 02 04 04 4a 00 5c 00  45 00 46 00 49 00 5c 00  |....J.\.E.F.I.\.|
00000070  66 00 65 00 64 00 6f 00  72 00 61 00 5c 00 66 00  |f.e.d.o.r.a.\.f.|
00000080  77 00 5c 00 66 00 77 00  75 00 70 00 64 00 61 00  |w.\.f.w.u.p.d.a.|
00000090  74 00 65 00 2d 00 79 00  4d 00 4c 00 35 00 43 00  |t.e.-.y.M.L.5.C.|
000000a0  6d 00 2e 00 63 00 61 00  70 00 00 00 7f ff 04 00  |m...c.a.p.......|
000000b0

Removing the variable fixed the error and I was able to run fwupdate.

add_capsule forces PERSIST_ACROSS_RESET and INITIATE_RESET flags

Hi,

according to UEFI specification, CAPSULE_FLAGS_PERSIST_ACROSS_RESET and CAPSULE_FLAGS_INITIATE_RESET flags are optional (spec page 1097), but fwupdate forces these before passing capsules to UpdateCapsule (1, 2). What is the reasoning behind that? Commit message doesn't help.

Thanks,
Bartosz

No easy way to #ifdef new functionality

It would be really useful to have something like this in fwup.h: https://github.com/hughsie/fwupd/blob/master/libfwupd/fwupd-version.h.in -- this way I can #ifdef the new things without having to rely on configure.ac checks.

fails to build on arm64 and armhf

Jared pulled in 8f8dcbc into the last upload to Debian that synced to Ubuntu. Under Ubuntu, this has failed to build on arm64 and armhf with the following errors:

arm64(https://launchpadlibrarian.net/211678696/buildlog_ubuntu-wily-arm64.fwupdate_0.4-3_BUILDING.txt.gz)

make[3]: Entering directory '/«PKGBUILDDIR»/efi'
gcc -O0 -g3 -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=c11 -DCONFIG_aarch64 -D__KERNEL__ -I/usr/include/efi/ -I/usr/include/efi/aarch64/ -iquote/«PKGBUILDDIR»/include "-DDEBUGDIR=L\"/\"" -ffreestanding -I/usr/lib/gcc/aarch64-linux-gnu/4.9/include -c -o fakeesrt2.o fakeesrt2.c
ld -nostdlib --warn-common --no-undefined --fatal-warnings -shared -Bsymbolic -L/usr/lib -L/usr/lib --build-id=sha1 /usr/lib/crt0-efi-aarch64.o --defsym=EFI_SUBSYSTEM=0xa -o fakeesrt2.so fakeesrt2.o -lefi -lgnuefi \
    /usr/lib/gcc/aarch64-linux-gnu/4.9/libgcc.a \
    -T elf_aarch64_efi.lds
ld: section .note.gnu.build-id loaded at [0000000000000000,0000000000000023] overlaps section .text loaded at [0000000000000000,000000000000668f]
Makefile:74: recipe for target 'fakeesrt2.so' failed
make[3]: *** [fakeesrt2.so] Error 1
rm fakeesrt2.o

armhf (https://launchpadlibrarian.net/211678705/buildlog_ubuntu-wily-armhf.fwupdate_0.4-3_BUILDING.txt.gz)

make[3]: Entering directory '/«PKGBUILDDIR»/efi'
gcc -O0 -g3 -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=c11 -DCONFIG_arm -D__KERNEL__ -I/usr/include/efi/ -I/usr/include/efi/arm/ -iquote/«PKGBUILDDIR»/include "-DDEBUGDIR=L\"/\"" -ffreestanding -I/usr/lib/gcc/arm-linux-gnueabihf/4.9/include -c -o fakeesrt2.o fakeesrt2.c
ld -nostdlib --warn-common --no-undefined --fatal-warnings -shared -Bsymbolic -L/usr/lib -L/usr/lib --build-id=sha1 /usr/lib/crt0-efi-arm.o --defsym=EFI_SUBSYSTEM=0xa -o fakeesrt2.so fakeesrt2.o -lefi -lgnuefi \
    /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a \
    -T elf_arm_efi.lds
ld: section .note.gnu.build-id loaded at [00000000,00000023] overlaps section .text loaded at [00000000,0000647f]
make[3]: *** [fakeesrt2.so] Error 1
Makefile:74: recipe for target 'fakeesrt2.so' failed
rm fakeesrt2.o

It built fine on amd64 and i386.

fwup_set_up_update possibly needs fflush and fsync

Another review happened in Ubuntu recently (https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1508926/comments/7) and one question was put forward that should be double checked:

fwup_set_up_update() lots of work between final fputc() and fclose() --
  does this need fflush(fout); fsync(outfd); before the work?

The remaining items from the review that were applicable are submitted in a pull request here: https://github.com/rhinstaller/fwupdate/pull/45/commits

Alternative EFI locations

Hi I'm currently struggling to use fwupdate due to the location of my efi partition. I have it mounted to /esp as FAT32 and /boot is a bind mount to /esp/EFI/arch. Due to it being fat32 I can't do a symlink to support fwupdate's expected folder structure. The exact process for bind mounts is shown here: https://wiki.archlinux.org/index.php/EFI_System_Partition#Using_bind_mount

and isn't too uncommon in the arch community. Would you please look at supporting alternative mount pounts.

Thanks! :)

Could not find device handle: not found

Hi,

I'm testing this on a future platform. I'm noticing that the boot entry isn't getting created even if the tool successfully exits 0 on Linux. It doesn't show up in efibootmgr output or in the F12 boot menu on the system.

It does stage efi$distro\fw\fwupdate-x0XphZ.cap on the disk though.

Ignoring that first problem (can be solved later unless it's related I guess), I tried to launch fwupdate from EFI shell.

Here's the output I got:

fs0:\ > fwupdate.efi
Found update fwupdate-6180aaaa-5529-4bb4-b4fd-65b4f788de5b-0
Could not locate device handle: Not Found.
fwupdate: Could not build update list: Not Found

Respect CFLAGS and LDFLAGS

Hi,

please merge this patch, as currently global CFLAGS and LDFLAGS are not respected by makefiles

https://github.com/OpenMandrivaAssociation/fwupdate/blob/master/fwupdate-0.4-respect-cflags-and-ldflags.patch

Thanks.

Incorrect prefix for esrt_disabled and enable_esrt

We probably want to do something like:

enable_esrt() -> fwup_esrt_enable()
esrt_disabled() -> fwup_esrt_is_disabled()

Otherwise it's quite confusing where these symbols are coming from...

Invalid device path for SSD on Dell SLA

The generated fwupdate status variable contains an invalid device path on my DELL SLA board. On this board, an USB key (/dev/sdb) and SSD(/dev/sda) are attached. Two drives all uses the first partition as ESP (MBR scheme not GPT). See the infos below.

# fdisk -l /dev/sda
Disk /dev/sda: 29.8 GiB, 32017047552 bytes, 62533296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5078fe0f

Device    Boot Start       End Blocks  Id System
/dev/sda1         63    273104 136521   e W95 FAT16 (LBA)

# fdisk -l /dev/sdb
Disk /dev/sdb: 7.5 GiB, 8004304896 bytes, 15633408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x59c88c89

Device    Boot     Start       End  Blocks  Id System
/dev/sdb1           2048    264191  131072   c W95 FAT32 (LBA)
/dev/sdb2         264192   6555647 3145728  83 Linux
/dev/sdb3        6555648  12847103 3145728  83 Linux
/dev/sdb4       12847104  15633407 1393152  83 Linux

# mount | grep sd
/dev/sdb2 on / type ext3 (rw,relatime,errors=continue,user_xattr,barrier=1,data=ordered)
/dev/sdb4 on /media/sdb4 type ext3 (rw,relatime,sync,errors=continue,user_xattr,barrier=1,data=ordered)
/dev/sdb3 on /media/sdb3 type ext3 (rw,relatime,sync,errors=continue,user_xattr,barrier=1,data=ordered)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sdb1 on /mnt type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

# rm -f /sys/firmware/efi/efivars/BootNext* /sys/firmware/efi/efivars/fwupdate* /sys/firmware/efi/efivars/Boot0000*

# hexdump -C fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
00000000  07 00 00 00 07 00 00 00  ed 14 f6 e0 82 fb 7a 46  |..............zF|
00000010  a3 4e 71 17 2c c0 7e 4d  00 00 00 00 00 00 00 00  |.Nq.,.~M........|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 01 00 00 00  02 01 0c 00 d0 41 03 0a  |.............A..|
00000040  00 00 00 00 01 01 06 00  00 13 03 12 0a 00 00 00  |................|
00000050  ff ff 00 00 04 01 2a 00  01 00 00 00 00 20 00 00  |......*...... ..|
00000060  00 00 00 00 00 20 00 00  00 00 00 00 6a a5 3a ce  |..... ......j.:.|
00000070  5b 51 37 49 a1 f2 b5 a1  a8 e6 f4 74 02 02 04 04  |[Q7I.......t....|
00000080  46 00 5c 00 45 00 46 00  49 00 5c 00 64 00 65 00  |F.\.E.F.I.\.d.e.|
00000090  6c 00 6c 00 5c 00 66 00  77 00 5c 00 66 00 77 00  |l.l.\.f.w.\.f.w.|
000000a0  75 00 70 00 64 00 61 00  74 00 65 00 2d 00 64 00  |u.p.d.a.t.e.-.d.|
000000b0  38 00 42 00 34 00 5a 00  63 00 2e 00 63 00 61 00  |8.B.4.Z.c...c.a.|
000000c0  70 00 00 00 7f ff 04 00                           |p.......|
000000c8

# # hexdump -C BootNext*
00000000  07 00 00 00 00 00                                 |......|
00000006

# hexdump -C Boot0000*
00000000  07 00 00 00 01 00 00 00  60 00 4c 00 69 00 6e 00  |........`.L.i.n.|
00000010  75 00 78 00 20 00 46 00  69 00 72 00 6d 00 77 00  |u.x. .F.i.r.m.w.|
00000020  61 00 72 00 65 00 20 00  55 00 70 00 64 00 61 00  |a.r.e. .U.p.d.a.|
00000030  74 00 65 00 72 00 00 00  04 01 2a 00 01 00 00 00  |t.e.r.....*.....|
00000040  00 20 00 00 00 00 00 00  00 20 00 00 00 00 00 00  |. ....... ......|
00000050  6a a5 3a ce 5b 51 37 49  a1 f2 b5 a1 a8 e6 f4 74  |j.:.[Q7I.......t|
00000060  02 02 04 04 32 00 5c 00  45 00 46 00 49 00 5c 00  |....2.\.E.F.I.\.|
00000070  64 00 65 00 6c 00 6c 00  5c 00 66 00 77 00 75 00  |d.e.l.l.\.f.w.u.|
00000080  70 00 64 00 61 00 74 00  65 00 2e 00 65 00 66 00  |p.d.a.t.e...e.f.|
00000090  69 00 00 00 7f ff 04 00                           |i.......|
00000098

# ls /dev/disk/by-uuid/ -l
total 0
lrwxrwxrwx 1 root root 10 Oct 15 02:55 1f66bb01-dfcb-4e84-abff-d873016bde4e -> ../../sdb4
lrwxrwxrwx 1 root root 10 Oct 15 02:55 2ef3b596-392d-43e2-9ca3-00fd747c14a3 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 15 02:56 561D-FFCC -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 15 02:55 AE67-7F11 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 15 02:55 f16d9979-60e3-48a6-abf5-d9505faf8fa1 -> ../../sdb3

# ls /dev/disk/
by-id  by-path  by-uuid

# ls -l /sys/dev/block/
total 0
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:0 -> ../../devices/virtual/block/ram0
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:1 -> ../../devices/virtual/block/ram1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:10 -> ../../devices/virtual/block/ram10
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:11 -> ../../devices/virtual/block/ram11
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:12 -> ../../devices/virtual/block/ram12
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:13 -> ../../devices/virtual/block/ram13
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:14 -> ../../devices/virtual/block/ram14
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:15 -> ../../devices/virtual/block/ram15
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:2 -> ../../devices/virtual/block/ram2
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:3 -> ../../devices/virtual/block/ram3
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:4 -> ../../devices/virtual/block/ram4
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:5 -> ../../devices/virtual/block/ram5
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:6 -> ../../devices/virtual/block/ram6
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:7 -> ../../devices/virtual/block/ram7
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:8 -> ../../devices/virtual/block/ram8
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:9 -> ../../devices/virtual/block/ram9
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:0 -> ../../devices/virtual/block/loop0
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:1 -> ../../devices/virtual/block/loop1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:2 -> ../../devices/virtual/block/loop2
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:3 -> ../../devices/virtual/block/loop3
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:4 -> ../../devices/virtual/block/loop4
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:5 -> ../../devices/virtual/block/loop5
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:6 -> ../../devices/virtual/block/loop6
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:7 -> ../../devices/virtual/block/loop7
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:0 -> ../../devices/pci0000:00/0000:00:13.0/ata1/host0/target0:0:0/0:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:1 -> ../../devices/pci0000:00/0000:00:13.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:16 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:17 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:18 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb2
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:19 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb3
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:20 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb4

# echo -e -n "\x07\x00\x00\x00\x01" > /sys/firmware/efi/efivars/SHIM_DEBUG-605dab50-e046-4300-abb6-3dd810dd8b23

After reboot, the fwupdate.efi is not launched at all. To work around this issue, I made such a patch and it works well:

 static EFI_STATUS
+search_file(EFI_DEVICE_PATH **file_dp, EFI_FILE_HANDLE *fh)
+{
+       EFI_DEVICE_PATH *dp, *parent_dp;
+       EFI_GUID sfsp = SIMPLE_FILE_SYSTEM_PROTOCOL;
+       EFI_GUID dpp = DEVICE_PATH_PROTOCOL;
+       EFI_HANDLE *devices;
+       UINTN i, n_handles, count;
+       EFI_STATUS rc;
+
+       rc = uefi_call_wrapper(BS->LocateHandleBuffer, 5, ByProtocol, &sfsp, NULL,
+                              &n_handles, &devices);
+       if (EFI_ERROR(rc)) {
+               Print(L"Could not find handles.\n");
+               return rc;
+       }
+
+       dp = *file_dp;
+
+       if (debugging)
+               Print(L"Searching Device Path: %s ...\n", DevicePathToStr(dp));
+
+       parent_dp = DuplicateDevicePath(dp);
+       if (!parent_dp) {
+               rc = EFI_INVALID_PARAMETER;
+               goto out;
+       }
+
+       dp = parent_dp;
+       count = 0;
+       while (1) {
+               if (IsDevicePathEnd(dp)) {
+                       rc = EFI_INVALID_PARAMETER;
+                       goto out;
+               }
+       
+               if (DevicePathType(dp) == MEDIA_DEVICE_PATH && DevicePathSubType(dp) == MEDIA_FILEPATH_DP)
+                       break;
+
+               dp = NextDevicePathNode(dp);
+               ++count;
+       }
+
+       SetDevicePathEndNode(dp);
+
+       if (debugging)
+               Print(L"Device Path prepared: %s\n", DevicePathToStr(parent_dp));
+
+       for (i = 0; i < n_handles; i++) {
+               EFI_DEVICE_PATH *path;
+
+       for (i = 0; i < n_handles; i++) {
+               EFI_DEVICE_PATH *path;
+
+               rc = uefi_call_wrapper(BS->HandleProtocol, 3, devices[i], &dpp,
+                                      (void **)&path);
+               if (EFI_ERROR(rc))
+                       continue;
+
+               if (debugging)
+                       Print(L"Device supporting SFSP: %s\n", DevicePathToStr(path));
+
+               rc = EFI_UNSUPPORTED;
+               while (!IsDevicePathEnd(path)) {
+                       if (debugging)
+                               Print(L"Comparing: %s and %s\n", DevicePathToStr(parent_dp), DevicePathToStr(path));
+
+                       if (LibMatchDevicePaths(path, parent_dp) == TRUE) {
+                               *fh = devices[i];
+                               for (i = 0; i < count; i++)
+                                       *file_dp = NextDevicePathNode(*file_dp);
+                               rc = EFI_SUCCESS;
+
+                               if (debugging)
+                                       Print(L"Match up! Returning %s\n", DevicePathToStr(*file_dp));
+
+                               goto out;
+                       }
+
+                       path = NextDevicePathNode(path);
+               }
+       }
+
+out:
+       if (!EFI_ERROR(rc))
+               Print(L"File %s searched\n", DevicePathToStr(*file_dp));
+
+       uefi_call_wrapper(BS->FreePool, 1, devices);
+       return rc;
+}
+
+static EFI_STATUS
 open_file(EFI_DEVICE_PATH *dp, EFI_FILE_HANDLE *fh)
 {
        EFI_DEVICE_PATH *file_dp = dp;
@@ -373,9 +461,12 @@ open_file(EFI_DEVICE_PATH *dp, EFI_FILE_HANDLE *fh)
        rc = uefi_call_wrapper(BS->LocateDevicePath, 3, &sfsp, &file_dp,
                               &device);
        if (EFI_ERROR(rc)) {
-               Print(L"%a:%a():%d: Could not locate device handle: %r\n",
-                             __FILE__, __func__, __LINE__, rc);
-               return rc;
+               rc = search_file(&file_dp, &device);
+               if (EFI_ERROR(rc)) {
+                       Print(L"%a:%a():%d: Could not locate device handle: %r\n",
+                                     __FILE__, __func__, __LINE__, rc);
+                       return rc;
+               }
        }

        if (DevicePathType(file_dp) != MEDIA_DEVICE_PATH ||
@@ -752,6 +753,11 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *systab)
                return rc;
        }

+       if (debugging) {
+               Print(L"Applying the capsules ...\n");
+               uefi_call_wrapper(BS->Stall, 1, 10000000);
+       }
+
        /*
         * Step 4: apply the capsules.
         */

If fwupdate employs USB key to execute capsule update, the generated device path is valid. However, the fwupdate.efi will report open_file() fails. With the patch above, USB key also works well.

Here are the dumps for USB key as ESP

# hexdump -C fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416 
00000000  07 00 00 00 07 00 00 00  ed 14 f6 e0 82 fb 7a 46  |..............zF|
00000010  a3 4e 71 17 2c c0 7e 4d  00 00 00 00 00 00 00 00  |.Nq.,.~M........|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 01 00 00 00  04 01 2a 00 01 00 00 00  |..........*.....|
00000040  00 08 00 00 00 00 00 00  00 00 04 00 00 00 00 00  |................|
00000050  89 8c c8 59 00 00 00 00  00 00 00 00 00 00 00 00  |...Y............|
00000060  01 01 04 04 46 00 5c 00  45 00 46 00 49 00 5c 00  |....F.\.E.F.I.\.|
00000070  64 00 65 00 6c 00 6c 00  5c 00 66 00 77 00 5c 00  |d.e.l.l.\.f.w.\.|
00000080  66 00 77 00 75 00 70 00  64 00 61 00 74 00 65 00  |f.w.u.p.d.a.t.e.|
00000090  2d 00 37 00 45 00 42 00  36 00 6c 00 31 00 2e 00  |-.7.E.B.6.l.1...|
000000a0  63 00 61 00 70 00 00 00  7f ff 04 00              |c.a.p.......|
000000ac
# hexdump -C BootNext-8be4df61-93ca-11d2-aa0d-00e098032b8c 
00000000  07 00 00 00 00 00                                 |......|
00000006
# hexdump -C Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c 
00000000  07 00 00 00 01 00 00 00  60 00 4c 00 69 00 6e 00  |........`.L.i.n.|
00000010  75 00 78 00 20 00 46 00  69 00 72 00 6d 00 77 00  |u.x. .F.i.r.m.w.|
00000020  61 00 72 00 65 00 20 00  55 00 70 00 64 00 61 00  |a.r.e. .U.p.d.a.|
00000030  74 00 65 00 72 00 00 00  04 01 2a 00 01 00 00 00  |t.e.r.....*.....|
00000040  00 08 00 00 00 00 00 00  00 00 04 00 00 00 00 00  |................|
00000050  89 8c c8 59 00 00 00 00  00 00 00 00 00 00 00 00  |...Y............|
00000060  01 01 04 04 32 00 5c 00  45 00 46 00 49 00 5c 00  |....2.\.E.F.I.\.|
00000070  64 00 65 00 6c 00 6c 00  5c 00 66 00 77 00 75 00  |d.e.l.l.\.f.w.u.|
00000080  70 00 64 00 61 00 74 00  65 00 2e 00 65 00 66 00  |p.d.a.t.e...e.f.|
00000090  69 00 00 00 7f ff 04 00                           |i.......|
00000098

The picture attached shows how the patch works (note that the picture is captures recently so it doesn't match the name of capsule file shown in the dumps):

Some IBV UEFI implementations will overwrite BootNext if not in BootOrder

It's been brought to my attention that some UEFI implementations will potentially overwrite any Boot#### variables that are not present in BootOrder during bootup.

Because of this, we've seen some scenarios that entries are overwritten by built-in entries as the UEFI boot manager would reshuffle them on boot-up. Putting the entries into BootOrder will prevent this from happening.

So I'd to propose that fwupdate does the following:

In the Linux application

Continue to place the entry in BootNext
Also place the entry in BootOrder (but at the end)

In the EFI application

Detect which Boot#### entry is currently assigned to fwupdate
Remove that Boot#### entry
Modify BootOrder to also remove that entry number.

The net result should be that whenever a FW update is staged the entry will be created and placed in the BootOrder. This should allow it to also show up in the one time boot menu.

When the update has ran (successfully or not) the entry would be cleaned up and not show in one time boot menu.

A future capsule update would perform the same steps again.

fwupdate should provide a display capsule

fwupdate should provide a rasterized text image capsule, so that the firmware's message can be localized the same as the OS.

We need a couple of things for this:

how do we pick which locale to rasterize into
what should it say?
what are the dimensions it needs to fit in, what resolution, etc.
how do we rasterize it :)

fwupdate needs to support abbreviated device paths in its control variables.

We need to support HD() abbreviated paths plus any of the networking ones.

This would have stopped #4 from having any effect.

help to "unharcode" paths for gnu-efi-lib to make fwupdate build in other distros

Not sure if this because fwupdate is not taking pkgconfig corretly or because the patch is hardcoded but make call /usr/lib/gnuefi//crt0-efi-ia32.o wich is different in some distros.
In Arch (yeah, I'm trying to make a MAKEPKG for fwupdate for Arch) the path for crt0-efi-ia32.o in gnu-efi-lib is simply usr/lib/crt0-efi-ia32.o

gnu-efi in arch only have this setup therefor I can build fwupdate (from git) without seed magic, but that is plain wrong, so, some hints help?

Canonical mini-audit

This isn't the full security audit we need - and in fact doesn't include the most important efi/ bits at all - but here's a list of stuff from https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1508926/comments/1 that should get addressed:

fwup_strerror_r() has unreachable statements, looks very buggy. Needs
rewrite. Fixed in 1e5a93f
fwup_set_up_update() calls free(relpath) after calling relpath =
onstack(relpath,...). This is a severe error. fixed in e3b443d
fwup_set_up_update() calls open(O_CREAT) without specifying permissions,
the permissions will be set to garbage Fixed in d9981cd
~~fwup_set_up_update() fullpath memory leak via open(fullpath...) error~~ fixed in e3b443d
~~fwup_set_up_update() mkostemps() call does not need O_CREAT or O_RDWR~~ fixed in 70fb117
fwup_set_up_update() nested read()/write() loop is intricate; stdio.h
fgetc() and fputc() loop with final fflush() might be easier to reason
about and probably no less efficient. Fixed in 05c0697
fwup_set_up_update() probably needs a rewrite -- it is doing too much
and its memory management is too confused which leads to a severe bug. basically done in e3b443d
extensive use of stack for storage; is stack able to handle the largest
EFI variables? As of cf40972, within libfwup we only use the stack for short lived file paths.
put_info() does ssize_t arithmetic without checking for overflows -- how
large will efidp_size() ever grow? Fixed in cf40972
get_info() free(local) may be called on uninitialized pointer if
efi_get_variable() returns success but data_size < sizeof(*local) Fixed as part of 1e5a93f (woops)
~~fwup_resource_iter_create() memory leak if opendir() or dirfd() fail~~ Fixed in 389787c
~~utf8len() and ucs2len() handle limit=0 differently, > vs >=~~ fixed in 49746a9
utf8len() may read beyond the end of a malformed utf8 string that is
shorter than limit Not fixed; this is used only by utf8_to_ucs2(). See below.
utf8_to_ucs2() may read beyond the end of a malformed utf8 string that
is shorter than max or may read beyond the end of utf8+max. not fixed - this is used entirely on file paths that we're reasonably sure are not malformed.
print_system_resources() and main() have user-visible strings that aren't
localized Fixed in 87c7d60
~~delete_variable() contains unreachable code, is this a patch failure?~~ Doesn't appear to be true in any code I have...
All the signed files are signed by 'Red Hat Test Certificate" -- is this
suitable for deployment? No, no it's not.

Fail to reboot into Ubuntu after successful update

I triggered the update with Gnome Software on Ubuntu 17.10. Gnome Software asked me to restart, I click restart. During boot, the update starts correctly, and succeeds. After it succeeds, the laptop boots back into fwupd, which fails with the following error:

found update fwupdate-49w03513-7afe-49a-9d03-89e5ba1da865-0
fwupdate: No updates to process. Called in error?
start_image() returned Invalid Parameter

After a few seconds, it shows another screen:

No bootable devices found.
Press F1 key to retry boot.
Press F2 key to reboot into setup.
Press F5 key to run onboard diagnostics.

Help, I've got this issue too and I can't boot!

I was able to workaround the issue by going into setup, general > Boot Sequence, and adding grub64.efi back as primary boot option.

Picture walkthrough:

When you see this message, press F2 to enter the UEFI/BIOS setup.

Once in the setup, go to general > Boot Sequence.

Click Add boot option.

Call the boot option "Ubuntu" and click the three dots behind "filename".

Choose the "grubx64.efi" file, click OK and add the boot option.

Now use the arrows to put the "Ubuntu" boot option to the top.

Save and exit, reboot and Ubuntu boots as normal!

Clean rule doesn't remove libfwup.so

I've noticed I can't run a make clean and have everything cleaned up.

This patch resolves the issue:

From 69162bf038954777b62599602e69d308a63cf3e1 Mon Sep 17 00:00:00 2001
From: Mario Limonciello <[email protected]>
Date: Thu, 4 Jun 2015 18:50:14 -0500
Subject: [PATCH] In clean rule, remove libfwup.so

Github issue: https://github.com/rhinstaller/fwupdate/issues/2

Signed-off-by: Mario Limonciello <[email protected]>

---
 linux/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux/Makefile b/linux/Makefile
index ed47fe1..ca4072c 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -68,7 +68,7 @@ test : tester
        LD_LIBRARY_PATH=$(shell pwd) ./tester

 clean :
-       @rm -vf $(BINTARGETS) $(LIBTARGETS) $(PCTARGETS) $(POTARGETS) *.o
+       @rm -vf $(BINTARGETS) $(LIBTARGETS) $(PCTARGETS) $(POTARGETS) *.o libfwup.so

 install : all
        $(INSTALL) -d -m 755 $(DESTDIR)/$(libdir)
--
1.9.1

Please support linking with CC rather than LD

efi/Makefile tries to prepare .so files by linking using $(LD), which breaks here.

Some distributions may set LDFLAGS with -Wl parameters intended for linking through $(CC).

For instance, in Ubuntu we set -Wl,-Bsymbolic-functions, which breaks linking because $(LD) will refuse to parse those directly -- it should be just -Bsymbolic-functions.

This should work properly if linking via $(CC), passing the -shared parameter like so:
$(CC) $(LDFLAGS) -shared -o $@ $^ -lefi -lgnuefi \

rather than:
$(LD) $(LDFLAGS) -o $@ $^ -lefi -lgnuefi \

Thanks!

fwupdate should include a --version option

At least encode the last tagged version or git hash it was built with

fwupdate needs to keep a debug log and dump it on error

FTBFS with new release

During make on ArchLinux:

gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DFWUPDATE_HAVE_LIBSMBIOS__ -Wall -Wextra -Werror -Wno-error=cpp -Wno-unused-result -Wno-unused-function -Wsign-compare -Werror=sign-compare -fshort-wchar --std=gnu11 -DLOCALEDIR=\"/usr/share/locale\" -D_GNU_SOURCE -DFWUP_EFI_DIR_NAME=\"arch\" -DFWUP_ESP_MOUNTPOINT=\""/boot/efi"\" -I include -I /build/fwupdate/src/fwupdate-10/linux/include/ -iquote /build/fwupdate/src/fwupdate-10/include/  -I/usr/include/efivar  -I/usr/include/efivar    -fPIC -c -o libfwup.o libfwup.c
xgettext -a --package-name=libfwup --package-version=10 -o libfwup.po libfwup.c
libfwup.c: In function ‘make_ux_capsule_entry’:
libfwup.c:733:30: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
  fwup_ux_capsule.esre.guid = efi_guid_ux_capsule;
                              ^~~~~~~~~~~~~~~~~~~
                              efi_guid_ux_capsule_guid
libfwup.c:733:30: note: each undeclared identifier is reported only once for each function it appears in
libfwup.c: In function ‘write_ux_capsule_header’:
libfwup.c:1648:11: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
   .guid = efi_guid_ux_capsule,
           ^~~~~~~~~~~~~~~~~~~
           efi_guid_ux_capsule_guid
libfwup.c: In function ‘fwup_set_up_update’:
libfwup.c:1795:37: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
  if (!efi_guid_cmp(&re->esre.guid, &efi_guid_ux_capsule)) {
                                     ^~~~~~~~~~~~~~~~~~~
                                     efi_guid_ux_capsule_guid
libfwup.c: In function ‘fwup_set_up_update_with_buf’:
libfwup.c:1899:37: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
  if (!efi_guid_cmp(&re->esre.guid, &efi_guid_ux_capsule)) {
                                     ^~~~~~~~~~~~~~~~~~~
                                     efi_guid_ux_capsule_guid
make[1]: *** [/build/fwupdate/src/fwupdate-10/linux/Makefile:90: libfwup.o] Error 1
make[1]: *** Waiting for unfinished jobs....

Add unconditional 5 second delay before rebooting

I think an unconditional 5 second delay before rebooting would be a really good thing to have. It's not like updating the firmware is in the fast path, and it would be reassuring to see (and read) any success or failure messages on the console.

add UEFI_GUID_IMAGE_UPLOAD to include headers

So that fwupd can use it (per a discussion somewhere in fwupd/fwupd#226)

Compiling with -02 causes failure

This is on Ubuntu 16.04 with it's current default compile flags and master. -O2 is used instead of -O0

gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fpic -Werror -Wall -Wextra -fshort-wchar -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=gnu11 -DCONFIG_x86_64 -I/usr/include/efi/ -I/usr/include/efi/x86_64/ -iquote/home/test/fwupdate/include "-DDEBUGDIR=L\"/\"" -mno-mmx -mno-sse -mno-red-zone -nostdinc -maccumulate-outgoing-args -DEFI_FUNCTION_WRAPPER -DGNU_EFI_USE_MS_ABI -I/usr/lib/gcc/x86_64-linux-gnu/5/include -c -o fwupdate.o fwupdate.c
fwupdate.c: In function ‘open_file’:
fwupdate.c:584:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  UINTN sz = *(UINT16 *)file_dp->Length - 4;
  ^
cc1: all warnings being treated as errors
Makefile:90: recipe for target 'fwupdate.o' failed

These were masked previously but 84dae17 added -Werror so this causes a failure now.

Support for HP

I currently have a HP Pavilion g7 and I was wondering if there was any way to get updated BIOS?

fwupdate called in error, work laptop unbootable

I've originally reported this over at fwupd/fwupd#152 and with continued research think this is a better place for it.

I've applied two firmware updates using gnome software centre, but now the laptop is unbootable. How can I fix this?

Nothing happens when running fwupdate or fwupdmgr on Dell XPS 15 9560

I recently purchased a Dell XPS 15 9560 and the BIOS version is 0.1.3.4 instead of the current 0.1.4.0 version. I have been trying to run fwupdate/ fwupdmgr to update the BIOS but running it does not seem to do anything

OS: Arch Linux
Kernel: 4.12.12-1-ARCH
fwupdmgr: 0.9.7
efivars: 31-1
efibootmgr: version 15

$ sudo efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001
Boot0000  Windows Boot Manager
Boot0001* Grub
Boot0002* grub
Boot0008  WindowsIns

This does not change upon calling fwupdate or fwupdmgr (no entry for Linux-Firmware-Updater is created)
When running the update commands it will download the correct package and does not seem to exit with any error however nothing happens, upon calling the commands again after it will say that the device already has an update scheduled

Output:

$ sudo fwupdmgr update -v
Downloading 0.1.4.0 for XPS 15 9560 System Firmware...
(fwupdmgr:10145): Fu-DEBUG: creating path /root/.cache/fwupdmgr
(fwupdmgr:10145): Fu-DEBUG: skpping download as file already exists
Updating 0.1.4.0 on XPS 15 9560 System Firmware...
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [decompressing]
Decompressing…         [-                                       ]
Decompressing…         [ -                                      ]
Decompressing…         [  -                                     ]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [idle]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [scheduling]
Scheduling…            [   -                                    ]
Retrying as an offline update...
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [decompressing]
Decompressing…         [   -                                    ]
Decompressing…         [    \                                   ]
Decompressing…         [     \                                  ]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [idle]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [scheduling]
Scheduling…            [      \                                 ]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [idle]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::device-changed((null))
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::changed()

Note: This did not print correctly on my terminal, I had to pipe it to a file and delete H^ strings in vim

Output fwupdmgr get-devices:

$ sudo fwupdmgr get-devices
Intel AMT (unprovisioned)
  DeviceID:             /dev/mei
  Guid:                 2800f812-b7b4-2d4b-aca8-46e0ff65814c
  Plugin:               amt
  Flags:                internal|registered
  Version:              11.6.29
  VersionBootloader:    11.6.29
  Created:              2017-09-14

XPS 15 9560 TPM 2.0
  DeviceID:             DELL-bc891321-25aa-54f6-86e7-633d065b8d5dlu
  Guid:                 bc891321-25aa-54f6-86e7-633d065b8d5d
  Plugin:               dell
  Flags:                internal|updatable|require-ac|supported|registered|needs-reboot
  Version:              1.3.1.0
  Created:              2017-09-14

XPS 15 9560 TPM 1.2
  DeviceID:             DELL-c5e6d7ef-4270-54bf-af0f-8b8ef2a561e6lu
  Guid:                 c5e6d7ef-4270-54bf-af0f-8b8ef2a561e6
  Plugin:               dell
  Flags:                internal|require-ac|locked|registered
  Created:              2017-09-14

XPS 15 9560 System Firmware
  DeviceID:             UEFI-34578c72-11dc-4378-bc7f-b643866f598c-dev0
  Guid:                 34578c72-11dc-4378-bc7f-b643866f598c
  Description:          <p>Updating the system firmware improves performance.</p>
  Plugin:               uefi
  Flags:                internal|updatable|require-ac|supported|registered|needs-reboot
  Version:              0.1.3.4
  VersionLowest:        0.1.3.4
  Created:              2017-09-14

Integrated Webcam HD
  DeviceID:             usb:00:0c
  Guid:                 4c03e6af-b94c-5c18-8689-e77ceadbe524
  Guid:                 fb0df457-b15e-5d4a-b73a-8491dca96a07
  Plugin:               usb
  Flags:                registered
  DeviceVendorId:       USB:0x0C45
  Version:              86.5
  Created:              2017-09-14

GP107M [GeForce GTX 1050 Mobile]
  DeviceID:             ro__sys_devices_pci0000_00_0000_00_01_0_0000_01_00_0
  Guid:                 37921484-dff0-57a0-b7dd-4cd6a82b54a1
  Plugin:               udev
  Flags:                internal|registered
  DeviceVendor:         NVIDIA Corporation
  DeviceVendorId:       PCI:0x10DE
  Created:              2017-09-14

Unknown Device
  DeviceID:             ro__sys_devices_pci0000_00_0000_00_02_0
  Guid:                 3ab5fe9e-bef7-5421-920a-ef7301884933
  Plugin:               udev
  Flags:                internal|registered
  DeviceVendor:         Intel Corporation
  DeviceVendorId:       PCI:0x8086
  Created:              2017-09-14

The XPS 15 9560 System Firmware with GUID: 34578c72-11dc-4378-bc7f-b643866f598c is the device which requires updating

And applying it manually through fwupdate outputs this:

$ sudo fwupdate -a 34578c72-11dc-4378-bc7f-b643866f598c ~/.cache/fwupdmgr/5b8e9cbc79dd4f37df0f792196f246d9b7da1e0d-firmware_XPS_9560_1_4_0.wu.cab -v
Could not set up firmware update: No such file or directory
error trace:
efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-34578c72-11dc-4378-bc7f-b643866f598c-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-34578c72-11dc-4378-bc7f-b643866f598c-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
libfwup.c:1194 get_fd_and_media_path(): failed to make /boot/efi/EFI/arch/fw: No such file or directory

If I have missed any important information please let me know and I will provide the details

MINOR_VERSION needs to be incremented to at least 5

Due to this change in fwupd:
fwupd/fwupd@a941c3a

MINOR_VERSION will need to be incremented to at least 5 to let fwupd still continue to compile.

Discussion: Automatic ESP discovery/management of boot assets

Following up on Richard's request to bring the G+ discussion to the tracker.

I would like to start a discussion around the packaging of assets in /boot, as well as dynamic discovery of where /boot really is.

Specifically, in Solus packaging, it is illegal for any package to ship files in /boot. For UEFI systems we automatically mount the ESP to /boot using the freedesktop bootloader specification (as we use systemd-boot), perform any updates, sync, and unmount again. With that said we'll automatically discover if /boot is actually mounted (i.e. getmntent) and leave it mounted if this is how the users system is configured.

In an ideal world, fwupdate would automatically discover the ESP, and as appropriate push the blobs (safely + sanely) into the ESP, respecting the various plagues of issues known to FAT on Linux (case ignorance, atomic writes, dangers of overwriting, requirement to sync) to facilitate integration with standard update procedures.

For an example of interacting with the freedesktop bootloader specification, please see the clr-boot-manager work. Note even in clr-boot-manager we still looked to see if the ESP was mounted at /boot (simple example) to locate a valid boot mount before falling back to var probing (because as we all know, firmware can and will suck.)

So in short, if approved, I'd like to implement:

Automatic failsafe ESP discovery to alleviate per-distro configuration differences
Sane and safe ESP blitting of the PE32 blobs
By default the removal of the PE32 blobs from the default packaging.

Before I go gung-ho on writing code, I'd like to see a conversation around this so its either rejected/approved, but either way, everyone would at least be on the same page. Cheers!

Allow bypass get_existing_media_path

Hello,
My ESP is mounted as /boot:

max@host % tree /boot
/boot
├── EFI
│   ├── Boot
│   │   └── …
│   ├── Dell
│   │   └── …
│   ├── fwupdate
│   │   ├── fw
│   │   │   └── fwupdate-30cdyM.cap
│   │   └── fwupx64.efi
│   └── systemd
│       └── …
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── loader
│   ├── entries
│   │   ├── arch.conf
│   │   ├── arch-fallback.conf
│   │   └── arch-save.conf
│   └── loader.conf
└── vmlinuz-linux

EFIDIR is set to "fwupdate" (as show on the tree above).

To make fwupdate work I had to apply the following patch since the ESP mount point is currently hardcoded (see #(58)) :

max@mde-oxalide % diff -Naur fwupdate-8/linux/libfwup.c aaa/linux/libfwup.c                               
--- fwupdate-8/linux/libfwup.c  2016-08-19 17:03:59.000000000 +0200
+++ aaa/linux/libfwup.c 2017-02-19 15:28:29.726339752 +0100
@@ -688,8 +688,8 @@
 {
        int ret = -1;

-       char shim_fs_path_tmpl[] = "/boot/efi/EFI/"FWUP_EFI_DIR_NAME"/shim";
-       char fwup_fs_path_tmpl[] = "/boot/efi/EFI/"FWUP_EFI_DIR_NAME"/fwup";
+       char shim_fs_path_tmpl[] = "/boot/EFI/"FWUP_EFI_DIR_NAME"/shim";
+       char fwup_fs_path_tmpl[] = "/boot/EFI/"FWUP_EFI_DIR_NAME"/fwup";
        uint8_t fwup_esp_path_tmpl[] = "\\fwup";

        char *shim_fs_path_tmp = NULL;
@@ -1059,7 +1059,7 @@
        untilt_slashes(relpath);

        /* build a complete path */
-       rc = asprintf(&fullpath, "/boot/efi%s", relpath);
+       rc = asprintf(&fullpath, "/boot%s", relpath);
        if (rc < 0)
                fullpath = NULL;

@@ -1097,7 +1097,7 @@
        } else {
                /* fall back to creating a new file from scratch */
                rc = asprintf(&fullpath,
-                             "/boot/efi/EFI/%s/fw/fwupdate-XXXXXX.cap",
+                             "/boot/EFI/%s/fw/fwupdate-XXXXXX.cap",
                              FWUP_EFI_DIR_NAME);
                if (rc < 0) {
                        efi_error("asprintf failed");

But it wasn't sufficient, I also had to bypass the get_existing_media_path function as the one which fwupdate try to use wasn't the /boot/EFI/fwupdate/….

Can you add an option to make it more easy to bypass get_existing_media_path ?

Regards

Explicit dependencies on libraries missing

This issue is in similar vain to rhboot/efivar#20.

I've noticed that the fwupdate build process isn't explicitly linking to libraries containing functions necessary for use. This causes problems when building on Ubuntu.

gcc -g -O0 -Wall -Wno-unused-result -Wno-unused-function -Wsign-compare -Werror=sign-compare -fshort-wchar --std=c11 -DLOCALEDIR=\"/usr/share//locale/\" -D_GNU_SOURCE -DFWUP_EFI_DIR_NAME=\"Ubuntu\" -I/home/supermario/src/efi-fw-packages/fwupdate/linux/include -iquote/home/supermario/src/efi-fw-packages/fwupdate/include/  -I/usr/include/efivar    -I/usr/include/efivar    -lpopt -lpthread  -ldl -lefivar    -ldl -lefivar -lefiboot   -pie -fPIE -Wl,-z,relro,-z,now -L. -o fwupdate fwupdate.o -lfwup
fwupdate.o: In function `efi_guid_is_zero':
/usr/include/efivar/efivar.h:141: undefined reference to `efi_guid_zero'
fwupdate.o: In function `print_system_resources':
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:96: undefined reference to `efi_guid_to_id_guid'
fwupdate.o: In function `main':
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:132: undefined reference to `poptAliasOptions'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:132: undefined reference to `poptHelpOptions'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:151: undefined reference to `poptGetContext'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:154: undefined reference to `poptReadDefaultConfig'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:156: undefined reference to `poptStrerror'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:156: undefined reference to `poptBadOption'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:159: undefined reference to `poptGetNextOpt'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:164: undefined reference to `poptGetArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:167: undefined reference to `poptPrintUsage'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:170: undefined reference to `efi_str_to_guid'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:174: undefined reference to `poptGetArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:178: undefined reference to `poptPrintUsage'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:185: undefined reference to `poptStrerror'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:185: undefined reference to `poptBadOption'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:188: undefined reference to `poptPeekArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:189: undefined reference to `poptPeekArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:194: undefined reference to `poptPrintUsage'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:197: undefined reference to `poptFreeContext'
./libfwup.so: undefined reference to `efi_loadopt_is_valid'
./libfwup.so: undefined reference to `efidp_make_generic'
./libfwup.so: undefined reference to `efi_generate_file_device_path'
./libfwup.so: undefined reference to `efi_guid_global'
./libfwup.so: undefined reference to `efi_loadopt_create'
./libfwup.so: undefined reference to `efi_loadopt_path'
./libfwup.so: undefined reference to `efi_get_next_variable_name'
./libfwup.so: undefined reference to `efi_set_variable'
./libfwup.so: undefined reference to `efi_loadopt_pathlen'
./libfwup.so: undefined reference to `efi_get_variable'
./libfwup.so: undefined reference to `efi_loadopt_attr_set'
./libfwup.so: undefined reference to `efi_guid_to_str'
collect2: error: ld returned 1 exit status
make[3]: *** [fwupdate] Error 1

There's a few errors here.

fwupdate needs to link with BIN_LIBS (popt and pthread)
fwupdate also needs a dependency on efivar for it's usage of efi_str_to_guid
libfwup.so.$(VERSION) needs to link with efivar and efiboot for it's usage of various efi_ functions.

build fails with `-Werror -Wextra`

@vathpela added these strict compile flags recently, but they actually cause the build to fail, on Fedora Rawhide at least. Here's a build of current git master on Fedora Rawhide:

https://kojipkgs.fedoraproject.org//work/tasks/2875/15232875/build.log

gcc -O0 -g3 -fpic -Werror -Wall -Wextra -fshort-wchar -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=gnu11 -DCONFIG_ia32 -I/usr/include/efi/ -I/usr/include/efi/ia32/ -iquote/builddir/build/BUILD/fwupdate-0.5/include "-DDEBUGDIR=L\"/\"" -mno-mmx -mno-sse -mno-red-zone -nostdinc -maccumulate-outgoing-args -m32 -I/usr/lib/gcc/i686-redhat-linux/6.1.1/include -c -o fwupdate.o fwupdate.c
fakeesrt.c: In function 'efi_main':
fakeesrt.c:50:14: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
  VOID *ptr = (VOID *)mem;
              ^
fwupdate.c: In function 'allocate':
fwupdate.c:74:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
  *addr = (void *)pageaddr;
          ^
In file included from /usr/include/efi/efi.h:35:0,
                 from fwupdate.c:11:
fwupdate.c: In function 'free':
fwupdate.c:87:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
  rc = uefi_call_wrapper(BS->FreePages, 2, (EFI_PHYSICAL_ADDRESS)addr,
                                           ^
/usr/include/efi/ia32/efibind.h:283:51: note: in definition of macro 'uefi_call_wrapper'
 #define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__)
                                                   ^~~~~~~~~~~
fwupdate.c: In function 'apply_capsules':
fwupdate.c:753:11: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
           (EFI_PHYSICAL_ADDRESS)(VOID *)cbd);
           ^
/usr/include/efi/ia32/efibind.h:283:51: note: in definition of macro 'uefi_call_wrapper'
 #define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__)
                                                   ^~~~~~~~~~~
cc1: all warnings being treated as errors
Makefile:92: recipe for target 'fakeesrt.o' failed

Before the commit to add -Werror -Wextra, the same warnings are present but they do only act as warnings and the compile succeeds.

fwup-version.h is broken

It's got #define LIBFWUP_VERSION (@FWUP_VERSION@) as in, it installs it into /usr/include without replacing the @FWUP_VERSION@ string with the actual version.

libfwup and fwupdate.efi need FMP support.

In order to support updating multiple PCI-style peripheral cards of the same model independently, and really to support PCI cards at all, we need to be able to express which FMP entry should be updated in the fwupdate EFI variables, and fwupdate.efi needs to know to use FMP with those updates.

When adding entry, should use efi_guid_global, not *guid

In trying to debug #4, I was walking through the code and found an inconsistency for adding Boot#### variables compared to efibootmgr.

Variables are getting added using the same GUID that corresponds to BootNext rather than the EFI Global GUID.

This patch fixes the behavior (and entries start to show up in efibootmgr):

commit e632b671466df50da60213493fd81aebba7f527b
Author: Mario Limonciello <[email protected]>
Date:   Fri Jul 10 13:52:00 2015 -0500

    When adding a Boot#### entry it should be the global GUID not the GUID
    that was found for the BootNext variable.

diff --git a/linux/libfwup.c b/linux/libfwup.c
index 860505d..0ccd88e 100644
--- a/linux/libfwup.c
+++ b/linux/libfwup.c
@@ -694,7 +694,7 @@ do_next:
                        goto out;

                sprintf(boot_next_name, "Boot%04X", boot_next);
-               rc = efi_set_variable(*guid, boot_next_name, opt, opt_size,
+               rc = efi_set_variable(efi_guid_global, boot_next_name, opt, opt_size,
                                      EFI_VARIABLE_NON_VOLATILE |
                                      EFI_VARIABLE_BOOTSERVICE_ACCESS |
                                      EFI_VARIABLE_RUNTIME_ACCESS);

Lenovo Thinkpad T460s FW update fails

Is there any public documentation on how to update a Lenovo (Thinkpad) UEFI with fwupdate?

The vendorlist show it as supported.
Also my Firmware update release notes mention fixes in the WUFU compatability.
Furthermore the update package from Lenovo itself contains strings that indicate that some sort of support should exist:

Found fwupdate variable, set as Linux WUFU (fwupd) triggered capsule update.
Delete fwupdate variable successfully.

However I could not find any public documentation about this.

Sorry if this was the wrong place to ask.

fwupdate needs to be able to find its files on tftp and http

so diskless systems can work.

fwupx64.efi stopped working on Dell Precision 5510 after overflow changes

fwupdate 0.5 was working properly on this system.
I bisected:

git bisect start
# bad: [c5fabccbea56e8c9f99efafe5c985c854e110513] fwupdate: Use libsmbios_c.pc instead of manually writing our command line.
git bisect bad c5fabccbea56e8c9f99efafe5c985c854e110513
# good: [03178919675d277178dc50c7c8941a9fd91e98ef] Release 0.5
git bisect good 03178919675d277178dc50c7c8941a9fd91e98ef
# good: [03178919675d277178dc50c7c8941a9fd91e98ef] Release 0.5
git bisect good 03178919675d277178dc50c7c8941a9fd91e98ef
# bad: [742ebb4ef1676467a36b846b9cd54b0a3b6d9756] Make our CFLAGS even meaner.
git bisect bad 742ebb4ef1676467a36b846b9cd54b0a3b6d9756
# good: [827a9dc84c4f1f866982b38b1c0a77abb2265754] fwupdate: support showing the info of fwupdate status variable
git bisect good 827a9dc84c4f1f866982b38b1c0a77abb2265754
# bad: [3674fec025e5be54e91ff14c26c67f5c1293da9f] efi: document our use of UINTN vs INTN comparison in get_info()
git bisect bad 3674fec025e5be54e91ff14c26c67f5c1293da9f
# bad: [47f65e83dda4ea558b13d6bd3eb0fab7e5005a93] efi: check for size overflow in read_file()
git bisect bad 47f65e83dda4ea558b13d6bd3eb0fab7e5005a93
# good: [172f8b3d5d3a2b103b5dc9bd502ade6296e3294d] efi: Get rid of -fno-strict-aliasing
git bisect good 172f8b3d5d3a2b103b5dc9bd502ade6296e3294d
# first bad commit: [47f65e83dda4ea558b13d6bd3eb0fab7e5005a93] efi: check for size overflow in read_file()

The results yielded two commits causing problems
1st: 47f65e8
2nd: a49f4ff

With both commits applied, this is the error received:

fwupdate.c:find_updates();290: would overflow size
fwupdate: Couldnot find updates: Out of Resources

With a49f4ff reverted, this is the error received:

Found update fwupdate-*
Update "fwupdate-*" has an invalid file path
update info size 172 dp size: 120 size for dp: 52
Could not get update info for "fwupdate-*", aborting
fwupdate: Could not find updates: Invalid Paramater

Reverting both isn't enough to resolve the problem, so bc3f523
probably needs to be removed too and there is definitely systemic about this overflow detection
wrong on this system. FWIW running the same fwupx64.efi binary in Virtualbox through EFI shell
reproduces the issues too.

Make.defaults hardcodes to "redhat"

This can be detected via lsb_release instead, which should make it more flexible to out of the box compiles on other OSes.

commit 971ff735adf93064e47af49a2195ea201bd043ae
Author: Mario Limonciello <[email protected]>
Date:   Mon Feb 29 10:32:58 2016 -0600

    Use lsb_release to detect EFIDIR instead of hardcoding

diff --git a/Make.defaults b/Make.defaults
index 912a893..59b4379 100644
--- a/Make.defaults
+++ b/Make.defaults
@@ -36,7 +36,7 @@ localedir     ?= $(datadir)/locale/
 libexecdir     ?= $(prefix)libexec/
 libdatadir     ?= $(prefix)lib/

-EFIDIR         ?= redhat
+EFIDIR         ?= $(lsb_release -s -i | tr A-Z a-z)
 DEBUGINFO      ?= $(prefix)lib/debug/
 DEBUGSOURCE    ?= $(prefix)src/debug/
 TARGETDIR      ?= /boot/efi/EFI/$(EFIDIR)/

fwupdate 8 depends upon nonexistant version 28 of efivar

commit c3429b2 changed the version of efivar that was required to 28, but this doesn't currently exist (even master for efivar is at 27: rhboot/efivar@1429d89)

Add tag for version 10

9669ab0 mentions a bump to version 10, but it was never tagged. Can you add a tag?

fwupdate paths should be arch specific

the path to fwupdate.efi needs to be arch specific, and we need to determine the correct arch at /runtime/ for things like baytrail.

git master fails to build: missing parameter to open at libfwup.c:820

I think the open() at line 820 in libfwup.c is missing a 0 (or some other mode) as third parameter.

make[3]: Leaving directory '/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/efi'
make[3]: Entering directory '/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/linux'
gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-unused-result -Wno-unused-function -Wsign-compare -Werror=sign-compare -fshort-wchar --std=c11 -DLOCALEDIR="/usr/share//locale/" -D_GNU_SOURCE -DFWUP_EFI_DIR_NAME="ubuntu" -I/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/linux/include -iquote/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/include/ -I/usr/include/efivar -I/usr/include/efivar -fPIC -c -o libfwup.o libfwup.c
In file included from /usr/include/fcntl.h:279:0,
from util.h:14,
from libfwup.c:27:
In function ‘open’,
inlined from ‘get_fd_and_media_path’ at libfwup.c:820:6:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments
__open_missing_mode ();
^
libfwup.c: In function ‘fwup_set_up_update’:
libfwup.c:1007:2: warning: ‘offset’ may be used uninitialized in this function [-Wmaybe-uninitialized]
lseek(infd, offset, SEEK_SET);
^
Makefile:59: recipe for target 'libfwup.o' failed

Something like this should do the trick:

linux/libfwup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/linux/libfwup.c

--- a/linux/libfwup.c
+++ b/linux/libfwup.c
@@ -817,7 +817,7 @@ get_fd_and_media_path (update_info *info
* littering the filesystem with old updates */
fullpath = fwup_get_existing_media_path (info);
if (fullpath) {

  fd = open(fullpath, O_CREAT|O_TRUNC|O_CLOEXEC|O_RDWR);

  fd = open(fullpath, O_CREAT|O_TRUNC|O_CLOEXEC|O_RDWR, 0);
if (fd < 0) {
    warn("open of %s failed", fullpath);
    goto out;

libfwupdate needs to be able to read the IEIT

We need to be able to tell if for some reason fwupdate did not get run, and IEIT will tell us that.

fwupdate-* variables can't be modified or removed in newer kernels

Since torvalds/linux@ed8b0de has been made, the fwupdate-* variable can no longer be deleted automatically from https://github.com/rhinstaller/fwupdate/blob/master/linux/cleanup.in

This causes problems on a fresh install with a new kernel that contains this patch but also contains an old fwupdate-* variable that is supposed to be cleaned up.

I suspect that the variable being immutable will also prevent fwupdate from updating the variable too, but haven't confirmed this.

Prints an error about finding SHIM_DEBUG when run

When running with an update to apply, fwupdate.efi prints an error on screen just above it's "Found fwupdate-..." message:

'Could not get variable "SHIM_DEBUG": Not Found'

Ideally there shouldn't be any error message printed on screen before running the update; otherwise users might think there is an issue.

Got double checksum for update

I had a failure installing firmware update 0.2.2.1:
https://bugzilla.redhat.com/show_bug.cgi?id=1506609

Now there is a 0.2.3.1 update available, but it tries to use the old checksum for it:

XPS 13 9360 System Firmware has firmware updates:
ID:                      com.dell.uefi5ffdbc0d.firmware
GUID:                    5ffdbc0d-f340-441c-a803-8439c8c0ae10
Update Version:          0.2.3.1
Update Remote ID:        lvfs
Update Checksum:         SHA1(52b875e4eab8bf4c384861b9cd878c62e8fc899f)
Update Checksum:         SHA1(18d9501fc82e8c39acb57693e2c6ad60a2712f9a)
Update Location:         https://fwupd.org/downloads/6fd391badc79a4d9a2c9916073f6941f885a22fd-firmware_XPS_9360_2_3_1.cab

rhboot / fwupdate Goto Github PK

fwupdate's People

Contributors

Stargazers

Watchers

Forkers

fwupdate's Issues

Help, I've got this issue too and I can't boot!

Something like this should do the trick:

Index: b/linux/libfwup.c

Recommend Projects

Recommend Topics

Recommend Org