linux-kernel - RE: [PATCH v6 07/10] x86, mpx: decode MPX instruction to get bound violation information

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9E0BE1322F2F2246BD820DA9FC397ADE016A5747@shsmsx102.ccr.corp.intel.com>
Date:	Fri, 20 Jun 2014 03:21:58 +0000
From:	"Ren, Qiaowei" <qiaowei.ren@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>,
	"Hansen, Dave" <dave.hansen@...el.com>,
	Borislav Petkov <bp@...en8.de>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v6 07/10] x86, mpx: decode MPX instruction to get bound
 violation information

On 2014-06-20, H. Peter Anvin wrote:
> On 06/19/2014 10:04 AM, Dave Hansen wrote:
>> 
>> Could you please support this position with some data?  I'm a bit
>> skeptical that instruction decoding is going to be a
>> performance-critical path.
>> 
>> I also don't see the extra field that you talked about in the
>> previous thread?  What's the extra field?  I see a 'limit' vs.
>> 'length', but you don't use 'length' at all, so I think you can use
>> it instead, or at least union it.
>> 
>> I've taken a quick stab at trying to consolidate things.  I think I
>> may have screwed up this:
>> 
>> 	insn->limit = MAX_MPX_INSN_SIZE - bytes;
>> 
>> Qiaowei, is there anything fundamentally broken with what I've got here?
>> 
> 
Firstly instructions will be got from user pointer stored in 'ip', and then validate_next() will use 'limit' to make sure that next sizeof(t) bytes can be on the same instruction.

As hpa said, generic decoder, including struct insn and implementation of decoding, is very heavyweight because it has to. So MPX specific decoding should be better choice.

> So I encouraged Qiaowei to do a limited special-purpose decoder,
> simply because the glue to use the generic decoder was almost as
> large.  I am overall not a huge fan of using the generic decoder in
> constrained situation, because the generic decoder is very heavyweight
> not just in terms of performance but in terms of interface -- because it has to.
> 
Thanks,
Qiaowei