All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@suse.de>, Zachary Amsden <zach@vmware.com>
Subject: Re: bad paravirt/Xen interaction in "x86 - Enhance DEBUG_RODATA support - alternatives"
Date: Fri, 29 Feb 2008 13:09:28 -0800	[thread overview]
Message-ID: <47C87488.9030205@goop.org> (raw)
In-Reply-To: <47C8717F.3030009@zytor.com>

H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>> The patch "x86 - Enhance DEBUG_RODATA support - alternatives" enables 
>> the kernel for writing by clearing X86_CR0_WP allow privileged 
>> writes.  This won't work in a paravirt environment for two reasons:
>>
>>   1. the kernel may not be running in ring 0, so writes will still be
>>      prevented
>>   2. the hypervisor prevents X86_CR0_WP from being cleared anyway (it
>>      GPFs the cr0 update)
>>
>> This crashes on Xen, and it would probably break VMI too.

(lguest too, of course)

>> The only safe way to allow writes is to change the page permissions 
>> (either on the page itself, or create a temporary writable alias for 
>> that page).  Perhaps something you could do it with kmap_atomic.
>>
>
> A properly implemented hypervisor should arguably emulate this.
>
> Doesn't really mean the patch is worth the pain.

No, it would be irritating to implement.

Seems to me that doing the update in a temporary kmap_atomic mapping 
would be a more straightforward way to go, anyway.  How would you 
implement this on a processor without something like X86_CR0_WP?

    J

  reply	other threads:[~2008-02-29 21:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29 20:39 bad paravirt/Xen interaction in "x86 - Enhance DEBUG_RODATA support - alternatives" Jeremy Fitzhardinge
2008-02-29 20:56 ` H. Peter Anvin
2008-02-29 21:09   ` Jeremy Fitzhardinge [this message]
2008-03-03 17:30     ` Mathieu Desnoyers
2008-03-03 17:35       ` Andi Kleen
2008-03-03 17:58       ` Jeremy Fitzhardinge
2008-03-03 18:03         ` Andi Kleen
2008-03-03 18:05           ` Jeremy Fitzhardinge
2008-03-03 20:53             ` Mathieu Desnoyers
2008-03-03 22:15               ` Jeremy Fitzhardinge
2008-03-04  4:12                 ` Mathieu Desnoyers
2008-02-29 21:24 ` Ingo Molnar

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=47C87488.9030205@goop.org \
    --to=jeremy@goop.org \
    --cc=ak@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=zach@vmware.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.