linux-kernel - Re: [PATCH] x86-64: no need to fix up physical addresses if they are correct

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] [day] [month] [year] [list]

Date:	Sat, 28 Feb 2015 14:48:32 +0100
From:	Borislav Petkov <bp@...e.de>
To:	Alexander Kuleshov <kuleshovmail@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86-64: no need to fix up physical addresses if they are
 correct

On Sat, Feb 28, 2015 at 07:34:20PM +0600, Alexander Kuleshov wrote:
> If kernel doesn't use kASLR and runned on the same address that was
> compiled to run, %rbp will be zero and no need to fix physical addresses
> in the page tables.
> 
> Signed-off-by: Alexander Kuleshov <kuleshovmail@...il.com>
> ---
>  arch/x86/kernel/head_64.S | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index 6fd514d9..c0127bc 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -86,6 +86,14 @@ startup_64:
>  	jnz	bad_address
>  
>  	/*
> +	 * We have no need to fixup the physical addresses in the page tables
> +	 * if there is no difference between the address where kernel compiled
> +	 * to run and the actual address where kernel running at.
> +	 */
> +	cmpq $0x0, %rbp
> +	je 1f

No thanks - this is saving 4 ADDs which probably execute even in
parallel on modern out-of-order x86, for the price of more code in asm
which people would have to spend mental energy on in the future without
any apparent gain.

If you really want to help out with kernel development, I'd suggest
you try fixing real bugs. You could read lkml and try to understand
and debug the issues people are reporting, get a box and start testing
linux-next every day and search the net for kernelnewbies (IRC channel
etc) for things to do.

Another great exercise is building randconfigs and trying to boot them
with kvm and see what splats happen - believe me, lots of them.

I sincerely hope that helps.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/