[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 7/7] x86: don't allow Dom0 access to ELCR ports
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 26 Oct 2023 13:02:43 +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=7vGAbp6mjTrWPJuIU6jAZaW13brH8j/1qJlULg7b2CQ=; b=l03ZRCTAKQO3D9xegqDyqcRPSeEzqW02Mh3Y3YapLfUfFYNWnJ+ngZ4c6b7vPYL0+R1GboKxNygQiwkNQcakH/ISOR/uNd2FBz5z5DJdbfwTpDyYGicQYYzR+fO4oiayUCHphgx6yMw0psolVPGx5n/fOE4IFDoFvii/7Uilk+aq7wehG5ABa1FULbuLN/upQLseAnlB9cgVxWdxgJe3WPZVxLZuaMvQ+4LanPgecqYH/LEV0L1c0crJtpd57dKsAnWn7Su0nX4JjAxm5m4/IWmZMAGd7VEUYRnBL4URplkp+lbhaqqS6nokK5MiLJtDwV3Ix0xpSDI/z1IcrbrMuw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XvRXA0t6hYtSheKjF52WwyBmB8TkJ/hXvSMJuf3E8RbncwoN0sZSdrlapGS717iKXWJw+/ffmESBMWLXrArErb9ndLQUe9T0Yl6VFZbWcsfhcJEmbA9bovUQnCCxC33d28WpYuYdw1sL2iQOIytVSAM3vyYCsO5aOKUjgVw5h2nv3Zg7oQns/WkFlMrU/fWp+BFnnQCu85E9YNb+sOahMjOF6zIHTUvXZ6WuWgV5tr2lJu4q02sXwjFkyk+bQPclfndcRJ3DT2DT6JLyrrmn6AqLcIqFRRtsDjRJOGq8sDFUns7fq05JIlTowcwzlQDDjQr2e17ZFez0/JhwKHn8Bw==
- 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>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Thu, 26 Oct 2023 11:03:01 +0000
- Ironport-data: A9a23:6m01h6laJvJi35nDHCMCupLo5gynJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xJNXW+BOfiPYzT3eI9+Pt/i8UIPsZXQmIcxTwNkqHw1FiMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+e6UKicfHkpGWeIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE0p5K+aVA8w5ARkPqkT5gGGzhH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 dgmKw4GfC/au+CzxKOpcfB01sc+E9a+aevzulk4pd3YJdAPZMmbBonvu5pf1jp2gd1SF/HDY cZfcSBocBnLfxxIPBEQFY46m+CrwHL4dlW0qnrM/fZxvzeVkVw3ieC0WDbWUoXiqcF9hEGXq 3iA523kKhobKMae2XyO9XfEaurnxHmlB9pNSu3onhJsqHuI1lEqDw0aaVyiqty6l22QUNkHI HVBr0LCqoB3riRHVOLVXRe1vXqFtR40QMdLHqsx7wTl4rrZ5UOVC3YJShZFacc6r4kmSDoyz FiLktj1Qzt1v9W9Vna15rqS6zSoNkAowXQqYCYFSU4J5oflqYRq1hbXFI87Seiyk8H/Hiz2z 3aSti8iir4PjMkNkaKm4VTAhDHqrZ/MJuIo2jjqsquexlsRTOaYi0aAsDA3Md4owF6lc2S8
- Ironport-hdrordr: A9a23:3103e6FKJOXR8lUypLqFaZHXdLJyesId70hD6qkvc3Fom52j/f xGws5x6fatskdqZJkh8erwW5VoMkmsiKKdgLNhdotKOTOLhILGFvAE0WNtqQeQfREWmtQ96U 4kSdkENDSSNykxsS+Z2njALz9I+rDun86VbKXlvg9QpGpRGsNdBnJCe2Km+zpNNWx77PQCdK a0145inX6NaH4XZsO0Cj0uRO7YveDGk5rgfFovGwMnwBPmt0Ll1JfKVzyjmjsOWTJGxrkvtU LflRbi26mlu/anjjfBym7o6YhMkteJ8KoNOCXMsLlaFtzfsHfpWG1TYczAgNnzmpDs1L8eqq iMn/7nBbU315qeRBDwnfKn4Xid7N9n0Q6c9bbfuwqvnSWxfkNFN+NRwY1eaRfX8EwmoZV117 9KxXuQs95NAQrHhzmV3am/a/hGrDvBnZMZq59ls1VPFY8FLLNBp40W+01YVJ8GASLh8YgiVO 1jFtvV6vpaeU6TKymxhBgm/PW8GnAoWhuWSEkLvcKYlzBQgXBi1kMdgMgShG0J+p4xQ4RNo+ 7ELqNrnrdTSdJ+V9M1OM4RBc+sTmDdSxPFN2yfZVzhCaEcInrI74X65b0kjdvaDaDgDKFC6q gpfGkoxlLaIXieePFm9Kc7gizwfA==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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>
> ---
> 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.
>
> 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.
>
> 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.
As a last resort, we could make the register RO?
Thanks, Roger.
|
