All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Grazvydas Ignotas <notasas@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, Denys Vlasenko <dvlasenk@redhat.com>
Subject: Re: [PATCH 0/1] (Was: Linux 3.11-rc4)
Date: Thu, 8 Aug 2013 17:41:07 +0200	[thread overview]
Message-ID: <20130808154107.GA28971@redhat.com> (raw)
In-Reply-To: <CA+55aFw7P7LYNFQzy6nrn9DDn5a0UdYYQNx_7sibShvZPLEcmg@mail.gmail.com>

On 08/07, Linus Torvalds wrote:
>
> Now, I do agree that the debug registers are *much* less likely to
> have those kinds of really subtle issues, so maybe relaxing some of
> the tests might be reasonable. I'd be a bit nervous about it, but if
> it's *only* the length/alignment, and Intel people can be convinced
> that it doesn't result in any nasty undefined behavior (as long as the
> address is in user space), maybe we could make that change just to
> make it easier for Wine.

Oh, I do not know. And again, this way a user can't notice the problem
if the arguments are wrong.

But personally I think it would be nice to cleanup the perf interface,
although probably it is too later.

On x86 execute breakpoints are only a single byte, which has to be
the first byte of the instruction. IOW the hardware requires len = 1
in dr7 or it doesn't work (iirc).

But for some reason perf requires bp_len = sizeof(long), not 1. And
note that it sets info->len = X86_BREAKPOINT_LEN_X. The comment says:

	x86 inst breakpoints need to have a specific undefined len

but despite its "special" name LEN_X is simply LEN_1, and other code
relies on this fact.

Now, ptrace correctly requires DR_LEN_1. So arch_bp_generic_fields()
translates this into "gen_len = sizeof(long)" for validation.

arch_build_bp_info() thinks that X86_BREAKPOINT_EXECUTE should have
->bp_len == sizeof(long), so we translate it back into LEN_1 internally.

This looks confusing, imho. And imho X86_BREAKPOINT_LEN_X should die.

> But the kernel address checking definitely needs to stay around for
> security reasons.

Sure. And btw it doesn't look right. I sent the patch below twice (iirc),
perhaps I should resend it again.

Oleg.


Date: Fri, 9 Nov 2012 19:29:43 +0100
Subject: [PATCH] arch_check_bp_in_kernelspace: fix the range check

arch_check_bp_in_kernelspace() tries to avoid the overflow and does 2
TASK_SIZE checks but it needs OR, not AND. Consider va = TASK_SIZE -1
and len = 2 case.

Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>

--- x/arch/arm64/kernel/hw_breakpoint.c
+++ x/arch/arm64/kernel/hw_breakpoint.c
@@ -293,7 +293,7 @@ int arch_check_bp_in_kernelspace(struct 
 	va = info->address;
 	len = get_hbp_len(info->ctrl.len);
 
-	return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 /*
--- x/arch/arm/kernel/hw_breakpoint.c
+++ x/arch/arm/kernel/hw_breakpoint.c
@@ -464,7 +464,7 @@ int arch_check_bp_in_kernelspace(struct 
 	va = info->address;
 	len = get_hbp_len(info->ctrl.len);
 
-	return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 /*
--- x/arch/sh/kernel/hw_breakpoint.c
+++ x/arch/sh/kernel/hw_breakpoint.c
@@ -132,7 +132,7 @@ int arch_check_bp_in_kernelspace(struct 
 	va = info->address;
 	len = get_hbp_len(info->len);
 
-	return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 int arch_bp_generic_fields(int sh_len, int sh_type,
--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct 
 	va = info->address;
 	len = get_hbp_len(info->len);
 
-	return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 int arch_bp_generic_fields(int x86_len, int x86_type,



  reply	other threads:[~2013-08-08 15:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-04 21:09 Linux 3.11-rc4 Linus Torvalds
2013-08-05  2:34 ` O_TMPFILE fs corruption (Re: Linux 3.11-rc4) Andy Lutomirski
2013-08-05  3:45   ` Linus Torvalds
2013-08-05  4:45     ` Andrew Lutomirski
2013-08-05  8:26     ` Christoph Hellwig
2013-08-05 16:04       ` Jörn Engel
2013-08-05 14:31     ` Al Viro
2013-08-05  4:20 ` Linux 3.11-rc4 Felipe Contreras
2013-08-05 13:29   ` Oleg Nesterov
2013-08-05 14:27     ` Felipe Contreras
2013-08-05 14:39       ` Oleg Nesterov
2013-08-05 17:02         ` Felipe Contreras
2013-08-05 17:11           ` Oleg Nesterov
2013-08-05 17:40             ` Felipe Contreras
2013-08-05 17:56               ` Oleg Nesterov
2013-08-05 17:39     ` Linus Torvalds
2013-08-05 17:43       ` Felipe Contreras
2013-08-05 18:08         ` Felipe Contreras
2013-08-05 17:47       ` Oleg Nesterov
2013-08-05 18:46   ` Oleg Nesterov
2013-08-05 18:54     ` Linus Torvalds
2013-08-05 18:57       ` Oleg Nesterov
2013-08-05 19:06         ` Linus Torvalds
2013-08-06 15:43   ` [PATCH 0/1] (Was: Linux 3.11-rc4) Oleg Nesterov
2013-08-06 15:43     ` [PATCH 1/1] Revert "ptrace: PTRACE_DETACH should do flush_ptrace_hw_breakpoint(child)" Oleg Nesterov
2013-08-07 12:05     ` [PATCH 0/1] (Was: Linux 3.11-rc4) Grazvydas Ignotas
2013-08-07 17:22       ` Oleg Nesterov
2013-08-07 19:26       ` Linus Torvalds
2013-08-07 19:27         ` Oleg Nesterov
2013-08-07 19:47           ` Linus Torvalds
2013-08-08 15:41             ` Oleg Nesterov [this message]
2013-08-08 16:25               ` Linus Torvalds
2013-08-08 16:54               ` Frederic Weisbecker
2013-08-08 18:15                 ` Oleg Nesterov
2013-08-09 16:45                   ` Frederic Weisbecker
2013-08-09 17:12                     ` Oleg Nesterov

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=20130808154107.GA28971@redhat.com \
    --to=oleg@redhat.com \
    --cc=dvlasenk@redhat.com \
    --cc=felipe.contreras@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=notasas@gmail.com \
    --cc=torvalds@linux-foundation.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.