Re: [PATCH] x86: guard against port I/O overlapping the RTC/CMOS range

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.07.2020 14:11, Andrew Cooper wrote:
> On 17/07/2020 14:10, Jan Beulich wrote:
>> Since we intercept RTC/CMOS port accesses, let's do so consistently in
>> all cases, i.e. also for e.g. a dword access to [006E,0071]. To avoid
>> the risk of unintended impact on Dom0 code actually doing so (despite
>> the belief that none ought to exist), also extend
>> guest_io_{read,write}() to decompose accesses where some ports are
>> allowed to be directly accessed and some aren't.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -210,7 +210,7 @@ static bool admin_io_okay(unsigned int p
>>          return false;
>>  
>>      /* We also never permit direct access to the RTC/CMOS registers. */
>> -    if ( ((port & ~1) == RTC_PORT(0)) )
>> +    if ( port <= RTC_PORT(1) && port + bytes > RTC_PORT(0) )
>>          return false;
> 
> This first hunk is fine.
> 
> However, why decompose anything?  Any disallowed port in the range
> terminates the entire access, and doesn't internally shrink the access.

What tells you that adjacent ports (e.g. 006E and 006F to match
the example in the description) are disallowed? The typical
case here is Dom0 (as mentioned in the description), which has
access to most of the ports.

Jan