linux-kernel - Re: [patch 4/7] Immediate Values

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: <20071020164721.GA6614@Krystal>
Date:	Sat, 20 Oct 2007 12:47:22 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@....de>,
	Chuck Ebbert <cebbert@...hat.com>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [patch 4/7] Immediate Values - i386 Optimization

* Jeremy Fitzhardinge (jeremy@...p.org) wrote:
> H. Peter Anvin wrote:
> > Allowing different registers should be doable, but if so, one would have
> > to put 0: at the *end* of the instruction and use (0f)-4 instead, since
> > the non-%eax forms are one byte longer.
> >   
> 
> OK, that's already a problem since its using "=r" as the constraint.
> 

Hi Jeremy,

I have tried generating asm-to-"register" c variables for char, short
and int on i386 and I do not see this happening. The char opcode is
always 1 byte, short 2 bytes and int 1 byte. Result:

gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)

   8:   b3 02                   mov    $0x2,%bl
   a:   b1 03                   mov    $0x3,%cl
   c:   b2 04                   mov    $0x4,%dl
   e:   b0 05                   mov    $0x5,%al

  4f:   66 be 06 00             mov    $0x6,%si
  53:   66 bb 07 00             mov    $0x7,%bx
  57:   66 b9 08 00             mov    $0x8,%cx
  5b:   66 ba 09 00             mov    $0x9,%dx
  5f:   66 b8 0a 00             mov    $0xa,%ax

  9f:   bb 0b 00 00 00          mov    $0xb,%ebx
  a4:   be 0c 00 00 00          mov    $0xc,%esi
  a9:   b9 0d 00 00 00          mov    $0xd,%ecx
  ae:   ba 0e 00 00 00          mov    $0xe,%edx
  b3:   b8 0f 00 00 00          mov    $0xf,%eax


I notice that having a "=r" inline assembly that outputs to the first
"register char" variable seems to be problematic. It fails with the
following error:

/tmp/ccy35Hq1.s: Assembler messages:
/tmp/ccy35Hq1.s:15: Error: bad register name `%sil'

But it seems to be specific to "register" variables, which I do not use
in my immediate values.


> > This also seems "safer", since an imm32 is always the last thing in the
> > instruction.
> 
> Good idea.  If gas/gcc generates entirely the wrong addressing mode,
> then we've got bigger problems.
> 

I am still trying to figure out if we must assume that gas will produce
different length opcodes for mov instructions. The choice is:

- Either I use a "r" constraint and let gcc produce the instructions,
  that I need to assume to have correct size so I can align their
  immediate values (therefore, taking the offset from the end of the
  instruction will not help). Here, if gas changes its behavior
  dramatically for a given immediate value size, it will break.

- Second choice is to stick to a particular register, choosing the one
  with the less side-effect, and encoding the instruction ourselves. I
  start to think that this second solution might be safer, even though
  we wouldn't let the compiler select the register which has the less
  impact by itself.

Any comments about this ?

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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/