From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH 4/7] x86: detect PIC aliasing on ports other than 0x[2A][01]
Date: Thu, 26 Oct 2023 10:34:56 +0200 [thread overview]
Message-ID: <ZToksEP1Fg8MscdK@macbook> (raw)
In-Reply-To: <27dd8f40-1ea6-1e7e-49c2-31936a17e9d7@suse.com>
On Thu, May 11, 2023 at 02:06:46PM +0200, Jan Beulich wrote:
> ... in order to also deny Dom0 access through the alias ports. Without
> this it is only giving the impression of denying access to both PICs.
> Unlike for CMOS/RTC, do detection very early, to avoid disturbing normal
> operation later on.
>
> Like for CMOS/RTC a fundamental assumption of the probing is that reads
> from the probed alias port won't have side effects in case it does not
> alias the respective PIC's one.
I'm slightly concerned about this probing.
Also I'm unsure we can fully isolate the hardware domain like this.
Preventing access to the non-aliased ports is IMO helpful for domains
to realize the PIT is not available, but in any case such accesses
shouldn't happen in the first place, as dom0 must be modified to run
in such mode.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -479,7 +479,7 @@ static void __init process_dom0_ioports_
> int __init dom0_setup_permissions(struct domain *d)
> {
> unsigned long mfn;
> - unsigned int i;
> + unsigned int i, offs;
> int rc;
>
> if ( pv_shim )
> @@ -492,10 +492,17 @@ int __init dom0_setup_permissions(struct
>
> /* Modify I/O port access permissions. */
>
> - /* Master Interrupt Controller (PIC). */
> - rc |= ioports_deny_access(d, 0x20, 0x21);
> - /* Slave Interrupt Controller (PIC). */
> - rc |= ioports_deny_access(d, 0xA0, 0xA1);
> + for ( offs = 0, i = pic_alias_mask & -pic_alias_mask ?: 2;
> + offs <= pic_alias_mask; offs += i )
I'm a bit lost with this, specifically:
i = pic_alias_mask & -pic_alias_mask ?: 2
Which is then used as the increment step in
offs += i
I could see the usage of pic_alias_mask & -pic_alias_mask in order to
find the first offset, but afterwards don't you need to increment at
single bit left shifts in order to test all possibly set bits in
pic_alias_mask?
> + {
> + if ( offs & ~pic_alias_mask )
> + continue;
> + /* Master Interrupt Controller (PIC). */
> + rc |= ioports_deny_access(d, 0x20 + offs, 0x21 + offs);
> + /* Slave Interrupt Controller (PIC). */
> + rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs);
> + }
> +
> /* Interval Timer (PIT). */
> rc |= ioports_deny_access(d, 0x40, 0x43);
> /* PIT Channel 2 / PC Speaker Control. */
> --- a/xen/arch/x86/i8259.c
> +++ b/xen/arch/x86/i8259.c
> @@ -19,6 +19,7 @@
> #include <xen/delay.h>
> #include <asm/apic.h>
> #include <asm/asm_defns.h>
> +#include <asm/setup.h>
> #include <io_ports.h>
> #include <irq_vectors.h>
>
> @@ -332,6 +333,55 @@ void __init make_8259A_irq(unsigned int
> irq_to_desc(irq)->handler = &i8259A_irq_type;
> }
>
> +unsigned int __initdata pic_alias_mask;
Should this be __hwdom_initdata? I see it gets used in an __init
function, so I guess this all permissions stuff is not really indented
for a late hardware domain to use?
> +
> +static void __init probe_pic_alias(void)
> +{
> + unsigned int mask = 0x1e;
> + uint8_t val = 0;
> +
> + /*
> + * The only properly r/w register is OCW1. While keeping the master
> + * fully masked (thus also masking anything coming through the slave),
> + * write all possible 256 values to the slave's base port, and check
> + * whether the same value can then be read back through any of the
> + * possible alias ports. Probing just the slave of course builds on the
> + * assumption that aliasing is identical for master and slave.
> + */
> +
> + outb(0xff, 0x21); /* Fully mask master. */
> +
> + do {
> + unsigned int offs;
> +
> + outb(val, 0xa1);
> +
> + /* Try to make sure we're actually having a PIC here. */
> + if ( inb(0xa1) != val )
> + {
> + mask = 0;
> + break;
> + }
> +
> + for ( offs = mask & -mask; offs <= mask; offs <<= 1 )
> + {
> + if ( !(mask & offs) )
> + continue;
> + if ( inb(0xa1 + offs) != val )
> + mask &= ~offs;
> + }
> + } while ( mask && (val += 0x0d) ); /* Arbitrary uneven number. */
> +
> + outb(cached_A1, 0xa1); /* Restore slave IRQ mask. */
> + outb(cached_21, 0x21); /* Restore master IRQ mask. */
> +
> + if ( mask )
> + {
> + dprintk(XENLOG_INFO, "PIC aliasing mask: %02x\n", mask);
> + pic_alias_mask = mask;
> + }
> +}
> +
> static struct irqaction __read_mostly cascade = { no_action, "cascade", NULL};
>
> void __init init_IRQ(void)
> @@ -342,6 +392,8 @@ void __init init_IRQ(void)
>
> init_8259A(0);
>
> + probe_pic_alias();
Could we use 8259A instead of pic in the function name and mask
variable? Just so that it's consistent with how we refer to the PIC
in other parts of the code.
Thanks, Roger.
next prev parent reply other threads:[~2023-10-26 8:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 12:03 [PATCH 0/7] x86: Dom0 I/O port access permissions Jan Beulich
2023-05-11 12:05 ` [PATCH 1/7] x86: don't allow Dom0 access to port CF9 Jan Beulich
2023-10-25 12:36 ` Roger Pau Monné
2023-10-25 13:59 ` Jan Beulich
2023-05-11 12:05 ` [PATCH 2/7] x86: don't allow Dom0 access to port 92 Jan Beulich
2023-10-25 12:49 ` Roger Pau Monné
2023-10-25 14:11 ` Jan Beulich
2023-05-11 12:06 ` [PATCH 3/7] x86/PVH: deny Dom0 access to the ISA DMA controller Jan Beulich
2023-10-25 13:22 ` Roger Pau Monné
2023-05-11 12:06 ` [PATCH 4/7] x86: detect PIC aliasing on ports other than 0x[2A][01] Jan Beulich
2023-10-26 8:34 ` Roger Pau Monné [this message]
2023-10-26 9:03 ` Jan Beulich
2023-10-26 13:24 ` Roger Pau Monné
2023-10-26 15:07 ` Jan Beulich
2023-10-26 15:19 ` Roger Pau Monné
2023-10-30 12:24 ` Jan Beulich
2023-10-30 15:14 ` Roger Pau Monné
2023-10-30 15:19 ` Jan Beulich
2023-10-30 15:23 ` Roger Pau Monné
2023-10-30 15:35 ` Jan Beulich
2023-10-30 16:25 ` Roger Pau Monné
2023-05-11 12:07 ` [PATCH 5/7] x86: detect PIT aliasing on ports other than 0x4[0-3] Jan Beulich
2023-10-26 10:25 ` Roger Pau Monné
2023-10-26 12:31 ` Jan Beulich
2023-10-26 13:57 ` Roger Pau Monné
2023-10-26 15:10 ` Jan Beulich
2023-10-26 15:13 ` Roger Pau Monné
2023-10-30 12:50 ` Jan Beulich
2023-05-11 12:07 ` [PATCH 6/7] x86: don't allow Dom0 (direct) access to port F0 Jan Beulich
2023-10-26 10:48 ` Roger Pau Monné
2023-05-11 12:08 ` [PATCH 7/7] x86: don't allow Dom0 access to ELCR ports Jan Beulich
2023-10-26 11:02 ` Roger Pau Monné
2023-10-26 12:51 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZToksEP1Fg8MscdK@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.