Re: [PATCH 2/7] x86: don't allow Dom0 access to port 92

[Jan Beulich <jbeulich@xxxxxxxx>]

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@xxxxxxxx>
> 
> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

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