linux-kernel - Re: [GIT PULL] perf changes for v3.8

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]

Message-ID: <CA+55aFyZ2kAQPmZSv_sfHDAR1gusOxO22TRX-kqSim-cZrMscw@mail.gmail.com>
Date:	Thu, 13 Dec 2012 08:33:54 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Ahern <dsahern@...il.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] perf changes for v3.8

On Thu, Dec 13, 2012 at 8:24 AM, David Ahern <dsahern@...il.com> wrote:
>
> Without the kernel side restriction existing perf binaries will crash all
> running VMs.

..and they apparently always did, and we had that situation for years
without anybody ever even noticing.

And no, it's not a security fix, since you can just add the 'H' flag
and it will *still* crash according to the thread I saw (ie there is
some race condition in PEBS handling at VM entry, possibly at a
hardware level).

So the real security fix has to either fix the root cause or the
actual crash (which apparently is unknown), or to make perf be
root-only at least in the presense of virtualization.

The "return EOPNOTSUPP" thing does nothing but annoy people.

> I could write the patch to completely invert the exclude_guest
> logic -- make it include_guest. That breaks all existing perf binaries as
> well - just a different syntax that gets broken. That regression is
> acceptable?

It's not a regression since THAT CODE NEVER WORKED, for chissake! The
case of people actually profiling into virtual machines crashes the
running VMs, as you say. There's no way in hell we can call it a
regression to say "you now have to use a flag if you profile a load
with virtualization", since there wasn't any working case to begin
with.

                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/