On 06/05/2021 14:09, Jan Beulich wrote: > On 06.05.2021 14:47, George Dunlap wrote: >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -55,7 +55,7 @@ config PV >> config PV32 >> bool "Support for 32bit PV guests" >> depends on PV >> - default y >> + default PV_SHIM >> select COMPAT >> ---help--- >> The 32bit PV ABI uses Ring1, an area of the x86 architecture which >> @@ -67,7 +67,10 @@ config PV32 >> reduction, or performance reasons. Backwards compatibility can be >> provided via the PV Shim mechanism. >> >> - If unsure, say Y. >> + Note that outside of PV Shim, 32-bit PV guests are not security >> + supported anymore. >> + >> + If unsure, use the default setting. > Alongside this I wonder whether we should also default opt_pv32 to false > then, unless running in shim mode.
No - that's just rude to users. Anyone whose enabled CONFIG_PV32 may potentially want to run such guests. Its easy to avoid issues here by not running 32bit bit guests, or not running untrusted guests, but forcing everyone to reboot a second time to specify pv=32 to unbreak their environment is downright unhelpful. Perhaps tangentially, xl/libxl needs some remedial work as a followup, because: Executing 'xl create -p tests/example/test-pv32pae-example.cfg' Parsing config from tests/example/test-pv32pae-example.cfg xc: error: panic: xg_dom_boot.c:121: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory libxl: error: libxl_dom.c:586:libxl__build_dom: xc_dom_boot_mem_init failed: Operation not supported libxl: error: libxl_create.c:1572:domcreate_rebuild_done: Domain 3:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:1182:libxl__destroy_domid: Domain 3:Non-existant domain libxl: error: libxl_domain.c:1136:domain_destroy_callback: Domain 3:Unable to destroy guest libxl: error: libxl_domain.c:1063:domain_destroy_cb: Domain 3:Destruction of domain failed is what the user gets back when Xen has correctly reported that it isn't pv32-capable, and rejects the switch_compat() hypercall. ~Andrew
