This introduces two new flags "secure" and "insecure" against
the Type struct, and helpers to check this against the ObjectClass
struct.

An object type can be considered secure if it is either marked
'secure', or is not marked 'insecure'. The gives an incremental
path where the security status is undefined for most types, but
with the possibility to require explicitly secure types, or
exclude explicitly insecure types.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 include/qom/object.h | 24 ++++++++++++++++++++++++
 qom/object.c         | 19 +++++++++++++++++++
 2 files changed, 43 insertions(+)

diff --git a/include/qom/object.h b/include/qom/object.h
index 26df6137b9..4b9c70f06f 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -453,6 +453,11 @@ struct Object
  *   function.
  * @abstract: If this field is true, then the class is considered abstract and
  *   cannot be directly instantiated.
+ * @secure: If this field is true, then the class is considered to provide
+ *   a security boundary. If false, the security status is not defined.
+ * @insecure: If this field is true, then the class is considered to NOT
+ *   provide a security boundary. If false, the security status is not
+ *   defined.
  * @class_size: The size of the class object (derivative of #ObjectClass)
  *   for this object.  If @class_size is 0, then the size of the class will be
  *   assumed to be the size of the parent class.  This allows a type to avoid
@@ -485,6 +490,8 @@ struct TypeInfo
     void (*instance_finalize)(Object *obj);
 
     bool abstract;
+    bool secure;
+    bool insecure;
     size_t class_size;
 
     void (*class_init)(ObjectClass *klass, const void *data);
@@ -996,6 +1003,23 @@ const char *object_class_get_name(ObjectClass *klass);
  */
 bool object_class_is_abstract(ObjectClass *klass);
 
+/**
+ * object_class_is_secure:
+ * @klass: The class to check security of
+ *
+ * Returns: %true if @klass is declared to be secure, %false if not declared
+ */
+bool object_class_is_secure(ObjectClass *klass);
+
+
+/**
+ * object_class_is_insecure:
+ * @klass: The class to check security of
+ *
+ * Returns: %true if @klass is declared to be insecure, %false if not declared
+ */
+bool object_class_is_insecure(ObjectClass *klass);
+
 /**
  * object_class_by_name:
  * @typename: The QOM typename to obtain the class for.
diff --git a/qom/object.c b/qom/object.c
index a654765e0a..a516ea0fea 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -47,6 +47,8 @@ struct InterfaceImpl
 
 enum TypeImplFlags {
     TYPE_IMPL_FLAG_ABSTRACT = (1 << 0),
+    TYPE_IMPL_FLAG_SECURE = (1 << 1),
+    TYPE_IMPL_FLAG_INSECURE = (1 << 2),
 };
 
 struct TypeImpl
@@ -134,6 +136,13 @@ static TypeImpl *type_new(const TypeInfo *info)
     if (info->abstract) {
         ti->flags |= TYPE_IMPL_FLAG_ABSTRACT;
     }
+    assert(!(info->secure && info->insecure));
+    if (info->secure) {
+        ti->flags |= TYPE_IMPL_FLAG_SECURE;
+    }
+    if (info->insecure) {
+        ti->flags |= TYPE_IMPL_FLAG_INSECURE;
+    }
 
     for (i = 0; info->interfaces && info->interfaces[i].type; i++) {
         ti->interfaces[i].typename = g_strdup(info->interfaces[i].type);
@@ -1054,6 +1063,16 @@ bool object_class_is_abstract(ObjectClass *klass)
     return klass->type->flags & TYPE_IMPL_FLAG_ABSTRACT;
 }
 
+bool object_class_is_secure(ObjectClass *klass)
+{
+    return klass->type->flags & TYPE_IMPL_FLAG_SECURE;
+}
+
+bool object_class_is_insecure(ObjectClass *klass)
+{
+    return klass->type->flags & TYPE_IMPL_FLAG_INSECURE;
+}
+
 const char *object_class_get_name(ObjectClass *klass)
 {
     return klass->type->name;
-- 
2.50.1

On Tue, Sep 09, 2025 at 05:57:13PM +0100, Daniel P. Berrangé wrote:
> This introduces two new flags "secure" and "insecure" against
> the Type struct, and helpers to check this against the ObjectClass
> struct.
> 
> An object type can be considered secure if it is either marked
> 'secure', or is not marked 'insecure'. The gives an incremental
> path where the security status is undefined for most types, but
> with the possibility to require explicitly secure types, or
> exclude explicitly insecure types.

Should there be a check in code that nothing tries to set both flags
simultaneously?


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org