lkml.org 
[lkml]   [2019]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86/alternatives: check int3 breakpoint physical addresses
    On Mon, 11 Feb 2019, Alexandre Chartre wrote:
    > On 02/10/2019 10:23 PM, Thomas Gleixner wrote:
    > > On Fri, 25 Jan 2019, Alexandre Chartre wrote:
    > > > Note that this issue has been observed and reproduced with a custom kernel
    > > > with some code mapped to different virtual addresses and using jump labels
    > > > As jump labels use text_poke_bp(), crashes were sometimes observed when
    > > > updating jump labels.
    > >
    > > Rightfully so. text_poke_bp() pokes at the kernels text mapping which is
    > > very well defined and unique. Why would you map the same text to different
    > > virtual addresses and then use a randomly chosen one to poke at it?
    > >
    >
    > As an example, we used to have per-CPU SYSCALL entry trampoline [1] where the
    > entry_SYSCALL_64_trampoline function was mapped to a different virtual address
    > for each CPU. So, a syscall would execute entry_SYSCALL_64_trampoline() from a
    > different virtual address depending on the CPU being used. With that code,
    > adding a jump label in entry_SYSCALL_64_trampoline() causes the described
    > issue.

    Right, but we knew that and there was no reason to put a jump label into
    that. AFAICT we don't have anything like this in the kernel.

    That said, I'm not opposed to apply the patch as is, I just wanted to get a
    better understanding about the background.

    Thanks,

    tglx

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