Mailing List <linux-crypto@xxxxxxxxxxxxxxx>,LKML <linux-kernel@xxxxxxxxxxxxxxx>,virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx,Linux PM list <linux-pm@xxxxxxxxxxxxxxx> From: hpa@xxxxxxxxx Message-ID: <F35C8DBD-9AC3-46F2-9043-6CB9A4FDDDC9@xxxxxxxxx> On March 3, 2020 1:19:22 PM PST, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi >wrote: >> On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: >> > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra ><peterz@xxxxxxxxxxxxx> >> > wrote: >> > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: >> > > > On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote: >> > > > > Minor changes based on feedback and rebase from v10. >> > > > > >> > > > > Splitting the previous serie in two. This part contains >> > > > > assembly code >> > > > > changes required for PIE but without any direct dependencies >> > > > > with the >> > > > > rest of the patchset. >> > > > > >> > > > > Note: Using objtool to detect non-compliant PIE relocations >is >> > > > > not yet >> > > > > possible as this patchset only includes the simplest PIE >> > > > > changes. >> > > > > Additional changes are needed in kvm, xen and percpu code. >> > > > > >> > > > > Changes: >> > > > > - patch v11 (assembly); >> > > > > - Fix comments on x86/entry/64. >> > > > > - Remove KASLR PIE explanation on all commits. >> > > > > - Add note on objtool not being possible at this stage of >> > > > > the patchset. >> > > > >> > > > This moves us closer to PIE in a clean first step. I think >these >> > > > patches >> > > > look good to go, and unblock the work in kvm, xen, and percpu >> > > > code. Can >> > > > one of the x86 maintainers pick this series up? >> > > >> > > But,... do we still need this in the light of that fine-grained >> > > kaslr >> > > stuff? >> > > >> > > What is the actual value of this PIE crud in the face of that? >> > >> > If I remember well, it makes it easier/better but I haven't seen a >> > recent update on that. Is that accurate Kees? >> >> I believe this patchset is valuable if people are trying to brute >force >> guess the kernel location, but not so awesome in the event of >> infoleaks. In the case of the current fgkaslr implementation, we only >> randomize within the existing text segment memory area - so with PIE >> the text segment base can move around more, but within that it >wouldn't >> strengthen anything. So, if you have an infoleak, you learn the base >> instantly, and are just left with the same extra protection you get >> without PIE. > >Right -- PIE improves both non- and fg- KASLR similarly, in the sense >that the possible entropy for base offset is expanded. It also opens >the >door to doing even more crazy things. (e.g. why keep the kernel text >all >in one contiguous chunk?) > >And generally speaking, it seems a nice improvement to me, as it gives >the kernel greater addressing flexibility. The difference in entropy between fgkaslr and extending the kernel to the PIC memory model (which is the real thing this is doing) is immense: The current kASLR has maybe 9 bits of entropy. PIC-model could extend that by at most 16 bits at considerable cost in performance and complexity. Fgkaslr would provide many kilobits worth of entropy; the limiting factor would be the random number source used! With a valid RNG, no two boots across all the computers in the world across all time would have an infinitesimal probability of ever being the same; never mind the infoleak issue. In addition to the combinatorics, fgkaslr pushes randomization right as well as left, so even for the address of any one individual function you get a gain of 15-17 bits. "More is better" is a truism, but so is Amdahl's Law. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
