On Friday, February 7, 2020 at 9:35:25 PM UTC, [email protected] wrote: > > I preemptively submitted this PR to see what the Qubes team thinks. > https://github.com/QubesOS/qubes-vmm-xen/pull/70 > > I agree it probably should be fixed upstream, although I've seen the Qubes > team make exceptions and apply their own changes. Upstream would probably > take a huge amount of time to get merged and tested. I'm not a developer > though so I'm sure you could explain the issue better than I. If you do > mention it, CC me as well! I like the CLI argument idea, that's probably a > much cleaner way of doing it and defaulting it to true. That way users > could disable it if needed due to hardware screw-ups. >
Marek is somewhat active on xen-devel. Submitting the PR to Qubes is probably as good a place to start the (github) discussion I suppose. I expect Claudia is correct that it's really a Xen defect to address, either with a flag to disable the check, or security/stability focused checks only. Xen might point upwards again, of course, and tell AMD to fix their microcode or manufacturer's their BIOS's... ...but if a disable flag could be added (--yes_i_know_what_im_doing caveat, of course) that'd be a good short term workaround for the larger Qubes user base that is less likely to be able to figure out how to get a build working and rpm applied and keep up to date with upstream. Brendan -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0ee7aa01-5daf-4d71-bc06-2d061994f7ca%40googlegroups.com.
