public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	jgross@suse.com, x86@kernel.org
Subject: Re: WARNING: can't access registers at asm_common_interrupt
Date: Wed, 11 Nov 2020 21:35:37 +0100	[thread overview]
Message-ID: <20201111203537.GO2628@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20201111201506.bftpmx4svxn376tn@treble>

On Wed, Nov 11, 2020 at 02:15:06PM -0600, Josh Poimboeuf wrote:
> On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:

> > Possible, we just need to be _really_ careful to not allow changing
> > those static_call()s. So maybe we need DEFINE_STATIC_CALL_RO() which
> > does a __ro_after_init on the whole thing.
> 
> But what if you want to live migrate to another hypervisor ;-)

Then you get to keep the pieces ;-)

> > > Either way it doesn't make objtool's job much easier.  But it would be
> > > nice to consolidate runtime patching mechanisms and get rid of
> > > .parainstructions.
> > 
> > I think the above (combining alternative and paravirt/static_call) does
> > make objtool's job easier, since then we at least have the actual
> > alternative instructions available to inspect, or am I mis-understanding
> > things?
> 
> Right, it makes objtool's job a _little_ easier, since it already knows
> how to read alternatives.  But it still has to learn to deal with the
> conflicting stack layouts.

Right, but at least now it can see the instructions. Which is a lot
better than: `add a magic +1 ORC entry when you see an indirect call to
$magic`.

Anyway, __orc_find(addr) looks for the ORC entry with the highest IP <=
@addr. So if we have:

	alt0			alt1

	0x00 CALL *foo		0x00 PUSHF
	0x07 insn		0x01 POP %rax
				0x02 .nops 5
				0x07 insn

we have ORC entries for alt1.0x00 and alt1.0x01. Then if we hit insn,
it'll find the alt1.0x01 entry, but that had better be the same as the
state at 0x00.

This means that for every alt, we have to unwind using the CFI of every
other alt and match for every instruction. Which should be doable I
think.

Certainly more complicated that outright disallowing CFI changes inside
alt groups though :/

  parent reply	other threads:[~2020-11-11 20:35 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-06  6:04 WARNING: can't access registers at asm_common_interrupt Shinichiro Kawasaki
2020-11-06 18:06 ` Josh Poimboeuf
2020-11-09  9:10   ` Shinichiro Kawasaki
2020-11-10  3:19     ` Josh Poimboeuf
2020-11-10  9:19       ` Shinichiro Kawasaki
2020-11-11 17:05 ` Josh Poimboeuf
2020-11-11 17:47   ` Peter Zijlstra
2020-11-11 18:13     ` Josh Poimboeuf
2020-11-11 18:46       ` Andrew Cooper
2020-11-11 19:42         ` Peter Zijlstra
2020-11-11 19:59           ` Josh Poimboeuf
2020-11-11 20:07             ` Peter Zijlstra
2020-11-11 20:15               ` Josh Poimboeuf
2020-11-11 20:25                 ` Andrew Cooper
2020-11-11 20:39                   ` Peter Zijlstra
2020-11-13 17:34                   ` Andy Lutomirski
2020-11-14  9:16                     ` Jürgen Groß
2020-11-14 18:10                       ` Andy Lutomirski
2020-11-15  6:33                         ` Jürgen Groß
2020-11-15 16:05                           ` Andy Lutomirski
2020-11-15 16:13                             ` Jürgen Groß
2020-11-16 11:56                     ` Jürgen Groß
2020-11-16 13:04                       ` Peter Zijlstra
2020-11-18  6:47                         ` Jürgen Groß
2020-11-18  8:22                           ` Peter Zijlstra
2020-11-19 11:51                             ` Shinichiro Kawasaki
2020-11-19 12:01                               ` Peter Zijlstra
2020-11-19 12:28                                 ` Jürgen Groß
2020-11-19 12:48                                 ` Shinichiro Kawasaki
2020-11-11 20:35                 ` Peter Zijlstra [this message]
2020-11-11 20:42       ` Peter Zijlstra
  -- strict thread matches above, loose matches on Subject: below --
2020-09-06 20:46 syzbot

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=20201111203537.GO2628@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Damien.LeMoal@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@gmail.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox