All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/3] objtool: Few x86 decoder updates
@ 2025-09-24 13:45 Peter Zijlstra
  2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
  To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre

Hi,

few patches that update the 0xea/udb situation and fix up the x86_64 NOP
decoding.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 1/3] objtool/x86: Remove 0xea hack
  2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
@ 2025-09-24 13:45 ` Peter Zijlstra
  2025-09-25  9:55   ` Alexandre Chartre
  2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
  2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
  2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
  2 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
  To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre

Was properly fixed in the decoder with commit 4b626015e1bf ("x86/insn:
Stop decoding i64 instructions in x86-64 mode at opcode")

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 tools/objtool/arch/x86/decode.c |    9 ---------
 1 file changed, 9 deletions(-)

--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -189,15 +189,6 @@ int arch_decode_instruction(struct objto
 	op2 = ins.opcode.bytes[1];
 	op3 = ins.opcode.bytes[2];
 
-	/*
-	 * XXX hack, decoder is buggered and thinks 0xea is 7 bytes long.
-	 */
-	if (op1 == 0xea) {
-		insn->len = 1;
-		insn->type = INSN_BUG;
-		return 0;
-	}
-
 	if (ins.rex_prefix.nbytes) {
 		rex = ins.rex_prefix.bytes[0];
 		rex_w = X86_REX_W(rex) >> 3;



^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 2/3] objtool/x86: Add UDB support
  2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
  2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
@ 2025-09-24 13:45 ` Peter Zijlstra
  2025-09-25  9:56   ` Alexandre Chartre
  2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
  2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
  2 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
  To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre

Per commit 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA"), make
sure objtool also recognises UDB as a #UD instruction.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 tools/objtool/arch/x86/decode.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -683,6 +683,10 @@ int arch_decode_instruction(struct objto
 		insn->type = INSN_SYSRET;
 		break;
 
+	case 0xd6: /* udb */
+		insn->type = INSN_BUG;
+		break;
+
 	case 0xe0: /* loopne */
 	case 0xe1: /* loope */
 	case 0xe2: /* loop */



^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
  2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
  2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
@ 2025-09-24 13:45 ` Peter Zijlstra
  2025-09-24 17:34   ` Alexandre Chartre
  2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
  2 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
  To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre

For x86_64 the kernel consistently uses 2 instructions for all NOPs:

  90       - NOP
  0f 1f /0 - NOPL

Notably:

 - REP NOP is PAUSE, not a NOP instruction.

 - 0f {0c...0f} is reserved space,
   except for 0f 0d /1, which is PREFETCHW, not a NOP.

 - 0f {19,1c...1f} is reserved space,
   except for 0f 1f /0, which is NOPL.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 tools/objtool/arch/x86/decode.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
 		break;
 
 	case 0x90:
-		insn->type = INSN_NOP;
+		if (prefix != 0xf3) /* REP NOP := PAUSE */
+			insn->type = INSN_NOP;
 		break;
 
 	case 0x9c:
@@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
 
 		} else if (op2 == 0x0b || op2 == 0xb9) {
 
-			/* ud2 */
+			/* ud2, ud1 */
 			insn->type = INSN_BUG;
 
-		} else if (op2 == 0x0d || op2 == 0x1f) {
+		} else if (op2 == 0x1f) {
 
-			/* nopl/nopw */
-			insn->type = INSN_NOP;
+			/* 0f 1f /0 := NOPL */
+			if (modrm_reg == 0)
+				insn->type = INSN_NOP;
 
 		} else if (op2 == 0x1e) {
 



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
@ 2025-09-24 17:34   ` Alexandre Chartre
  2025-09-24 18:41     ` Peter Zijlstra
  2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
  1 sibling, 1 reply; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-24 17:34 UTC (permalink / raw)
  To: Peter Zijlstra, jpoimboe, x86; +Cc: alexandre.chartre, linux-kernel


On 9/24/25 15:45, Peter Zijlstra wrote:
> For x86_64 the kernel consistently uses 2 instructions for all NOPs:
> 
>    90       - NOP
>    0f 1f /0 - NOPL
>
>
> Notably:
> 
>   - REP NOP is PAUSE, not a NOP instruction.
> 
>   - 0f {0c...0f} is reserved space,
>     except for 0f 0d /1, which is PREFETCHW, not a NOP.
> 
>   - 0f {19,1c...1f} is reserved space,
>     except for 0f 1f /0, which is NOPL.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>   tools/objtool/arch/x86/decode.c |   12 +++++++-----
>   1 file changed, 7 insertions(+), 5 deletions(-)
> 
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
>   		break;
>   
>   	case 0x90:
> -		insn->type = INSN_NOP;
> +		if (prefix != 0xf3) /* REP NOP := PAUSE */
> +			insn->type = INSN_NOP;
>   		break;

So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?

>   
>   	case 0x9c:
> @@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
>   
>   		} else if (op2 == 0x0b || op2 == 0xb9) {
>   
> -			/* ud2 */
> +			/* ud2, ud1 */
>   			insn->type = INSN_BUG;
>   
> -		} else if (op2 == 0x0d || op2 == 0x1f) {
> +		} else if (op2 == 0x1f) {
>   
> -			/* nopl/nopw */
> -			insn->type = INSN_NOP;
> +			/* 0f 1f /0 := NOPL */
> +			if (modrm_reg == 0)
> +				insn->type = INSN_NOP;
>   
>   		} else if (op2 == 0x1e) {
>   

And this covers all other NOPs (0x0f 0x1f ...), including NOP6 which has
a 0x66 preifx (0x66 0xf 0x1f ...) ?

 From arch/x86/include/asm/nops.h we have:

/*
  * Generic 64bit nops from GAS:
  *
  * 1: nop
  * 2: osp nop
  * 3: nopl (%eax)
  * 4: nopl 0x00(%eax)
  * 5: nopl 0x00(%eax,%eax,1)
  * 6: osp nopl 0x00(%eax,%eax,1)
  * 7: nopl 0x00000000(%eax)
  * 8: nopl 0x00000000(%eax,%eax,1)
  */
#define BYTES_NOP1      0x90
#define BYTES_NOP2      0x66,BYTES_NOP1
#define BYTES_NOP3      0x0f,0x1f,0x00
#define BYTES_NOP4      0x0f,0x1f,0x40,0x00
#define BYTES_NOP5      0x0f,0x1f,0x44,0x00,0x00
#define BYTES_NOP6      0x66,BYTES_NOP5
#define BYTES_NOP7      0x0f,0x1f,0x80,0x00,0x00,0x00,0x00
#define BYTES_NOP8      0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00


alex.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-24 17:34   ` Alexandre Chartre
@ 2025-09-24 18:41     ` Peter Zijlstra
  2025-09-25  9:55       ` Alexandre Chartre
  0 siblings, 1 reply; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 18:41 UTC (permalink / raw)
  To: Alexandre Chartre; +Cc: jpoimboe, x86, linux-kernel

On Wed, Sep 24, 2025 at 07:34:00PM +0200, Alexandre Chartre wrote:
> 
> On 9/24/25 15:45, Peter Zijlstra wrote:
> > For x86_64 the kernel consistently uses 2 instructions for all NOPs:
> > 
> >    90       - NOP
> >    0f 1f /0 - NOPL
> > 
> > 
> > Notably:
> > 
> >   - REP NOP is PAUSE, not a NOP instruction.
> > 
> >   - 0f {0c...0f} is reserved space,
> >     except for 0f 0d /1, which is PREFETCHW, not a NOP.
> > 
> >   - 0f {19,1c...1f} is reserved space,
> >     except for 0f 1f /0, which is NOPL.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> >   tools/objtool/arch/x86/decode.c |   12 +++++++-----
> >   1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > --- a/tools/objtool/arch/x86/decode.c
> > +++ b/tools/objtool/arch/x86/decode.c
> > @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
> >   		break;
> >   	case 0x90:
> > +		if (prefix != 0xf3) /* REP NOP := PAUSE */
> > +			insn->type = INSN_NOP;
> >   		break;
> 
> So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?

Yes. Everything with opcode 0x90, except 0xf3 0x90, which as stated is
PAUSE.

> >   	case 0x9c:
> > @@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
> >   		} else if (op2 == 0x0b || op2 == 0xb9) {
> > +			/* ud2, ud1 */
> >   			insn->type = INSN_BUG;
> > +		} else if (op2 == 0x1f) {
> > +			/* 0f 1f /0 := NOPL */
> > +			if (modrm_reg == 0)
> > +				insn->type = INSN_NOP;
> >   		} else if (op2 == 0x1e) {
> 
> And this covers all other NOPs (0x0f 0x1f ...), including NOP6 which has
> a 0x66 preifx (0x66 0xf 0x1f ...) ?

Sorta, it accepts everything with opcode 0f 1f and modrm_reg==0, which is
how NOPL is encoded.

Both: 66 66 66 66 66 66 66 66 66 66 66 66 66 66 90 (NOP15)
And:  66 66 66 66 66 66 66 0f 1f 84 00 00 00 00 00 (NOP15)

will be accepted here as max length instructions. The kernel will not
actually use those, since a bunch of micro archs have decode penalties
for too many prefixes.

> From arch/x86/include/asm/nops.h we have:

You're looking at old code :-)

> /*
>  * Generic 64bit nops from GAS:
>  *
>  * 1: nop
>  * 2: osp nop
>  * 3: nopl (%eax)
>  * 4: nopl 0x00(%eax)
>  * 5: nopl 0x00(%eax,%eax,1)
>  * 6: osp nopl 0x00(%eax,%eax,1)
>  * 7: nopl 0x00000000(%eax)
>  * 8: nopl 0x00000000(%eax,%eax,1)

 * 9: cs nopl 0x00000000(%eax,%eax,1)
 * 10: osp cs nopl 0x00000000(%eax,%eax,1)
 * 11: osp osp cs nopl 0x00000000(%eax,%eax,1)

>  */
> #define BYTES_NOP1      0x90
> #define BYTES_NOP2      0x66,BYTES_NOP1
> #define BYTES_NOP3      0x0f,0x1f,0x00
> #define BYTES_NOP4      0x0f,0x1f,0x40,0x00
> #define BYTES_NOP5      0x0f,0x1f,0x44,0x00,0x00
> #define BYTES_NOP6      0x66,BYTES_NOP5
> #define BYTES_NOP7      0x0f,0x1f,0x80,0x00,0x00,0x00,0x00
> #define BYTES_NOP8      0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00

#define BYTES_NOP9      0x2e,BYTES_NOP8
#define BYTES_NOP10     0x66,BYTES_NOP9
#define BYTES_NOP11     0x66,BYTES_NOP10

But yes, first two are NOP and then it switches to NOPL for 3 bytes and
longer (2 opcode, 1 modrm). Where for 11 bytes we have:

 - 3 prefixes
 - 2 opcode
 - 1 modrm
 - 1 sib
 - 4 displacement


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-24 18:41     ` Peter Zijlstra
@ 2025-09-25  9:55       ` Alexandre Chartre
  2025-09-25 10:03         ` Peter Zijlstra
  0 siblings, 1 reply; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25  9:55 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: alexandre.chartre, jpoimboe, x86, linux-kernel


On 9/24/25 20:41, Peter Zijlstra wrote:
> On Wed, Sep 24, 2025 at 07:34:00PM +0200, Alexandre Chartre wrote:
>>
>> On 9/24/25 15:45, Peter Zijlstra wrote:
>>> For x86_64 the kernel consistently uses 2 instructions for all NOPs:
>>>
>>>     90       - NOP
>>>     0f 1f /0 - NOPL
>>>
>>>
>>> Notably:
>>>
>>>    - REP NOP is PAUSE, not a NOP instruction.
>>>
>>>    - 0f {0c...0f} is reserved space,
>>>      except for 0f 0d /1, which is PREFETCHW, not a NOP.
>>>
>>>    - 0f {19,1c...1f} is reserved space,
>>>      except for 0f 1f /0, which is NOPL.
>>>
>>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>>> ---
>>>    tools/objtool/arch/x86/decode.c |   12 +++++++-----
>>>    1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> --- a/tools/objtool/arch/x86/decode.c
>>> +++ b/tools/objtool/arch/x86/decode.c
>>> @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
>>>    		break;
>>>    	case 0x90:
>>> +		if (prefix != 0xf3) /* REP NOP := PAUSE */
>>> +			insn->type = INSN_NOP;
>>>    		break;
>>
>> So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?
> 
> Yes. Everything with opcode 0x90, except 0xf3 0x90, which as stated is
> PAUSE.
> 

What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?


>>>    	case 0x9c:
>>> @@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
>>>    		} else if (op2 == 0x0b || op2 == 0xb9) {
>>> +			/* ud2, ud1 */
>>>    			insn->type = INSN_BUG;
>>> +		} else if (op2 == 0x1f) {
>>> +			/* 0f 1f /0 := NOPL */
>>> +			if (modrm_reg == 0)
>>> +				insn->type = INSN_NOP;
>>>    		} else if (op2 == 0x1e) {
>>
>> And this covers all other NOPs (0x0f 0x1f ...), including NOP6 which has
>> a 0x66 preifx (0x66 0xf 0x1f ...) ?
> 
> Sorta, it accepts everything with opcode 0f 1f and modrm_reg==0, which is
> how NOPL is encoded.
> 
> Both: 66 66 66 66 66 66 66 66 66 66 66 66 66 66 90 (NOP15)
> And:  66 66 66 66 66 66 66 0f 1f 84 00 00 00 00 00 (NOP15)
> 
> will be accepted here as max length instructions. The kernel will not
> actually use those, since a bunch of micro archs have decode penalties
> for too many prefixes.
> 
>>  From arch/x86/include/asm/nops.h we have:
> 
> You're looking at old code :-)
> 

Correct, I was on the 5.15 branch.

alex.

>> /*
>>   * Generic 64bit nops from GAS:
>>   *
>>   * 1: nop
>>   * 2: osp nop
>>   * 3: nopl (%eax)
>>   * 4: nopl 0x00(%eax)
>>   * 5: nopl 0x00(%eax,%eax,1)
>>   * 6: osp nopl 0x00(%eax,%eax,1)
>>   * 7: nopl 0x00000000(%eax)
>>   * 8: nopl 0x00000000(%eax,%eax,1)
> 
>   * 9: cs nopl 0x00000000(%eax,%eax,1)
>   * 10: osp cs nopl 0x00000000(%eax,%eax,1)
>   * 11: osp osp cs nopl 0x00000000(%eax,%eax,1)
> 
>>   */
>> #define BYTES_NOP1      0x90
>> #define BYTES_NOP2      0x66,BYTES_NOP1
>> #define BYTES_NOP3      0x0f,0x1f,0x00
>> #define BYTES_NOP4      0x0f,0x1f,0x40,0x00
>> #define BYTES_NOP5      0x0f,0x1f,0x44,0x00,0x00
>> #define BYTES_NOP6      0x66,BYTES_NOP5
>> #define BYTES_NOP7      0x0f,0x1f,0x80,0x00,0x00,0x00,0x00
>> #define BYTES_NOP8      0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00
> 
> #define BYTES_NOP9      0x2e,BYTES_NOP8
> #define BYTES_NOP10     0x66,BYTES_NOP9
> #define BYTES_NOP11     0x66,BYTES_NOP10
> 
> But yes, first two are NOP and then it switches to NOPL for 3 bytes and
> longer (2 opcode, 1 modrm). Where for 11 bytes we have:
> 
>   - 3 prefixes
>   - 2 opcode
>   - 1 modrm
>   - 1 sib
>   - 4 displacement
> 


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 1/3] objtool/x86: Remove 0xea hack
  2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
@ 2025-09-25  9:55   ` Alexandre Chartre
  2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
  1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25  9:55 UTC (permalink / raw)
  To: Peter Zijlstra, jpoimboe, x86; +Cc: alexandre.chartre, linux-kernel


On 9/24/25 15:45, Peter Zijlstra wrote:
> Was properly fixed in the decoder with commit 4b626015e1bf ("x86/insn:
> Stop decoding i64 instructions in x86-64 mode at opcode")
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>   tools/objtool/arch/x86/decode.c |    9 ---------
>   1 file changed, 9 deletions(-)
> 
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -189,15 +189,6 @@ int arch_decode_instruction(struct objto
>   	op2 = ins.opcode.bytes[1];
>   	op3 = ins.opcode.bytes[2];
>   
> -	/*
> -	 * XXX hack, decoder is buggered and thinks 0xea is 7 bytes long.
> -	 */
> -	if (op1 == 0xea) {
> -		insn->len = 1;
> -		insn->type = INSN_BUG;
> -		return 0;
> -	}
> -
>   	if (ins.rex_prefix.nbytes) {
>   		rex = ins.rex_prefix.bytes[0];
>   		rex_w = X86_REX_W(rex) >> 3;
> 
> 

Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>

alex.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/3] objtool/x86: Add UDB support
  2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
@ 2025-09-25  9:56   ` Alexandre Chartre
  2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
  1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25  9:56 UTC (permalink / raw)
  To: Peter Zijlstra, jpoimboe, x86; +Cc: alexandre.chartre, linux-kernel


On 9/24/25 15:45, Peter Zijlstra wrote:
> Per commit 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA"), make
> sure objtool also recognises UDB as a #UD instruction.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>   tools/objtool/arch/x86/decode.c |    4 ++++
>   1 file changed, 4 insertions(+)
> 
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -683,6 +683,10 @@ int arch_decode_instruction(struct objto
>   		insn->type = INSN_SYSRET;
>   		break;
>   
> +	case 0xd6: /* udb */
> +		insn->type = INSN_BUG;
> +		break;
> +
>   	case 0xe0: /* loopne */
>   	case 0xe1: /* loope */
>   	case 0xe2: /* loop */
> 
> 

Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>

alex.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-25  9:55       ` Alexandre Chartre
@ 2025-09-25 10:03         ` Peter Zijlstra
  2025-09-25 10:42           ` Peter Zijlstra
  0 siblings, 1 reply; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 10:03 UTC (permalink / raw)
  To: Alexandre Chartre; +Cc: jpoimboe, x86, linux-kernel

On Thu, Sep 25, 2025 at 11:55:23AM +0200, Alexandre Chartre wrote:
> 
> On 9/24/25 20:41, Peter Zijlstra wrote:
> > On Wed, Sep 24, 2025 at 07:34:00PM +0200, Alexandre Chartre wrote:
> > > 
> > > On 9/24/25 15:45, Peter Zijlstra wrote:
> > > > For x86_64 the kernel consistently uses 2 instructions for all NOPs:
> > > > 
> > > >     90       - NOP
> > > >     0f 1f /0 - NOPL
> > > > 
> > > > 
> > > > Notably:
> > > > 
> > > >    - REP NOP is PAUSE, not a NOP instruction.
> > > > 
> > > >    - 0f {0c...0f} is reserved space,
> > > >      except for 0f 0d /1, which is PREFETCHW, not a NOP.
> > > > 
> > > >    - 0f {19,1c...1f} is reserved space,
> > > >      except for 0f 1f /0, which is NOPL.
> > > > 
> > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > > ---
> > > >    tools/objtool/arch/x86/decode.c |   12 +++++++-----
> > > >    1 file changed, 7 insertions(+), 5 deletions(-)
> > > > 
> > > > --- a/tools/objtool/arch/x86/decode.c
> > > > +++ b/tools/objtool/arch/x86/decode.c
> > > > @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
> > > >    		break;
> > > >    	case 0x90:
> > > > +		if (prefix != 0xf3) /* REP NOP := PAUSE */
> > > > +			insn->type = INSN_NOP;
> > > >    		break;
> > > 
> > > So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?
> > 
> > Yes. Everything with opcode 0x90, except 0xf3 0x90, which as stated is
> > PAUSE.
> > 
> 
> What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?

Ooh, that is a nice one. Yes, that needs fixing. Thanks!

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-25 10:03         ` Peter Zijlstra
@ 2025-09-25 10:42           ` Peter Zijlstra
  2025-09-25 11:29             ` Andrew Cooper
  2025-09-25 13:05             ` Alexandre Chartre
  0 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 10:42 UTC (permalink / raw)
  To: Alexandre Chartre; +Cc: jpoimboe, x86, linux-kernel

On Thu, Sep 25, 2025 at 12:03:23PM +0200, Peter Zijlstra wrote:

> > > > >    	case 0x90:
> > > > > +		if (prefix != 0xf3) /* REP NOP := PAUSE */
> > > > > +			insn->type = INSN_NOP;
> > > > >    		break;

> > What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?

I've made that:

	case 0x90:                                                                                                                                                                                                                        
		if (rex_b) /* XCHG %r8, %rax */ 
			break; 

		if (prefix == 0xf3) /* REP NOP := PAUSE */ 
			break; 

		insn->type = INSN_NOP; 
		break;



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-25 10:42           ` Peter Zijlstra
@ 2025-09-25 11:29             ` Andrew Cooper
  2025-09-25 12:43               ` Peter Zijlstra
  2025-09-25 13:05             ` Alexandre Chartre
  1 sibling, 1 reply; 19+ messages in thread
From: Andrew Cooper @ 2025-09-25 11:29 UTC (permalink / raw)
  To: peterz; +Cc: alexandre.chartre, jpoimboe, linux-kernel, x86

> I've made that:
>
> 	case 0x90:                                                                                                                                                                                                                        
> 		if (rex_b) /* XCHG %r8, %rax */ 
> 			break; 
>
> 		if (prefix == 0xf3) /* REP NOP := PAUSE */ 
> 			break; 
>
> 		insn->type = INSN_NOP; 
> 		break;

Legacy prefixes can come in any order.  What is F3 66 90 ?

Also, VEX/EVEX/REX2 want excluding too, all of which can encode rex_b
differently.

Is it really only rex_b which prevents NOP becoming a pause, or is it
any REX prefix?  I would have thought it was any REX prefix.

~Andrew


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-25 11:29             ` Andrew Cooper
@ 2025-09-25 12:43               ` Peter Zijlstra
  2025-09-25 13:04                 ` Alexandre Chartre
  2025-09-25 14:11                 ` Peter Zijlstra
  0 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 12:43 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: alexandre.chartre, jpoimboe, linux-kernel, x86

On Thu, Sep 25, 2025 at 12:29:18PM +0100, Andrew Cooper wrote:
> > I've made that:
> >
> > 	case 0x90:                                                                                                                                                                                                                        
> > 		if (rex_b) /* XCHG %r8, %rax */ 
> > 			break; 
> >
> > 		if (prefix == 0xf3) /* REP NOP := PAUSE */ 
> > 			break; 
> >
> > 		insn->type = INSN_NOP; 
> > 		break;
> 
> Legacy prefixes can come in any order.  What is F3 66 90 ?
> 
> Also, VEX/EVEX/REX2 want excluding too, all of which can encode rex_b
> differently.

So luckily objtool only really cares about instructions as found in the
kernel text. Neither f3 66 90 nor VEX/EVEX/REX2 prefixes are of much
concern.

But yes.. I happen to have an insn_is_nop() function that can be used on
userspace, and that certainly wants to be taught about these... x86 is
such a pain :/

> Is it really only rex_b which prevents NOP becoming a pause, or is it
> any REX prefix?  I would have thought it was any REX prefix.

SDM opcode table and instruction reference seems consistent with f3
only.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-25 12:43               ` Peter Zijlstra
@ 2025-09-25 13:04                 ` Alexandre Chartre
  2025-09-25 14:11                 ` Peter Zijlstra
  1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25 13:04 UTC (permalink / raw)
  To: Peter Zijlstra, Andrew Cooper
  Cc: alexandre.chartre, jpoimboe, linux-kernel, x86



On 9/25/25 14:43, Peter Zijlstra wrote:
> On Thu, Sep 25, 2025 at 12:29:18PM +0100, Andrew Cooper wrote:
>>> I've made that:
>>>
>>> 	case 0x90:
>>> 		if (rex_b) /* XCHG %r8, %rax */
>>> 			break;
>>>
>>> 		if (prefix == 0xf3) /* REP NOP := PAUSE */
>>> 			break;
>>>
>>> 		insn->type = INSN_NOP;
>>> 		break;
>>
>> Legacy prefixes can come in any order.  What is F3 66 90 ?
>>
>> Also, VEX/EVEX/REX2 want excluding too, all of which can encode rex_b
>> differently.
> 
> So luckily objtool only really cares about instructions as found in the
> kernel text. Neither f3 66 90 nor VEX/EVEX/REX2 prefixes are of much
> concern.

And it looks like objtool ignores VEX instructions earlier in the same function:

int arch_decode_instruction(struct objtool_file *file, const struct section *sec,
                             unsigned long offset, unsigned int maxlen,
                             struct instruction *insn)
{
        ...

        if (ins.vex_prefix.nbytes)
                 return 0;

        ...
}

vex_prefix is set for VEX/EVEX/VEX3/VEX2.

alex.

> But yes.. I happen to have an insn_is_nop() function that can be used on
> userspace, and that certainly wants to be taught about these... x86 is
> such a pain :/
> 
>> Is it really only rex_b which prevents NOP becoming a pause, or is it
>> any REX prefix?  I would have thought it was any REX prefix.
> 
> SDM opcode table and instruction reference seems consistent with f3
> only.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-25 10:42           ` Peter Zijlstra
  2025-09-25 11:29             ` Andrew Cooper
@ 2025-09-25 13:05             ` Alexandre Chartre
  1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25 13:05 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: alexandre.chartre, jpoimboe, x86, linux-kernel



On 9/25/25 12:42, Peter Zijlstra wrote:
> On Thu, Sep 25, 2025 at 12:03:23PM +0200, Peter Zijlstra wrote:
> 
>>>>>>     	case 0x90:
>>>>>> +		if (prefix != 0xf3) /* REP NOP := PAUSE */
>>>>>> +			insn->type = INSN_NOP;
>>>>>>     		break;
> 
>>> What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?
> 
> I've made that:
> 
> 	case 0x90:
> 		if (rex_b) /* XCHG %r8, %rax */
> 			break;
> 
> 		if (prefix == 0xf3) /* REP NOP := PAUSE */
> 			break;
> 
> 		insn->type = INSN_NOP;
> 		break;
> 
> 

Sounds good.

Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>

alex.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
  2025-09-25 12:43               ` Peter Zijlstra
  2025-09-25 13:04                 ` Alexandre Chartre
@ 2025-09-25 14:11                 ` Peter Zijlstra
  1 sibling, 0 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 14:11 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: alexandre.chartre, jpoimboe, linux-kernel, x86

On Thu, Sep 25, 2025 at 02:43:32PM +0200, Peter Zijlstra wrote:

> But yes.. I happen to have an insn_is_nop() function that can be used on
> userspace, and that certainly wants to be taught about these... x86 is
> such a pain :/

This is the delta I ended up with for my insn_is_nop() function to
support *VEX*/REX2.

I'll post the whole thing later.

--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -138,6 +138,10 @@ struct insn {
 #define X86_VEX_V(vex)	(((vex) & 0x78) >> 3)	/* VEX3 Byte2, VEX2 Byte1 */
 #define X86_VEX_P(vex)	((vex) & 0x03)		/* VEX3 Byte2, VEX2 Byte1 */
 #define X86_VEX_M_MAX	0x1f			/* VEX3.M Maximum value */
+/* EVEX bit fields */
+#define X86_EVEX_R4(vex) ((vex) & 0x10)		/* EVEX Byte1 */
+#define X86_EVEX_B4(vex) ((vex) & 0x08)		/* EVEX Byte1 */
+#define X86_EVEX_X4(vex) ((vex) & 0x04)		/* EVEX Byte2 */
 /* XOP bit fields */
 #define X86_XOP_R(xop)	((xop) & 0x80)	/* XOP Byte2 */
 #define X86_XOP_X(xop)	((xop) & 0x40)	/* XOP Byte2 */
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -1689,33 +1689,62 @@ enum insn_mmio_type insn_decode_mmio(str
  */
 bool insn_is_nop(struct insn *insn)
 {
-	u8 rex, rex_b = 0, rex_x = 0, rex_r = 0, rex_w = 0;
+	u8 b3 = 0, x3 = 0, r3 = 0, w = 0;
+	u8 b4 = 0, x4 = 0, r4 = 0;
 	u8 modrm, modrm_mod, modrm_reg, modrm_rm;
 	u8 sib = 0, sib_scale, sib_index, sib_base;
 	insn_byte_t p;
+	u8 nrex, rex;
 	int i;
 
-	if (insn->rex_prefix.nbytes) {
-		rex = insn->rex_prefix.bytes[0];
-		rex_w = !!X86_REX_W(rex);
-		rex_r = !!X86_REX_R(rex);
-		rex_x = !!X86_REX_X(rex);
-		rex_b = !!X86_REX_B(rex);
+	if ((nrex = insn->rex_prefix.nbytes)) {
+		rex = insn->rex_prefix.bytes[nrex-1];
+
+		w  = !!X86_REX_W(rex);
+		r3 = !!X86_REX_R(rex);
+		x3 = !!X86_REX_X(rex);
+		b3 = !!X86_REX_B(rex);
+		if (nrex > 1) {
+			r4 = !!X86_REX2_R(rex);
+			x4 = !!X86_REX2_X(rex);
+			b4 = !!X86_REX2_B(rex);
+		}
+
+	} else switch (insn->vex_prefix.nbytes) {
+	case 2: /* VEX2 */
+		r3 =  !X86_VEX_R(insn->vex_prefix.bytes[1]);
+		break;
+	case 3: /* VEX3 */
+		r3 =  !X86_VEX_R(insn->vex_prefix.bytes[1]);
+		x3 =  !X86_VEX_X(insn->vex_prefix.bytes[1]);
+		b3 =  !X86_VEX_B(insn->vex_prefix.bytes[1]);
+		w  = !!X86_VEX_W(insn->vex_prefix.bytes[2]);
+		break;
+	case 4: /* EVEX */
+		r3 =  !X86_VEX_R(insn->vex_prefix.bytes[1]);
+		x3 =  !X86_VEX_X(insn->vex_prefix.bytes[1]);
+		b3 =  !X86_VEX_B(insn->vex_prefix.bytes[1]);
+		w  = !!X86_VEX_W(insn->vex_prefix.bytes[2]);
+		r4 =  !X86_EVEX_R4(insn->vex_prefix.bytes[1]);
+		b4 = !!X86_EVEX_B4(insn->vex_prefix.bytes[1]);
+		x4 =  !X86_EVEX_X4(insn->vex_prefix.bytes[2]);
+		break;
+	default: break;
 	}
 
 	if (insn->modrm.nbytes) {
 		modrm = insn->modrm.bytes[0];
 		modrm_mod = X86_MODRM_MOD(modrm);
-		modrm_reg = X86_MODRM_REG(modrm) + 8*rex_r;
-		modrm_rm  = X86_MODRM_RM(modrm)  + 8*rex_b;
+		modrm_reg = X86_MODRM_REG(modrm) + 8*r3 + 16*r4;
+		modrm_rm  = X86_MODRM_RM(modrm)  + 8*b3 + 16*b4;
 		modrm = 1;
 	}
 
 	if (insn->sib.nbytes) {
 		sib = insn->sib.bytes[0];
 		sib_scale = X86_SIB_SCALE(sib);
-		sib_index = X86_SIB_INDEX(sib) + 8*rex_x;
-		sib_base  = X86_SIB_BASE(sib)  + 8*rex_b;
+		sib_index = X86_SIB_INDEX(sib) + 8*x3 + 16*x4;
+		sib_base  = X86_SIB_BASE(sib)  + 8*b3 + 16*b4;
 		sib = 1;
 
 		modrm_rm = sib_base;
@@ -1729,7 +1758,7 @@ bool insn_is_nop(struct insn *insn)
 		if (modrm_mod != 3) /* register-direct */
 			return false;
 
-		if (insn->x86_64 && !rex_w) /* native size */
+		if (insn->x86_64 && !w) /* native size */
 			return false;
 
 		for_each_insn_prefix(insn, i, p) {
@@ -1743,7 +1772,7 @@ bool insn_is_nop(struct insn *insn)
 		if (modrm_mod == 0 || modrm_mod == 3) /* register-indirect with disp */
 			return false;
 
-		if (insn->x86_64 && !rex_w) /* native size */
+		if (insn->x86_64 && !w) /* native size */
 			return false;
 
 		if (insn->displacement.value != 0)
@@ -1760,7 +1789,7 @@ bool insn_is_nop(struct insn *insn)
 		return modrm_reg == modrm_rm; /* LEA 0(%reg), %reg */
 
 	case 0x90: /* NOP */
-		if (rex_b) /* XCHG %r8,%rax */
+		if (b3 || b4) /* XCHG %r8,%rax */
 			return false;
 
 		for_each_insn_prefix(insn, i, p) {

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [tip: objtool/core] objtool/x86: Fix NOP decode
  2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
  2025-09-24 17:34   ` Alexandre Chartre
@ 2025-10-14 11:47   ` tip-bot2 for Peter Zijlstra
  1 sibling, 0 replies; 19+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2025-10-14 11:47 UTC (permalink / raw)
  To: linux-tip-commits; +Cc: Peter Zijlstra (Intel), x86, linux-kernel

The following commit has been merged into the objtool/core branch of tip:

Commit-ID:     044f721ccd33103349eebbb960825584bc6d8e23
Gitweb:        https://git.kernel.org/tip/044f721ccd33103349eebbb960825584bc6d8e23
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Wed, 24 Sep 2025 15:27:03 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 14 Oct 2025 13:43:11 +02:00

objtool/x86: Fix NOP decode

For x86_64 the kernel consistently uses 2 instructions for all NOPs:

  90       - NOP
  0f 1f /0 - NOPL

Notably:

 - REP NOP is PAUSE, not a NOP instruction.

 - 0f {0c...0f} is reserved space,
   except for 0f 0d /1, which is PREFETCHW, not a NOP.

 - 0f {19,1c...1f} is reserved space,
   except for 0f 1f /0, which is NOPL.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 tools/objtool/arch/x86/decode.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index ef6e96d..204e2ad 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -494,6 +494,12 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
 		break;
 
 	case 0x90:
+		if (rex_b) /* XCHG %r8, %rax */
+			break;
+
+		if (prefix == 0xf3) /* REP NOP := PAUSE */
+			break;
+
 		insn->type = INSN_NOP;
 		break;
 
@@ -547,13 +553,14 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
 
 		} else if (op2 == 0x0b || op2 == 0xb9) {
 
-			/* ud2 */
+			/* ud2, ud1 */
 			insn->type = INSN_BUG;
 
-		} else if (op2 == 0x0d || op2 == 0x1f) {
+		} else if (op2 == 0x1f) {
 
-			/* nopl/nopw */
-			insn->type = INSN_NOP;
+			/* 0f 1f /0 := NOPL */
+			if (modrm_reg == 0)
+				insn->type = INSN_NOP;
 
 		} else if (op2 == 0x1e) {
 

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [tip: objtool/core] objtool/x86: Add UDB support
  2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
  2025-09-25  9:56   ` Alexandre Chartre
@ 2025-10-14 11:47   ` tip-bot2 for Peter Zijlstra
  1 sibling, 0 replies; 19+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2025-10-14 11:47 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Peter Zijlstra (Intel), Alexandre Chartre, x86, linux-kernel

The following commit has been merged into the objtool/core branch of tip:

Commit-ID:     76e1851a1bc28e760d6acc7a54ec9dce05717028
Gitweb:        https://git.kernel.org/tip/76e1851a1bc28e760d6acc7a54ec9dce05717028
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Wed, 24 Sep 2025 15:25:27 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 14 Oct 2025 13:43:11 +02:00

objtool/x86: Add UDB support

Per commit 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA"), make
sure objtool also recognises UDB as a #UD instruction.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
---
 tools/objtool/arch/x86/decode.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index ce16fb2..ef6e96d 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -683,6 +683,10 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
 		insn->type = INSN_SYSRET;
 		break;
 
+	case 0xd6: /* udb */
+		insn->type = INSN_BUG;
+		break;
+
 	case 0xe0: /* loopne */
 	case 0xe1: /* loope */
 	case 0xe2: /* loop */

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [tip: objtool/core] objtool/x86: Remove 0xea hack
  2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
  2025-09-25  9:55   ` Alexandre Chartre
@ 2025-10-14 11:47   ` tip-bot2 for Peter Zijlstra
  1 sibling, 0 replies; 19+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2025-10-14 11:47 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Peter Zijlstra (Intel), Alexandre Chartre, x86, linux-kernel

The following commit has been merged into the objtool/core branch of tip:

Commit-ID:     c5df4e1ab8c00c4dc13094fa44e219bc48d910f4
Gitweb:        https://git.kernel.org/tip/c5df4e1ab8c00c4dc13094fa44e219bc48d910f4
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Wed, 24 Sep 2025 15:22:46 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 14 Oct 2025 13:43:10 +02:00

objtool/x86: Remove 0xea hack

Was properly fixed in the decoder with commit 4b626015e1bf ("x86/insn:
Stop decoding i64 instructions in x86-64 mode at opcode")

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
---
 tools/objtool/arch/x86/decode.c |  9 ---------
 1 file changed, 9 deletions(-)

diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index 0ad5cc7..ce16fb2 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -189,15 +189,6 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
 	op2 = ins.opcode.bytes[1];
 	op3 = ins.opcode.bytes[2];
 
-	/*
-	 * XXX hack, decoder is buggered and thinks 0xea is 7 bytes long.
-	 */
-	if (op1 == 0xea) {
-		insn->len = 1;
-		insn->type = INSN_BUG;
-		return 0;
-	}
-
 	if (ins.rex_prefix.nbytes) {
 		rex = ins.rex_prefix.bytes[0];
 		rex_w = X86_REX_W(rex) >> 3;

^ permalink raw reply related	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2025-10-14 11:48 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
2025-09-25  9:55   ` Alexandre Chartre
2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
2025-09-25  9:56   ` Alexandre Chartre
2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
2025-09-24 17:34   ` Alexandre Chartre
2025-09-24 18:41     ` Peter Zijlstra
2025-09-25  9:55       ` Alexandre Chartre
2025-09-25 10:03         ` Peter Zijlstra
2025-09-25 10:42           ` Peter Zijlstra
2025-09-25 11:29             ` Andrew Cooper
2025-09-25 12:43               ` Peter Zijlstra
2025-09-25 13:04                 ` Alexandre Chartre
2025-09-25 14:11                 ` Peter Zijlstra
2025-09-25 13:05             ` Alexandre Chartre
2025-10-14 11:47   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.