linux-kernel - Re: [PATCH 1/3] perf/x86/intel: output LBR support statement after validation

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: <CABPqkBQH+_-z8SnXAKKH-3TwpPGRsBgHoW=EEXQKsFT1ZRnCkg@mail.gmail.com>
Date:	Thu, 2 Jun 2016 10:28:18 -0700
From:	Stephane Eranian <eranian@...gle.com>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	David Carrillo-Cisneros <davidcc@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	"Yan, Zheng" <zheng.z.yan@...el.com>,
	Kan Liang <kan.liang@...el.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 1/3] perf/x86/intel: output LBR support statement after validation

Andi,

On Thu, Jun 2, 2016 at 9:04 AM, Andi Kleen <ak@...ux.intel.com> wrote:
>
>
> I don't think the context switch support is really needed. It's only
> needed for saving/restoring LBRs, and we only do that with LBR callstacks.
> In any other LBR mode that LBRs are only flushed on context switch
> But LBR callstacks will never put kernel addresses into the LBRs
> because they are forced to set a ring 3 filter. So you can't have
> kernel addresses in the LBR when saving/restoring them
> (unless I missed some case)
>
It is not because you force LBR to ring3 only that you do not capture
kernel addresses in the FROM field.
Keep in mind that LBR priv level filtering applies to the target of
the branch and not the source. You might
still get a kernel address if returning from kernel. Now, in callstack
mode, I think the return branch is never
actually recorded in the LBR, it just causes a pop, so theoretically
this should not happen. I'd like to be
100% sure of that, though.

> Dropping that will likely simplify the patch somewhat.
>
> -Andi