linux-kernel - Re: [PATCH] perf, x86: Disable sanity check

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:	Fri, 20 Apr 2012 09:16:42 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arun Sharma <asharma@...com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Namhyung Kim <namhyung.kim@....com>,
	Tom Zanussi <tzanussi@...il.com>,
	linux-perf-users@...r.kernel.org
Subject: Re: [PATCH] perf, x86: Disable sanity check

On Fri, Apr 20, 2012 at 2:11 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> Makes me really nervous.. Ingo, Linus ?

I don't care as long as this only *ever* triggers for user stacks, and
the code verifies that. And I'm not sure it does, actually.

Why am I not sure? Because it uses copy_from_user_nmi(), which in turn
uses "access_ok()". But can we perhaps have the perf event happen
*while* the kernel has done a "set_fs(KERNEL_DS)" - and we just
happen to follow the user stack too? In which case we may be copying
kernel memory.

So I think this user stack following code is buggy in *other* ways.

Guys: stack following has to be *f^&%ing* careful! This shows yet
again how people blithely follow frame pointers without verifying
everything they damn well can.

Also, I note that the deepest stack chain allowed is something
*ridiculously* deep (like 255), and we use copy_from_user_nmi() for
this each entry. Which is slow as hell. So I would suggest at least
considering limiting that depth more.

End result: I'm ok with removing that one test. But I want more tests
to replace it. The user frame pointer had damn well better be in user
space (and no, "access_ok()" is not valid or sufficient in interrupt
context!) and I suspect there are other things you could check.

                  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/