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: <20200323115804.GA2597@C02TD0UTHF1T.local>
Date:   Mon, 23 Mar 2020 11:58:04 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Rémi Denis-Courmont <remi@...lab.net>,
        will@...nel.org, linux-arm-kernel@...ts.infradead.org,
        james.morse@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] arm64: reduce trampoline data alignment

On Sat, Mar 21, 2020 at 01:41:01PM +0000, Catalin Marinas wrote:
> On Thu, Mar 19, 2020 at 11:14:07AM +0200, Rémi Denis-Courmont wrote:
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index c36733d8cd75..ecad15443655 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -858,7 +858,7 @@ SYM_CODE_END(tramp_exit_compat)
> >  	.popsection				// .entry.tramp.text
> >  #ifdef CONFIG_RANDOMIZE_BASE
> >  	.pushsection ".rodata", "a"
> > -	.align PAGE_SHIFT
> > +	.align	4	// all .rodata must be in a single fixmap page
> >  SYM_DATA_START(__entry_tramp_data_start)
> >  	.quad	vectors
> >  SYM_DATA_END(__entry_tramp_data_start)
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 9b08f7c7e6f0..6a0e75f48e7b 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -599,9 +599,8 @@ static int __init map_entry_trampoline(void)
> >  	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> >  		extern char __entry_tramp_data_start[];
> >  
> > -		__set_fixmap(FIX_ENTRY_TRAMP_DATA,
> > -			     __pa_symbol(__entry_tramp_data_start),
> > -			     PAGE_KERNEL_RO);
> > +		pa_start = __pa_symbol(__entry_tramp_data_start) & PAGE_MASK;
> > +		__set_fixmap(FIX_ENTRY_TRAMP_DATA, pa_start, PAGE_KERNEL_RO);
> >  	}
> >  
> >  	return 0;
> 
> For some reason, I haven't investigated yet, a kernel with KASAN and 64K
> pages enabled does not boot (see the attached config). It seems to lock
> up when starting user space. Bisected to this commit, reverting it fixes
> the issue.

I think the issue might be due to ADRP + ADD :lo12: using 4K offsets,
and so patch 1 isn't quite right for !4K kernels, as we're not
accounting for 4 bits of the address when we try to generate it.

I'll check that now.

Thanks,
Mark.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ