linux-kernel - Re: [RFC] perf: mmap2 not covering VM

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: <CAGXu5jLd3yw+RasWgMg_JJPhsfiM+hVhMru4gfkXmAcn7asEdw@mail.gmail.com>
Date:	Wed, 2 Oct 2013 10:14:11 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Stephane Eranian <eranian@...gle.com>,
	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC] perf: mmap2 not covering VM_CLONE regions

On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote:
>> On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> > On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
>> >> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> >> > On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
>> >> >>  - then there are timing attacks, and someone having access to a PMU
>> >> >>    context and who can trigger this SHA1 computation arbitrarily in task
>> >> >>    local context can run very accurate and low noise timing attacks...
>> >> >>
>> >> >>    I don't think the kernel's sha_transform() is hardened against timing
>> >> >>    attacks, it's performance optimized so it has variable execution time
>> >> >>    highly dependent on plaintext input - which leaks information about the
>> >> >>    plaintext.
>> >> >
>> >> > Typical user doesn't have enough priv to profile kernel space; once you
>> >> > do you also have enough priv to see kernel addresses outright (ie.
>> >> > kallsyms etc..).
>> >> >
>> >> I was going to say just that. But that's not the default, paranoid level
>> >> is at 1 by default and not 2. So I supposedly can still do:
>> >>
>> >> $ perf record -e cycles ......
>> >>
>> >> In per-thread mode and collect kernel level addresses.
>> >
>> > Oh right you are.. so yes that's a very viable avenue.
>>
>> You mean simply encoding the vma->vm_mm as the ino number, for instance.
>
> Nah.. I think Kees would very much shoot us on the spot for doing that.
> But with the paranoid level defaulting to 1 the PMU attack on the kernel
> SHA implenentation is feasible.

We already have other kernel address leaks (e.g. heap addresses via
INET_DIAG), and I'd like to avoid adding more. It'd be nice if there
was a common way to uniquely mask these values that are really just
"handles". We could use it both here and in the network code.

Would it be possible to just have a "regular" incrementing handle,
like fd, or are we talking about doing that map for all VMAs, which
would make that mapping unfeasible due to storage needs?

On the other hand, trying to hide kernel addresses from root is no
easy task, especially given that while kptr_restrict has a "2" level,
dmesg_restrict does not. Are these kernel-address-leaking perf modes
already limited to a specific POSIX capability?

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/