Hi Ed, Thanks for reporting this issue, we will root cause and fix the issue as soon as we can. As we do not have an Intel S2600GL machine at hand, to root cause completely your issue, can you try this by modifying the config.h file and build the tboot.gz: //#define TBOOT_KERNEL_CMDLINE_SIZE 0x0400 #define TBOOT_KERNEL_CMDLINE_SIZE 0x0100
This modification will redefine the TBOOT_KERNEL_CMDLINE_SIZE to 256 bytes, if this works for your Intel S2600GL system, we need to figure out a way to move the tboot kernel command line to other address below 1M. Thanks, -ning -----Original Message----- From: Ed Swierk [mailto:eswi...@skyportsystems.com] Sent: Tuesday, December 27, 2016 8:01 PM To: tboot-devel@lists.sourceforge.net Subject: [tboot-devel] Real-mode Linux command line buffer overflow Current tboot fails to boot a Linux 4.4 kernel on an Intel S2600GL (Xeon E5-2600 v2) system, hanging after printing "TBOOT: transfering control to kernel @0x1000000...". I isolated the problem to the change "Initiaize kernel header comdline buffer before copying kernel cmdline arguments to the buffer" (https://sourceforge.net/p/tboot/code/ci/356ad4b1d363c70d7b25907f812bd411a28eecd3/). This change tries to avoid leaving trailing garbage on the kernel command line by zeroing a 1024-byte buffer. However, the command line buffer resides in the real-mode boot header, which if tboot/include/linux_defns.h is to be believed, leaves only 0x9100 - 0x9000 = 256 bytes for the command line. With this change, tboot ends up zeroing another 768 bytes in the "Do not use. Reserved for BIOS EBDA" region. Also, tboot assumes fixed boundaries for the EBDA (real_mode_base + 0x99100 to real_mode_base + 0xa0000), while according to https://www.kernel.org/doc/Documentation/x86/boot.txt the BIOS decides how much space it needs and reports it via int 12h. At least tboot should fail gracefully if the BIOS expects more space than tboot reserves. Finally, there doesn't appear to be any bounds checking on the kernel_cmdline string; whatever get_cmdline() returns is blindly memcpyed into the buffer up to the first null, possibly overwriting part of the BIOS EBDA with user-provided data. I can hack around the problem on my system by changing LEGACY_REAL_START to 0x80000, but I think a proper fix needs to address the above issues. --Ed ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
