On Fri, 2019-10-25 at 18:07 +0100, James Morse wrote: > Hi Mimi, > > On 16/10/2019 02:44, Mimi Zohar wrote: > > On Tue, 2019-10-15 at 18:39 +0100, James Morse wrote: > >> If SecureBoot isn't relevant, I'm confused as to why kexec_file_load() is. > >> > >> I thought kexec_file_load() only existed because SecureBoot systems need to validate the > >> new OS images's signature before loading it, and we can't trust user-space calling Kexec > >> to do this. > >> > >> If there is no secure boot, why does this thing only work with kexec_file_load()? > >> (good news! With the UEFI memreseve table, it should work transparently with regular kexec > >> too) > > > I'm so sorry for the confusion. IMA was originally limited to > > extending trusted boot concepts to the OS. As of Linux 3.10, IMA > > added support for extending secure boot concepts and auditing file > > hashes (commit e7c568e0fd0cf). > > > > True, kexec_file_load is required for verifying the kexec kernel > > image, but it is also required for measuring the kexec kernel image as > > well. > > > > After reading the kernel image into memory (kernel_read_file_from_fd), > > the hash is calculated and then added to the IMA measurement list and > > used to extend the TPM. All of this is based on the IMA policy, > > including the TPM PCR. > > Don't we get a set of segments with the regular kexec syscall? These could equally be > hashed and measured, and logged via IMA and/or extending the TPMs measurements. IMA works at the file level. I'm not sure what it would mean to measure "segments". Originally, kexec_file_load read the KEXEC kernel image twice, once to calculate the file hash, and again to verify the signature. Now kexec_file_load calls kernel_read_file_from_fd, which reads the file into memory, before IMA calculates the file buffer hash. > > (obviously this would include the command-line and maybe purgatory, which makes it less > predictable, but these are still the binary blobs that were given privileged access to the > system). > > > >>> I am not sure if i addressed all your concerns, please let me know > >>> if i missed anything. To me most concerns look to be towards the kexec case and dependency > >>> on hardware(ACPI/TPM) during boot and early boot services, where as carrying the logs is > >>> only during the kexec_file_load sys call and does not interfere with that code path. > >>> IMA documentation: https://sourceforge.net/p/linux-ima/wiki/Home/ > >> > >> Supporting ACPI in the same way is something we need to do from day one. kexec_file_load() > >> already does this. I'm not sure "only kexec_file_load()" is a justifiable restriction... > > > The TPM PCRs are not reset on a soft reboot. As a result, in order to > > validate the IMA measurement list against the TPM PCRs, the IMA > > measurement list is saved on kexec load, restored on boot, and then > > the memory allocated for carrying the measurement list across kexec is > > freed. > > Hmm, this is why the reserved memory gets freed. Yes > > What happens to stuff that happens between kexec-load and boot? > There is a comment: > | /* segment size can't change between kexec load and execute */ Right, the original version addressed this, but was nixed by Eric, saying it was unnecessary. The current version allocates more memory than needed to hopefully compensate. > > But I can't see anywhere that enforces that. I guess those measurements will go missing, > and the TPM value will not match after kexec. No, the kexec load will succeed, but if there isn't enough memory to store the measurement list, the exec should fail. Mimi
