[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 19 Apr 2023 17:55:29 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JAi+37JWDwMaeQymdzel3P9769qLutm3BqZRLCAEZHI=; b=A2s1k4hr5tQYLXtUjLy35EdS/O+QPj8PwH0GOR9b0wjkAuSNnCOvY10WCA0wvPRkxTvZh2Bz0EhEdfphRoZsj1H028ewad3AkTc4ADGuW/oJ1fibKxMhNIFNIaF1g647PTyM0ANw9sh1KtgFJW3PEHSTeDbQhHljEzP6fxrNztjf1okGogEn+Q8NtwW1QJ796TZzVzBu1WS6uh1qX49GYS37jdsSb8t+XapVoo9En6mKvGzpC0bfuf6fdY9Qn0zH6zPQy9ZelUA2sRs6EfdH7AhWr5U/aPCvRLrA9p8xV/t3ydsepC7etNVR3dvvYbx6nXickHxGX3mrhtiw7mWGew==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WrOh7XV1fyMTqusNF13J19r3xsZKOP6bnBh6qdFM7yozjUpKe78yZSTNeEpNEyIQqTvz/CBcX+JAOemIqQyFGmP6TuulL8Vf2C3e/gJiXhbMII9M/aQHOLzEpA7z1LsqPxX3snysW/fcPqaeJf7fEE/RwgCqSPaCcl5X347J0tCltS6fQF7hi9WcB4Dyu/1k3UQj6vRq4CmvcGaL0cHqwFzFTieRkd2pnosRvrh8EsBJqfNT7bKr7+m7ZEda7o0siks8Fql3a7q6vTrDAONcmw/1Rfa3vHcf9vCfzhRLqaVEQqHs0nOEx0BtL4YUgdzOS8YLqf8Bq1ctN+BYnajWGQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 19 Apr 2023 15:56:12 +0000
  • Ironport-data: A9a23:Y7fvbahGdakqwiIIzRrcQnhiX161VBEKZh0ujC45NGQN5FlHY01je htvWWDUa6reZmOmLtEgPoznoE5VsZfSytZkGlRprnw9EH4b9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOgTrWCYmYpHlUMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsy+qWj0N8klgZmP6sT4AaPzyB94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQIJHdcaCifg9mu++2aG8MrnOkRdODCadZ3VnFIlVk1DN4AaLWaGuDhwoYd2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilEvluGyb7I5efTTLSlRtlyfq W/cuXzwHzkRNcCFyCrD+XWp7gPKtXqjCN9MSeLgrpaGhnXOzGYBByU2bGeEoOarj2yFdoNSC nMLr39GQa8asRbDosPGdx+yrWOAvxUcc8FNCOB84waIooLE7gDcCmUaQzppbN09qNRwVTEsz kWOnd7iGXpoqrL9YWqU67O8vT60fy8PIgcqeissXQYDpd75r+kOYgnnS99iFOu+iYTzEDSpm jSS9nFh2PMUkNIB0Li98RbfmTWwq5PVTwkzoALKQmai6QA/b4mgD2C11WXmAT97BN7xZjG8U LIswqByMMhm4UmxqRGw
  • Ironport-hdrordr: A9a23:QZYqGa6LOo9inBxHNAPXwNnXdLJyesId70hD6qkRc203TiX8ra vFoB1173PJYUkqKRMdcLy7VZVoIkm9yXcW2+cs1N6ZNWHbUQCTQ72Kg7GC/9ToIVyaytJg
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Apr 19, 2023 at 03:58:10PM +0200, Jan Beulich wrote:
> On 18.04.2023 13:35, Roger Pau Monné wrote:
> > On Tue, Apr 18, 2023 at 11:24:19AM +0200, Jan Beulich wrote:
> >> ... in order to also intercept Dom0 accesses through the alias ports.
> >>
> >> Also stop intercepting accesses to the CMOS ports if we won't ourselves
> >> use the CMOS RTC, because of there being none.
> >>
> >> Note that rtc_init() deliberately uses 16 as the upper loop bound,
> >> despite probe_cmos_alias() using 8: The higher bound is benign now, but
> >> would save us touching the code (or, worse, missing to touch it) in case
> >> the lower one was doubled.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > 
> > Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Before committing I went back to read through doc and earlier comments,
> in particular regarding the NMI disable. As a result I'm now inclined
> to follow your earlier request and fold in the change below. Thoughts?

It was unclear to me whether port 0x70 also had this NMI disabling
behavior when the RTC/CMOS is not present but it seems that port is
shared between the RTC index and the NMI logic, so lack of RTC doesn't
imply lack of the NMI bit.

> Jan
> 
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1305,6 +1305,13 @@ bool is_cmos_port(unsigned int port, uns
>  {
>      unsigned int offs;
>  
> +    /*
> +     * While not really CMOS-related, port 0x70 always needs intercepting
> +     * to deal with the NMI disable bit.
> +     */
> +    if ( port <= RTC_PORT(0) && port + bytes > RTC_PORT(0) )
> +        return true;

It might make it clearer to move this after the !is_hardware_domain(d)
check, as non-hardware domains don't get access to that port anyway?

> +
>      if ( !is_hardware_domain(d) )
>          return port <= RTC_PORT(1) && port + bytes > RTC_PORT(0);
>  
> @@ -1342,6 +1349,17 @@ unsigned int rtc_guest_read(unsigned int
>           * underlying hardware would permit doing so.
>           */
>          data = currd->arch.cmos_idx & (0xff >> (port == RTC_PORT(0)));
> +
> +        /*
> +         * When there's (supposedly) no RTC/CMOS, we don't intercept the 
> other
> +         * ports. While reading the index register isn't normally possible,
> +         * play safe and return back whatever can be read (just in case a 
> value
> +         * written through an alias would be attempted to be read back here).
> +         */
> +        if ( port == RTC_PORT(0) &&
> +             (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) &&
> +             ioports_access_permitted(currd, port, port) )
> +            data = inb(port) & 0x7f;

Do we really need to mask the high bit here?  We don't allow setting
that bit in the first place.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.