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

[Jan Beulich <jbeulich@suse.com>]

On 24.07.2020 16:19, Jan Beulich wrote:
> 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@suse.com>
>>>
>>> --- 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.

Are you okay with this answer, and hence may I commit the change
with Roger's R-b (and the cosmetic adjustments he did ask for)?
(Unless I hear otherwise within the next day or two, I guess I'll
assume so.)

Jan