qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Soichiro Isshiki <sisshiki@isshiki-clinic.com>,
	qemu-devel@nongnu.org, qemu-trivial@nongnu.org
Cc: sisshiki1969 <sisshiki@mac.com>
Subject: Re: [PATCH] linux-user: mprotect() should returns 0 when len is 0.
Date: Thu, 6 Oct 2022 17:38:19 -0700	[thread overview]
Message-ID: <4e087808-e687-2bf5-db1d-2e4072f1c69f@linaro.org> (raw)
In-Reply-To: <20221006153841.10750-1-sisshiki@mac.com>

On 10/6/22 08:38, Soichiro Isshiki wrote:
> From: sisshiki1969 <sisshiki@mac.com>
> 
> For now, qemu-x86_64 returns ENOMEM when mprotect() was called with an argument
> len is 0 from a guest process.
> This behavior is incompatible with the current Linux implementation,
> which mprotect() with len = 0 does nothing and returns 0,
> although it does not appear to be explicitly described in man.

You're right that the ordering of checks differs from the kernel.
The kernel has:

(1) validate prot !(growdown && growup)
(2) validate page aligned
(3) pass len == 0
(4) validate no wraparound
(5) validate prot for arch.
(6) validate vma valid.

while we have

(1) validate page aligned
(2) validate prot for arch
(3) validate vma valid
(4) pass len == 0.

My previous answer vs guest_range_valid_untagged is incorrect considering all of this: if 
start > GUEST_ADDR_MAX, that *should* fail vma valid, but the kernel will have returned 
success before that.

Although, sorta, this smells like a kernel bug.
Why should mprotect(-4096, 0, 0) succeed while mprotect(-4096, 4096, 0) fails?

But anyway, if we're going to fix len == 0 to match, we might as well fix all 3 test 
ordering bugs at the same time.


r~


  parent reply	other threads:[~2022-10-07  0:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 15:38 [PATCH] linux-user: mprotect() should returns 0 when len is 0 Soichiro Isshiki
2022-10-06 18:13 ` Peter Maydell
2022-10-06 18:31   ` Richard Henderson
2022-10-06 22:28     ` 一色聡一郎
2022-10-07  0:38 ` Richard Henderson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-10-06 16:43 Soichiro Isshiki

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=4e087808-e687-2bf5-db1d-2e4072f1c69f@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=sisshiki@isshiki-clinic.com \
    --cc=sisshiki@mac.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).