linux-kernel - Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Nov 2014 15:59:15 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andi Kleen <andi@...stfloor.org>, Borislav Petkov <bp@...en8.de>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in
 schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> My only real objection is that it's going to be ugly and error prone.
> It'll have to be something like:

No.

> because the whole point of this series is to make the IST entries not
> be atomic when they come from userspace.

Andy,  you need to lay off the drugs.

NMI absolutely *has* to be atomic. The whole "oh, there's a per-core
NMI flag and it disables all other NMI's and interrupts" kind of
enforces that.

Trust me. Talking about being able to preempt the NMI handler is just
crazy talk.

                    Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/