From: Alexander Graf <agraf@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Tom Musta <tommusta@gmail.com>, Riku Voipio <riku.voipio@iki.fi>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 2.2 2/2] linux-user: Properly handle timer magic offset
Date: Mon, 10 Nov 2014 18:01:52 +0100 [thread overview]
Message-ID: <5460EF7F.5010303@suse.de> (raw)
In-Reply-To: <CAFEAcA_F3KOqZ9EdBDVXfSe+exqhgs43yxSRZq6atQZe21MAqw@mail.gmail.com>
On 10.11.14 17:55, Peter Maydell wrote:
> On 10 November 2014 16:46, Alexander Graf <agraf@suse.de> wrote:
>> When creating a timer handle, we give the timer id a special magic offset
>> of 0xcafe0000. However, we never mask that offset out of the timer id before
>> we start using it to dereference our timer array. So we always end up aborting
>> timer operations because the timer id is out of bounds.
>>
>> This was not an issue before my patch e52a99f756e ("linux-user: Simplify
>> timerid checks on g_posix_timers range") because before we would blindly mask
>> anything above the first 16 bits.
>>
>> This patch is superior to the plain masking in that it also adds validity checks
>> against the timer id to ensure we're always dealing with an actual timer id
>> created by QEMU.
>
> The commit message says this...
>
>> @@ -9619,6 +9622,11 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
>> * struct itimerspec * old_value */
>> target_ulong timerid = arg1;
>>
>> + /* Convert QEMU provided timer ID back to internal 16bit index format */
>> + if ((timerid & TIMER_MAGIC_MASK) == TIMER_MAGIC) {
>> + timerid &= 0xffff;
>> + }
>
> ...but the code doesn't actually fail EINVAL in the case that the
> magic value doesn't match, so if you just pass in a small integer
> for the timerid that will work even though the magic is wrong.
> (You can't actually make it overflow the array this way, obviously.)
Well, it's not exactly horribly obvious, but...
>
>> +
>> if (arg3 == 0 || timerid >= ARRAY_SIZE(g_posix_timers)) {
... this check will catch cases where the magic is not masked out ;). So
the only case we don't catch is when a user passes a number < 32 as
timer id - that will work still and IMHO it's desirable to maintain that
behavior as Linux (some times) treats timer ids as u16.
Alex
>> ret = -TARGET_EINVAL;
>> } else {
>> @@ -9640,6 +9648,11 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
>> /* args: timer_t timerid, struct itimerspec *curr_value */
>> target_ulong timerid = arg1;
>>
>> + /* Convert QEMU provided timer ID back to internal 16bit index format */
>> + if ((timerid & TIMER_MAGIC_MASK) == TIMER_MAGIC) {
>> + timerid &= 0xffff;
>> + }
>> +
>
> Same here.
>
> thanks
> - PMM
>
prev parent reply other threads:[~2014-11-10 17:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-10 16:46 [Qemu-devel] [PATCH 2.2 0/2] linux-user: Fix posix timer implementation Alexander Graf
2014-11-10 16:46 ` [Qemu-devel] [PATCH 2.2 1/2] linux-user: Fix timer creation tswap Alexander Graf
2014-11-10 16:46 ` [Qemu-devel] [PATCH 2.2 2/2] linux-user: Properly handle timer magic offset Alexander Graf
2014-11-10 16:55 ` Peter Maydell
2014-11-10 17:01 ` Alexander Graf [this message]
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=5460EF7F.5010303@suse.de \
--to=agraf@suse.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
--cc=tommusta@gmail.com \
/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.