Hi,
Due to very limited space in the setup_header this patch series introduces new
kernel_info struct which will be used to convey information from the kernel to
the bootloader. This way the boot protocol can be extended regardless of the
setup_header limitations. Additionally, the patch series introduces some
convenience features like the setup_indirect struct and the
kernel_info.setup_type_max field.
Daniel
Documentation/x86/boot.rst | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/x86/boot/Makefile | 2 +-
arch/x86/boot/compressed/Makefile | 4 +-
arch/x86/boot/compressed/kaslr.c | 12 ++++++
arch/x86/boot/compressed/kernel_info.S | 22 ++++++++++
arch/x86/boot/header.S | 3 +-
arch/x86/boot/tools/build.c | 5 +++
arch/x86/include/uapi/asm/bootparam.h | 16 +++++++-
arch/x86/kernel/e820.c | 11 +++++
arch/x86/kernel/kdebugfs.c | 20 +++++++--
arch/x86/kernel/ksysfs.c | 30 ++++++++++----
arch/x86/kernel/setup.c | 4 ++
arch/x86/mm/ioremap.c | 11 +++++
13 files changed, 298 insertions(+), 16 deletions(-)
Daniel Kiper (3):
x86/boot: Introduce the kernel_info
x86/boot: Introduce the kernel_info.setup_type_max
x86/boot: Introduce the setup_indirect
This field contains maximal allowed type for setup_data.
This patch does not bump setup_header version in arch/x86/boot/header.S
because it will be followed by additional changes coming into the
Linux/x86 boot protocol.
Suggested-by: H. Peter Anvin (Intel) <[email protected]>
Signed-off-by: Daniel Kiper <[email protected]>
Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
Reviewed-by: Ross Philipson <[email protected]>
Reviewed-by: H. Peter Anvin (Intel) <[email protected]>
---
v5 - suggestions/fixes:
- move incorrect references to the setup_indirect to the
patch introducing it,
- do not bump setup_header version in arch/x86/boot/header.S
(suggested by H. Peter Anvin).
---
Documentation/x86/boot.rst | 9 ++++++++-
arch/x86/boot/compressed/kernel_info.S | 5 +++++
arch/x86/include/uapi/asm/bootparam.h | 3 +++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index c60fafda9427..1dad6eee8a5c 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -73,7 +73,7 @@ Protocol 2.14: BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c188
(x86/boot: Add ACPI RSDP address to setup_header)
DO NOT USE!!! ASSUME SAME AS 2.13.
-Protocol 2.15: (Kernel 5.5) Added the kernel_info.
+Protocol 2.15: (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
============= ============================================================
.. note::
@@ -981,6 +981,13 @@ Offset/size: 0x0008/4
This field contains the size of the kernel_info including kernel_info.header
and kernel_info.kernel_info_var_len_data.
+============ ==============
+Field name: setup_type_max
+Offset/size: 0x0008/4
+============ ==============
+
+ This field contains maximal allowed type for setup_data.
+
The Image Checksum
==================
diff --git a/arch/x86/boot/compressed/kernel_info.S b/arch/x86/boot/compressed/kernel_info.S
index 8ea6f6e3feef..018dacbd753e 100644
--- a/arch/x86/boot/compressed/kernel_info.S
+++ b/arch/x86/boot/compressed/kernel_info.S
@@ -1,5 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
+#include <asm/bootparam.h>
+
.section ".rodata.kernel_info", "a"
.global kernel_info
@@ -12,6 +14,9 @@ kernel_info:
/* Size total. */
.long kernel_info_end - kernel_info
+ /* Maximal allowed type for setup_data. */
+ .long SETUP_TYPE_MAX
+
kernel_info_var_len_data:
/* Empty for time being... */
kernel_info_end:
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index a1ebcd7a991c..dbb41128e5a0 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -11,6 +11,9 @@
#define SETUP_APPLE_PROPERTIES 5
#define SETUP_JAILHOUSE 6
+/* max(SETUP_*) */
+#define SETUP_TYPE_MAX SETUP_JAILHOUSE
+
/* ram_size flags */
#define RAMDISK_IMAGE_START_MASK 0x07FF
#define RAMDISK_PROMPT_FLAG 0x8000
--
2.11.0
On 2019-11-04 07:13, Daniel Kiper wrote:
> Hi,
>
> Due to very limited space in the setup_header this patch series introduces new
> kernel_info struct which will be used to convey information from the kernel to
> the bootloader. This way the boot protocol can be extended regardless of the
> setup_header limitations. Additionally, the patch series introduces some
> convenience features like the setup_indirect struct and the
> kernel_info.setup_type_max field.
>
> Daniel
>
Looks great! Ship it!
Reviewed-by: H. Peter Anvin (Intel) <[email protected]>
-hpa
On Mon, Nov 04, 2019 at 04:13:51PM +0100, Daniel Kiper wrote:
> Hi,
>
> Due to very limited space in the setup_header this patch series introduces new
> kernel_info struct which will be used to convey information from the kernel to
> the bootloader. This way the boot protocol can be extended regardless of the
> setup_header limitations. Additionally, the patch series introduces some
> convenience features like the setup_indirect struct and the
> kernel_info.setup_type_max field.
That's all fine and dandy but I'm missing an example about what that'll
be used for, in practice.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On November 6, 2019 9:03:33 AM PST, Borislav Petkov <[email protected]> wrote:
>On Mon, Nov 04, 2019 at 04:13:51PM +0100, Daniel Kiper wrote:
>> Hi,
>>
>> Due to very limited space in the setup_header this patch series
>introduces new
>> kernel_info struct which will be used to convey information from the
>kernel to
>> the bootloader. This way the boot protocol can be extended regardless
>of the
>> setup_header limitations. Additionally, the patch series introduces
>some
>> convenience features like the setup_indirect struct and the
>> kernel_info.setup_type_max field.
>
>That's all fine and dandy but I'm missing an example about what that'll
>be used for, in practice.
>
>Thx.
For one thing, we already have people asking for more than 4 GiB worth of initramfs, and especially with initramfs that huge it would make a *lot* of sense to allow loading it in chunks without having to concatenate them. I have been asking for a long time for initramfs creators to split the kernel-dependent and kernel independent parts into separate initramfs modules.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Wed, Nov 06, 2019 at 09:56:48AM -0800, [email protected] wrote:
> For one thing, we already have people asking for more than 4 GiB
> worth of initramfs, and especially with initramfs that huge it would
> make a *lot* of sense to allow loading it in chunks without having to
> concatenate them.
Yeah, tglx gave me his use case on IRC where they have the rootfs in the
initrd and how they would hit the limit when the rootfs has a bunch of
debug libs etc tools, which would blow up its size.
> I have been asking for a long time for initramfs creators to split the
> kernel-dependent and kernel independent parts into separate initramfs
> modules.
Right.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Nov 06, 2019 at 09:56:48AM -0800, [email protected] wrote:
> On November 6, 2019 9:03:33 AM PST, Borislav Petkov <[email protected]> wrote:
> >On Mon, Nov 04, 2019 at 04:13:51PM +0100, Daniel Kiper wrote:
> >> Hi,
> >>
> >> Due to very limited space in the setup_header this patch series introduces new
> >> kernel_info struct which will be used to convey information from the kernel to
> >> the bootloader. This way the boot protocol can be extended regardless of the
> >> setup_header limitations. Additionally, the patch series introduces some
> >> convenience features like the setup_indirect struct and the
> >> kernel_info.setup_type_max field.
> >
> >That's all fine and dandy but I'm missing an example about what that'll
> >be used for, in practice.
> >
> >Thx.
>
> For one thing, we already have people asking for more than 4 GiB worth
> of initramfs, and especially with initramfs that huge it would make a
> *lot* of sense to allow loading it in chunks without having to
> concatenate them. I have been asking for a long time for initramfs
> creators to split the kernel-dependent and kernel independent parts
> into separate initramfs modules.
Another user of this patchset is the TrenchBoot project on which we are
working on. We have to introduce separate entry point for Intel TXT MLE
startup code. That is why we need the kernel_info struct.
Daniel
On Mon, Nov 04, 2019 at 04:13:53PM +0100, Daniel Kiper wrote:
> This field contains maximal allowed type for setup_data.
>
> This patch does not bump setup_header version in arch/x86/boot/header.S
> because it will be followed by additional changes coming into the
> Linux/x86 boot protocol.
>
> Suggested-by: H. Peter Anvin (Intel) <[email protected]>
> Signed-off-by: Daniel Kiper <[email protected]>
> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
> Reviewed-by: Ross Philipson <[email protected]>
> Reviewed-by: H. Peter Anvin (Intel) <[email protected]>
> ---
> v5 - suggestions/fixes:
> - move incorrect references to the setup_indirect to the
> patch introducing it,
> - do not bump setup_header version in arch/x86/boot/header.S
> (suggested by H. Peter Anvin).
> ---
> Documentation/x86/boot.rst | 9 ++++++++-
> arch/x86/boot/compressed/kernel_info.S | 5 +++++
> arch/x86/include/uapi/asm/bootparam.h | 3 +++
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> index c60fafda9427..1dad6eee8a5c 100644
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -73,7 +73,7 @@ Protocol 2.14: BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c188
> (x86/boot: Add ACPI RSDP address to setup_header)
> DO NOT USE!!! ASSUME SAME AS 2.13.
>
> -Protocol 2.15: (Kernel 5.5) Added the kernel_info.
> +Protocol 2.15: (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
> ============= ============================================================
>
> .. note::
> @@ -981,6 +981,13 @@ Offset/size: 0x0008/4
> This field contains the size of the kernel_info including kernel_info.header
> and kernel_info.kernel_info_var_len_data.
>
> +============ ==============
> +Field name: setup_type_max
> +Offset/size: 0x0008/4
You already have
Field name: size_total
Offset/size: 0x0008/4
at that offset.
I guess you mean setup_type_max's offset to be 0x000c and it would be
that member:
.long 0x01234567 /* Some fixed size data for the bootloaders. */
?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Nov 08, 2019 at 11:09:30AM +0100, Borislav Petkov wrote:
> On Mon, Nov 04, 2019 at 04:13:53PM +0100, Daniel Kiper wrote:
> > This field contains maximal allowed type for setup_data.
> >
> > This patch does not bump setup_header version in arch/x86/boot/header.S
> > because it will be followed by additional changes coming into the
> > Linux/x86 boot protocol.
> >
> > Suggested-by: H. Peter Anvin (Intel) <[email protected]>
> > Signed-off-by: Daniel Kiper <[email protected]>
> > Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
> > Reviewed-by: Ross Philipson <[email protected]>
> > Reviewed-by: H. Peter Anvin (Intel) <[email protected]>
> > ---
> > v5 - suggestions/fixes:
> > - move incorrect references to the setup_indirect to the
> > patch introducing it,
> > - do not bump setup_header version in arch/x86/boot/header.S
> > (suggested by H. Peter Anvin).
> > ---
> > Documentation/x86/boot.rst | 9 ++++++++-
> > arch/x86/boot/compressed/kernel_info.S | 5 +++++
> > arch/x86/include/uapi/asm/bootparam.h | 3 +++
> > 3 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> > index c60fafda9427..1dad6eee8a5c 100644
> > --- a/Documentation/x86/boot.rst
> > +++ b/Documentation/x86/boot.rst
> > @@ -73,7 +73,7 @@ Protocol 2.14: BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c188
> > (x86/boot: Add ACPI RSDP address to setup_header)
> > DO NOT USE!!! ASSUME SAME AS 2.13.
> >
> > -Protocol 2.15: (Kernel 5.5) Added the kernel_info.
> > +Protocol 2.15: (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
> > ============= ============================================================
> >
> > .. note::
> > @@ -981,6 +981,13 @@ Offset/size: 0x0008/4
> > This field contains the size of the kernel_info including kernel_info.header
> > and kernel_info.kernel_info_var_len_data.
> >
> > +============ ==============
> > +Field name: setup_type_max
> > +Offset/size: 0x0008/4
>
> You already have
>
> Field name: size_total
> Offset/size: 0x0008/4
>
> at that offset.
>
> I guess you mean setup_type_max's offset to be 0x000c and it would be
> that member:
>
> .long 0x01234567 /* Some fixed size data for the bootloaders. */
>
> ?
Yeah, you are right. Would you like me to repost whole patch series or
could you fix it before committing?
Daniel
On Fri, Nov 08, 2019 at 11:47:02AM +0100, Daniel Kiper wrote:
> Yeah, you are right. Would you like me to repost whole patch series or
> could you fix it before committing?
Lemme finish looking at patch 3 first.
If you have to resend, please remove "This patch" and "We" in your text.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Nov 08, 2019 at 12:07:03PM +0100, Borislav Petkov wrote:
> On Fri, Nov 08, 2019 at 11:47:02AM +0100, Daniel Kiper wrote:
> > Yeah, you are right. Would you like me to repost whole patch series or
> > could you fix it before committing?
>
> Lemme finish looking at patch 3 first.
>
> If you have to resend, please remove "This patch" and "We" in your text.
OK, got your comments. I will repost the patch series probably on Tuesday.
I hope that it will land in 5.5 then.
Daniel
On Fri, Nov 08, 2019 at 01:52:48PM +0100, Daniel Kiper wrote:
> OK, got your comments. I will repost the patch series probably on Tuesday.
> I hope that it will land in 5.5 then.
I don't see why not if you base it ontop of tip:x86/boot and test it
properly before sending.
Out of curiosity, is there any particular reason this should be in 5.5?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Nov 08, 2019 at 02:03:38PM +0100, Borislav Petkov wrote:
> On Fri, Nov 08, 2019 at 01:52:48PM +0100, Daniel Kiper wrote:
> > OK, got your comments. I will repost the patch series probably on Tuesday.
> > I hope that it will land in 5.5 then.
>
> I don't see why not if you base it ontop of tip:x86/boot and test it
> properly before sending.
Great!
> Out of curiosity, is there any particular reason this should be in 5.5?
Just want to have it done... :-))) ...and continue work on stuff which
depends on it.
Daniel