feat: Support multi-format integer parsing for CLI arguments

[hyperfinitism]

This PR introduces a custom integer parser able to accept decimal, prefixed hexadecimal (0x…) and prefixed binary (0b…) strings in the snpguest CLI, and wires it into the key subcommand.

This was discussed and proposed in PR #115.

What's changed

• Add src/clparser/mod.rs implementing the multi-format integer parser parse_int_auto_radix::<T>
• Enable multi-format CLI arguments in the key subcommand ― arguments gfs, gsvn, tcbv and lmv now use clparser::parse_int_auto_radix as their value_parser
• Refactor KeyArgs to use typed defaults and streamline validation logic
• Update README.md to document the new multi-format parsing in CLI examples

Test Environment

• VM: GCE n2d-standard-2 (AMD Milan)
• OS image: ubuntu-2404-noble-amd64-v20250805
• Linux kernel: 6.14.0-1014-gcp

All affected CLI arguments (gfs, gsvn, tcbv, lmv) were tested in this environment and worked as expected. Note: lmv is not supported on GCE SNP VMs (SEV-SNP FW ABI pre-1.58), so the expected behavior is to emit an error.

[DGonzalezVillal]

The only other format that we might need to consider is Base64. Qemu takes in a lot of base 64 encoded values. That is why in some of the other commands we support that format. Besides that everything else looks good!

[hyperfinitism]

Thanks for the suggestion! I agree that support for Base64 is worthwhile. The main challenge is that it is not possible to unambiguously detect Base64 purely from the input string (e.g., a hex literal like 0x00 can also be parsed as valid Base64 bits: 0x00 → 110100 110001 110100 110100).

One approach I would propose is to assign an appropriate default format for each argument type (e.g., binary for bitfields, decimal for plain integers, hex for general byte strings) and then allow overriding via explicit flags such as --lmv-format base64 or --gfs-format hex. This way we can consistently support decimal, hex, binary, Base64 (and potentially Base64URL).

In the case of the key subcommand, the default formats are set as follows:

• --vmpl: decimal
• --guest_field_select: binary
• --launch_mit_vector: hex

Does that approach make sense to you?

[DGonzalezVillal]

A point @tylerfanelli brought up is that maybe user's won't be inputting Base64 as much as they would require the output, so maybe we support Base64 outputs, but not necessarily inputs.

@tylerfanelli any thoughts on this PR?

[tylerfanelli]

Yes, i suggest that because of different padding formats, etc, its best to just have users input hex. If QEMU depends on base64 inputs, then this tool's outputs can be in base64. But I think it's best to standardize around hex (and thus not needing a 0x prefix to inputs) and not worry about different encoding formats.

[DGonzalezVillal]

I personally like that we can support different types of inputs by prefixing the input type with 0x or 0b for hex and binary. It gives the users flexibility. It also helps standarize inputs to the tool. people can use what makes the most sense or is most convenient to them. Unless you just want to do hex all through out the tool @tylerfanelli .

[DGonzalezVillal]

@tylerfanelli thoughts?

[tylerfanelli]

I personally like that we can support different types of inputs by prefixing the input type with 0x or 0b for hex and binary.

I have a hard time believing anyone will be inputting binary. IMO that should ultimately be removed.

It also helps standarize inputs to the tool. people can use what makes the most sense or is most convenient to them. Unless you just want to do hex all through out the tool @tylerfanelli .

Sure, fine with me.

[DGonzalezVillal]

I think for the binary input we were thinking of fields like Guest field select in the key derivation were we have several different inputs values |MIT_VECTOR, TCB VERSION, SVN, ...| were 1 is include and 0 is not include. And so binary is an easier way of inputting that value.