From: David Mosberger <davidm@napali.hpl.hp.com>
To: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
Cc: "Seth, Rohit" <rohit.seth@intel.com>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
davidm@hpl.hp.com
Subject: Re: Mprotect needs arch hook for updated PTE settings
Date: Wed, 16 Mar 2005 17:51:22 +0000 [thread overview]
Message-ID: <16952.29210.623642.622054@napali.hpl.hp.com> (raw)
In-Reply-To: <42382D5C.1030104@bull.net>
>>>>> On Wed, 16 Mar 2005 13:58:04 +0100, Zoltan Menyhart <Zoltan.Menyhart@bull.net> said:
Zoltan> An application should not change the protection of its _own_
Zoltan> text region without knowing well the requirements of the
Zoltan> given architecture.
And the rationale being?
Zoltan> I did see /lib/ld-linux-ia64.so.* changing the protection of
Zoltan> the text segment of the _victim_ application, when it linked
Zoltan> the library references. ld-linux-ia64.so.* changes the
Zoltan> protection for the whole text segment (otherwise, as the
Zoltan> protection is per VMA, it would result in a VMA
Zoltan> fragmentation). The text segment can be huge. There is no
Zoltan> reason to flush all the text segment every time when
Zoltan> ld-linux-ia64.so.* patches an instruction and changes the
Zoltan> protection.
You're missing the point:
- ld.so does NOT patch any instructions; it only patches constant
data which normally is write-protected
- if the text segment is brought into memory via DMA (which it
usually is), the only pages that need to be flushed from the cache
are the ones that were being written to by ld.so; that's usually a
tiny portion of the text segment
Zoltan> I think the solution should consist of these two measures:
Zoltan> 1. Let's say that if an VMA is "executable", then it remains
Zoltan> "executable" for ever, i.e. the mprotect() keeps the
Zoltan> PROT_EXEC bit. As a result, if a page is faulted in for
Zoltan> this VMA in the mean time, the old good mechanism makes sure
Zoltan> that the I-caches are flushed.
Zoltan> 2. Let's modify ld-linux-<arch>.so.*: having patched an
Zoltan> instruction, it should take the appropriate, architecture
Zoltan> dependent measure, e.g. for ia64, it should issue an "fc"
Zoltan> instruction.
Again, ld.so never patches any instructions.
Zoltan> (Who cares for a debugger ? It should know what it does ;-).)
Zoltan> I think there is no need for any extra flushes.
There won't be any "extra" flushing, just the flushing that is really
needed (i.e., for pages that were dirtied via CPU stores).
--david
next prev parent reply other threads:[~2005-03-16 17:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-15 17:43 Mprotect needs arch hook for updated PTE settings Seth, Rohit
2005-03-16 12:58 ` Zoltan Menyhart
2005-03-16 17:51 ` David Mosberger [this message]
2005-03-16 19:15 ` Seth, Rohit
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=16952.29210.623642.622054@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=Zoltan.Menyhart@bull.net \
--cc=davidm@hpl.hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rohit.seth@intel.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