Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On Mon, 21 Sep 2020 14:15:55 -0500, Tyler Hicks wrote: > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This > config option can be used to extend the kernel command line parameters, > specified by the bootloader, with additional command line parameters > specified in the kernel configuration. > > This option addresses the following use cases: > > [...] Applied to arm64 (for-next/cmdline-extended), thanks! [1/2] arm64: kaslr: Refactor early init command line parsing https://git.kernel.org/arm64/c/52ec03f75d59 [2/2] arm64: Extend the kernel command line from the bootloader https://git.kernel.org/arm64/c/1e40d105dae5 -- Catalin
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On Thu, Nov 5, 2020 at 9:28 AM Tyler Hicks wrote:
>
> On 2020-11-05 09:58:54, Will Deacon wrote:
> > On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > > > > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > > > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels.
> > > > > > This
> > > > > > config option can be used to extend the kernel command line
> > > > > > parameters,
> > > > > > specified by the bootloader, with additional command line parameters
> > > > > > specified in the kernel configuration.
> > > > >
> > > > > Hi Catalin and Will - Friendly ping on this series now that we're
> > > > > on the other side of the 5.10 merge window. I hope it can be
> > > > > considered
> > > > > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks!
> > > >
> > > > Can you use bootconfig to achieve what you need?
> > >
> > > Thanks for mentioning bootconfig. I hadn't considered it.
> > >
> > > After reading the docs and code, I see a few reasons why I can't use it
> > > out of the box:
> > >
> > > 1) It requires "bootconfig" to be appended to the kernel command line.
> > > My proposed patch series makes it possible to append new options to
> > > the kernel command line in situations where the bootloader is not
> > > interactive. This presents a circular dependency problem for my use
> > > case.
> > >
> > > A new config option could be added to force the enablement of
> > > bootconfig but that would sort of be a single-use duplicate of
> > > CONFIG_CMDLINE_EXTEND's functionality.
> > >
> > > 2) Not all kernel command line options can be configured using
> > > bootconfig. For example, the "nokaslr" and "crashkernel=" parameters
> > > are parsed/handled before setup_boot_config() is called. KASLR can
> > > be disabled via a kernel config change but there's no config option
> > > equivalent for "crashkernel=". Changing the "crashkernel=" command
> > > line option is something that I need to support because a
> > > development/debug kernel build often requires a larger reservation
> > > and we find ourselves adjusting the "crashkernel=" value fairly
> > > often.
> > >
> > > 3) External FIT image build systems do not yet support bootconfig since
> > > it is so new. It is completely fair if you file this away in your
> > > not-my-problem folder but simple kernel config modifications, as
> > > needed for CONFIG_CMDLINE_EXTEND, are something that every image
> > > build system is likely to support today.
> > >
> > > All that said, I do really like the look of bootconfig. Unfortunately,
> > > it doesn't let me achieve everything I need.
> >
> > Ok, well thanks for having a look. A follow-up question I have is how is
> > this handled on x86? They don't appear to have CONFIG_CMDLINE_EXTEND either
> > afaict. Is it because their bootloader story tends to be more uniform?
>
> x86's equivalent was implemented by commit 516cbf3730c4 ("x86, bootup:
> add built-in kernel command line for x86 (v2)"). To summarize, you have
> to enable CONFIG_CMDLINE_BOOL and then that lets you define built-in
> command line parameters in CONFIG_CMDLINE. However, it is backwards in
> that the command line provided by the bootloader is appended onto the
> end of CONFIG_CMDLINE.
>
> This doesn't seem as useful to me because, using the crashkernel=
> example from above, the bootloader provided crashkernel= value may need
> to be overridden by the built-in command line to provide a different
> crashkernel= value for the particular kernel build being booted. Most
> kernel command line parameter parsers are implemented in a way that
> supports multiple instances of the parameter while only honoring the
> last instance.
These config options should be common IMO. It's a minefield though.
You might want to look at this prior attempt[1].
Rob
[1] https://lore.kernel.org/lkml/20190319232448.45964-2-danie...@cisco.com/
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On Thu, Nov 19, 2020 at 10:56:12AM -0600, Tyler Hicks wrote:
> On 2020-11-05 09:28:38, Tyler Hicks wrote:
> > On 2020-11-05 09:58:54, Will Deacon wrote:
> > > On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > > > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > > > > > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > > > > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64
> > > > > > > kernels. This
> > > > > > > config option can be used to extend the kernel command line
> > > > > > > parameters,
> > > > > > > specified by the bootloader, with additional command line
> > > > > > > parameters
> > > > > > > specified in the kernel configuration.
> > > > > >
> > > > > > Hi Catalin and Will - Friendly ping on this series now that we're
> > > > > > on the other side of the 5.10 merge window. I hope it can be
> > > > > > considered
> > > > > > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks!
> > > > >
> > > > > Can you use bootconfig to achieve what you need?
> > > >
> > > > Thanks for mentioning bootconfig. I hadn't considered it.
> > > >
> > > > After reading the docs and code, I see a few reasons why I can't use it
> > > > out of the box:
> > > >
> > > > 1) It requires "bootconfig" to be appended to the kernel command line.
> > > > My proposed patch series makes it possible to append new options to
> > > > the kernel command line in situations where the bootloader is not
> > > > interactive. This presents a circular dependency problem for my use
> > > > case.
> > > >
> > > > A new config option could be added to force the enablement of
> > > > bootconfig but that would sort of be a single-use duplicate of
> > > > CONFIG_CMDLINE_EXTEND's functionality.
> > > >
> > > > 2) Not all kernel command line options can be configured using
> > > > bootconfig. For example, the "nokaslr" and "crashkernel=" parameters
> > > > are parsed/handled before setup_boot_config() is called. KASLR can
> > > > be disabled via a kernel config change but there's no config option
> > > > equivalent for "crashkernel=". Changing the "crashkernel=" command
> > > > line option is something that I need to support because a
> > > > development/debug kernel build often requires a larger reservation
> > > > and we find ourselves adjusting the "crashkernel=" value fairly
> > > > often.
> > > >
> > > > 3) External FIT image build systems do not yet support bootconfig since
> > > > it is so new. It is completely fair if you file this away in your
> > > > not-my-problem folder but simple kernel config modifications, as
> > > > needed for CONFIG_CMDLINE_EXTEND, are something that every image
> > > > build system is likely to support today.
> > > >
> > > > All that said, I do really like the look of bootconfig. Unfortunately,
> > > > it doesn't let me achieve everything I need.
> > >
> > > Ok, well thanks for having a look. A follow-up question I have is how is
> > > this handled on x86? They don't appear to have CONFIG_CMDLINE_EXTEND
> > > either
> > > afaict. Is it because their bootloader story tends to be more uniform?
> >
> > x86's equivalent was implemented by commit 516cbf3730c4 ("x86, bootup:
> > add built-in kernel command line for x86 (v2)"). To summarize, you have
> > to enable CONFIG_CMDLINE_BOOL and then that lets you define built-in
> > command line parameters in CONFIG_CMDLINE. However, it is backwards in
> > that the command line provided by the bootloader is appended onto the
> > end of CONFIG_CMDLINE.
> >
> > This doesn't seem as useful to me because, using the crashkernel=
> > example from above, the bootloader provided crashkernel= value may need
> > to be overridden by the built-in command line to provide a different
> > crashkernel= value for the particular kernel build being booted. Most
> > kernel command line parameter parsers are implemented in a way that
> > supports multiple instances of the parameter while only honoring the
> > last instance.
>
> Hey Will - Do you any additional concerns that I should look into?
No, you convinced me it's useful. I just haven't found time to look at the
implementation yet!
Will
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On 2020-11-05 09:28:38, Tyler Hicks wrote:
> On 2020-11-05 09:58:54, Will Deacon wrote:
> > On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > > > > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > > > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels.
> > > > > > This
> > > > > > config option can be used to extend the kernel command line
> > > > > > parameters,
> > > > > > specified by the bootloader, with additional command line parameters
> > > > > > specified in the kernel configuration.
> > > > >
> > > > > Hi Catalin and Will - Friendly ping on this series now that we're
> > > > > on the other side of the 5.10 merge window. I hope it can be
> > > > > considered
> > > > > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks!
> > > >
> > > > Can you use bootconfig to achieve what you need?
> > >
> > > Thanks for mentioning bootconfig. I hadn't considered it.
> > >
> > > After reading the docs and code, I see a few reasons why I can't use it
> > > out of the box:
> > >
> > > 1) It requires "bootconfig" to be appended to the kernel command line.
> > > My proposed patch series makes it possible to append new options to
> > > the kernel command line in situations where the bootloader is not
> > > interactive. This presents a circular dependency problem for my use
> > > case.
> > >
> > > A new config option could be added to force the enablement of
> > > bootconfig but that would sort of be a single-use duplicate of
> > > CONFIG_CMDLINE_EXTEND's functionality.
> > >
> > > 2) Not all kernel command line options can be configured using
> > > bootconfig. For example, the "nokaslr" and "crashkernel=" parameters
> > > are parsed/handled before setup_boot_config() is called. KASLR can
> > > be disabled via a kernel config change but there's no config option
> > > equivalent for "crashkernel=". Changing the "crashkernel=" command
> > > line option is something that I need to support because a
> > > development/debug kernel build often requires a larger reservation
> > > and we find ourselves adjusting the "crashkernel=" value fairly
> > > often.
> > >
> > > 3) External FIT image build systems do not yet support bootconfig since
> > > it is so new. It is completely fair if you file this away in your
> > > not-my-problem folder but simple kernel config modifications, as
> > > needed for CONFIG_CMDLINE_EXTEND, are something that every image
> > > build system is likely to support today.
> > >
> > > All that said, I do really like the look of bootconfig. Unfortunately,
> > > it doesn't let me achieve everything I need.
> >
> > Ok, well thanks for having a look. A follow-up question I have is how is
> > this handled on x86? They don't appear to have CONFIG_CMDLINE_EXTEND either
> > afaict. Is it because their bootloader story tends to be more uniform?
>
> x86's equivalent was implemented by commit 516cbf3730c4 ("x86, bootup:
> add built-in kernel command line for x86 (v2)"). To summarize, you have
> to enable CONFIG_CMDLINE_BOOL and then that lets you define built-in
> command line parameters in CONFIG_CMDLINE. However, it is backwards in
> that the command line provided by the bootloader is appended onto the
> end of CONFIG_CMDLINE.
>
> This doesn't seem as useful to me because, using the crashkernel=
> example from above, the bootloader provided crashkernel= value may need
> to be overridden by the built-in command line to provide a different
> crashkernel= value for the particular kernel build being booted. Most
> kernel command line parameter parsers are implemented in a way that
> supports multiple instances of the parameter while only honoring the
> last instance.
Hey Will - Do you any additional concerns that I should look into?
Thanks!
Tyler
>
> Tyler
>
> >
> > Will
> >
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On 2020-11-05 09:58:54, Will Deacon wrote:
> On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > > > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels.
> > > > > This
> > > > > config option can be used to extend the kernel command line
> > > > > parameters,
> > > > > specified by the bootloader, with additional command line parameters
> > > > > specified in the kernel configuration.
> > > >
> > > > Hi Catalin and Will - Friendly ping on this series now that we're
> > > > on the other side of the 5.10 merge window. I hope it can be considered
> > > > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks!
> > >
> > > Can you use bootconfig to achieve what you need?
> >
> > Thanks for mentioning bootconfig. I hadn't considered it.
> >
> > After reading the docs and code, I see a few reasons why I can't use it
> > out of the box:
> >
> > 1) It requires "bootconfig" to be appended to the kernel command line.
> > My proposed patch series makes it possible to append new options to
> > the kernel command line in situations where the bootloader is not
> > interactive. This presents a circular dependency problem for my use
> > case.
> >
> > A new config option could be added to force the enablement of
> > bootconfig but that would sort of be a single-use duplicate of
> > CONFIG_CMDLINE_EXTEND's functionality.
> >
> > 2) Not all kernel command line options can be configured using
> > bootconfig. For example, the "nokaslr" and "crashkernel=" parameters
> > are parsed/handled before setup_boot_config() is called. KASLR can
> > be disabled via a kernel config change but there's no config option
> > equivalent for "crashkernel=". Changing the "crashkernel=" command
> > line option is something that I need to support because a
> > development/debug kernel build often requires a larger reservation
> > and we find ourselves adjusting the "crashkernel=" value fairly
> > often.
> >
> > 3) External FIT image build systems do not yet support bootconfig since
> > it is so new. It is completely fair if you file this away in your
> > not-my-problem folder but simple kernel config modifications, as
> > needed for CONFIG_CMDLINE_EXTEND, are something that every image
> > build system is likely to support today.
> >
> > All that said, I do really like the look of bootconfig. Unfortunately,
> > it doesn't let me achieve everything I need.
>
> Ok, well thanks for having a look. A follow-up question I have is how is
> this handled on x86? They don't appear to have CONFIG_CMDLINE_EXTEND either
> afaict. Is it because their bootloader story tends to be more uniform?
x86's equivalent was implemented by commit 516cbf3730c4 ("x86, bootup:
add built-in kernel command line for x86 (v2)"). To summarize, you have
to enable CONFIG_CMDLINE_BOOL and then that lets you define built-in
command line parameters in CONFIG_CMDLINE. However, it is backwards in
that the command line provided by the bootloader is appended onto the
end of CONFIG_CMDLINE.
This doesn't seem as useful to me because, using the crashkernel=
example from above, the bootloader provided crashkernel= value may need
to be overridden by the built-in command line to provide a different
crashkernel= value for the particular kernel build being booted. Most
kernel command line parameter parsers are implemented in a way that
supports multiple instances of the parameter while only honoring the
last instance.
Tyler
>
> Will
>
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote: > On 2020-11-04 12:08:12, Will Deacon wrote: > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote: > > > On 2020-09-21 14:15:55, Tyler Hicks wrote: > > > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This > > > > config option can be used to extend the kernel command line parameters, > > > > specified by the bootloader, with additional command line parameters > > > > specified in the kernel configuration. > > > > > > Hi Catalin and Will - Friendly ping on this series now that we're > > > on the other side of the 5.10 merge window. I hope it can be considered > > > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks! > > > > Can you use bootconfig to achieve what you need? > > Thanks for mentioning bootconfig. I hadn't considered it. > > After reading the docs and code, I see a few reasons why I can't use it > out of the box: > > 1) It requires "bootconfig" to be appended to the kernel command line. > My proposed patch series makes it possible to append new options to > the kernel command line in situations where the bootloader is not > interactive. This presents a circular dependency problem for my use > case. > > A new config option could be added to force the enablement of > bootconfig but that would sort of be a single-use duplicate of > CONFIG_CMDLINE_EXTEND's functionality. > > 2) Not all kernel command line options can be configured using > bootconfig. For example, the "nokaslr" and "crashkernel=" parameters > are parsed/handled before setup_boot_config() is called. KASLR can > be disabled via a kernel config change but there's no config option > equivalent for "crashkernel=". Changing the "crashkernel=" command > line option is something that I need to support because a > development/debug kernel build often requires a larger reservation > and we find ourselves adjusting the "crashkernel=" value fairly > often. > > 3) External FIT image build systems do not yet support bootconfig since > it is so new. It is completely fair if you file this away in your > not-my-problem folder but simple kernel config modifications, as > needed for CONFIG_CMDLINE_EXTEND, are something that every image > build system is likely to support today. > > All that said, I do really like the look of bootconfig. Unfortunately, > it doesn't let me achieve everything I need. Ok, well thanks for having a look. A follow-up question I have is how is this handled on x86? They don't appear to have CONFIG_CMDLINE_EXTEND either afaict. Is it because their bootloader story tends to be more uniform? Will
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On 2020-11-04 12:08:12, Will Deacon wrote: > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote: > > On 2020-09-21 14:15:55, Tyler Hicks wrote: > > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This > > > config option can be used to extend the kernel command line parameters, > > > specified by the bootloader, with additional command line parameters > > > specified in the kernel configuration. > > > > Hi Catalin and Will - Friendly ping on this series now that we're > > on the other side of the 5.10 merge window. I hope it can be considered > > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks! > > Can you use bootconfig to achieve what you need? Thanks for mentioning bootconfig. I hadn't considered it. After reading the docs and code, I see a few reasons why I can't use it out of the box: 1) It requires "bootconfig" to be appended to the kernel command line. My proposed patch series makes it possible to append new options to the kernel command line in situations where the bootloader is not interactive. This presents a circular dependency problem for my use case. A new config option could be added to force the enablement of bootconfig but that would sort of be a single-use duplicate of CONFIG_CMDLINE_EXTEND's functionality. 2) Not all kernel command line options can be configured using bootconfig. For example, the "nokaslr" and "crashkernel=" parameters are parsed/handled before setup_boot_config() is called. KASLR can be disabled via a kernel config change but there's no config option equivalent for "crashkernel=". Changing the "crashkernel=" command line option is something that I need to support because a development/debug kernel build often requires a larger reservation and we find ourselves adjusting the "crashkernel=" value fairly often. 3) External FIT image build systems do not yet support bootconfig since it is so new. It is completely fair if you file this away in your not-my-problem folder but simple kernel config modifications, as needed for CONFIG_CMDLINE_EXTEND, are something that every image build system is likely to support today. All that said, I do really like the look of bootconfig. Unfortunately, it doesn't let me achieve everything I need. Tyler > > Will >
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote: > On 2020-09-21 14:15:55, Tyler Hicks wrote: > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This > > config option can be used to extend the kernel command line parameters, > > specified by the bootloader, with additional command line parameters > > specified in the kernel configuration. > > Hi Catalin and Will - Friendly ping on this series now that we're > on the other side of the 5.10 merge window. I hope it can be considered > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks! Can you use bootconfig to achieve what you need? Will
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On 2020-09-21 14:15:55, Tyler Hicks wrote: > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This > config option can be used to extend the kernel command line parameters, > specified by the bootloader, with additional command line parameters > specified in the kernel configuration. Hi Catalin and Will - Friendly ping on this series now that we're on the other side of the 5.10 merge window. I hope it can be considered for 5.10+1. Let me know if I need to rebase/resubmit. Thanks! Tyler
[PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This
config option can be used to extend the kernel command line parameters,
specified by the bootloader, with additional command line parameters
specified in the kernel configuration.
This option addresses the following use cases:
1) Switching between stable and development kernel versions, where one
of the versions benefits from additional command line parameters,
such as debugging options.
2) Specifying additional command line parameters, for additional tuning
or debugging, when the bootloader does not offer an interactive mode.
After implementing these patches, I noticed that a previous attempt has
been made to upstream CONFIG_CMDLINE_EXTEND support in arm64:
https://lore.kernel.org/linux-arm-kernel/1447838885-9888-1-git-send-email-p.fe...@samsung.com/
I don't believe that the previous objection still holds as the generic
command line parsing series hasn't been revised in over a year.
This series is based on commit f322010a08da ("Merge branch
'for-next/mte' into for-next/core") of the for-next/core branch of the
arm64 tree.
Below is a summary of testing that I performed.
Upgrade testing:
* CONFIG_CMDLINE unset
- oldconfig target doesn't prompt,
* CONFIG_CMDLINE set, CONFIG_CMDLINE_FORCE unset
- oldconfig target prompts for command line type with default choice
set to CONFIG_CMDLINE_FROM_BOOTLOADER
* CONFIG_CMDLINE set, CONFIG_CMDLINE_FORCE set
- oldconfig target prompts for command line type with default choice
set to CONFIG_CMDLINE_FORCE
Functional testing:
* Set CONFIG_CMDLINE="nokaslr apparmor=0" and CONFIG_CMDLINE_EXTEND=y to
test early init parsing and regular parsing
- /proc/cmdline shows that "nokaslr apparmor=0" was appended to the
end of the bootloader supplied command line
- "KASLR disabled on command line" found in dmesg
- AppArmor is disabled. /sys/kernel/security/apparmor does not exist
and aa-status prints:
apparmor module is loaded.
apparmor filesystem is not mounted.
* Set CONFIG_CMDLINE="nokaslr apparmor=0",
CONFIG_CMDLINE_FROM_BOOTLOADER=y, and have the bootloader specify a
command line without those options
- The bootloader's command line is used and does not contain
CONFIG_CMDLINE's value
- AppArmor and KASLR are enabled
* Set CONFIG_CMDLINE="nokaslr apparmor=0" and CONFIG_CMDLINE_FORCE=y
- The CONFIG_CMDLINE value is used and does not contain the
bootloader's command line
- AppArmor and KASLR are disabled
Tyler
Tyler Hicks (2):
arm64: kaslr: Refactor early init command line parsing
arm64: Extend the kernel command line from the bootloader
arch/arm64/Kconfig| 23 ++-
arch/arm64/kernel/kaslr.c | 26 ++
2 files changed, 40 insertions(+), 9 deletions(-)
--
2.25.1
