From: Ingo Molnar <mingo@kernel.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: kexec@lists.infradead.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
David Woodhouse <dwmw@amazon.co.uk>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Kai Huang <kai.huang@intel.com>,
Nikolay Borisov <nik.borisov@suse.com>,
linux-kernel@vger.kernel.org, Simon Horman <horms@kernel.org>,
Dave Young <dyoung@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
jpoimboe@kernel.org, bsz@amazon.de
Subject: Re: [PATCH v6 2/7] x86/kexec: Debugging support: load a GDT
Date: Sun, 23 Feb 2025 10:53:07 +0100 [thread overview]
Message-ID: <Z7rwA-qVauX7lY8G@gmail.com> (raw)
In-Reply-To: <20250115191423.587774-3-dwmw2@infradead.org>
* David Woodhouse <dwmw2@infradead.org> wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> There are some failure modes which lead to triple-faults in the
> relocate_kernel function, which is fairly much undebuggable for normal
> mortals.
>
> Adding a GDT in the relocate_kernel environment is step 1 towards being
> able to catch faults and do something more useful.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> arch/x86/kernel/relocate_kernel_64.S | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
> index af2cd06ff318..c62f03808f18 100644
> --- a/arch/x86/kernel/relocate_kernel_64.S
> +++ b/arch/x86/kernel/relocate_kernel_64.S
> @@ -39,6 +39,18 @@ SYM_DATA(kexec_pa_table_page, .quad 0)
> SYM_DATA(kexec_pa_swap_page, .quad 0)
> SYM_DATA_LOCAL(pa_backup_pages_map, .quad 0)
>
> +#ifdef CONFIG_KEXEC_DEBUG
> + .balign 16
> +SYM_DATA_START_LOCAL(kexec_debug_gdt)
> + .word kexec_debug_gdt_end - kexec_debug_gdt - 1
> + .long 0
> + .word 0
> + .quad 0x00cf9a000000ffff /* __KERNEL32_CS */
> + .quad 0x00af9a000000ffff /* __KERNEL_CS */
> + .quad 0x00cf92000000ffff /* __KERNEL_DS */
> +SYM_DATA_END_LABEL(kexec_debug_gdt, SYM_L_LOCAL, kexec_debug_gdt_end)
> +#endif /* CONFIG_KEXEC_DEBUG */
Yeah, so is there any reason (other than paranoia) why the early-early
GDT and IDT shouldn't be unconditional? There's many ways for such an
approach to bitrot, it's much better to not hide it behind a
default-disabled debug option...
Some of the other bits, like the hard-coded serial debugging
assumptions, probably need to be behind the debug option - but much of
the new debug mechanism looks safe and generic and can be always-on,
IMHO.
This would also throw regressions back into the face of whoever manages
to introduce them, ideally. ;-)
Thanks,
Ingo
next prev parent reply other threads:[~2025-02-23 9:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 19:09 [PATCH v6 0/7] x86/kexec: Add exception handling for relocate_kernel David Woodhouse
2025-01-15 19:09 ` [PATCH v6 1/7] x86/kexec: Add CONFIG_KEXEC_DEBUG option David Woodhouse
2025-01-15 19:09 ` [PATCH v6 2/7] x86/kexec: Debugging support: load a GDT David Woodhouse
2025-02-23 9:53 ` Ingo Molnar [this message]
2025-02-23 10:53 ` David Woodhouse
2025-01-15 19:09 ` [PATCH v6 3/7] x86/kexec: Debugging support: Load an IDT and basic exception entry points David Woodhouse
2025-01-15 19:09 ` [PATCH v6 4/7] x86/kexec: Debugging support: Dump registers on exception David Woodhouse
2025-01-15 19:09 ` [PATCH v6 5/7] x86/kexec: Add 8250 serial port output David Woodhouse
2025-01-15 19:09 ` [PATCH v6 6/7] x86/kexec: Add 8250 MMIO " David Woodhouse
2025-01-15 19:09 ` [PATCH v6 7/7] [DO NOT MERGE] x86/kexec: Add int3 in kexec path for testing David Woodhouse
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=Z7rwA-qVauX7lY8G@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=bsz@amazon.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=dyoung@redhat.com \
--cc=horms@kernel.org \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kexec@lists.infradead.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.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.