linux-kernel - Re: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's

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: <53469F95.1030709@redhat.com>
Date:	Thu, 10 Apr 2014 15:41:41 +0200
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Anton Arapov <aarapov@...hat.com>,
	David Long <dave.long@...aro.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Jonathan Lebon <jlebon@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's

On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
> On 04/08, Jim Keniston wrote:
>>
>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
>>> 0xe8. Anything else?
>>
>> No, I think e8 is the only call instruction uprobes will see.
> 
> Good.

There is this monstrosity, "16-bit override for branches" in 64-mode:

66 e8 nn nn       callw   <offset16>

Nobody sane uses it because it truncates instruction pointer.

Or rather, *I think* it should truncate it (i.e. zero-extend to full width),
but conceivably some CPUs can be buggy wrt that:
they can decide to modify only lower 16 bits of IP,
or even they can decided to use signed <offset16> but apply it
to full-width RIP.

AMD manuals are not clear on what exactly should happen.

I am sure no one sane uses this form of branch instructions
in 32-bit and 64-bit code.

I don't think we should be trying to support it "correctly"
(we can just let program crash with SIGILL or something),
we only need to make sure we don't overlook its existence
and thus are not tricked into touching or modifying unrelated data.

Imagine that   66 e8 nn nn    bytes are exactly at the end of
a page, and we wrongly assume that offset is 32-bit, not 16-bit.

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