lkml.org 
[lkml]   [2019]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2 2/3] x86/traps: Print non-canonical address on #GP
    On Wed, Nov 20, 2019 at 5:25 AM Andi Kleen <ak@linux.intel.com> wrote:
    > Jann Horn <jannh@google.com> writes:
    > > + if (error_code)
    > > + pr_alert("GPF is segment-related (see error code)\n");
    > > + else
    > > + print_kernel_gp_address(regs);
    >
    > Is this really correct? There are a lot of instructions that can do #GP
    > (it's the CPU's equivalent of EINVAL) and I'm pretty sure many of them
    > don't set an error code, and many don't have operands either.
    >
    > You would need to make sure the instruction decoder handles these
    > cases correctly, and ideally that you detect it instead of printing
    > a bogus address.

    Is there a specific concern you have about the instruction decoder? As
    far as I can tell, all the paths of insn_get_addr_ref() only work if
    the instruction has a mod R/M byte according to the instruction
    tables, and then figures out the address based on that. While that
    means that there's a wide variety of cases in which we won't be able
    to figure out the address, I'm not aware of anything specific that is
    likely to lead to false positives.

    But Andy did suggest that we hedge a bit in the error message because
    even if the address passed to the instruction is non-canonical, we
    don't know for sure whether that's actually the reason why things
    failed, and that's why it says "probably" in the message about the
    address now.

    \
     
     \ /
      Last update: 2019-11-20 11:32    [W:5.441 / U:0.620 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site