Messages in this thread | | | Date | Mon, 11 Feb 2019 10:15:03 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [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
| |