From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: adeos-main <adeos-main@gna.org>, Philippe Gerum <rpm@xenomai.org>
Subject: Re: [Adeos-main] [PATCH] ipipe: Prevent unwritable pages after mprotect
Date: Fri, 08 Jul 2011 14:15:28 +0200 [thread overview]
Message-ID: <4E16F4E0.8020900@domain.hid> (raw)
In-Reply-To: <4E16F032.1050905@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
On 2011-07-08 13:55, Gilles Chanteperdrix wrote:
> On 07/07/2011 09:14 PM, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@domain.hid>
>>
>> Page protection changes issued via mprotect, e.g. to enable executable
>> stacks, cause spurious minor faults as they remove the write permission
>> from the modified range again. Avoid this by faking shared pages so that
>> vm_get_page_prot returns the desired page permissions.
>
> This looks dangerous to me. Have you checked that write to private heaps
> will not end up corrupting shared data?
Can't follow this yet.
If you check the comment on protection_map in mm/mmap.c, the difference
between private and shared is in real write vs. COW-able write. That's
what my patch is exploiting to get the proper arch-dependent page
protection bits.
Are you aware of side effects or do you know a better way to inject
write permissions into the protection flags?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-07-08 12:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 19:14 [Adeos-main] [PATCH] ipipe: Prevent unwritable pages after mprotect Jan Kiszka
2011-07-08 11:55 ` Gilles Chanteperdrix
2011-07-08 12:15 ` Jan Kiszka [this message]
2011-07-12 6:48 ` Gilles Chanteperdrix
2011-07-12 7:15 ` Jan Kiszka
2011-07-27 18:41 ` Gilles Chanteperdrix
2011-07-28 16:26 ` Jan Kiszka
2011-07-28 16:28 ` Jan Kiszka
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=4E16F4E0.8020900@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=adeos-main@gna.org \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=rpm@xenomai.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.