All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Chartre <alexandre.chartre@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Alexandre Chartre <alexandre.chartre@oracle.com>
Subject: Re: [PATCH] x86/alternatives: check int3 breakpoint physical addresses
Date: Mon, 11 Feb 2019 10:08:11 +0100	[thread overview]
Message-ID: <8995b3b4-b805-c8c7-95a8-a39ab000f289@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1902102221500.8784@nanos.tec.linutronix.de>


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.

This mapping was eventually removed [2]. I don't know if any other code like this
is currently present in the kernel (I couldn't find any, but I might not have
covered everything). But, as this past commit have shown, this is definitively
something that can happen.

Thanks,

alex.

---
[1] 3386bc8aed82 ("x86/entry/64: Create a per-CPU SYSCALL entry trampoline")
     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3386bc8aed82

[2] bf904d2762ee ("x86/pti/64: Remove the SYSCALL64 entry trampoline")
     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf904d2762ee

  reply	other threads:[~2019-02-11  9:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-25 14:57 [PATCH] x86/alternatives: check int3 breakpoint physical addresses Alexandre Chartre
2019-02-10 21:23 ` Thomas Gleixner
2019-02-11  9:08   ` Alexandre Chartre [this message]
2019-02-11  9:15     ` Thomas Gleixner
2019-02-11  9:57       ` Alexandre Chartre
2019-02-21 10:14         ` Alexandre Chartre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8995b3b4-b805-c8c7-95a8-a39ab000f289@oracle.com \
    --to=alexandre.chartre@oracle.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.