All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.