Input validation in SEAM/TD Calls for reading metadata.

I have encountered some TDX Module behaviors related to a set of SEAM/TD calls available for reading metadata fields of the TDX-Module/TDs/VCPUs etc. I appreciate your help in clarifying these.

Let me elaborate w.r.t the behavior of the TDH.MNG.RD SEAM call.

**Expected behavior - ABI Specification**

*TDH.MNG.RD: Input operand RDX (from the ABI specification)*
1. Field identifier – see 3.10.
2. The LAST_ELEMENT_IN_FIELD and LAST_FIELD_IN_SEQUENCE components of the field identifier must be 0.
3. WRITE_MASK_VALID, INC_SIZE, CONTEXT_CODE and ELEMENT_SIZE_CODE components of the field identifier are ignored.
4. For TDH.MNG.RD version 1 or higher, a value of -1 is a special case: it is not a valid field identifier; in this case, the first readable field identifier is returned in RDX.

*TDH.MNG.RD: Output operand RDX (from the ABI specification)*
1. For TDH.MNG.RD version 0, RDX is unmodified.
2. For TDH.MNG.RD version 1 or higher:
If the input field identifier was -1, RDX returns the first readable field identifier.
Else, in case of an error, RDX returns -1.
On success, RDX returns the next readable field identifier.
A value of -1 indicates no next field identifier is available.

**A1:Current Module behavior - Input RDX = -1**
1. If input-RDX = -1, the returned output-RDX is the next readable field identifier, 0x8010000000000001 and the output-RAX = 0xc0b00000000. This is correct as per the ABI specification.
2. However, other input-RDX values also produce the same output (RDX:0x8010000000000001 and RAX:0xc0b00000000). Specifically, any input-RDX within the range 0xff8fffffffffffff to 0xffffffffffffffff returns the first readable field identifier.
3. As per the source code, this behavior results from the is_null_field_id() implementation, which ignores the bits 52:54 (CONTEXT_CODE).

#define CONTEXT_CODE_MASK BITS(54,52) //0x0070000000000000
#define MD_FIELD_ID_NA ((uint64_t)(-1ULL))

_STATIC_INLINE_ bool_t is_null_field_id(md_field_id_t field_id)
{
return ((field_id.raw | CONTEXT_CODE_MASK) == MD_FIELD_ID_NA);
}

**A2:Current Module behavior - Input RDX Bit 63 (NON_ARCH)**
1. According to the ABI specification, the NON_ARCH field is not among the components of the field identifier that are explicitly ignored( those are WRITE_MASK_VALID, INC_SIZE, CONTEXT_CODE and ELEMENT_SIZE_CODE).
2. However, the Module ignores the NON_ARCH field and the SEAM call still succeeds when this bit does not match.
E.g. Both the field identifiers 0x8110000100000001 and 0x0110000100000001 return the correct field contents (in this case TD HKID) and the SEAM call succeeds (RAX = 0).

**Discussion**
The behavior of is_null_field_id() described in A1 impacts several other API calls including.
SEAM calls: TDH.SYS.RD, TDH.SYS.RDALL, TDH.VP.READ
TD Calls: TDG.SYS.RD, TDG.VP.READ, TDG.VM.READ
As per the ABI specification for these API calls, only a value -1 should trigger the return of the next readable field identifier in RDX with status code 0xc0b00000000 in RAX.
Additionally, It appears the "NON_ARCH" component of the field identifier is ignored in these API calls as well. I have verified this for TDH.SYS.RD, but not for the rest.

**Questions**

1. For A1: Is this considered a bug? Any thoughts on this inconsistency with the ABI specification?
2. For A1: Could you explain why the is_null_field_id() check for -1 ignores bits 52:54 ?
3. For A2: Is this a bug? Shouldn't the NON_ARCH component of the field identifier be validated according to the specification? Please help clarify.

Thank you.

Start with is_null_field_id() and the TDH.MNG.RD input-validation path, then compare the observed handling of -1, CONTEXT_CODE, and NON_ARCH with the ABI specification quoted here. Check the related TDH.SYS.RD, TDH.SYS.RDALL, and TDH.VP.READ paths for the same behavior. Done means establishing whether these differences are specification bugs or intentional behavior and documenting the resolution.

Written by the indexing model from the issue text.