| Message ID | ba1de950-185e-8d8e-e313-aef54b18a097@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:05:45PM +0200, Jan Beulich wrote: > Somewhat like port CF9 this may have a bit controlling the CPU's INIT# > signal, and it also may have a bit involved in the driving of A20M#. > Neither of these - just like CF9 - we want to allow Dom0 to drive. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> I'm kind of concerned that such ports might be used for other stuff not described in the specifications I'm looking at, I guess we will find out. > > --- a/xen/arch/x86/dom0_build.c > +++ b/xen/arch/x86/dom0_build.c > @@ -500,6 +500,10 @@ int __init dom0_setup_permissions(struct > rc |= ioports_deny_access(d, 0x40, 0x43); > /* PIT Channel 2 / PC Speaker Control. */ > rc |= ioports_deny_access(d, 0x61, 0x61); > + > + /* INIT# and alternative A20M# control. */ > + rc |= ioports_deny_access(d, 0x92, 0x92); I do wonder whether it would make sense to create an array of [start, end] IO ports to deny access to, so that we could loop over them and code a single call to ioports_deny_access(). Maybe that's over engineering it. Thanks, Roger.
On 25.10.2023 14:49, Roger Pau Monné wrote: > On Thu, May 11, 2023 at 02:05:45PM +0200, Jan Beulich wrote: >> Somewhat like port CF9 this may have a bit controlling the CPU's INIT# >> signal, and it also may have a bit involved in the driving of A20M#. >> Neither of these - just like CF9 - we want to allow Dom0 to drive. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Acked-by: Roger Pau Monné <roger.pau@citrix.com> Thanks. > I'm kind of concerned that such ports might be used for other stuff > not described in the specifications I'm looking at, I guess we will > find out. There's a small risk, but there's also a certain risk from not making the port inaccessible. >> --- a/xen/arch/x86/dom0_build.c >> +++ b/xen/arch/x86/dom0_build.c >> @@ -500,6 +500,10 @@ int __init dom0_setup_permissions(struct >> rc |= ioports_deny_access(d, 0x40, 0x43); >> /* PIT Channel 2 / PC Speaker Control. */ >> rc |= ioports_deny_access(d, 0x61, 0x61); >> + >> + /* INIT# and alternative A20M# control. */ >> + rc |= ioports_deny_access(d, 0x92, 0x92); > > I do wonder whether it would make sense to create an array of [start, > end] IO ports to deny access to, so that we could loop over them and > code a single call to ioports_deny_access(). Maybe that's over > engineering it. It would compact part of the invocations, but some aren't using build- time constants, so wouldn't fit well with such a table approach. (I would probably ack a patch doing such a partial consolidation, but at least right now I don't think I would put time in making such a patch.) Jan
--- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -500,6 +500,10 @@ int __init dom0_setup_permissions(struct rc |= ioports_deny_access(d, 0x40, 0x43); /* PIT Channel 2 / PC Speaker Control. */ rc |= ioports_deny_access(d, 0x61, 0x61); + + /* INIT# and alternative A20M# control. */ + rc |= ioports_deny_access(d, 0x92, 0x92); + /* ACPI PM Timer. */ if ( pmtmr_ioport ) rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
Somewhat like port CF9 this may have a bit controlling the CPU's INIT# signal, and it also may have a bit involved in the driving of A20M#. Neither of these - just like CF9 - we want to allow Dom0 to drive. Signed-off-by: Jan Beulich <jbeulich@suse.com>