| Message ID | 20200921191557.350256-1-tyhicks@linux.microsoft.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: Implement CONFIG_CMDLINE_EXTEND | expand |
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
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
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 >
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
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 >
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 > >
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
On Thu, Nov 5, 2020 at 9:28 AM Tyler Hicks <tyhicks@linux.microsoft.com> 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-danielwa@cisco.com/
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
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.fedin@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(-)