linux-kernel - Re: [PATCH 3/3] x86/64/kexec: Rewrite init_transition_pgtable() with kernel_ident_mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <vyvbvham7qcj2pnotfn4mocozx6x33zkvuks63w3ymzk4w6sjc@2gk5xbtb5xrb>
Date: Thu, 4 Jul 2024 16:44:03 +0300
From: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
To: "Huang, Kai" <kai.huang@...el.com>
Cc: "luto@...nel.org" <luto@...nel.org>, 
	"rafael@...nel.org" <rafael@...nel.org>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, 
	"bp@...en8.de" <bp@...en8.de>, "peterz@...radead.org" <peterz@...radead.org>, 
	"hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>, 
	"tglx@...utronix.de" <tglx@...utronix.de>, "bhe@...hat.com" <bhe@...hat.com>, 
	"x86@...nel.org" <x86@...nel.org>, "thomas.lendacky@....com" <thomas.lendacky@....com>, 
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"ardb@...nel.org" <ardb@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>, 
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "tzimmermann@...e.de" <tzimmermann@...e.de>
Subject: Re: [PATCH 3/3] x86/64/kexec: Rewrite init_transition_pgtable() with
 kernel_ident_mapping_init()

On Wed, Jul 03, 2024 at 11:06:21AM +0000, Huang, Kai wrote:
> >  static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
> >  {
> > -	pgprot_t prot = PAGE_KERNEL_EXEC_NOENC;
> > -	unsigned long vaddr, paddr;
> > -	int result = -ENOMEM;
> > -	p4d_t *p4d;
> > -	pud_t *pud;
> > -	pmd_t *pmd;
> > -	pte_t *pte;
> > +	struct x86_mapping_info info = {
> > +		.alloc_pgt_page	= alloc_transition_pgt_page,
> > +		.context	= image,
> > +		.page_flag	= __PAGE_KERNEL_LARGE_EXEC,
> > +		.kernpg_flag	= _KERNPG_TABLE_NOENC,
> > +		.offset = __START_KERNEL_map - phys_base,
> > +	};
> > +	unsigned long mstart = PAGE_ALIGN_DOWN(__pa(relocate_kernel));
> > +	unsigned long mend = mstart + PAGE_SIZE;
> >  
> > -	vaddr = (unsigned long)relocate_kernel;
> > -	paddr = __pa(page_address(image->control_code_page)+PAGE_SIZE);
> 
> Perhaps I am missing something, but this seems a functional change to me.
> 
> IIUC the page after image->control_code_page is allocated when loading the
> kexec kernel image.  It is a different page from the page where the
> relocate_kernel code resides in.
> 
> The old code maps relocate_kernel kernel VA to the page after the
> control_code_page.  Later in machine_kexec(), the relocate_kernel code is
> copied to that page so the mapping can work for that:
> 
> 	control_page = page_address(image->control_code_page) + PAGE_SIZE;
> 	__memcpy(control_page, relocate_kernel,
> KEXEC_CONTROL_CODE_MAX_SIZE);
> 
> The new code in this patch, however, seems just maps the relocate_kernel VA
> to the PA of the relocate_kernel, which should be different from the old
> mapping.

Yes, original code maps at relocate_kernel() VA the page with copy of the
relocate_kernel() in control_code_page. But it is safe to map original
relocate_kernel() page there as well as it is not going to be overwritten
until swap_pages(). We are not going to use original relocate_kernel()
page after RET at the end of relocate_kernel().

Does it make any sense?

I will try to explain it in the commit message in the next version.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov