On Tuesday, 14 September, 2021, 07:00:27 pm IST, P J P <p...@fedoraproject.org> wrote: >* Thanks so much for restarting this thread. I've been at it intermittently >last few > months, thinking about how could we annotate the source/module objects. > > -> [*] https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04642.html > >* Last time we discussed about having both compile and run time options for >users > to be able to select the qualified objects/backends/devices as desired. > >* To confirm: How/Where is the security policy defined? Is it device/module >specific OR QEMU project wide? > >>> it feels like we need >> 'secure': 'bool' > >* Though we started the (above [*]) discussion with '--security' option in >mind, > I wonder if 'secure' annotation is much specific. And if we could widen its > scope. > > >Source annotations: I've been thinking over following approaches >=================== > >1) Segregate the QEMU sources under > > ../staging/ <= devel/experimental, not for production usage > ../src/ <= good for production usage, hence security relevant > ../deprecated/ <= Bad for production usage, not security relevant > > - This is similar to Linux staging drivers' tree. > - Staging drivers are not considered for production usage and hence CVE > allocation. > - At build time by default we only build sources under ../src/ tree. > - But we can still have options to build /staging/ and /deprecated/ trees. > - It's readily understandable to end users. > >2) pkgconfig(1) way: > - If we could define per device/backend a configuration (.pc) file which is > then used > at build/run time to decide which sources are suitable for the build or > usage. > > - I'm trying to experiment with this. > >3) We annotate QEMU devices/backends/modules with macros which define its >status. > It can then be used at build/run times to decide if it's suitable for usage. > For ex: > > $ cat annotsrc.h > > #include <inttypes.h> > > enum SRCSTATUS { > DEVEL = 0, > STAGING, > PRODUCTION, > DEPRECATED > }; > ... > > >* Approach 3) above is similar to the _security_policy_taint() API, > but works at the source/object file level, rather than specific 'struct > type' field. > >* Does adding a field to struct type (ex. DeviceClass) scale to all >objects/modules/backends etc? > Does it have any limitations to include/cover other sources/objects? > >* I'd really appreciate your feedback/inputs/suggestions.
Ping...!? --- -P J P http://feedmug.com
