Re: [PATCH 7/7] x86: don't allow Dom0 access to ELCR ports

[Jan Beulich <jbeulich@xxxxxxxx>]

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

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