linux-kernel - Re: [PATCH 1/3] uprobes: add comment with insn opcodes, mnemonics and why we dont support them

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:	Mon, 07 Jul 2014 20:41:56 +0200
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Jim Keniston <jkenisto@...ux.vnet.ibm.com>
CC:	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...nel.org>, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH 1/3] uprobes: add comment with insn opcodes, mnemonics
 and why we dont support them

On 07/07/2014 07:12 PM, Jim Keniston wrote:
> Also, as noted below, some of the opcodes that were invalid back in
> 2006-2007 are now valid.  However, arpl, lar, and lsl still look
> questionable to me.

arpl, lar, and lsl never throw any exceptions
apart from those which any memory-referencing
arithmetic insn can throw.

In particular, they don't throw exceptions
if their operand is an invalid segment selector.

No additional code needed for them to work
when probed.

Thus I think no harm done enabling them.

>> + * Opcodes which can be enabled right away:
>> + * 63 - arpl. This insn has no unusual exceptions (it's basically an arith op).
> 
> The AMD64 Architecture Programmer's Manual documents arpl as a system
> instruction ("Adjust Requestor Privilege Level").  Is this really valid
> for user-space apps?

"arpl r1,r2" does the following:

"If bits 0-1 of r2 are less than same bits of r1,
set them to bits from r1 and set ZF, else clear ZF.

I doubt anyone uses this insn, but it *is* just a funky
arith op. It doesn't even check whether register values
are valid selectors.

The idea was that it helps to perform "lowering"
of selector privileges when code in comforming
code segment uses "untrusted" (caller-supplied)
selector values to access data.
Example: if CPL-2 caller gave us CPL-0 selector,
convert it to CPL-2 selector.
Some misguided guy at Intel thought it's vitally important to save
a few measly CPU cycles doing this, and created a special insn.

>> + * 0f 38-3f - 3-byte opcodes (why?? all look safe)
> 
> My AMD64 reference back then (AMD64 Architecture Programmer's Manual Vol
> 3, dated September 2003) showed all those opcodes as invalid.
> 
>> + * 0f 78 - vmread
>> + * 0f 79 - vmwrite
>> + * 0f 7a - undefined
>> + * 0f 7b - undefined
>> + * 0f 7c - undefined
>> + * 0f 7d - undefined
>> + * 0f a6 - undefined
>> + * 0f a7 - undefined
>> + * 0f b8 - popcnt (why?? it's an ordinary ALU op)hinhinkyky
> 
> Invalid in 2003 AMD64 ref.
>
>> + * 0f d0 - undefined
>> + * 0f f0 - lddqu (why?? it's an ordinary vector load op)
> 
> Invalid in 2003 AMD64 ref.

Correct. There insns are newer than 2003.
--
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/