Preamble: I'm not a C developer :)

After reading the code, I think this is the culprit:


printk(TBOOT_INFO"Linux cmdline placed in header: ");
     printk_long(kernel_cmdline);
     printk(TBOOT_INFO"\n");
    memcpy((void *)hdr->cmd_line_ptr, kernel_cmdline, strlen(kernel_cmdline)); 
<=== here

C strings are NULL-terminated, but this only copies the string contents (raw 
length) at the pointer - not including the terminating NULL. Is there a 
guarantee that memory at the pointer contains only NULLs?
This results in random garbage read by the kernel afterwards, essentialy until 
some random NULL gets in place.

Why this happens only with PXE-boot (iPXE, GRUB) I have no idea (I hope you 
guys know).

I made this patch:

diff -r 6531a0eaf369 tboot/common/linux.c
--- a/tboot/common/linux.c      Wed May 18 10:13:24 2016 -0700
+++ b/tboot/common/linux.c      Mon Jun 06 16:43:12 2016 +0200
@@ -307,7 +307,7 @@
     printk(TBOOT_INFO"Linux cmdline placed in header: ");
     printk_long(kernel_cmdline);
     printk(TBOOT_INFO"\n");
-    memcpy((void *)hdr->cmd_line_ptr, kernel_cmdline, strlen(kernel_cmdline));
+    memcpy((void *)hdr->cmd_line_ptr, kernel_cmdline, strlen(kernel_cmdline) + 
1);
 
     /* need to put boot_params in real mode area so it gets mapped */
     boot_params = (boot_params_t *)(real_mode_base + real_mode_size);

This copies one byte more (the NULL character that should be there after the 
original string) and tboot now works for me over PXE, e.g. cmdline is not 
corrupted anymore.
I've only tested this on one machine.

Is this patch correct? Or shoulld the target memory be NULL-ed beforehand? (I 
suspect this might cause problems with modules that have no parameters?)


Jan



> On 06 Jun 2016, at 14:55, Jan Schermer <j...@schermer.cz> wrote:
> 
> Hi,
> I've seen this happen with both iPXE and GRUB now.
> 
> For example if I load tboot+linux like this in GRUB:
> 
>        multiboot boot/tboot.gz logging=vga,serial,memory
>        module boot/Ubuntu-TXT-16.04-x86_64-linux interface=auto 
> url=http://something.somewhere ramdisk_size=10800 root=/dev/rd/0 rw auto 
> hostname=test BOOTIF=${net_pxe_mac} console-setup/ask_detect=false 
> console-setup/layout=USA console-setup/variant=USA 
> keyboard-configuration/layoutcode=us 
> localechooser/translation/warn-light=true 
> localechooser/translation/warn-severe=true locale=en_US brm
>        module boot/Ubuntu-TXT-16.04-x86_64-initrd.gz
> 
> System loads fine, but /proc/cmdline contains ~20 characters of random 
> garbage appended to the original cmdline contents.
> 
> 
> 
> I first saw it wheb trying to load Foreman Discovery Image - a ramdisk based 
> on CentOS 7.
> I decided to ignore it then and switched to GRUB, this fixed booting the 
> Discovery Image (no /cmdline corruption).
> 
> Next step is provisioning = booting Ubuntu preseed, and /proc/cmdline is 
> corrupted there now.
> 
> So I'm pretty sure that it is tboot corrupting the cmdline (is it terminated 
> differently in PXE environment? Some padding needed?)
> 
> I'm not sure how reproducible it is. While I can trigger it every time in 
> those combinations, apparently with some modules it boots fine (because FDI 
> boots fine...)
> 
> Has anybody encountered this before? Any PXE users here?
> 
> Thanks
> 
> Jan


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Reply via email to