Bug#776999: broken 32-bit userland on 64-bit kernel
On Wed, Feb 04, 2015 at 04:57:52PM -0600, Adam Borowski wrote: On Wed, Feb 04, 2015 at 04:48:23PM -0600, D. Jared Dominguez wrote: On Tue, Feb 03, 2015 at 04:40:16PM -0600, Adam Borowski wrote: I'm not convinced that this doesn't break the use case in #773412 [1] since you're looking to define the type at compile-time[2], and that's precisely why #773412 came about. We'll end up replacing a bug in an unofficial port for a bug in an official port. If I read that correctly, #773412 fixed i386 on an i386 kernel. As you can see in the dumps above, i386 userland on an amd64 kernel receives a 32-bit field rather than 64-bit that patch wants. It's for 32-bit efivar/efibootmgr on 64-bit kernel with 32-bit UEFI (which is why 32-bit efithings are used). -- Jared Domínguez Infrastructure Software Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776999: broken 32-bit userland on 64-bit kernel
On Wed, Feb 04, 2015 at 05:54:41PM -0600, Dominguez, Jared wrote: On Wed, Feb 04, 2015 at 05:40:28PM -0600, Adam Borowski wrote: On Wed, Feb 04, 2015 at 05:36:06PM -0600, D. Jared Dominguez wrote: On Wed, Feb 04, 2015 at 05:25:59PM -0600, Adam Borowski wrote: On Wed, Feb 04, 2015 at 05:12:09PM -0600, D. Jared Dominguez wrote: On Wed, Feb 04, 2015 at 04:57:52PM -0600, Adam Borowski wrote: If I read that correctly, #773412 fixed i386 on an i386 kernel. As you can see in the dumps above, i386 userland on an amd64 kernel receives a 32-bit field rather than 64-bit that patch wants. It's for 32-bit efivar/efibootmgr on 64-bit kernel with 32-bit UEFI (which is why 32-bit efithings are used). Let's see if I understand right: a) 32-bit efivar on 64-bit kernel on 32-bit UEFI receives 64-bit fields, b) 32-bit efivar on 64-bit kernel on 64-bit UEFI receives 32-bit fields, c) 64-bit efivar on 64-bit kernel on 64-bit UEFI receives 64-bit fields. a) is claimed in the patch from Dec 17, b) and c) come in dumps I quoted. Not just claims but does. Remember that you're using the x32 ABI, which is different. While initially I found the issue on x32, the same happens on i386. I wonder how to tell these cases apart then -- both have 32-bit userland on 64-bit kernel (not just efivar, even cat gets such fields). Or perhaps I'm missing something? 32-bit efivar/efibootmgr on 64-bit kernel without x32 ABI and 32-bit UEFI. In other words, 32-bit efivar/efibootmgr on 64-bit kernel is going to get the same value from the kernel as 64-bit efivar/efibootmgr on 64-bit. With the x32 ABI, you're going to see the same value on a 64-bit kernel (through the x32 ABI) as you would see on a 32-bit kernel. So we need some way to determine not just whether the kernel 32-bit or 64-bit but if 64-bit, whether we're using the x32 ABI. -- Jared Domínguez Infrastructure Software Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776999: broken 32-bit userland on 64-bit kernel
On Tue, Feb 03, 2015 at 04:40:16PM -0600, Adam Borowski wrote: Package: efivar Version: 0.15-3 Severity: serious I'm afraid the patch 07-num_bits.patch breaks the case of 32-bit userland on a 64-bit kernel. As far as I know, this is how i386 would get installed on any non-ancient machine if d-i could get that far (it doesn't for me in qemu-kvm.x86-64, though). The bad assumption is that an 64-bit kernel would give the same data to any process. This seems to be obvious, but it's not the case: Here's a set of sample dumps of /sys/firmware/efi/vars/Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var -- all done on the same virtual machine, same kernel, same boot-up, all that differs is the ABI of the cat process: cat is amd64: 42 00 6f 00 6f 00 74 00 30 00 30 00 30 00 35 00 |B.o.o.t.0.0.0.5.| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0400 61 df e4 8b ca 93 d2 11 aa 0d 00 e0 98 03 2b 8c |a.+.| 0410 76 00 00 00 00 00 00 00 01 00 00 00 62 00 64 00 |v...b.d.| ^^^ 0420 65 00 62 00 69 00 61 00 6e 00 00 00 04 01 2a 00 |e.b.i.a.n.*.| 0430 01 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 || 0440 00 00 00 00 14 ab c8 38 14 e4 68 40 89 28 2a 27 |...8..h@.(*'| 0450 8b 45 06 d2 02 02 04 04 34 00 5c 00 45 00 46 00 |.E..4.\.E.F.| 0460 49 00 5c 00 64 00 65 00 62 00 69 00 61 00 6e 00 |I.\.d.e.b.i.a.n.| 0470 5c 00 67 00 72 00 75 00 62 00 78 00 36 00 34 00 |\.g.r.u.b.x.6.4.| 0480 2e 00 65 00 66 00 69 00 00 00 7f ff 04 00 00 00 |..e.f.i.| 0490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0820 07 00 00 00 || 0824 cat is x32: 42 00 6f 00 6f 00 74 00 30 00 30 00 30 00 35 00 |B.o.o.t.0.0.0.5.| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0400 61 df e4 8b ca 93 d2 11 aa 0d 00 e0 98 03 2b 8c |a.+.| 0410 76 00 00 00 01 00 00 00 62 00 64 00 65 00 62 00 |v...b.d.e.b.| ^^^ 0420 69 00 61 00 6e 00 00 00 04 01 2a 00 01 00 00 00 |i.a.n.*.| 0430 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 || 0440 14 ab c8 38 14 e4 68 40 89 28 2a 27 8b 45 06 d2 |...8..h@.(*'.E..| 0450 02 02 04 04 34 00 5c 00 45 00 46 00 49 00 5c 00 |4.\.E.F.I.\.| 0460 64 00 65 00 62 00 69 00 61 00 6e 00 5c 00 67 00 |d.e.b.i.a.n.\.g.| 0470 72 00 75 00 62 00 78 00 36 00 34 00 2e 00 65 00 |r.u.b.x.6.4...e.| 0480 66 00 69 00 00 00 7f ff 04 00 00 00 00 00 00 00 |f.i.| 0490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0810 00 00 00 00 00 00 00 00 07 00 00 00 || 081c cat is i386: 42 00 6f 00 6f 00 74 00 30 00 30 00 30 00 35 00 |B.o.o.t.0.0.0.5.| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0400 61 df e4 8b ca 93 d2 11 aa 0d 00 e0 98 03 2b 8c |a.+.| 0410 76 00 00 00 01 00 00 00 62 00 64 00 65 00 62 00 |v...b.d.e.b.| ^^^ 0420 69 00 61 00 6e 00 00 00 04 01 2a 00 01 00 00 00 |i.a.n.*.| 0430 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 || 0440 14 ab c8 38 14 e4 68 40 89 28 2a 27 8b 45 06 d2 |...8..h@.(*'.E..| 0450 02 02 04 04 34 00 5c 00 45 00 46 00 49 00 5c 00 |4.\.E.F.I.\.| 0460 64 00 65 00 62 00 69 00 61 00 6e 00 5c 00 67 00 |d.e.b.i.a.n.\.g.| 0470 72 00 75 00 62 00 78 00 36 00 34 00 2e 00 65 00 |r.u.b.x.6.4...e.| 0480 66 00 69 00 00 00 7f ff 04 00 00 00 00 00 00 00 |f.i.| 0490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0810 00 00 00 00 00 00 00 00 07 00 00 00 || 081c Note that, surprisingly, the kernel detects the ABI of the running process and presents different contents of that file on the sys fs. This means, runtime detection is bad as any 32-bit process will get 32-bit fields (actually, just one, the rest is arch-independent). Thus, to fix the issue, it seems you can drop 07-num_bits.patch and install the patch I attached instead. I'm afraid I can't test it save for qemu and virtualbox at this time, though. I'm not convinced that this doesn't break the use case in #773412 [1] since you're looking to define the type at compile-time[2], and that's precisely why #773412 came about. We'll end up replacing a bug in an unofficial port for a bug in an official port. And while we're here... could you please add x32 to the list of architectures in debian/control? This would fix a FTBFS on an unofficial arch. Yes, I can do that assuming it's not otherwise an issue. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773412 [2]
Bug#776999: broken 32-bit userland on 64-bit kernel
On Wed, Feb 04, 2015 at 05:25:59PM -0600, Adam Borowski wrote: On Wed, Feb 04, 2015 at 05:12:09PM -0600, D. Jared Dominguez wrote: On Wed, Feb 04, 2015 at 04:57:52PM -0600, Adam Borowski wrote: If I read that correctly, #773412 fixed i386 on an i386 kernel. As you can see in the dumps above, i386 userland on an amd64 kernel receives a 32-bit field rather than 64-bit that patch wants. It's for 32-bit efivar/efibootmgr on 64-bit kernel with 32-bit UEFI (which is why 32-bit efithings are used). Let's see if I understand right: a) 32-bit efivar on 64-bit kernel on 32-bit UEFI receives 64-bit fields, b) 32-bit efivar on 64-bit kernel on 64-bit UEFI receives 32-bit fields, c) 64-bit efivar on 64-bit kernel on 64-bit UEFI receives 64-bit fields. a) is claimed in the patch from Dec 17, b) and c) come in dumps I quoted. Not just claims but does. Remember that you're using the x32 ABI, which is different. -- Jared Domínguez Infrastructure Software Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776999: broken 32-bit userland on 64-bit kernel
On Wed, Feb 04, 2015 at 05:40:28PM -0600, Adam Borowski wrote: On Wed, Feb 04, 2015 at 05:36:06PM -0600, D. Jared Dominguez wrote: On Wed, Feb 04, 2015 at 05:25:59PM -0600, Adam Borowski wrote: On Wed, Feb 04, 2015 at 05:12:09PM -0600, D. Jared Dominguez wrote: On Wed, Feb 04, 2015 at 04:57:52PM -0600, Adam Borowski wrote: If I read that correctly, #773412 fixed i386 on an i386 kernel. As you can see in the dumps above, i386 userland on an amd64 kernel receives a 32-bit field rather than 64-bit that patch wants. It's for 32-bit efivar/efibootmgr on 64-bit kernel with 32-bit UEFI (which is why 32-bit efithings are used). Let's see if I understand right: a) 32-bit efivar on 64-bit kernel on 32-bit UEFI receives 64-bit fields, b) 32-bit efivar on 64-bit kernel on 64-bit UEFI receives 32-bit fields, c) 64-bit efivar on 64-bit kernel on 64-bit UEFI receives 64-bit fields. a) is claimed in the patch from Dec 17, b) and c) come in dumps I quoted. Not just claims but does. Remember that you're using the x32 ABI, which is different. While initially I found the issue on x32, the same happens on i386. I wonder how to tell these cases apart then -- both have 32-bit userland on 64-bit kernel (not just efivar, even cat gets such fields). Or perhaps I'm missing something? 32-bit efivar/efibootmgr on 64-bit kernel without x32 ABI and 32-bit UEFI. -- Jared Domínguez Infrastructure Software Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773726: efibootmgr: duplicate bootnum created
Looks like this bug also needed this, which was already in 0.11.0-1: https://github.com/vathpela/efibootmgr/commit/301c0628f7fa7333791d2b5d79eb8e02fc848ee7 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768880: tags jessie sid
control: tags -1 + jessie control: tags -1 + sid -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773007: tags jessie sid
control: tags -1 + jessie control: tags -1 + sid -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768889: tags jessie sid
control: tags -1 + jessie control: tags -1 + sid -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773007: Doesn't work on i386, crashes also
Hrmph. There was a 32-bit issue in 0.9.0-1 that was supposed to be fixed in 0.9.0-2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764797 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764796 Any chance you can test with efibootmgr from unstable? I've looked at the changes upstream and don't see anything that seems like it'd be relevant to efibootmgr -v segfaulting. However, about efibootmgr -c -d /dev/sda -o 1 -w -L debian -l \EFI\debian\grubia32.efi failing, these changes are in unstable's efibootmgr and might be relevant: 8c725c629f2ead41532c4b908e9c713187a7f564 - Make -o's behavior actually match the documented behavior. b857ce058d6f7fa3fa47c839bc86de243cd1fd4e - Make all the other places we're parsing also do a better job. Once you test against unstable's efibootmgr, Peter Jones (upstream) can help us try to triage this bug more. Relatedly, there are a bunch of fixes since 0.9.0-2. Actually, all changes since then are bug fixes. How hard would it be at this point in the game to get an exception to pull 0.11.0 into testing? --Jared On Fri, Dec 12, 2014 at 07:05:51PM -0600, Steve McIntyre wrote: Package: efibootmgr Version: 0.9.0-2 Severity: serious Tags: upstream Hi Jared, Testing on an i386 EFI installation using OVMF in qemu, efibootmgr just doesn't work properly. I'm working on i386 UEFI support in d-i, so I've built an i386 UEFI installer image. During installation, everything completes without error, but the system didn't boot after reboot. Booting the system by hand, I can run efibootmgr by hand and I get (transcribed by hand, so may have the odd error): root@debian:~# efibootmgr BootCurrent: BootOrder: 0002,0003,0004,, Boot: I DVD/CDROM Boot0001: I Floppy Boot0002: I Floppy 1 Boot0003: I Hard Drive Boot0004: I Internal Shell which tells me that the efibootmgr from grub install did not work. Worse, efibootmgr -v crashes: root@debian:~# efibootmgr -v BootCurrent: BootOrder: 0002,0003,0004,, Segmentation fault (core dumped) I've attached the core dump for reference. If I run grub-install by hand, I get more useful output: root@debian:~# grub-install Installing for i386-efi platform. Could not prepare boot variable: No such file or directory Installation finished. No error reported. (Useful - clear failure, but grub-install reports no error!) grub-install -v shows me the exact efibootmgr command that fails, which is: # efibootmgr -c -d /dev/sda -o 1 -w -L debian -l \EFI\debian\grubia32.efi As expected, running that by hand gives the same error. If I install an old version of efibootmgr for i386 (0.5.4-2), this all works just fine. I can install a boot record for debian using grub install or the efibootmgr -c command as above, and it works. efibootmgr and efibootmgr -v both work correctly. Tellingly, once I've used the older efibootmgr to install a debian boot record, if I upgrade to 0.9.0-2 again and run efibootmgr I now get a badly broken list: root@debian:~# efibootmgr BootCurrent: BootOrder: 0001,0002,0003,0004,, Boot: I DVD/CDROM Boot0001: I Floppy Boot0002: I Floppy 1 Boot0003: I Hard Drive Boot0004: I Internal Shell Boot0005: bian This smells like libefivar is broken on i386, maybe? Actually, not sure. I've attached a gdb and the backtrace looks like: (gdb) bt #0 0x0805036c in unparse_raw_text (buffer=0x0, buffer_size=0, p=0x80570fc , length=4294967260) ar src/lib/unparse_path.c:69 #1 0x0804acb2 in show_boot_vars () at src/efibootmgr/efibootmgr.c:776 #2 0x0804bcec in main (argc=2, argv=0xbd74) at src/efibootmgr/efibootmgr.c:1272 The length passed into unparse_raw_text() looks a little suspicious (0xFFDC, or -36). Debugging further up in show_boot_vars: boot-data_size is 64 load_option-file_path_list_length is 70 ((char *)path - (char *)load_option) is 30 This looks a little wrong to me, but I've not dug any deeper. -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768880: efibootmgr: unusable if reading any boot variable fails
Jan, My apologies for not seeing this bug report earlier. I just noticed it this morning thanks to Bastien. I reviewed the patch. It looks like it should be fine for at least restoring previous behavior, so I passed it along to Peter Jones, the upstream maintainer, to see whether he concurs so I can get this pushed into Jessie. --Jared -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764386: libefivar0: Segmentation fault in vars_get_variable() (vars.c:165)
Jan, I passed your patch upstream. Peter Jones is looking at it. It'd probably help him to know more details about what system you're on, though, like what make/model this is and probably an strace if you can. --Jared -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764386: libefivar0: Segmentation fault in vars_get_variable() (vars.c:165)
Actually, never mind. Peter broke out your patch and applied it upstream. I've just uploaded efivar 0.15-2. Please verify that it works correctly on your system. On Mon, Nov 03, 2014 at 09:58:20AM -0600, Dominguez, Jared wrote: Jan, I passed your patch upstream. Peter Jones is looking at it. It'd probably help him to know more details about what system you're on, though, like what make/model this is and probably an strace if you can. --Jared -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764386: libefivar0: Segmentation fault in vars_get_variable() (vars.c:165)
On Mon, Oct 06, 2014 at 06:14:59PM -0500, Jan Echternach wrote: Package: libefivar0 Version: 0.12-1 Severity: critical Justification: breaks the whole system Upgrading libefivar0 from version 0.10-5 to 0.12-1 causes a segmentation fault when running efibootmgr without arguments (I tried it with both efibootmgr 0.7.0-2 and 0.9.0-1). I'm not quite sure if severity critical is justified, but I think a broken efibootmgr is at least potentially able to break the whole system. gdb pointed to libefivar.so.0 which has no debugging symbols, so I built my own and that one crashes in vars.c line 165 with var == NULL. The last two lines in an strace log before the crash are open(/sys/firmware/efi/vars/Boot0005-8be4[...]/raw_var, O_RDONLY) = 3 read(3, [...], 4096) = -1 EIO (Input/output error) (Sorry, no copypaste, just readtype; the system in question has only very limited network connectivity at the moment and I'm sending this report from a different system.) var is apparently returned from a call to read_file() a few lines above. The source code history shows that read_fd() has recently been replaced by read_file(), but they behave differently after read errors. In particular, read_file() resets the buffer to NULL whereas read_fd() didn't. Jan, Can you confirm whether this is still an issue for you? New versions of libefivar0 are in testing and unstable. Please test against them. --Jared -- Jared Domínguez Server OS Engineering Dell | Enterprise Solutions Group -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764797: efibootmgr has multiple bugs in its 32bit version
I just uploaded new efi{var,bootmgr} packages with these patches.
On Sat, Oct 11, 2014 at 02:30:21AM -0500, Michael Tokarev wrote:
Package: efibootmgr
Version: 0.9.0-1
Severity: serious
32bit version (i386 package) of efibootmgr has several bugs which makes
it unusable at least with large (2TiB) drives. Yesterday we had a
long debugging session with Peter Jones on IRC, which resulted in the
following 3 patches:
http://paste.fedoraproject.org/141063/29722481/
http://paste.fedoraproject.org/141085/41297720/
To sum it: using wrong (32bit) data type in partition/drive size calculation,
not using BLKGETSIZE64 on kernels with 2-component version numbers (so 32bit
version of ioctl is used which is unsuitable for large drives), and inventing
own ioctl macros which makes kernel 32/64bit compat layer unhappy (so that
BLKGETSIZE64 from 32bit app running under 64bit kernel returns ENOTTY), which
again making efibootmgr to use 32bit number for drive sizes.
The result of these bugs is inability of efibootmgr to install boot entry
for a large (2TiB) drive, making the system unbootable.
These fixes should be in the next upstream version of efibootmgr, please
package it once it's released to fix 32bit efibootmgr. And please don't
forget to make it multi-arch-aware while at it ;)
Thanks,
/mjt
--
Jared Domínguez
Server OS Engineering
Dell | Enterprise Solutions Group
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
