On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote: > On Mon, Mar 12, 2018 at 08:58:00PM +0000, Ard Biesheuvel wrote: > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@xxxxxxxxxx> wrote: > More importantly, neither arm64 _kexec_ supports kaslr. The below is just considering this, and ignoring kdump (where I don't think we care at all about KASLR). > Currently kexec-tools is set to determine where the kernel actually be > loaded, using a constant offset, text_offset, which comes from an image's > boot header and relocation of an image to the load address is performed > at the very end of the first kernel without knowing whether the 2nd kernel > has kaslr support enabled or not. The kexec tools shouldn't need to know whether the kernel supports KASLR at all. If the new kernel image has bit 3 (Kernel physical placement) set, kexec tools can choose to randomize the physical load address, regardless of whether that kernel has KASLR enabled. Note that the bootloader is responsible for physical randomization, and the kernel is responsible for virtual randomization. It just happens that the EFI stub acts as a bootloader when we use EFI. > > > B. Regarding the arm64 kaslr support in kdump (I have Cc'ed AKASHI and > > > kexec list in this thread as well for their inputs), but currently we > > > don't seem to have a way to support kaslr in arm64 kdump kernel: > > > > > > - '/chosen/kaslr-seed' a property is zeroed out in the primary kernel > > So, even if adding /chosen/kaslr-seed to dtb at kexec would not be > difficult, we would have to have efi_entry-like entry code. The kaslr-seed property is used for *virtual* randomization, so we don't need more code in the kernel for this. The kexec tools can populate this property if desired. Thanks, Mark. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
