Sounds like something we should fix. I'll take a look either today or
tomorrow.

Gabe

On May 22, 2017 1:22 PM, "Gross, Joe" <[email protected]> wrote:

> Gabe,
>
> Looking into this a bit more, I see that in doOneByteOpcodeState() that
> opcode_map <- 20. This is decoder.cc:297. Since this is 20 and
> ImmediateTypeVex has only 10 entries, it's reading past the end of this
> array. Does this mean that there are some vector instrs to implement or
> that map_select is being set improperly?
> I know very little about the x86 decoder so I'm not familiar with how the
> emi.vex values are set. Thanks.
>
> Joe
>
> -----Original Message-----
> From: gem5-dev [mailto:[email protected]] On Behalf Of Gabe Black
> Sent: Thursday, May 18, 2017 6:23 PM
> To: gem5 Developer List <[email protected]>
> Cc: [email protected]
> Subject: Re: [gem5-dev] Issue With X86 O3 CPU
>
> I don't think the problem is a buffer overflow perse, or that it has
> anything to do with an undefined instruction. I think you may have a wild
> pointer to the instruction memory or the local nugget of instruction memory
> the x86 predecoder is processing which ends up pointed to some part of the
> data segment, and it just happens to be near some string constants which
> belong to the fault objects including the one you're referring to. Note
> that below that it talks about the 'Abort exception!' string literal being
> near where you're accessing too.
>
> Gabe
>
> On Thu, May 18, 2017 at 2:28 PM, Gross, Joe <[email protected]> wrote:
>
> > Hello,
> >
> > When running an application internally, with the address sanitizer
> > enabled, I'm seeing a global buffer overflow in the x86 decoder during
> > processExtendedOpcode() and wondered if anybody, possibly Gabe, would
> know
> > a quick solution for this. If anybody would like a trace then I could
> > generate this, but unfortunately the binaries that cause the problem are
> > internal. The problem seems contained to decoding an unexpected opcode.
> > Also the location changes slightly from application to application, so
> > there may be several unsupported opcodes.
> >
> > Joe
> >
> > ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000454bcdf
> > at pc 0x000000adb323 bp 0x7fff873f1870 sp 0x7fff873f1868
> > READ of size 1 at 0x00000454bcdf thread T0
> >     #0 0xadb322 in X86ISA::Decoder::processExtendedOpcode(unsigned char
> > const (&) [256]) X86/arch/x86/decoder.cc:460:23
> >     #1 0xadb322 in X86ISA::Decoder::doOneByteOpcodeState(unsigned char)
> > X86/arch/x86/decoder.cc:299
> >     #2 0xad890d in X86ISA::Decoder::process()
> > X86/arch/x86/decoder.cc:113:21
> >     #3 0x1f40de7 in X86ISA::Decoder::moreBytes(X86ISA::PCState const&,
> > unsigned long, unsigned long) X86/arch/x86/decoder.hh:312:9
> >     #4 0x1f40de7 in DefaultFetch<O3CPUImpl>::fetch(bool&)
> > X86/cpu/o3/fetch_impl.hh:1313
> >     #5 0x1f398fc in DefaultFetch<O3CPUImpl>::tick()
> > X86/cpu/o3/fetch_impl.hh:947:9
> >     #6 0x1ec2ba6 in FullO3CPU<O3CPUImpl>::tick() X86/cpu/o3/cpu.cc:565:11
> >     #7 0x2eaa586 in EventQueue::serviceOne() X86/sim/eventq.cc:228:16
> >     #8 0x2efd8d4 in doSimLoop(EventQueue*)  X86/sim/simulate.cc:219:37
> >     #9 0x2efcd7d in simulate(unsigned long)  X86/sim/simulate.cc:132:26
> >
> > 0x00000454bcdf is located 33 bytes to the left of global variable
> '<string
> > literal>' defined in 'X86/arch/x86/faults.cc:131:13' (0x454bd00) of size
> > 47
> >   '<string literal>' is ascii string 'Unrecognized/invalid instruction
> > executed:
> >  %s'
> > 0x00000454bcdf is located 14 bytes to the right of global variable
> > '<string literal>' defined in 'X86/arch/x86/faults.cc:122:9' (0x454bcc0)
> of
> > size 17
> >   '<string literal>' is ascii string 'Abort exception!'
> > SUMMARY: AddressSanitizer: global-buffer-overflow
> > X86/arch/x86/decoder.cc:460:23 in X86ISA::Decoder::
> processExtendedOpcode(unsigned
> > char const (&) [256])
> > Shadow bytes around the buggy address:
> >   0x0000808a1740: 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9
> >   0x0000808a1750: 07 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 02 f9 f9 f9
> >   0x0000808a1760: f9 f9 f9 f9 00 00 00 00 00 00 00 05 f9 f9 f9 f9
> >   0x0000808a1770: 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> >   0x0000808a1780: 00 00 02 f9 f9 f9 f9 f9 03 f9 f9 f9 f9 f9 f9 f9
> > =>0x0000808a1790: 06 f9 f9 f9 f9 f9 f9 f9 00 00 01[f9]f9 f9 f9 f9
> >   0x0000808a17a0: 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
> >   0x0000808a17b0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
> >   0x0000808a17c0: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
> >   0x0000808a17d0: 03 f9 f9 f9 f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9
> >   0x0000808a17e0: 00 00 01 f9 f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9
> > Shadow byte legend (one shadow byte represents 8 application bytes):
> >   Addressable:           00
> >   Partially addressable: 01 02 03 04 05 06 07
> >   Heap left redzone:       fa
> >   Freed heap region:       fd
> >   Stack left redzone:      f1
> >   Stack mid redzone:       f2
> >   Stack right redzone:     f3
> >   Stack after return:      f5
> >   Stack use after scope:   f8
> >   Global redzone:          f9
> >   Global init order:       f6
> >   Poisoned by user:        f7
> >   Container overflow:      fc
> >   Array cookie:            ac
> >   Intra object redzone:    bb
> >   ASan internal:           fe
> >   Left alloca redzone:     ca
> >   Right alloca redzone:    cb
> > _______________________________________________
> > gem5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to