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

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

On Tue, Dec 2, 2014 at 11:56 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Tue, 2 Dec 2014, Andy Lutomirski wrote:
>> TBH, I'm wondering whether this is actually a good idea.  It might be
>> more valuable and less scary to try to make this work for BUG instead.
>> To get the most impact, it might be worth allocating a new exception
>> vector for BUG and using 'int 0xwhatever', and the prologue to that
>> could read out all the MSRs without any branches.
>
> BUG is pretty uninteresting. We usually know how we got there. Now
> where LBR might be useful is if you have stack corruption and branch
> into nirvana or access random crap via a few hoops. There the LBR data
> might help, because the corrupted stack does not tell anything.
>
> So yes, this is a corner case debugging scenario, but given the
> complexity of coordination with perf and the possible intrusiveness in
> the low level entry path, we really need to see a few real world
> examples where this helps, aside of the constructed case.
>

One option would be to treat this as the debugging feature that it is.

Don't change the exception entry code at all.  Instead add a run-time
switch that will ask perf to set up the LBR stuff appropriately and
will change the IDT entries to stubs that first use rdmsr to copy all
the LBRs to some per-cpu, per-vector area and then jump to the real
entry point.

Yes, performance will suck, and there will be some artifacts if the
exception nests inside itself before reporting the error (which can
happen for page faults, I think), but this isn't the end of the world
if it's an opt-in feature.

And the whole pile of rdmsrs can be generated at run-time to match the
running CPU.

--Andy

> Thanks,
>
>         tglx



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/