linux-kernel - Re: [PATCH v2 1/3] x86/uprobes: Fix not using prefixes.nbytes for loop over prefixes.bytes

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: <20201204202855.2851ece0930402faf49b0baa@kernel.org>
Date:   Fri, 4 Dec 2020 20:28:55 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Tom Lendacky <thomas.lendacky@....com>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        "H . Peter Anvin" <hpa@...or.com>, Joerg Roedel <jroedel@...e.de>,
        "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        Jann Horn <jannh@...gle.com>,
        Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
        Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] x86/uprobes: Fix not using prefixes.nbytes for
 loop over prefixes.bytes

On Fri, 4 Dec 2020 12:06:44 +0100
Borislav Petkov <bp@...en8.de> wrote:

> On Fri, Dec 04, 2020 at 09:56:53AM +0900, Masami Hiramatsu wrote:
> > Hmm, there is a difference between Intel SDM and AMD APM.
> > 
> > Intel SDM vol.2
> > 
> > 2.1.1 Instruction Prefixes
> > Instruction prefixes are divided into four groups, each with a set of allowable prefix codes. For each instruction, it
> > is only useful to include up to one prefix code from each of the four groups (Groups 1, 2, 3, 4).
> > 
> > AMD APM vol.3
> > 
> > 1.2.1 Summary of Legacy Prefixes
> > Table 1-1 on page 7 shows the legacy prefixes. The legacy prefixes are organized into five groups, as
> > shown in the left-most column of Table 1-1. An instruction encoding may include a maximum of one
> > prefix from each of the five groups.
> > 
> > So, Intel CPU doesn't accept LOCK-REP because those are in a same prefix
> > group, but AMD says it is acceptable.
> 
> That would be a huge problem for code if both vendors would behave
> differently wrt prefixes.
> 
> > Actually, insn.c only accepts the prefix up to 4, so if there is any
> > instruction which has 5 prefixes, it will fail to parse.
> 
> Well, actually it looks more like a difference in how both vendors group
> things:
> 
> AMD has 5 groups and Intel 4 by putting LOCK and REP together.
> 
> The most important aspect, however, is that you can have as many
> prefixes as you want and there's no hardware limitation on the number -
> I'm being told - just that you can overflow the instruction limit of 15
> and then get a #GP for invalid insn. See here:
> 
> https://sandpile.org/x86/opc_enc.htm
> 
> note #1
> 
> with examples how you can overflow the 15 bytes limit even with a valid
> insn.
> 
> > Note that anyway the same prefix can be repeated, we can see a good example
> > in K8_NOP*.
> 
> Yap.
> 
> > In this case, insn.c just store the 1 osp in the prefixes.bytes[], and
> > just increment prefixes.nbytes for the repeated prefixes.
> > 
> > Anyway, if there is LOCK-REP prefix combination, I have to introduce new
> > insn_field for legacy prefix.
> 
> Well, the legacy prefixes field needs to be of 4 fields because REP and
> LOCK really are two separate but mutually exclusive groups. Why?
> 
> They're used by a disjoint set of instructions, see the AMD doc for both
> REP and LOCK prefixes.
> 
> Which means, you can either have a REP (exclusive or) LOCK but not both.

Yeah, I found that. So I think the "max number of legacy groups on one
instruction" is 4.

> Which means, as a stable@ fix I can use Tom's ARRAY_SIZE() suggestion
> and then later on we can make the legacy prefixes a separate struct.
> Maybe even a struct with a bitfield:

Sorry, but I don't think we need such optimization. It seems over-
optimized the code for me. Moreover, the last-prefix is meaningful
for switching the opcode, so we need to keep it.

Thank you,


> 
> struct legacy_prefixes {
>         /* operand-size override: 0x66 */
>         u8 os_over: 1,
>         /* address-size override: 0x67 */
>            as_over: 1,
>         /*
>          * segment override: 0x2e(CS), 0x3e(DS), 0x26(ES), 0x64(FS), 0x65(GS),
>          * 0x36(SS)
>          */
>            s_over: 1,
>         /* lock prefix: 0xf0 */
>            lock:   1,
>         /* repeat prefixes: 0xf2: REPNx, 0xf3: REPx */
>            rep:    1,
> 	   __resv: 3;
> };
> 
> or so which you can set to denote when you've seen the respective
> prefixes.
> 
> But that we can discuss later.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette


-- 
Masami Hiramatsu <mhiramat@...nel.org>