linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/2] x86/boot: fix relying on link order
@ 2022-11-01 16:15 Alexander Lobakin
  2022-11-01 16:15 ` [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code Alexander Lobakin
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Alexander Lobakin @ 2022-11-01 16:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen
  Cc: Alexander Lobakin, Jiri Slaby, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

The series contains stuff I caught last week while working on some
x86 code. It can be considered a material for fixes or for next,
I'm okay with either, although leaning more towards fixes :P

Notes on patches:
* 0001: I didn't put any "Fixes:" tag since it's not linear. The
        lines changed with this patch came from the initial x86
        KASLR series, but that unconditional jump to the kernel
        beginning already was there. It goes at least from the set
        that brought relocatable kernel support to x86, but this
        is quite prehistoric already and might not look really
        relatable. So up to you whether it needs any.
* 0002: doesn't fix anything, except that having any files listed
        in that whitelist already is an architecture bug :D And
        it wouldn't be convenient to decouple it from #0001, but
        up to you as well.

From v1[0]:
 * collect the Tested-by tags (Jiri);
 * don't add pathetic returns after noreturn error() (Jiri);
 * debug-print the entry point offset via debug_putaddr() before
   booting (Jiri);
 * always have an empty line before return statements (Jiri). 

[0] https://lore.kernel.org/all/20221031151047.167288-1-alexandr.lobakin@intel.com

Alexander Lobakin (2):
  x86/boot: robustify calling startup_{32,64}() from the decompressor
    code
  scripts/head-object-list: remove x86 from the list

 arch/x86/boot/compressed/head_32.S |  2 +-
 arch/x86/boot/compressed/head_64.S |  2 +-
 arch/x86/boot/compressed/misc.c    | 16 ++++++++++------
 scripts/head-object-list.txt       |  6 ------
 4 files changed, 12 insertions(+), 14 deletions(-)

-- 
2.38.1


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code
  2022-11-01 16:15 [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
@ 2022-11-01 16:15 ` Alexander Lobakin
  2022-11-02  6:14   ` Jiri Slaby
  2022-11-01 16:15 ` [PATCH v2 2/2] scripts/head-object-list: remove x86 from the list Alexander Lobakin
  2022-11-07 12:55 ` [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
  2 siblings, 1 reply; 13+ messages in thread
From: Alexander Lobakin @ 2022-11-01 16:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen
  Cc: Alexander Lobakin, Jiri Slaby, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

After commit ce697ccee1a8 ("kbuild: remove head-y syntax"), I
started digging whether x86 is ready for removing this old cruft.
Removing its objects from the list makes the kernel unbootable.
This applies only to bzImage, vmlinux still works correctly.
The reason is that with no strict object order determined by the
linker arguments, not the linker script, startup_64 can be placed
not right at the beginning of the kernel.
Here's vmlinux.map's beginning before removing:

ffffffff81000000         vmlinux.o:(.head.text)
ffffffff81000000                 startup_64
ffffffff81000070                 secondary_startup_64
ffffffff81000075                 secondary_startup_64_no_verify
ffffffff81000160                 verify_cpu

and after:

ffffffff81000000         vmlinux.o:(.head.text)
ffffffff81000000                 pvh_start_xen
ffffffff81000080                 startup_64
ffffffff810000f0                 secondary_startup_64
ffffffff810000f5                 secondary_startup_64_no_verify

Not a problem itself, but the self-extractor code has the address of
that function hardcoded the beginning, not looking onto the ELF
header, which always contains the address of startup_{32,64}().

So, instead of doing an "act of blind faith", just take the address
from the ELF header and extract a relative offset to the entry
point. The decompressor function already returns a pointer to the
beginning of the kernel to the Asm code, which then jumps to it,
so add that offset to the return value.
This doesn't change anything for now, but allows to resign from the
"head object list" for x86 and makes sure valid Kbuild or any other
improvements won't break anything here in general.

Tested-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
---
 arch/x86/boot/compressed/head_32.S |  2 +-
 arch/x86/boot/compressed/head_64.S |  2 +-
 arch/x86/boot/compressed/misc.c    | 16 ++++++++++------
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
index 3b354eb9516d..56f9847e208b 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -187,7 +187,7 @@ SYM_FUNC_START_LOCAL_NOALIGN(.Lrelocated)
 	leal	boot_heap@GOTOFF(%ebx), %eax
 	pushl	%eax			/* heap area */
 	pushl	%esi			/* real mode pointer */
-	call	extract_kernel		/* returns kernel location in %eax */
+	call	extract_kernel		/* returns kernel entry point in %eax */
 	addl	$24, %esp
 
 /*
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index d33f060900d2..aeba5aa3d26c 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -593,7 +593,7 @@ SYM_FUNC_START_LOCAL_NOALIGN(.Lrelocated)
 	movl	input_len(%rip), %ecx	/* input_len */
 	movq	%rbp, %r8		/* output target address */
 	movl	output_len(%rip), %r9d	/* decompressed length, end of relocs */
-	call	extract_kernel		/* returns kernel location in %rax */
+	call	extract_kernel		/* returns kernel entry point in %rax */
 	popq	%rsi
 
 /*
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index cf690d8712f4..2548d7fb243e 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -277,7 +277,7 @@ static inline void handle_relocations(void *output, unsigned long output_len,
 { }
 #endif
 
-static void parse_elf(void *output)
+static size_t parse_elf(void *output)
 {
 #ifdef CONFIG_X86_64
 	Elf64_Ehdr ehdr;
@@ -287,16 +287,15 @@ static void parse_elf(void *output)
 	Elf32_Phdr *phdrs, *phdr;
 #endif
 	void *dest;
+	size_t off;
 	int i;
 
 	memcpy(&ehdr, output, sizeof(ehdr));
 	if (ehdr.e_ident[EI_MAG0] != ELFMAG0 ||
 	   ehdr.e_ident[EI_MAG1] != ELFMAG1 ||
 	   ehdr.e_ident[EI_MAG2] != ELFMAG2 ||
-	   ehdr.e_ident[EI_MAG3] != ELFMAG3) {
+	   ehdr.e_ident[EI_MAG3] != ELFMAG3)
 		error("Kernel is not a valid ELF file");
-		return;
-	}
 
 	debug_putstr("Parsing ELF... ");
 
@@ -305,6 +304,7 @@ static void parse_elf(void *output)
 		error("Failed to allocate space for phdrs");
 
 	memcpy(phdrs, output + ehdr.e_phoff, sizeof(*phdrs) * ehdr.e_phnum);
+	off = ehdr.e_entry - phdrs->p_paddr;
 
 	for (i = 0; i < ehdr.e_phnum; i++) {
 		phdr = &phdrs[i];
@@ -328,6 +328,8 @@ static void parse_elf(void *output)
 	}
 
 	free(phdrs);
+
+	return off;
 }
 
 /*
@@ -356,6 +358,7 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,
 	const unsigned long kernel_total_size = VO__end - VO__text;
 	unsigned long virt_addr = LOAD_PHYSICAL_ADDR;
 	unsigned long needed_size;
+	size_t off;
 
 	/* Retain x86 boot parameters pointer passed from startup_32/64. */
 	boot_params = rmode;
@@ -456,14 +459,15 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,
 	debug_putstr("\nDecompressing Linux... ");
 	__decompress(input_data, input_len, NULL, NULL, output, output_len,
 			NULL, error);
-	parse_elf(output);
+	off = parse_elf(output);
+	debug_putaddr(off);
 	handle_relocations(output, output_len, virt_addr);
 	debug_putstr("done.\nBooting the kernel.\n");
 
 	/* Disable exception handling before booting the kernel */
 	cleanup_exception_handling();
 
-	return output;
+	return output + off;
 }
 
 void fortify_panic(const char *name)
-- 
2.38.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH v2 2/2] scripts/head-object-list: remove x86 from the list
  2022-11-01 16:15 [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
  2022-11-01 16:15 ` [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code Alexander Lobakin
@ 2022-11-01 16:15 ` Alexander Lobakin
  2022-11-07 12:55 ` [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
  2 siblings, 0 replies; 13+ messages in thread
From: Alexander Lobakin @ 2022-11-01 16:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen
  Cc: Alexander Lobakin, Jiri Slaby, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

Now that x86 boot code is not hardcoded to the particular linking
order, remove x86 files from the list and let them be placed inside
the vmlinux according only to the linker script and linker
preferences.

Tested-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
---
 scripts/head-object-list.txt | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/scripts/head-object-list.txt b/scripts/head-object-list.txt
index b16326a92c45..405d2942898a 100644
--- a/scripts/head-object-list.txt
+++ b/scripts/head-object-list.txt
@@ -44,10 +44,4 @@ arch/s390/kernel/head64.o
 arch/sh/kernel/head_32.o
 arch/sparc/kernel/head_32.o
 arch/sparc/kernel/head_64.o
-arch/x86/kernel/head_32.o
-arch/x86/kernel/head_64.o
-arch/x86/kernel/head32.o
-arch/x86/kernel/head64.o
-arch/x86/kernel/ebda.o
-arch/x86/kernel/platform-quirks.o
 arch/xtensa/kernel/head.o
-- 
2.38.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code
  2022-11-01 16:15 ` [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code Alexander Lobakin
@ 2022-11-02  6:14   ` Jiri Slaby
  0 siblings, 0 replies; 13+ messages in thread
From: Jiri Slaby @ 2022-11-02  6:14 UTC (permalink / raw)
  To: Alexander Lobakin, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen
  Cc: H. Peter Anvin, Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

On 01. 11. 22, 17:15, Alexander Lobakin wrote:
> After commit ce697ccee1a8 ("kbuild: remove head-y syntax"), I
> started digging whether x86 is ready for removing this old cruft.
> Removing its objects from the list makes the kernel unbootable.
> This applies only to bzImage, vmlinux still works correctly.
> The reason is that with no strict object order determined by the
> linker arguments, not the linker script, startup_64 can be placed
> not right at the beginning of the kernel.
> Here's vmlinux.map's beginning before removing:
> 
> ffffffff81000000         vmlinux.o:(.head.text)
> ffffffff81000000                 startup_64
> ffffffff81000070                 secondary_startup_64
> ffffffff81000075                 secondary_startup_64_no_verify
> ffffffff81000160                 verify_cpu
> 
> and after:
> 
> ffffffff81000000         vmlinux.o:(.head.text)
> ffffffff81000000                 pvh_start_xen
> ffffffff81000080                 startup_64
> ffffffff810000f0                 secondary_startup_64
> ffffffff810000f5                 secondary_startup_64_no_verify
> 
> Not a problem itself, but the self-extractor code has the address of
> that function hardcoded the beginning, not looking onto the ELF
> header, which always contains the address of startup_{32,64}().
> 
> So, instead of doing an "act of blind faith", just take the address
> from the ELF header and extract a relative offset to the entry
> point. The decompressor function already returns a pointer to the
> beginning of the kernel to the Asm code, which then jumps to it,
> so add that offset to the return value.
> This doesn't change anything for now, but allows to resign from the
> "head object list" for x86 and makes sure valid Kbuild or any other
> improvements won't break anything here in general.
> 
> Tested-by: Jiri Slaby <jirislaby@kernel.org>
> Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>

Reviewed-by: Jiri Slaby <jirislaby@kernel.org>

thanks,
-- 
js
suse labs


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-11-01 16:15 [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
  2022-11-01 16:15 ` [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code Alexander Lobakin
  2022-11-01 16:15 ` [PATCH v2 2/2] scripts/head-object-list: remove x86 from the list Alexander Lobakin
@ 2022-11-07 12:55 ` Alexander Lobakin
  2022-11-08 23:09   ` Dave Hansen
  2 siblings, 1 reply; 13+ messages in thread
From: Alexander Lobakin @ 2022-11-07 12:55 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen
  Cc: Alexander Lobakin, Jiri Slaby, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

From: Alexander Lobakin <alexandr.lobakin@intel.com>
Date: Tue, 1 Nov 2022 17:15:27 +0100

> The series contains stuff I caught last week while working on some
> x86 code. It can be considered a material for fixes or for next,
> I'm okay with either, although leaning more towards fixes :P
> 
> Notes on patches:
> * 0001: I didn't put any "Fixes:" tag since it's not linear. The
>         lines changed with this patch came from the initial x86
>         KASLR series, but that unconditional jump to the kernel
>         beginning already was there. It goes at least from the set
>         that brought relocatable kernel support to x86, but this
>         is quite prehistoric already and might not look really
>         relatable. So up to you whether it needs any.
> * 0002: doesn't fix anything, except that having any files listed
>         in that whitelist already is an architecture bug :D And
>         it wouldn't be convenient to decouple it from #0001, but
>         up to you as well.
> 
> From v1[0]:
>  * collect the Tested-by tags (Jiri);
>  * don't add pathetic returns after noreturn error() (Jiri);
>  * debug-print the entry point offset via debug_putaddr() before
>    booting (Jiri);
>  * always have an empty line before return statements (Jiri). 
> 
> [0] https://lore.kernel.org/all/20221031151047.167288-1-alexandr.lobakin@intel.com
> 
> Alexander Lobakin (2):
>   x86/boot: robustify calling startup_{32,64}() from the decompressor
>     code
>   scripts/head-object-list: remove x86 from the list
> 
>  arch/x86/boot/compressed/head_32.S |  2 +-
>  arch/x86/boot/compressed/head_64.S |  2 +-
>  arch/x86/boot/compressed/misc.c    | 16 ++++++++++------
>  scripts/head-object-list.txt       |  6 ------
>  4 files changed, 12 insertions(+), 14 deletions(-)

Ping?

Also, I managed to remove .head.text at all from x86. Would it be
better to respin this series with the third patch or send a
follow-up later?

> 
> -- 
> 2.38.1

Thanks,
Olek

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-11-07 12:55 ` [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
@ 2022-11-08 23:09   ` Dave Hansen
  2022-11-21 12:09     ` Alexander Lobakin
  0 siblings, 1 reply; 13+ messages in thread
From: Dave Hansen @ 2022-11-08 23:09 UTC (permalink / raw)
  To: Alexander Lobakin, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen
  Cc: Jiri Slaby, H. Peter Anvin, Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

On 11/7/22 04:55, Alexander Lobakin wrote:
> Ping?
> 
> Also, I managed to remove .head.text at all from x86. Would it be
> better to respin this series with the third patch or send a
> follow-up later?
> 

Hi Alexander,

Things are a bit busy in the review queue at the moment.  As always,
we'd love help reviewing stuff.  So, while you're waiting for us to
review this, could you perhaps look around and find a series that's also
hurting for review tags?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-11-08 23:09   ` Dave Hansen
@ 2022-11-21 12:09     ` Alexander Lobakin
  2022-11-21 13:14       ` Borislav Petkov
  0 siblings, 1 reply; 13+ messages in thread
From: Alexander Lobakin @ 2022-11-21 12:09 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Alexander Lobakin, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, Jiri Slaby, H. Peter Anvin, Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

From: Dave Hansen <dave.hansen@intel.com>
Date: Tue, 8 Nov 2022 15:09:07 -0800

> On 11/7/22 04:55, Alexander Lobakin wrote:
> > Ping?
> > 
> > Also, I managed to remove .head.text at all from x86. Would it be
> > better to respin this series with the third patch or send a
> > follow-up later?
> > 
> 
> Hi Alexander,

Hey,

> 
> Things are a bit busy in the review queue at the moment.  As always,
> we'd love help reviewing stuff.  So, while you're waiting for us to
> review this, could you perhaps look around and find a series that's also
> hurting for review tags?

I've got Reviewed-by and Tested-by from Jiri, isn't that enough? Or
I need also some other group to get tags from?

Thanks,
Olek

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-11-21 12:09     ` Alexander Lobakin
@ 2022-11-21 13:14       ` Borislav Petkov
  2022-11-21 16:00         ` Alexander Lobakin
  0 siblings, 1 reply; 13+ messages in thread
From: Borislav Petkov @ 2022-11-21 13:14 UTC (permalink / raw)
  To: Alexander Lobakin
  Cc: Dave Hansen, Thomas Gleixner, Ingo Molnar, Dave Hansen,
	Jiri Slaby, H. Peter Anvin, Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

On Mon, Nov 21, 2022 at 01:09:18PM +0100, Alexander Lobakin wrote:
> > Things are a bit busy in the review queue at the moment.  As always,
> > we'd love help reviewing stuff.  So, while you're waiting for us to
> > review this, could you perhaps look around and find a series that's also
> > hurting for review tags?
> 
> I've got Reviewed-by and Tested-by from Jiri, isn't that enough? Or
> I need also some other group to get tags from?

What he actually means is if *you* yourself help out with patch review.
Like find a set on lkml which you're interested in - I believe there
will be no shortage of such sets - and poke at it, review it, ask
devil's advocate questions, etc.

The distribution of work - gazillion submitters vs a handful of
maintainers simply cannot scale and instead of submitters pinging
maintainers all the time when they can look at their set, submitters
could review other submitters' work in the meantime, while waiting.

I.e., a win-win-win situation. :-)

Makes more sense?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-11-21 13:14       ` Borislav Petkov
@ 2022-11-21 16:00         ` Alexander Lobakin
  2022-12-07 15:08           ` Alexander Lobakin
  0 siblings, 1 reply; 13+ messages in thread
From: Alexander Lobakin @ 2022-11-21 16:00 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Alexander Lobakin, Dave Hansen, Thomas Gleixner, Ingo Molnar,
	Dave Hansen, Jiri Slaby, H. Peter Anvin, Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, x86, linux-kernel

From: Borislav Petkov <bp@alien8.de>
Date: Mon, 21 Nov 2022 14:14:43 +0100

> On Mon, Nov 21, 2022 at 01:09:18PM +0100, Alexander Lobakin wrote:
> > > Things are a bit busy in the review queue at the moment.  As always,
> > > we'd love help reviewing stuff.  So, while you're waiting for us to
> > > review this, could you perhaps look around and find a series that's also
> > > hurting for review tags?
> > 
> > I've got Reviewed-by and Tested-by from Jiri, isn't that enough? Or
> > I need also some other group to get tags from?
> 
> What he actually means is if *you* yourself help out with patch review.
> Like find a set on lkml which you're interested in - I believe there
> will be no shortage of such sets - and poke at it, review it, ask
> devil's advocate questions, etc.
> 
> The distribution of work - gazillion submitters vs a handful of
> maintainers simply cannot scale and instead of submitters pinging
> maintainers all the time when they can look at their set, submitters
> could review other submitters' work in the meantime, while waiting.
> 
> I.e., a win-win-win situation. :-)
> 
> Makes more sense?

I know, I got it from the first read :D I try to review stuff I have
mature knowledge in each day, not that lots of them are from the x86
ML :s

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Thanks,
Olek

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-11-21 16:00         ` Alexander Lobakin
@ 2022-12-07 15:08           ` Alexander Lobakin
  2022-12-07 15:24             ` Borislav Petkov
  0 siblings, 1 reply; 13+ messages in thread
From: Alexander Lobakin @ 2022-12-07 15:08 UTC (permalink / raw)
  To: x86
  Cc: Alexander Lobakin, Borislav Petkov, Dave Hansen, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, Jiri Slaby, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, linux-kernel

From: Alexander Lobakin <alexandr.lobakin@intel.com>
Date: Mon, 21 Nov 2022 17:00:30 +0100

> From: Borislav Petkov <bp@alien8.de>
> Date: Mon, 21 Nov 2022 14:14:43 +0100
> 
> > On Mon, Nov 21, 2022 at 01:09:18PM +0100, Alexander Lobakin wrote:
> > > > Things are a bit busy in the review queue at the moment.  As always,
> > > > we'd love help reviewing stuff.  So, while you're waiting for us to
> > > > review this, could you perhaps look around and find a series that's also
> > > > hurting for review tags?

[...]

> I know, I got it from the first read :D I try to review stuff I have
> mature knowledge in each day, not that lots of them are from the x86
> ML :s

I was hoping it would hit one of the 6.1 RCs as a fix, oh well :D
Why did some other fixes hit the x86 tree during that time then?

> 
> > 
> > -- 
> > Regards/Gruss,
> >     Boris.
> > 
> > https://people.kernel.org/tglx/notes-about-netiquette
> 
> Thanks,
> Olek

Thanks,
Olek

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-12-07 15:08           ` Alexander Lobakin
@ 2022-12-07 15:24             ` Borislav Petkov
  2022-12-07 15:30               ` Alexander Lobakin
  0 siblings, 1 reply; 13+ messages in thread
From: Borislav Petkov @ 2022-12-07 15:24 UTC (permalink / raw)
  To: Alexander Lobakin
  Cc: x86, Dave Hansen, Thomas Gleixner, Ingo Molnar, Dave Hansen,
	Jiri Slaby, H. Peter Anvin, Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, linux-kernel

On Wed, Dec 07, 2022 at 04:08:54PM +0100, Alexander Lobakin wrote:
> I was hoping it would hit one of the 6.1 RCs as a fix,

As a fix for which existing configuration which breaks if this fix is
missing?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-12-07 15:24             ` Borislav Petkov
@ 2022-12-07 15:30               ` Alexander Lobakin
  2022-12-07 15:52                 ` Borislav Petkov
  0 siblings, 1 reply; 13+ messages in thread
From: Alexander Lobakin @ 2022-12-07 15:30 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Alexander Lobakin, x86, Dave Hansen, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, Jiri Slaby, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, linux-kernel

From: Borislav Petkov <bp@alien8.de>
Date: Wed, 7 Dec 2022 16:24:00 +0100

> On Wed, Dec 07, 2022 at 04:08:54PM +0100, Alexander Lobakin wrote:
> > I was hoping it would hit one of the 6.1 RCs as a fix,
> 
> As a fix for which existing configuration which breaks if this fix is
> missing?

Ugh, fair enough :D Without it, FG-KASLR is broken, GCC-LTO is
broken, but none of them is in the mainline.
I recall there were some folks with LLD for which this $(head-y)
removal caused issues as well. But if they're quiet now, seems like
they don't hardly need it.
But not every fix is a fix only when it's easy to find a repro,
right...? But at least such are not urgent, you're correct here.

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Thanks,
Olek

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/2] x86/boot: fix relying on link order
  2022-12-07 15:30               ` Alexander Lobakin
@ 2022-12-07 15:52                 ` Borislav Petkov
  0 siblings, 0 replies; 13+ messages in thread
From: Borislav Petkov @ 2022-12-07 15:52 UTC (permalink / raw)
  To: Alexander Lobakin
  Cc: x86, Dave Hansen, Thomas Gleixner, Ingo Molnar, Dave Hansen,
	Jiri Slaby, H. Peter Anvin, Peter Zijlstra (Intel),
	Tony Luck, Kees Cook, Masahiro Yamada, linux-kernel

On Wed, Dec 07, 2022 at 04:30:00PM +0100, Alexander Lobakin wrote:
> But not every fix is a fix only when it's easy to find a repro,
> right...?

The basic rule is: only regression fixes during the -rc phase.

Documentation/process/2.Process.rst

although there it is not spelled out that it is regressions only. But
this is the rule we adhere to in the tip tree in general.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-12-07 15:52 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-01 16:15 [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
2022-11-01 16:15 ` [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code Alexander Lobakin
2022-11-02  6:14   ` Jiri Slaby
2022-11-01 16:15 ` [PATCH v2 2/2] scripts/head-object-list: remove x86 from the list Alexander Lobakin
2022-11-07 12:55 ` [PATCH v2 0/2] x86/boot: fix relying on link order Alexander Lobakin
2022-11-08 23:09   ` Dave Hansen
2022-11-21 12:09     ` Alexander Lobakin
2022-11-21 13:14       ` Borislav Petkov
2022-11-21 16:00         ` Alexander Lobakin
2022-12-07 15:08           ` Alexander Lobakin
2022-12-07 15:24             ` Borislav Petkov
2022-12-07 15:30               ` Alexander Lobakin
2022-12-07 15:52                 ` Borislav Petkov

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).