On 7/12/21 11:24 AM, Daniel P. Berrangé wrote:>>
policy: 8 bytes
flags: 8 bytes
id_block: 96 bytes
id_auth: 4096 bytes
host_data: 32 bytes
gosvw: 16 bytes
Only the id_auth parameter is really considered large here.
When you say "up to a page size", that implies that the size is
actually variable. Is that correct, and if so, what is a real
world common size going to be ? Is the common size much smaller
than this upper limit ? If so I'd just ignore the issue entirely.
Looking at the recent spec, it appears that id_auth is fixed to 4K.
If not, then, 4k on the command line is certainly ugly, but isn't
technically impossible. It would be similarly ugly to have this
value stuffed into a libvirt XML configuration for that matter.
One option is to supply only that one parameter via an external
file, with the file being an opaque blob whose context is the
parameter value thus avoiding inventing a custom file format
parser.
When "id_auth" is described as "authentication data", are there
any secrecy requirements around this ?
Yes this sounds much better, we have been using the similar approach for
the SEV in which we pass the PDH and session blob through the file.
QEMU does have the '-object secret' framework for passing blobs
of sensitive data to QEMU and can allow passing via a file:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fqemu-project.gitlab.io%2Fqemu%2Fsystem%2Fsecrets.html&data=04%7C01%7Cbrijesh.singh%40amd.com%7C891fdc1ab0d8483aecb808d945519054%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637617038899405482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8AHUC3DeyauxT4Pd2ZkUJkDyu9XHtexybM0BgdRlego%3D&reserved=0
Even if this doesn't actually need to be kept private, we
could decide to simply (ab)use the 'secret' object anyway
as a way to let it be passed in out of band via a file.
The content of the field does not need to be protected. It's a public
information, so I am not sure the secrets object fits here.
thanks
