public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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

  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