From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Kees Cook <keescook@chromium.org>,
Dave Hansen <dave.hansen@intel.com>,
Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH] x86/mm: Do not verify W^X at boot up
Date: Mon, 24 Oct 2022 12:08:49 -0700 [thread overview]
Message-ID: <CAHk-=wjRpCS3oAJHVfByDoaj0-tAhV5a5YKV7QssUdMOAm8bAg@mail.gmail.com> (raw)
In-Reply-To: <20221024145250.08cfc147@gandalf.local.home>
On Mon, Oct 24, 2022 at 11:52 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> It's not just speed up at boot up. It's because text_poke doesn't work at
> early boot up when function tracing is enabled. If I remove the
> SYSTEM_BOOTING checks in text_poke() this happens:
Let's just fix that up.
>
> [ 1.013753] BUG: kernel NULL pointer dereference, address: 0000000000000048
This is due to
__get_locked_pte:
0: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
5: 48 89 f0 mov %rsi,%rax
8: 41 55 push %r13
a: 48 c1 e8 24 shr $0x24,%rax
e: 41 54 push %r12
10: 25 f8 0f 00 00 and $0xff8,%eax
15: 55 push %rbp
16: 53 push %rbx
17:* 48 03 47 48 add 0x48(%rdi),%rax <-- trapping instruction
1b: 0f 84 c4 00 00 00 je 0xe5
21: 49 89 fc mov %rdi,%r12
24: 48 8b 38 mov (%rax),%rdi
27: 48 89 f3 mov %rsi,%rbx
2a: 48 89 c5 mov %rax,%rbp
and that 'addq' seems to be walk_to_pmd() doing
pgd = pgd_offset(mm, addr);
with a zero mm (that's 'mm->pgd').
And that, in turn, seems to be due to the absolutely disgusing 'poking_mm' hack.
> Interrupts haven't been enabled yet, so things are still rather fragile at
> this point of start up.
I don't think this has anything to do with interrupts. We do need the
page structures etc to be workable, but all the tracing setup needs
that *anyway*.
I suspect it would be fixed by just moving 'poking_init()' earlier. In
many ways I suspect it would make most sense as part of 'mm_init()',
not as a random call fairly late in start_kernel().
In other words, this all smells like "people added special cases
because they didn't want to hunt down the underlying problem".
And then all these special cases beget other special cases.
Linus
next prev parent reply other threads:[~2022-10-24 21:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 15:45 [PATCH] x86/mm: Do not verify W^X at boot up Steven Rostedt
2022-10-24 16:14 ` Dave Hansen
2022-10-24 18:13 ` Steven Rostedt
2022-10-24 19:26 ` Steven Rostedt
2022-10-24 18:19 ` Linus Torvalds
2022-10-24 18:52 ` Steven Rostedt
2022-10-24 19:08 ` Linus Torvalds [this message]
2022-10-24 22:04 ` Steven Rostedt
2022-10-25 9:39 ` Peter Zijlstra
2022-10-25 10:16 ` Peter Zijlstra
2022-10-25 16:53 ` Linus Torvalds
2022-10-25 17:47 ` Peter Zijlstra
2022-10-25 18:14 ` Linus Torvalds
2022-10-25 18:46 ` Peter Zijlstra
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='CAHk-=wjRpCS3oAJHVfByDoaj0-tAhV5a5YKV7QssUdMOAm8bAg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=seanjc@google.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;
as well as URLs for NNTP newsgroup(s).