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: <CA+55aFwbji562dZ0X0B6aDvO_JkvsCpJmVa_S56PDiapoL0agA@mail.gmail.com>
Date:	Fri, 6 Jul 2012 13:59:29 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	mingo@...nel.org, hpa@...or.com, eranian@...gle.com,
	linux-kernel@...r.kernel.org, fweisbec@...il.com,
	akpm@...ux-foundation.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org,
	Robert Richter <robert.richter@....com>
Subject: Re: [tip:perf/core] perf/x86: Fix USER/KERNEL tagging of samples

On Fri, Jul 6, 2012 at 1:48 PM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> On Fri, 2012-07-06 at 11:34 -0700, Linus Torvalds wrote:
>> Also, somebody should check. Is the PEBS information *actually* the
>> instruction pointer (address within the code segment), or is it the
>> "linear address" (segment base + rip)? I hope it is the latter,
>> because in the absense of CS, the segment-based address is very
>> unclear indeed.
>
> I _think_ it is just the RIP since its part of a more general register
> dump (which does not include the segment registers).

Ugh. That would be really sad if true (and I would not be at all
surprised if it *is* true). Sure, flat segments are standard, and once
you get into 64-bit mode I don't think you can even do any CS base,
but afaik the code there is supposed to work on x86-32 too, no?

> Supposing the worst case and Intel simply provides the RIP as is, what
> should we do then?

Well, if the RIP is all you have, the RIP is all you can use, and you
have to just assume flat segments. That will be true in practice, and
if it means that you can't sanely profile vm86 mode etc on x86-32,
that's sad but you have to blame the hardware for that.

And I don't have any huge problems with assuming flat segments and
just "work in the simple cases".

What I reacted negatively to is literally that

    kernel_ip(regs->ip)

test, because once you have "regs", that's absolutely the wrong thing
to do. That kind of test just shows that somebody filled in "regs"
incorrectly. So if you have a pt_regs pointer, that kind of test is
simply crap, and indicates a bug somewhere.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ