On Tue, Dec 21, 2021 at 2:41 AM cuigaosheng <cuigaosheng1@xxxxxxxxxx> wrote: > > > I could apply them directly with the maintainer Acks, but I don't understand > > the significance of you sending them now. Is something broken without the > > three patches? Are these the only ones missing from Ard's original series, > > or is this preparation? Would you expect the patches to get backported to > > stable kernels? > > Thanks for your reply. > > This is preparation work for arm32 kaslr,and I want to continue to improve > the solution based on the work of Ard. These patches are relatively > independent, so I submit these patches first. The approach of merging support incrementally is good in principle, but in this case I think we first need to agree on the overall direction first. How far have you come rebasing Ard's patches, do you have KASLR working yet? This is information that should go into the [PATCH 0/3] cover letter. Do you have a particular target platform in mind? I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G memory model, which in turn depends on having the kernel in vmalloc space, as implemented by Linus Walleij in https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1 With this work, the randomization will look quite different, on the one hand it leaves less room for relocating the kernel within the smaller 256MB vmalloc space, while on the other hand it does open the possibility of complete randomization by scrambling the virt-to-phys mapping in vmalloc space, using linear virtual addresses to refer to a randomized set of physical addresses. (this is just a wild idea that one could implement, nobody has actual plans for it at the moment, and it comes with additional runtime overhead). Arnd
