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] x86/vPIT: check/bound values loaded from state save record
Date: Wed, 25 Oct 2023 11:11:38 +0200 [thread overview]
Message-ID: <ZTjbygYgCYTNtc-W@macbook> (raw)
In-Reply-To: <f83213df-2433-ec51-814c-436ce5ea4967@suse.com>
On Thu, May 11, 2023 at 01:50:05PM +0200, Jan Beulich wrote:
> In particular pit_latch_status() and speaker_ioport_read() perform
> calculations which assume in-bounds values. Several of the state save
> record fields can hold wider ranges, though.
>
> Note that ->gate should only be possible to be zero for channel 2;
> enforce that as well.
>
> Adjust pit_reset()'s writing of ->mode as well, to not unduly affect
> the value pit_latch_status() may calculate. The chosen mode of 7 is
> still one which cannot be established by writing the control word.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Of course an alternative would be to simply reject state save records
> with out of bounds values.
I've been taking a look at how we load other records, and
lapic_load_hidden() for example will return error when invalid values
are found.
IMO that seems safer, I think there's a risk in the adjustments
done below to also lead to not safe combinations of fields.
So we either reject the state and return an error, or we silently
reject and leave the PIT in the reset state.
Unless there's a reason we need to handle such bogus state.
> --- a/xen/arch/x86/emul-i8254.c
> +++ b/xen/arch/x86/emul-i8254.c
> @@ -47,6 +47,7 @@
> #define RW_STATE_MSB 2
> #define RW_STATE_WORD0 3
> #define RW_STATE_WORD1 4
> +#define RW_STATE_NUM 5
>
> static int cf_check handle_pit_io(
> int dir, unsigned int port, unsigned int bytes, uint32_t *val);
> @@ -426,6 +427,33 @@ static int cf_check pit_load(struct doma
> }
>
> /*
> + * Convert loaded values to be within valid range, for them to represent
> + * actually reachable state. Uses of some of the values elsewhere assume
> + * this is the case.
> + */
> + for ( i = 0; i < ARRAY_SIZE(pit->hw.channels); ++i )
> + {
> + struct hvm_hw_pit_channel *ch = &pit->hw.channels[i];
> +
> + /* pit_load_count() will convert 0 suitably back to 0x10000. */
> + ch->count &= 0xffff;
Might be helpful to have this in a define, as it's also used by
pit_get_count().
Thanks, Roger.
next prev parent reply other threads:[~2023-10-25 9:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 11:50 [PATCH] x86/vPIT: check/bound values loaded from state save record Jan Beulich
2023-05-11 17:51 ` Jason Andryuk
2023-05-12 6:50 ` Jan Beulich
2023-10-25 9:11 ` Roger Pau Monné [this message]
2023-10-25 9:44 ` 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=ZTjbygYgCYTNtc-W@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.