[PATCH 15/15] docs: expand security docs with info about secure/insecure markers

Daniel P. Berrangé posted 15 patches 2 weeks, 5 days ago
Maintainers: Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <richard.henderson@linaro.org>, Peter Maydell <peter.maydell@linaro.org>, Eduardo Habkost <eduardo@habkost.net>, Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, "Philippe Mathieu-Daudé" <philmd@linaro.org>, Yanan Wang <wangyanan55@huawei.com>, Zhao Liu <zhao1.liu@intel.com>, "Michael S. Tsirkin" <mst@redhat.com>, Sergio Lopez <slp@redhat.com>, Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Beniamino Galvani <b.galvani@gmail.com>, Strahinja Jankovic <strahinja.p.jankovic@gmail.com>, Jason Wang <jasowang@redhat.com>, Alistair Francis <alistair@alistair23.me>, Pavel Pisa <pisa@cmp.felk.cvut.cz>, Francisco Iglesias <francisco.iglesias@amd.com>, Vikram Garhwal <vikram.garhwal@bytedance.com>, Dmitry Fleytman <dmitry.fleytman@gmail.com>, Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>, Stefan Weil <sw@weilnetz.de>, Bernhard Beschow <shentey@gmail.com>, "Cédric Le Goater" <clg@kaod.org>, Steven Lee <steven_lee@aspeedtech.com>, Troy Lee <leetroy@gmail.com>, Jamin Lin <jamin_lin@aspeedtech.com>, Andrew Jeffery <andrew@codeconstruct.com.au>, Joel Stanley <joel@jms.id.au>, Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>, Helge Deller <deller@gmx.de>, Thomas Huth <huth@tuxfamily.org>, Subbaraya Sundeep <sundeep.lkml@gmail.com>, Jan Kiszka <jan.kiszka@web.de>, Tyrone Ting <kfting@nuvoton.com>, Hao Wu <wuhaotsh@google.com>, Max Filippov <jcmvbkbc@gmail.com>, Jiri Pirko <jiri@resnulli.us>, Nicholas Piggin <npiggin@gmail.com>, Harsh Prateek Bora <harshpb@linux.ibm.com>, Sven Schnelle <svens@stackframe.org>, Rob Herring <robh@kernel.org>, David Hildenbrand <david@redhat.com>, Ilya Leoshkevich <iii@linux.ibm.com>, Halil Pasic <pasic@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, Matthew Rosato <mjrosato@linux.ibm.com>, "Daniel P. Berrangé" <berrange@redhat.com>, Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>
There is a newer version of this series
[PATCH 15/15] docs: expand security docs with info about secure/insecure markers
Posted by Daniel P. Berrangé 2 weeks, 5 days ago
The explicit 'secure' or 'insecure' markers will take priority over
the general "virtualization" vs "non-virtualization" use case
classfication.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 docs/system/security.rst | 41 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/docs/system/security.rst b/docs/system/security.rst
index f2092c8768..15cffc2685 100644
--- a/docs/system/security.rst
+++ b/docs/system/security.rst
@@ -49,6 +49,47 @@ Bugs affecting the non-virtualization use case are not considered security
 bugs at this time.  Users with non-virtualization use cases must not rely on
 QEMU to provide guest isolation or any security guarantees.
 
+Security status reporting
+'''''''''''''''''''''''''
+
+QEMU is progressively working to annotate object types to explicitly state
+whether they are considered to provide a security boundary or not.
+
+When the `require-secure=yes` parameter is given to the `-machine` argument
+attempts to use any type which is not explicitly considered secure will
+result in an error.
+
+When the `prohibit-insecure=yes` parameter is given to the `-machine` argument
+attempts to use any type which is explicitly considered insecure will result
+in an error.
+
+This gives three effective levels of control over the security
+
+ * default: any type can be used
+ * `prohibit-insecure=yes`: only exclude explicitly insecure types, allow
+   those which have no security statement, or which are explicitly secure
+ * `require-secure=yes`: only allow explicitly secure types, exclude those
+   which have no security statement, or which are explicitly insecure
+
+Violations of the requested policy will result in QEMU preventing the launch
+of the VM, or preventing hot-add of the device in the monitor.
+
+When considering whether to treat a flaw as a security issue, the following
+criteria will be used
+
+ * Type marked 'secure': eligible for security process with embargo where
+   applicable
+ * Type marked 'insecure': ineligible for security process, will be triaged
+   on the public mailing list / bug trackers
+ * Type with no security statement: "Virtualization" vs "Non-Virtualization"
+   use case will be used as a guide to decide on handling process, evaluated
+   upon bug report
+
+Machine type security status can be queried using '-machine help' or the
+QMP 'query-machines' command.
+
+Device type security status can be queried using '-device help'.
+
 Architecture
 ------------
 
-- 
2.50.1