Thanks for the patch, it was merged. -ning
-----Original Message----- From: Ahmed, Safayet (GE Global Research, US) [mailto:safayet.ah...@ge.com] Sent: Monday, June 05, 2017 8:36 AM To: TBoot Dev List (tboot-devel@lists.sourceforge.net) <tboot-devel@lists.sourceforge.net> Cc: Smith, William D (GE Global Research, US) <smit...@ge.com> Subject: Re: [tboot-devel] tboot-loader patch I apologize for the previous email. The correct patch is attached. Signed-off-by: Safayet Ahmed <safayet.ah...@ge.com> Safayet ________________________________________ From: Ahmed, Safayet (GE Global Research, US) Sent: Monday, June 05, 2017 10:36 AM To: TBoot Dev List (tboot-devel@lists.sourceforge.net) Cc: Smith, William D (GE Global Research, US) Subject: EXT: [tboot-devel] tboot-loader patch Hello Attached is a patch to address multiboot-loading problems that may have security implications. Before unpacking module 0 as an ELF binary, TBoot moves all modules to a "ceiling" computed from the E820 map. This move is meant to ensure that the module images aren't corrupted in the process of unpacking the ELF binary. Then, after unpacking the ELF binary, TBoot moves all the modules back down to just above the highest end address of the ELF binary. The problem with this approach is that TBoot can overwrite one module with another module. We have seen this happen with a specific boot configuration. This is a possible vulnerability because this process of moving modules occurs after the modules have been measured and the PCRs have been extended with the measurements. Further, an adversary may control the corruption of the modules because the placement of modules in memory and the E820 map come from the pre-launch environment and the pre-launch environment is not trusted. 1) The Multiboot specification does not impose restrictions on the order of modules in memory. For example, module 0 can occur at a higher address in physical memory than module 1. 2) Even though the E820 map is verified to ensure that unusable memory is not marked as valid RAM (verify_e820_map), valid RAM may still be marked as unusable memory. There is no way to check for this latter form of corruption. To prevent TBoot from overwriting one module with another, the following restrictions are imposed: 1) Always move modules in the same direction. For example, when moving modules up to the "ceiling", only move modules up in memory, never down. More specifically, only move those modules that occur below the computed ceiling. In the case of modules that straddle the ceiling, move the ceiling down. 2) Move modules in order of their occurance in memory (not in order of their index). For example, when moving modules up, first move the module with the highest base/end address. The above changes should ensure that Tboot never overwrites one module with another in the process of moving them. Signed-off-by: Safayet Ahmed <safayet.ah...@ge.com> thanks, Safayet ------------------------------------------------------------------------------ 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
