Re: [PATCH v1] qga: add guest-get-windows-security-info command

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Mar 17, 2026 at 04:45:20PM +0200, Kostiantyn Kostiuk wrote:
> On Tue, Mar 17, 2026 at 4:15 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> 
> > On Tue, Mar 17, 2026 at 04:07:59PM +0200, Kostiantyn Kostiuk wrote:
> > > On Mon, Mar 16, 2026 at 2:32 PM Elizabeth Ashurov <eashurov@redhat.com>
> > > wrote:
> > >
> > > > Add a new Windows-only QGA command to retrieve Windows security
> > > > features status including VBS, Secure Boot, and TPM information
> > > > from the guest.
> > > >
> > > > The implementation queries Win32_DeviceGuard and Win32_Tpm via
> > > > WMI, and reads the SecureBoot UEFI variable through
> > > > GetFirmwareEnvironmentVariable().
> > > >
> > > > Signed-off-by: Elizabeth Ashurov <eashurov@redhat.com>
> > > > ---
> > > >  qga/commands-win32.c | 404 +++++++++++++++++++++++++++++++++++++++++++
> > > >  qga/qapi-schema.json |  56 ++++++
> > > >  2 files changed, 460 insertions(+)
> >
> > snip
> >
> > > > diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
> > > > index c57bc9a02f..f54fdf942f 100644
> > > > --- a/qga/qapi-schema.json
> > > > +++ b/qga/qapi-schema.json
> > > > @@ -1952,3 +1952,59 @@
> > > >    'returns': ['GuestNetworkRoute'],
> > > >    'if': { 'any': ['CONFIG_LINUX', 'CONFIG_WIN32'] }
> > > >  }
> > > > +
> > > > +##
> > > > +# @GuestWindowsSecurityInfo:
> > > > +#
> > > > +# Windows security features status.
> > > > +#
> > > > +# @vbs-status: VirtualizationBasedSecurityStatus
> > > > +#
> > > > +# @available-security-properties: AvailableSecurityProperties
> > > > +#
> > > > +# @code-integrity-policy-enforcement-status:
> > > > +#     CodeIntegrityPolicyEnforcementStatus
> > > > +#
> > > > +# @required-security-properties: RequiredSecurityProperties
> > > > +#
> > > > +# @security-services-configured: SecurityServicesConfigured
> > > > +#
> > > > +# @security-services-running: SecurityServicesRunning
> > > > +#
> > > > +# @usr-cfg-code-integrity-policy-enforcement-status:
> > > > +#     UsermodeCodeIntegrityPolicyEnforcementStatus
> > > > +#
> > > > +# @secure-boot: Whether UEFI Secure Boot is enabled
> > > > +#
> > > > +# @tpm-present: Whether a TPM device is present
> > > > +#
> > > > +# @tpm-version: TPM specification version string (e.g. "2.0")
> > > > +#
> > > > +# Since: 10.3
> > > > +##
> > > > +{ 'struct': 'GuestWindowsSecurityInfo',
> > > > +  'data': {
> > > > +      'vbs-status': 'int',
> > > > +      '*available-security-properties': ['int'],
> > > > +      '*code-integrity-policy-enforcement-status': 'int',
> > > > +      '*required-security-properties': ['int'],
> > > > +      '*security-services-configured': ['int'],
> > > > +      '*security-services-running': ['int'],
> > > > +      '*usr-cfg-code-integrity-policy-enforcement-status': 'int',
> > > > +      'secure-boot': 'bool',
> > > > +      'tpm-present': 'bool',
> > > > +      '*tpm-version': 'str' },
> > > > +  'if': 'CONFIG_WIN32' }
> > > >
> > > >
> > > Let's make this more generic
> > > command guest-get-security-info
> > > use 'union' to describe OS specific option like VBS
> > > { 'tmp_present': false, 'secure_boot': true, 'os': { 'type': 'windows',
> > > 'vbs': false, .... } }
> > >
> > > make tmp_present, secure_boot, vbs_status optiononal
> > > missing = unknown - as we can have it unimplemented for some POSIX/BSD
> > OSes
> > >
> > > vbs_status is Win10+ only feature, so it can be unknown for Win8
> >
> > I wonder if a new command is justifiable / needed.
> >
> > Should we consider returning more info with 'guest-get-osinfo' ? It
> > is slightly different from the info returned there currently, but
> > at the same time reasonably in scope in the sense that it is
> > essentially reporting a set of OS "feature flags". They happen to
> > be security related in this case, but we could have other feature
> > flags we want to report too in future.
> >
> 
> guest-get-security-info can fail due to WMI issue. If we merge this into
> guest-get-osinfo,
> it means guest-get-osinfo will fail just because of a Windows component
> error. Sounds bad.

In what scenarios would WMI fail, and should we treat that as non-fatal
regardless ? ie indicate that the information is unavailable - that
already appears to be done for the TPM feature, but not the other
security features.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|