| Message ID | 118fa3e5-e1ac-ab3e-8b86-1ec751513434@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: Dom0 I/O port access permissions | expand |
On Thu, May 11, 2023 at 02:08:09PM +0200, Jan Beulich wrote: > Much like the other PIC ports, Dom0 has no business touching these. Even > our own uses are somewhat questionable, as the corresponding IO-APIC > code in Linux is enclosed in a CONFIG_EISA conditional; I don't think > there are any x86-64 EISA systems. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> > --- > RFC: For Linux'es (matching our) construct_default_ioirq_mptable() we > may need to permit read access at least for PVH, if such default > table construction is assumed to be sensible there in the first > place (we assume ACPI and no PIC for PVH Dom0, after all). Unless I'm confused, thise ports only control the triggering mode of the PICs, and hence a PVH dom0 should have no business with them, as not having a PIC in the first place. > > RFC: Linux further has ACPI boot code accessing ELCR > (acpi_pic_sci_set_trigger() and acpi_register_gsi_pic()), which we > have no equivalent of. If access to the port is denied, ~0 will be returned, and hence all IRQs will be assumed to be level. Some bits reserved and must be 0 will also be returned as 1. > > Taken together, perhaps the hiding needs to be limited to PVH Dom0? I very much doubt Xen will ever use the PIC unless forced on the command line, and we should likely remove such option and just mandate a working IO-APIC in order to run Xen. My only doubt is whether some Linux code will get confused by poking at ELCR{1,2} and malfunction as a result of not being able to fetch a sane mask. As a last resort, we could make the register RO? Thanks, Roger.
On 26.10.2023 13:02, Roger Pau Monné wrote: > On Thu, May 11, 2023 at 02:08:09PM +0200, Jan Beulich wrote: >> Much like the other PIC ports, Dom0 has no business touching these. Even >> our own uses are somewhat questionable, as the corresponding IO-APIC >> code in Linux is enclosed in a CONFIG_EISA conditional; I don't think >> there are any x86-64 EISA systems. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Acked-by: Roger Pau Monné <roger.pau@citrix.com> Thanks. >> --- >> RFC: For Linux'es (matching our) construct_default_ioirq_mptable() we >> may need to permit read access at least for PVH, if such default >> table construction is assumed to be sensible there in the first >> place (we assume ACPI and no PIC for PVH Dom0, after all). > > Unless I'm confused, thise ports only control the triggering mode of > the PICs, and hence a PVH dom0 should have no business with them, as > not having a PIC in the first place. It should have no business, but the code I'm referring to still reads these ports. >> RFC: Linux further has ACPI boot code accessing ELCR >> (acpi_pic_sci_set_trigger() and acpi_register_gsi_pic()), which we >> have no equivalent of. > > If access to the port is denied, ~0 will be returned, and hence all > IRQs will be assumed to be level. Some bits reserved and must be 0 > will also be returned as 1. As with any reserved bits, the party reading them would better ignore their values (like we do). >> Taken together, perhaps the hiding needs to be limited to PVH Dom0? > > I very much doubt Xen will ever use the PIC unless forced on the > command line, and we should likely remove such option and just > mandate a working IO-APIC in order to run Xen. > > My only doubt is whether some Linux code will get confused by poking > at ELCR{1,2} and malfunction as a result of not being able to fetch a > sane mask. Over many years this code hasn't changed much, if at all. So simply from it being okay right now this would hopefully be only a theoretical concern. > As a last resort, we could make the register RO? If and when needed, perhaps. Jan
--- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -503,6 +503,9 @@ int __init dom0_setup_permissions(struct rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs); } + /* ELCR of both PICs. */ + rc |= ioports_deny_access(d, 0x4D0, 0x4D1); + /* Interval Timer (PIT). */ for ( offs = 0, i = pit_alias_mask & -pit_alias_mask ?: 4; offs <= pit_alias_mask; offs += i )
Much like the other PIC ports, Dom0 has no business touching these. Even our own uses are somewhat questionable, as the corresponding IO-APIC code in Linux is enclosed in a CONFIG_EISA conditional; I don't think there are any x86-64 EISA systems. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- RFC: For Linux'es (matching our) construct_default_ioirq_mptable() we may need to permit read access at least for PVH, if such default table construction is assumed to be sensible there in the first place (we assume ACPI and no PIC for PVH Dom0, after all). RFC: Linux further has ACPI boot code accessing ELCR (acpi_pic_sci_set_trigger() and acpi_register_gsi_pic()), which we have no equivalent of. Taken together, perhaps the hiding needs to be limited to PVH Dom0?