Messages in this thread | | | Date | Wed, 10 Sep 2014 21:55:55 +0800 | From | Baoquan He <> | Subject | Re: [PATCH 2/4] kaslr: check if the random addr is available |
| |
On 09/09/14 at 03:41pm, Vivek Goyal wrote: > On Sat, Sep 06, 2014 at 06:16:57AM +0800, Baoquan He wrote: > > [CC hpa ] > > > Hi Kees, > > > > Yes, process_e820_entry() can make sure the choice+output_len < > > CONFIG_RANDOMIZE_BASE_MAX_OFFSET, but that can't stop other bootloaders > > to put kernel in region above CONFIG_RANDOMIZE_BASE_MAX_OFFSET. > > > > E.g in kdump, we can set crashkernel=256M@1024M in cmdline. Then the 1st > > kernel will reserve 256M memory just at 1024M place. So if load kdump > > kernel now, the output will be 1024M before choose_kernel_location(). > > With this value, output won't be changed in choose_kernel_location(), > > then it will do decompress(), then call handle_relocations(). Then since > > 1024 is not equal to LOAD_PHYSICAL_ADDR, it will start relocatoins > > handling. And this cause _text stamping into MODULES vaddr range. System > > will be exceptional. > > Bao, > > If you apply your first patch where output_orig == output, then > handle_relocations() will not do anything for x86_64 case and bail > out. That should take care of this issue. Isn't it? And we should > not require this patch.
Yes, exactly.
> > Thanks > Vivek
| |