On Tue, Mar 13, 2018 at 10:47:15AM +0000, Mark Rutland wrote: > 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. So, by definition, is randomness, if we say so, in physical address not part of KASLR? > 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. Hmm, so saving/re-using kaslr-seed of the 1st kernel, as Bhupesh hinted, is not important, anyway. -Takahiro AKASHI > Thanks, > Mark. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
