Paranoid NOP padding?

[Denis Vlasenko]

On Thursday 14 July 2005 10:18, Bernd Jendrissek wrote:
> Looking for some 80386 timings (32-bit div in real mode), I came across
> this:
> 
> http://www.microsoft.com/msj/0698/hood0698.aspx
> 
> It seems gas fills gaps created by .align N with NOP instructions, such
> that if the CPU reaches the beginning (!) of the gap, it skips over it
> without any state change other than for %eip.
> 
> Sometimes, though, the CPU should *never* execute code in a "gap".
> Think gaps between functions, for example.
> 
> Could it be cool to teach gas (or is ld the better place?) to insert
> 0xcc (debugger traps) instead, or even one of the guaranteed-invalid
> opcodes (if there are any that are 1 byte long)?

There is none. Both D6 and F1 were undefined,
but it is known for a long time that D6 is undocumented SETALC
and F1 is officially ICEBP now.

It's unclear why Intel introduced "guaranteed-undefined 2 byte
opcode", since LEA reg,reg already exist and likely to
stay undefined to the end of x86 universe. Same for LES and LDS.

LES/LDS reg,reg is attractive because:

"LES eax,esp" is C4 C4
"LDS eax,ebp" is C5 C5
(both are written in Intel operand order)

If you want to get fancy, use these as filler. If you
want to get fancy & safe, use

C4 C4 ... C4 F1
(or same with C5)

or else bad jump to last byte is not 100% guaranteed to trap.
F1 may give you false debug trap, but that's not catastrophic.

Strings of FEs or FFs also may trap, but this relies on
undefined-ness of mod_reg_rm opcode groups - not guaranteed
for future CPUs.
--
vda