Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1193984 > unrolled thread

Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack Borislav Petkov <bp@alien8.de> - 2015-07-28 12:00 +0200
    Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack Borislav Petkov <bp@alien8.de> - 2015-07-30 06:20 +0200

#1193984 — Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack

On Fri, Jul 24, 2015 at 10:57:06PM -0700, Andy Lutomirski wrote:
> There's nothing IST-worthy about #BP/int3.  We don't allow kprobes
> in the small handful of places in the kernel that run at CPL0 with
> an invalid stack, and 32-bit kernels have used normal interrupt
> gates for #BP forever.
> 
> Furthermore, we don't allow kprobes in places that have usergs while
> in kernel mode, so "paranoid" is also unnecessary.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  arch/x86/entry/entry_64.S |  2 +-
>  arch/x86/kernel/traps.c   | 26 +++++++++++++-------------
>  2 files changed, 14 insertions(+), 14 deletions(-)

...

> @@ -494,7 +494,15 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
>  	if (poke_int3_handler(regs))
>  		return;
>  
> +	/*
> +	 * Use ist_enter despite the fact that we don't use an IST stack.
> +	 * We can be called from a kprobe in non-CONTEXT_KERNEL kernel
> +	 * mode or even during context tracking state changes.
> +	 *
> +	 * This means that we can't schedule.  That's okay.
> +	 */
>  	ist_enter(regs);

Let's rename that thing. Call it atomic_ctxt_enter or whatever...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1195706

On Wed, Jul 29, 2015 at 10:57:26AM -0700, Andy Lutomirski wrote:
> OK if I do that as a follow-up?  It would probably want to be a
> separate patch anyway.

Of course.

> Hmm, I'm starting to like this new regime in which we never ever
> switch to user mode from anywhere other than the standard kernel
> stack.  It looks like even Xen may play along and do it cleanly soon
> :)  Maybe I'll even add an assertion somewhere to make sure we don't
> break it.  (I think this also means that the bad iret fixup can be
> simplified.)

Definitely sounds like a nice, logical thing. We sometimes switch stacks
to land on the kernel stack before returning to user mode (IST and all)
but I guess that's a clean enough thing to do. Oh, and only a couple of
insns so yeah.

> Also, with all this stuff applied (and the modify_ldt thing, once the
> Xen folks figure out what's wrong), I think we can reinstate the old
> LARL check for 16-bit segments and thus prevent naughty users from
> banging on espfix using only sigreturn.

Uuh, and then only check ZF. I guess this should cover all the legacy
cases, which is nice.

Yeah, sounds coolio. :-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web