REPNZ XSTORE is decoded (does it support REPNZ?)

[woodruffw]

Iced currently allows an f3/REPNZ prefix in front of a Via PadLock XSTORE, but VIA lists this as undefined:

Example instructions (via mishegos):

	./src/worker/xed/xed.so	./src/worker/zydis/zydis.so	./src/worker/bddisasm/bddisasm.so	./src/worker/iced/iced.so
2e6667f20fa7c0	(0 / 0)	(0 / 0)	REPNZ XSTORE (7 / 12)	addr32 repnz xstore (7 / 19)
f267470fa7c0	(0 / 0)	(0 / 0)	REPNZ XSTORE (6 / 12)	addr32 repnz xstore (6 / 19)
65f267470fa7c0	(0 / 0)	(0 / 0)	REPNZ XSTORE (7 / 12)	addr32 repnz xstore (7 / 19)
3e65f267470fa7c0	(0 / 0)	(0 / 0)	REPNZ XSTORE (8 / 12)	addr32 repnz xstore (8 / 19)

(Both XED and Zydis get it right; I originally reported it as a XED bug via intelxed/xed#250 but was able to eventually find the VIA PadLock Guide.)

[woodruffw]

Similarly: REPNZ is undefined in front of XCRYPT, XSHA, and MONTMUL.

[0xd4d]

This is one of a few instructions that I've wanted to test on real HW but I don't have a VIA CPU.

It's not 100% clear if they actually treat it as a mandatory prefix or just like a regular prefix that's just ignored or if it even acts like a REP prefix. The REP is optional so it's possible that it behaves like the old string instructions where REP or REPNZ can be used even though only one of them is documented to work, eg. REPNZ STOSD works even though Intel only documents REP STOSD.

Have you tested this on a real VIA CPU? The docs you showed says it's undefined but that doesn't mean it #UDs.

I think the pic above is from the 2005 docs. The 2008 "PadLock Quick Reference" docs (although shorter) don't mention REPNE prefixes being 'undefined'.

[woodruffw]

This is one of a few instructions that I've wanted to test on real HW but I don't have a VIA CPU.

Unfortunately not -- this is solely from me running mishegos with consensus across a whole slew of different decoders. REPNZ XSTORE was one of a handful of cases where no clear consensus was found (exactly 50% of decoders think it's valid, the other 50% think it's invalid).

I know a few people with access to VIA C3s, primarily via ATMs. I'll see if any of them can/are willing to run a hardware test.

I think the pic above is from the 2005 docs. The 2008 "PadLock Quick Reference" docs (although shorter) don't mention REPNE prefixes being 'undefined'.

Yep, that's from the 2005 manual.

[Symbai]

I'll see if any of them can/are willing to run a hardware test.

So, did they ran the hardware test or not?

[woodruffw]

So, did they ran the hardware test or not?

No tests yet.

[woodruffw]

And 4 months later, did they finally ran the hardware test? Or this is no longer a real issue for you so that you stopped carrying about?

This is an unnecessarily adversarial follow-up. The friends that had access to a VIA C3 changed jobs, like a lot of people have over the past 18 months.

Nobody has stopped caring about it; I just don't have any resources available to test it.

[wtfsck]

@Symbai I'm sure he'll update this thread when he gets the results.

[wtfsck]

BTW, and no more questions about when it will be tested. It's now off topic.

[tremalrik]

No idea about VIA C3, but I have recently been able to test the REPNZ XSTORE (f2 0f a7 c0) instruction on a Zhaoxin KX-U6580 processor (which officially supports Padlock). The instruction does not #UD; it appears to behave just like REP XSTORE, in that it writes (ECX) number of randomized bytes to memory.

This Zhaoxin processor does a lot of odd/interesting things with the Padlock instructions in general; I posted a writeup as issue #279 on Zydis ( zyantific/zydis#279 ) yesterday.

[wtfsck]

@tremalrik Thanks for the info!

[ValdikSS]

Sorry, I know the thread is old, but I've just tested f2 0f a7 c0 on Via Eden Esther (32 bit core with ACE first gen) and it works just like without REPNZ, no UD.

[woodruffw]

No need to be sorry! Thanks a ton for the additional datapoint, it sounds like the answer is "yes, this is decoded, and behaves exactly like the REP variant."

@wtfsck I'm happy closing this as answered if you are 🙂 -- iced is arguably 100% correct to decode it as-is, from a functional perspective (even if the N{E,Z} is misleading in terms of semantics).

[wtfsck]

OK, I'll close it then!