lkml.org 
[lkml]   [2023]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC 1/7] x86/head/64: Mark star tup gdt and startup gdt descr as initdata
    On October 17, 2023 6:02:27 AM PDT, Ingo Molnar <mingo@kernel.org> wrote:
    >
    >* Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
    >
    >> Hi Ingo,
    >>
    >> I have sent patch #6 separately for x86. Do you have any ideas about
    >> building the head code as PIE? Should I resend the patchset for the PIE
    >> feature?
    >
    >So I had a brief look, and despite reading 0/43 it was unclear to me what
    >the precise advantages of building as PIE are.
    >
    >Ie. could you please outline:
    >
    > - *Exactly* how much PIE based KASLR randomization would gain us in terms
    > of randomization granularity and effective number of randomization bits,
    > compared to the current status quo?
    >
    > - How is code generation changed at the instruction level - how does
    > kernel size change and what are the micro-advantages/disadvantages?
    >
    > - Are there any other advantages/motivation than improving KASLR?
    >
    >Ie. before asking us to apply ~50 patches and add a whole new build mode
    >and the maintainance overhead to support it into infinity and beyond, could
    >you please offer a better list of pros and cons?
    >
    >Thanks,
    >
    > Ingo

    If the goal is better KASLR, then what we really should spend time on was Kristen Accardi's fgKASLR patches, which not only exponentially(!) increases the randomization entrophy but also *actually* avoids the "one leak and it's over" problem.

    However, she gave up on it because she got no interest, despite working code.

    \
     
     \ /
      Last update: 2023-10-17 19:11    [W:2.879 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site