Re: [PATCH v4] x86: detect CMOS aliasing on ports other than 0x70/0x71

[Jan Beulich <jbeulich@suse.com>]

On 23.03.2023 13:29, Roger Pau Monné wrote:
> On Wed, Mar 22, 2023 at 10:55:42AM +0100, Jan Beulich wrote:
>> On 21.03.2023 15:12, Roger Pau Monné wrote:
>>> On Mon, Mar 20, 2023 at 09:32:26AM +0100, Jan Beulich wrote:
>>>> ... in order to also intercept Dom0 accesses through the alias ports.
>>>
>>> I'm trying to get some documentation about this aliasing, but so far I
>>> haven't been able to find any.  Do you have any references of where I
>>> might be able to find it?
>>
>> I think several ICH datasheet documents mention this. Right now I'm
>> looking at the ICH10 one (319973-003), section 13.6.1 ("I/O Register
>> Address Map" under "Real Time Clock Registers").
> 
> Thanks, I had to fetch this from elsewhere as I haven't been able to
> find it on the Intel documentation site, maybe it's too old?
> 
>> But such aliasing (really: lack of decoding) has been present on
>> various of the low 1024 ports from the very early days of x86. So we
>> may want to take care of such elsewhere as well, e.g. for the PIC
>> (where aforementioned doc also explicitly mentions the aliases).
> 
> I wonder how relevant those aliases are for OSes, do we know of any OS
> that uses them?
> 
> For example we don't seem to provide them to HVM guests at all, and we
> seem to get away with it.

There are two aspects here: One is the functionality that becomes available
specifically via using the aliases here (and I'm not 100% certain this isn't
chipset dependent in the first place), allowing access to the full 256 bytes
of CMOS storage (i.e. no parts clipped off for the RTC registers). The other
aspect is simply disallowing access to ports we mean Dom0 to not have access
to. That would be the sole purpose e.g. for the PIC port ranges. Otherwise
there's little point disallowing access to the base ranges, imo.

>>>> Also stop intercepting accesses to the CMOS ports if we won't ourselves
>>>> use the CMOS RTC.
>>>
>>> Could this create any concerns with the ability to disable NMIs if we
>>> no longer filter accesses to the RTC?
>>
>> Hmm, that's a valid concern, but I'm not sure in how far we need to
>> be worried about giving Dom0 this level of control. As long as we
>> don't use it ourselves of course (I'm unaware of us using this
>> anywhere). If we're worried, we could continue to intercept port
>> 0x70 alone, just to mask off the top bit for writes.
> 
> I would be mostly worried about dom0 disabling NMI and thus causing
> the Xen watchdog to trigger for example.  I don't think we should
> allow dom0 to disable NMIs at all.

I'll see what I can do, preferably without keeping the intercepts fully
engaged.

Jan