lkml.org 
[lkml]   [2017]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: keys: GPF in request_key
    On Wed, Feb 1, 2017 at 2:11 PM, David Howells <dhowells@redhat.com> wrote:
    > Dmitry Vyukov <dvyukov@google.com> wrote:
    >
    >> Code: 41 54 49 89 f4 53 49 89 d7 48 89 fb 48 83 ec 08 e8 d1 50 67 ff
    >> 49 8d 7c 24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
    >> 3c 02 00 0f 85 35 02 00 00 49 83 7c 24 10 00 0f 84 bb 01 00
    >
    > This disassembles to:
    >
    > 0: 41 54 push %r12
    > 2: 49 89 f4 mov %rsi,%r12
    > 5: 53 push %rbx
    > 6: 49 89 d7 mov %rdx,%r15
    > 9: 48 89 fb mov %rdi,%rbx
    > c: 48 83 ec 08 sub $0x8,%rsp
    > 10: e8 d1 50 67 ff callq 0xffffffffff6750e6
    > 15: 49 8d 7c 24 10 lea 0x10(%r12),%rdi
    > 1a: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
    > 21: fc ff df
    > 24: 48 89 fa mov %rdi,%rdx
    > 27: 48 c1 ea 03 shr $0x3,%rdx
    > 2b:* 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction
    > 2f: 0f 85 35 02 00 00 jne 0x26a
    > 35: 49 83 7c 24 10 00 cmpq $0x0,0x10(%r12)
    > 3b: 0f .byte 0xf
    > 3c: 84 .byte 0x84
    > 3d: bb .byte 0xbb
    > 3e: 01 00 add %eax,(%rax)
    >
    > I can see that RAX got loaded from the instruction at 0x1a, but the code
    > doesn't look very much like what I get out of the compiler (your compiled
    > function is also at least double the size of what I get, presumably due to
    > kasan?).
    >
    > Can you disassemble __key_link_begin() for me and send me your config?
    >
    > In particular, 0xdffffc0000000000 looks very weird. Is this code validating
    > the pointer in R12?


    Here is the disasm:
    https://gist.githubusercontent.com/dvyukov/c06f742adba0ee162dfb1ece75b5d8ab/raw/14aba22492090e09ea36bddd5db344fdcfc25065/gistfile1.txt

    Yes, this is with KASAN+KCOV so size increase is expected.

    Before each memory access to *p KASAN inserts:

    if (*(char*)(0xdffffc0000000000 + p/8)) __kasan_report();
    ... *p .... // original memory accesses

    You can see it here:

    ffffffff8203ea84: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
    ffffffff8203ea8b: fc ff df
    ffffffff8203ea8e: 48 89 fa mov %rdi,%rdx
    ffffffff8203ea91: 48 c1 ea 03 shr $0x3,%rdx
    ffffffff8203ea95: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) //
    <<< ACCESS that crashes

    For valid kernel addresses this never crashes.
    In this case the original addresses that code tried to accesses is in
    %RDI. And they look bogus.

    \
     
     \ /
      Last update: 2017-02-01 14:24    [W:2.366 / U:0.316 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site