Re: [RFC] perf: mmap2 not covering VM_CLONE regions

[Kees Cook]

On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/