linux-kernel - RE: [PATCH v3 3/6] x86/gsseg: make asm_load_gs

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: <bdf3f750103f4b64a697191d1edb8ad0@AcuMS.aculab.com>
Date:   Mon, 17 Oct 2022 07:49:41 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "'H. Peter Anvin'" <hpa@...or.com>, 'Xin Li' <xin3.li@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "brgerst@...il.com" <brgerst@...il.com>,
        "chang.seok.bae@...el.com" <chang.seok.bae@...el.com>
Subject: RE: [PATCH v3 3/6] x86/gsseg: make asm_load_gs_index() take an u16

From: H. Peter Anvin
> Sent: 15 October 2022 03:41
> 
> On October 14, 2022 5:28:25 AM PDT, David Laight <David.Laight@...LAB.COM> wrote:
> >From: Xin Li
> >> Sent: 13 October 2022 21:02
> >>
> >> From: "H. Peter Anvin (Intel)" <hpa@...or.com>
> >>
> >> Let gcc know that only the low 16 bits of load_gs_index() argument
> >> actually matter. It might allow it to create slightly better
> >> code. However, do not propagate this into the prototypes of functions
> >> that end up being paravirtualized, to avoid unnecessary changes.
> >
> >Using u16 will almost always make the code worse.
> >At some point the value has to be masked and/or extended
> >to ensure an out of range value doesn't appear in
> >a register.
> >
> >	David
> 
> Is that a general statement or are you actually invoking it in this case?
> This is about it being a narrowing input, *removing* such constraints.

It is a general statement.
You suggested you might get better code.
If fact you'll probably get worse code.
It might not matter here, but ...

Most modern calling conventions use cpu register to pass arguments
and results.
So the compiler is required to ensure that u16 values are in range
in either the caller or called code (or both).
Just because the domain of a value is small doesn't mean that
the best type isn't 'int' or 'unsigned int'.

Additionally (except on x86) any arithmetic on sub-32bit values
requires additional instructions to mask the result.

Even on x86-64 if you index an array with an 'int' the compiler
has to generate code to sign extend the value to 64 bits.
You get better code for 'signed long' or unsigned types.
This is probably true for all 64bit architectures.

Since (most) cpu have both sign extending an zero extending
loads from memory, it can make sense to use u8 and u16 to
reduce the size of structures.
But for function arguments and function locals it almost
always makes the code worse.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)