All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nadav Amit <namit@vmware.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"linux_dti@icloud.com" <linux_dti@icloud.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v5 00/10] x86/alternative: text_poke() fixes
Date: Tue, 20 Nov 2018 18:52:25 +0000	[thread overview]
Message-ID: <05F89744-E7B7-4670-82E8-161CB84821A7@vmware.com> (raw)
In-Reply-To: <20181120124232.GK2131@hirez.programming.kicks-ass.net>

> On Nov 20, 2018, at 4:42 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> On Tue, Nov 13, 2018 at 05:07:20AM -0800, Nadav Amit wrote:
>> v4->v5:
>> - Fix Xen breakage [Damian Tometzki]
>> - BUG_ON() when poking_mm initialization fails [PeterZ]
>> - Better comments on "x86/mm: temporary mm struct"
>> - Cleaner removal of the custom poker
> 
> I'll re-iterate my position: it is impossible for the text not to match,
> and if it somehow does not match, something went sideways in an
> unrecoverably fashion.
> 
> text_poke() must not fail, ever. If it does, our text is inconsistent
> and we must abort/panic/bug.
> 
> The only way I will accept anything else is if someone can come up with
> a sensible scenario of text_poke() failing and recovering from it.
> AFAICT there is no possible way to gracefully recover.
> 
> Consider a jump label with multiple patch sites; we patch the first,
> then fail. In order to restore to a sane state, we must undo the
> patching of the first, but undoing text_poke() fails again. Then
> what?
> 
> Allowing text_poke() to fail only creates an unfixable mess. Esp. since
> there is no sane scenario under which is can fail.

Ok, ok... I tried to stand my ground, but I guess I failed. I don’t feel
that strongly about this assertion to argue with you. I’m just the “chicken”
kind of guy.

Yet, take into consideration that I will need to use you as my “vest” once I
get being “shot” for adding BUG_ON(). ;-)

I will send another version tonight, assuming no new issues are raised.

Regards,
NAdav

      reply	other threads:[~2018-11-20 18:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 13:07 [PATCH v5 00/10] x86/alternative: text_poke() fixes Nadav Amit
2018-11-13 13:07 ` [PATCH v5 01/10] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()" Nadav Amit
2018-11-13 13:07 ` [PATCH v5 02/10] x86/jump_label: Use text_poke_early() during early init Nadav Amit
2018-11-20 18:10   ` H. Peter Anvin
2018-11-20 18:18     ` Peter Zijlstra
2018-11-20 18:23       ` H. Peter Anvin
2018-11-20 18:47         ` Nadav Amit
2018-11-13 13:07 ` [PATCH v5 03/10] x86/mm: temporary mm struct Nadav Amit
2018-11-13 13:07 ` [PATCH v5 04/10] fork: provide a function for copying init_mm Nadav Amit
2018-11-13 13:07 ` [PATCH v5 05/10] x86/alternative: initializing temporary mm for patching Nadav Amit
2018-11-13 13:07 ` [PATCH v5 06/10] x86/alternative: use temporary mm for text poking Nadav Amit
2018-11-13 13:07 ` [PATCH v5 07/10] x86/kgdb: avoid redundant comparison of patched code Nadav Amit
2018-11-13 13:07 ` [PATCH v5 08/10] x86: avoid W^X being broken during modules loading Nadav Amit
2018-11-13 13:07 ` [PATCH v5 09/10] x86/jump-label: remove support for custom poker Nadav Amit
2018-11-13 13:07 ` [PATCH v5 10/10] x86/alternative: remove the return value of text_poke_*() Nadav Amit
2018-11-20 12:42 ` [PATCH v5 00/10] x86/alternative: text_poke() fixes Peter Zijlstra
2018-11-20 18:52   ` Nadav Amit [this message]

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=05F89744-E7B7-4670-82E8-161CB84821A7@vmware.com \
    --to=namit@vmware.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux_dti@icloud.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.