2015-02-28 13:34:34

by Alexander Kuleshov

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

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 <[email protected]>
---
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
+
+ /*
* Fixup the physical addresses in the page table
*/
addq %rbp, early_level4_pgt + (L4_START_KERNEL*8)(%rip)
@@ -95,6 +103,7 @@ startup_64:

addq %rbp, level2_fixmap_pgt + (506*8)(%rip)

+1:
/*
* Set up the identity mapping for the switchover. These
* entries should *NOT* have the global bit set! This also
--
2.3.1.167.g7f4ba4b

2015-02-28 13:49:42

by Borislav Petkov

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 <[email protected]>
> ---
> 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.
--