* [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel
@ 2020-11-19 2:29 Jinyang He
2020-11-19 2:29 ` [PATCH 2/3] MIPS: Loongson64: Add KASLR support Jinyang He
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Jinyang He @ 2020-11-19 2:29 UTC (permalink / raw)
To: Thomas Bogendoerfer, Huacai Chen, Jiaxun Yang; +Cc: linux-mips, linux-kernel
Apply_r_mips_26_rel() relocates instructions like j, jal and etc. These
instructions consist of 6bits function field and 26bits address field.
The value of target_addr as follows,
=================================================================
| high 4bits | low 28bits |
=================================================================
|the high 4bits of this PC | the low 26bits of instructions << 2|
=================================================================
Thus, loc_orig and log_new both need high 4bits ranther than high 6bits.
Replace 0x3ffffff with 0xfffffff.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
---
arch/mips/kernel/relocate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 3d80a51..709cfa0 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -95,7 +95,7 @@ static int __init apply_r_mips_26_rel(u32 *loc_orig, u32 *loc_new, long offset)
/* Original target address */
target_addr <<= 2;
- target_addr += (unsigned long)loc_orig & ~0x03ffffff;
+ target_addr += (unsigned long)loc_orig & ~0x0fffffff;
/* Get the new target address */
target_addr += offset;
@@ -105,7 +105,7 @@ static int __init apply_r_mips_26_rel(u32 *loc_orig, u32 *loc_new, long offset)
return -ENOEXEC;
}
- target_addr -= (unsigned long)loc_new & ~0x03ffffff;
+ target_addr -= (unsigned long)loc_new & ~0x0fffffff;
target_addr >>= 2;
*loc_new = (*loc_new & ~0x03ffffff) | (target_addr & 0x03ffffff);
--
2.1.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 2/3] MIPS: Loongson64: Add KASLR support
2020-11-19 2:29 [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Jinyang He
@ 2020-11-19 2:29 ` Jinyang He
2020-11-19 2:29 ` [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured Jinyang He
2020-11-19 12:36 ` [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Thomas Bogendoerfer
2 siblings, 0 replies; 9+ messages in thread
From: Jinyang He @ 2020-11-19 2:29 UTC (permalink / raw)
To: Thomas Bogendoerfer, Huacai Chen, Jiaxun Yang; +Cc: linux-mips, linux-kernel
Provide null return plat_get_fdt(). Loongson64 start supporting KASLR.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
---
arch/mips/Kconfig | 4 +++-
arch/mips/loongson64/setup.c | 7 +++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0f638bf..1508829 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -488,6 +488,7 @@ config MACH_LOONGSON64
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_ZBOOT
+ select SYS_SUPPORTS_RELOCATABLE
select ZONE_DMA32
select NUMA
select SMP
@@ -2778,7 +2779,8 @@ config RELOCATABLE
depends on CPU_MIPS32_R2 || CPU_MIPS64_R2 || \
CPU_MIPS32_R5 || CPU_MIPS64_R5 || \
CPU_MIPS32_R6 || CPU_MIPS64_R6 || \
- CPU_P5600 || CAVIUM_OCTEON_SOC
+ CPU_P5600 || CAVIUM_OCTEON_SOC || \
+ CPU_LOONGSON64
help
This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.
diff --git a/arch/mips/loongson64/setup.c b/arch/mips/loongson64/setup.c
index 6fe3fff..5a5b745 100644
--- a/arch/mips/loongson64/setup.c
+++ b/arch/mips/loongson64/setup.c
@@ -31,6 +31,13 @@ static void wbflush_loongson(void)
void (*__wbflush)(void) = wbflush_loongson;
EXPORT_SYMBOL(__wbflush);
+#ifdef CONFIG_RELOCATABLE
+void __init *plat_get_fdt(void)
+{
+ return NULL;
+}
+#endif
+
void __init plat_mem_setup(void)
{
if (loongson_fdt_blob)
--
2.1.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured
2020-11-19 2:29 [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Jinyang He
2020-11-19 2:29 ` [PATCH 2/3] MIPS: Loongson64: Add KASLR support Jinyang He
@ 2020-11-19 2:29 ` Jinyang He
2020-11-19 8:06 ` Sergei Shtylyov
2020-11-19 12:45 ` Thomas Bogendoerfer
2020-11-19 12:36 ` [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Thomas Bogendoerfer
2 siblings, 2 replies; 9+ messages in thread
From: Jinyang He @ 2020-11-19 2:29 UTC (permalink / raw)
To: Thomas Bogendoerfer, Huacai Chen, Jiaxun Yang; +Cc: linux-mips, linux-kernel
When CONFIG_RANDOMIZE_BASE is not set, determine_relocation_address()
always returns a constant. It is not friendly to users if the address
cannot be used. Make it can be configured at Kconfig.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
---
arch/mips/Kconfig | 5 +++++
arch/mips/kernel/relocate.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 1508829..1c95478 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2803,6 +2803,11 @@ config RELOCATION_TABLE_SIZE
If unsure, leave at the default value.
+config RELOCATE_DESTINATION
+ hex "Relocate address when RANDOMIZE_BASE is not set"
+ depends on RELOCATABLE && !RANDOMIZE_BASE
+ default "0xffffffff81000000"
+
config RANDOMIZE_BASE
bool "Randomize the address of the kernel image"
depends on RELOCATABLE
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 709cfa0..b7ea6ff 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -276,7 +276,7 @@ static inline void __init *determine_relocation_address(void)
* Choose a new address for the kernel
* For now we'll hard code the destination
*/
- return (void *)0xffffffff81000000;
+ return (void *)CONFIG_RELOCATE_DESTINATION;
}
#endif
--
2.1.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured
2020-11-19 2:29 ` [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured Jinyang He
@ 2020-11-19 8:06 ` Sergei Shtylyov
2020-11-19 9:31 ` Jinyang He
2020-11-19 12:45 ` Thomas Bogendoerfer
1 sibling, 1 reply; 9+ messages in thread
From: Sergei Shtylyov @ 2020-11-19 8:06 UTC (permalink / raw)
To: Jinyang He, Thomas Bogendoerfer, Huacai Chen, Jiaxun Yang
Cc: linux-mips, linux-kernel
Hello!
On 19.11.2020 5:29, Jinyang He wrote:
> When CONFIG_RANDOMIZE_BASE is not set, determine_relocation_address()
> always returns a constant. It is not friendly to users if the address
> cannot be used. Make it can be configured at Kconfig.
Make it configurable?
> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
[...]
MBR, Sergei
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured
2020-11-19 8:06 ` Sergei Shtylyov
@ 2020-11-19 9:31 ` Jinyang He
0 siblings, 0 replies; 9+ messages in thread
From: Jinyang He @ 2020-11-19 9:31 UTC (permalink / raw)
To: Sergei Shtylyov, Thomas Bogendoerfer, Huacai Chen, Jiaxun Yang
Cc: linux-mips, linux-kernel
Hi,
On 11/19/2020 04:06 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 19.11.2020 5:29, Jinyang He wrote:
>
>> When CONFIG_RANDOMIZE_BASE is not set, determine_relocation_address()
>> always returns a constant. It is not friendly to users if the address
>> cannot be used. Make it can be configured at Kconfig.
>
> Make it configurable?
Oh, yes. Sorry for the expression.
0xffffffff81000000 cannot be used on Loongson64 if CONFIG_RANDOMIZE_BASE
is disabled.
It's lower than address of _end. It makes relocation_addr_valid() return
0 always.
Thanks!
Jinyang
>> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
> [...]
>
> MBR, Sergei
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel
2020-11-19 2:29 [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Jinyang He
2020-11-19 2:29 ` [PATCH 2/3] MIPS: Loongson64: Add KASLR support Jinyang He
2020-11-19 2:29 ` [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured Jinyang He
@ 2020-11-19 12:36 ` Thomas Bogendoerfer
2020-11-20 2:48 ` Jinyang He
2 siblings, 1 reply; 9+ messages in thread
From: Thomas Bogendoerfer @ 2020-11-19 12:36 UTC (permalink / raw)
To: Jinyang He; +Cc: Huacai Chen, Jiaxun Yang, linux-mips, linux-kernel
On Thu, Nov 19, 2020 at 10:29:12AM +0800, Jinyang He wrote:
> Apply_r_mips_26_rel() relocates instructions like j, jal and etc. These
> instructions consist of 6bits function field and 26bits address field.
> The value of target_addr as follows,
> =================================================================
> | high 4bits | low 28bits |
> =================================================================
> |the high 4bits of this PC | the low 26bits of instructions << 2|
> =================================================================
> Thus, loc_orig and log_new both need high 4bits ranther than high 6bits.
rather
> Replace 0x3ffffff with 0xfffffff.
>
> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
> ---
> arch/mips/kernel/relocate.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
> index 3d80a51..709cfa0 100644
> --- a/arch/mips/kernel/relocate.c
> +++ b/arch/mips/kernel/relocate.c
> @@ -95,7 +95,7 @@ static int __init apply_r_mips_26_rel(u32 *loc_orig, u32 *loc_new, long offset)
>
> /* Original target address */
> target_addr <<= 2;
> - target_addr += (unsigned long)loc_orig & ~0x03ffffff;
> + target_addr += (unsigned long)loc_orig & ~0x0fffffff;
how about using
target_addr += (unsigned long)log_orig & 0xf0000000;
which makes it IMHO even clearer what this does ?
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured
2020-11-19 2:29 ` [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured Jinyang He
2020-11-19 8:06 ` Sergei Shtylyov
@ 2020-11-19 12:45 ` Thomas Bogendoerfer
2020-11-20 2:43 ` Jinyang He
1 sibling, 1 reply; 9+ messages in thread
From: Thomas Bogendoerfer @ 2020-11-19 12:45 UTC (permalink / raw)
To: Jinyang He; +Cc: Huacai Chen, Jiaxun Yang, linux-mips, linux-kernel
On Thu, Nov 19, 2020 at 10:29:14AM +0800, Jinyang He wrote:
> When CONFIG_RANDOMIZE_BASE is not set, determine_relocation_address()
> always returns a constant. It is not friendly to users if the address
> cannot be used. Make it can be configured at Kconfig.
and how do I get the information which address I need to enter ?
This looks more like platforms need to supply a working address and
not the user configuring the kernel...
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured
2020-11-19 12:45 ` Thomas Bogendoerfer
@ 2020-11-20 2:43 ` Jinyang He
0 siblings, 0 replies; 9+ messages in thread
From: Jinyang He @ 2020-11-20 2:43 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Huacai Chen, Jiaxun Yang, linux-mips, linux-kernel
Hi,
On 11/19/2020 08:45 PM, Thomas Bogendoerfer wrote:
> On Thu, Nov 19, 2020 at 10:29:14AM +0800, Jinyang He wrote:
>> When CONFIG_RANDOMIZE_BASE is not set, determine_relocation_address()
>> always returns a constant. It is not friendly to users if the address
>> cannot be used. Make it can be configured at Kconfig.
> and how do I get the information which address I need to enter ?
> This looks more like platforms need to supply a working address and
> not the user configuring the kernel...
You are right.
We only have two address to enter if CONFIG_RANDOMIZE_BASE disabled. One
is 0xffffffff81000000 in the current if succeed, the other is the orignal
address if failed. From relocation_addr_valid() we see that the avaliable
address need to higher than &_end to avoid overlaps original kernel.
E.g. 0xffffffff83000000 and 0xffffffff84000000 both is avaliable on
Loongson64 platform when &_end == 0xffffffff82213f80. But
0xffffffff82000000 is not available in that case.
In reality test, I compiled kernel first and got &_end. And then modified
the relocate_address to avaliable and compiled kernel once more. It is
a bad idea.
Is it different from modifying CONFIG_PHYSICAL_START when just relocate
one address? Does it make sense if only one address to relocate?
Morever, RANDOMIZE_BASE is normally avaliable. Can we add a kernel
parameter like "relocation=0xffffffff81000000" to direct address?
At least, other architecture disabling RANDOMIZE_BASE looks like "nokaslr".
Thus, can we delete these code which RANDOMIZE_BASE disabled?
Thanks! :-)
Jinyang
> Thomas.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel
2020-11-19 12:36 ` [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Thomas Bogendoerfer
@ 2020-11-20 2:48 ` Jinyang He
0 siblings, 0 replies; 9+ messages in thread
From: Jinyang He @ 2020-11-20 2:48 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Huacai Chen, Jiaxun Yang, linux-mips, linux-kernel
Hi,
On 11/19/2020 08:36 PM, Thomas Bogendoerfer wrote:
> On Thu, Nov 19, 2020 at 10:29:12AM +0800, Jinyang He wrote:
>> Apply_r_mips_26_rel() relocates instructions like j, jal and etc. These
>> instructions consist of 6bits function field and 26bits address field.
>> The value of target_addr as follows,
>> =================================================================
>> | high 4bits | low 28bits |
>> =================================================================
>> |the high 4bits of this PC | the low 26bits of instructions << 2|
>> =================================================================
>> Thus, loc_orig and log_new both need high 4bits ranther than high 6bits.
> rather
>
>> Replace 0x3ffffff with 0xfffffff.
>>
>> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
>> ---
>> arch/mips/kernel/relocate.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
>> index 3d80a51..709cfa0 100644
>> --- a/arch/mips/kernel/relocate.c
>> +++ b/arch/mips/kernel/relocate.c
>> @@ -95,7 +95,7 @@ static int __init apply_r_mips_26_rel(u32 *loc_orig, u32 *loc_new, long offset)
>>
>> /* Original target address */
>> target_addr <<= 2;
>> - target_addr += (unsigned long)loc_orig & ~0x03ffffff;
>> + target_addr += (unsigned long)loc_orig & ~0x0fffffff;
> how about using
>
> target_addr += (unsigned long)log_orig & 0xf0000000;
>
> which makes it IMHO even clearer what this does ?
That sounds good. I'll send v2 later.
Thanks,
Jinyang.
> Thomas.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-11-20 2:48 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-19 2:29 [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Jinyang He
2020-11-19 2:29 ` [PATCH 2/3] MIPS: Loongson64: Add KASLR support Jinyang He
2020-11-19 2:29 ` [PATCH 3/3] MIPS: KASLR: Make relocation_address can be configured Jinyang He
2020-11-19 8:06 ` Sergei Shtylyov
2020-11-19 9:31 ` Jinyang He
2020-11-19 12:45 ` Thomas Bogendoerfer
2020-11-20 2:43 ` Jinyang He
2020-11-19 12:36 ` [PATCH 1/3] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel Thomas Bogendoerfer
2020-11-20 2:48 ` Jinyang He
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).