linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, Juergen Gross <jgross@suse.com>,
	Andi Kleen <ak@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: [PATCH] x86/paravirt: Detect oversized patching bugs as they happen and BUG_ON() to avoid later crashes
Date: Thu, 25 Apr 2019 11:17:17 +0200	[thread overview]
Message-ID: <20190425091717.GA72229@gmail.com> (raw)
In-Reply-To: <20190425081012.GA115378@gmail.com>


* Ingo Molnar <mingo@kernel.org> wrote:

> Third, beyond readability there's another advantage of my suggested 
> approach as well: for example that way we could verify the passed in 
> length with the patchlet length. Right now it's completely unverified:
> 
>         case PARAVIRT_PATCH(ops.m):                                     \
>                 return PATCH(data, ops##_##m, ibuf, len)
> 
> right now we don't check whether the 'len' passed in by the usage site 
> matches the actual structure field length.
> 
> Although maybe we could do that with your C space structure as well.

So I was wrong here, got confused by the 'len' name which doesn't mean 
what it suggests: it's not the length of the patchlet, but the 
maximum/original length of the patch site - which we trim down in 
paravirt_patch_insns():

unsigned paravirt_patch_insns(void *insnbuf, unsigned len,
                              const char *start, const char *end)
{
        unsigned insn_len = end - start;

        if (insn_len > len || start == NULL)
                insn_len = len;
        else
                memcpy(insnbuf, start, insn_len);

        return insn_len;
}

What is the logic behind silently returning 'len' here and not copying 
anything?

It basically means that we silently won't do any patching and the kernel 
will crash later on in mysterious ways, because paravirt patching is 
usually relied on.

Instead I think we should BUG_ON() that condition with the patch below - 
there's no way to continue successfully at that point.

I've tested this patch, with the vanilla kernel check never triggers, and 
if I intentionally increase the size of one of the patch templates to a 
too high value the assert triggers:

[    0.164385] kernel BUG at arch/x86/kernel/paravirt.c:167!

Without this patch a broken kernel randomly crashes in later places, 
after the silent patching failure.

Thanks,

	Ingo

Signed-off-by: Ingo Molnar <mingo@kernel.org>

--- tip.orig/arch/x86/kernel/paravirt.c
+++ tip/arch/x86/kernel/paravirt.c
@@ -163,10 +163,10 @@ unsigned paravirt_patch_insns(void *insn
 {
 	unsigned insn_len = end - start;
 
-	if (insn_len > len || start == NULL)
-		insn_len = len;
-	else
-		memcpy(insnbuf, start, insn_len);
+	/* Alternative instruction is too large for the patch site and we cannot continue: */
+	BUG_ON(insn_len > len || start == NULL);
+
+	memcpy(insnbuf, start, insn_len);
 
 	return insn_len;
 }

  reply	other threads:[~2019-04-25  9:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 13:41 [patch 0/3] x86/paravirt: Rework paravirt patching Thomas Gleixner
2019-04-24 13:41 ` [patch 1/3] x86/paravirt: Remove bogus extern declarations Thomas Gleixner
2019-04-25  7:31   ` [tip:x86/paravirt] " tip-bot for Thomas Gleixner
2019-05-24  7:58   ` tip-bot for Thomas Gleixner
2019-04-24 13:41 ` [patch 2/3] x86/paravirt: Unify 32/64 bit patch code Thomas Gleixner
2019-04-25  7:32   ` [tip:x86/paravirt] " tip-bot for Thomas Gleixner
2019-05-24  8:00   ` [tip:x86/paravirt] x86/paravirt: Unify the 32/64 bit paravirt patching code tip-bot for Thomas Gleixner
2019-04-24 13:41 ` [patch 3/3] x86/paravirt: Replace paravirt patch asm magic Thomas Gleixner
2019-04-25  6:52   ` Ingo Molnar
2019-04-25  7:22     ` Thomas Gleixner
2019-04-25  7:46       ` Juergen Gross
2019-04-25  8:10       ` [PATCH] x86/paravirt: Match paravirt patchlet field definition ordering to initialization ordering Ingo Molnar
2019-04-25  9:17         ` Ingo Molnar [this message]
2019-04-25  9:21           ` [PATCH] x86/paravirt: Detect oversized patching bugs as they happen and BUG_ON() to avoid later crashes Peter Zijlstra
2019-04-25  9:50             ` x86/paravirt: Detect over-sized patching bugs in paravirt_patch_call() Ingo Molnar
2019-04-25 10:22               ` Peter Zijlstra
2019-04-25 10:57                 ` Ingo Molnar
2019-04-25 11:30                   ` Juergen Gross
2019-04-25 12:30                     ` Juergen Gross
2019-04-25 11:40                   ` Peter Zijlstra
2019-04-25 12:30                     ` Peter Zijlstra
2019-05-24  7:59               ` [tip:x86/paravirt] " tip-bot for Ingo Molnar
2019-05-24  7:58           ` [tip:x86/paravirt] x86/paravirt: Detect over-sized patching bugs in paravirt_patch_insns() tip-bot for Ingo Molnar
2019-05-24  8:01         ` [tip:x86/paravirt] x86/paravirt: Match paravirt patchlet field definition ordering to initialization ordering tip-bot for Ingo Molnar
2019-04-25  8:08     ` [patch 3/3] x86/paravirt: Replace paravirt patch asm magic Peter Zijlstra
2019-04-25  8:19       ` Peter Zijlstra
2019-04-25  9:20       ` Ingo Molnar
2019-05-24  8:00   ` [tip:x86/paravirt] x86/paravirt: Replace the " tip-bot for Thomas Gleixner

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=20190425091717.GA72229@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ak@linux.intel.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).