Hi Pavel, On 15/10/2019 19:47, Pavel Tatashin wrote: >> I think the UEFI persistent-memory-reservations thing is a better fit for this [0][1]. > Thank you for your thought. As I understand you propose the to use the > existing method as such: > 1. Use the existing kexec ABI to pass reservation from kernel to > kernel using EFI the same as is done for GICv3 tables. > 2. Allow this memory to be reservable only during first Linux boot via > EFI memory reserve > 3. Allow to have this memory pre-reserved by firmware or to be > embedded into device tree. > > A question I have is how to tell that a reserved region is reserved > for IMA use. With GICv3 it is done by reading the registers, finding > the interrupt tables memory, and check that the memory ranges are > indeed pre-reserved. Good point, efi_mem_reserve_persistent() has no way of describing what a region is for, you have to know that from somewhere else. > Is there a way to name memory with the current ABI that you think is acceptable? This would need to go in the chosen node of the DT, like power-pc already does. This would work on arm64:ACPI systems too (because they have a DT chosen node). I'd like to understand why removing these entries is needed, it doesn't look like we have an API call to remove them from the efi mem-reserve... If it had a fixed position in memory its the sort of thing we'd expect firmware to reserved during boot. (e.g. ramoops). ~ >From ima_add_kexec_buffer() this really is a transient memory reservation over kexec. I think the efi mem-reserve and a DT-chosen node entry with the PA is the only way to make this work smoothly between DT<->ACPI systems. We'd need a way of removing the efi mem-reserve in ima_free_kexec_buffer(), otherwise the memory remains lost. The DT-chosen node entry should have its pointer zero'd out once we've done this. (like we do for the KASLR seed). Not considered is parsing the DT-chosen node entry as if it were a memreserve during early boot. This wouldn't work if you kexec something that doesn't know what the node is, it would overwrite the the memory and may not remove the node for the next kexec, which does. Thanks, James _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
