linux-kernel - Re: [PATCH v2] [LBR] Dump LBRs on Exception

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-next>] [day] [month] [year] [list]

Date:	Sun, 07 Dec 2014 19:40:48 +0100
From:	Robert Jarzmik <robert.jarzmik@...el.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Robert Jarzmik <robert.jarzmik@...el.com>,
	<linux-kernel@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>,
	X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
	"Berthier\, Emmanuel" <emmanuel.berthier@...el.com>
Subject: Re: [PATCH v2] [LBR] Dump LBRs on Exception

Hi Andy,

Andy Lutomirski <luto@...capital.net> writes:
> On Dec 6, 2014 2:31 AM, "Robert Jarzmik" <robert.jarzmik@...el.com> wrote:
>> We would have a "LBR resource" variable to track who owns the LBR :
>> - nobody : LBR_UNCLAIMED
>> - the exception handler : LBR_EXCEPTION_DEBUG_USAGE
>
> Which exception handler? There can be several on the stack.
All of them, ie. LBR is used by exception handlers, ie. perf cannot use it, just
as what Emmanuel's patch is doing I think. Or said differently LBR are reserved
for expeption handlers only, whichever have the implementation to use them.

>> - case 3d: kernel exception with a reschedule inside
>> -> exception entry
>> -> test lbr_dump_state == EXCEPTION_OWNED => true => STOP LBR
>> -> exception handling
>> -> context_switch()
>> -> perf cannot touch LBR, nobody can
>> -> test lbr_dump_state == EXCEPTION_OWNED => true => START LBR
>
> Careful. This is still the nested exception, and it just did the wrong thing.
Can you be more explicit about the "wrong" thing ? And would that wrong thing be
solved by a per-cpu reference counter ?

>> I might be very wrong in the description as I'm not that sharp on x86, but is
>> there a flaw in the above cases ?
>>
>> If not, a couple of tests and Thomas's per-cpu variable can solve the issue,
>> while keeping the exception handler code simple as Emmanual has proposed
> (given
>> the additionnal test inclusion - which will be designed to not pollute the
> LBR),
>> and having a small impact on perf to solve the resource acquire issue.
>
> On current kernels, percpu memory is vmalloced, so accessing it can fault, so
> you can't touch percpu memory at all from page_fault until the vmalloc fixup
> runs. Sorry :(
What about INIT_PER_CPU_VAR (as in gdt_page) ? Won't that be mapped all the time
without need for faulting in pages ?

> This is a problem with rdmsr, too.
You mean rdmsr can fault in a non-hypervisor environment ? Because that
definetely opens a new range of corner cases.

> It may be worth fixing that. In fact, it may be worth getting rid of lazy vmap
> entirely.
Your battle ? ;)

Anyway, would a static per-cpu variable (or variables, one about resources
usage, one reference counter) solve our cases (ie. 3d) ?

-- 
Robert
--
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/