Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support default kernel arguments #479

Open
vtolstov opened this issue Aug 31, 2016 · 30 comments · May be fixed by #1836
Open

Support default kernel arguments #479

vtolstov opened this issue Aug 31, 2016 · 30 comments · May be fixed by #1836
Labels
difficulty/medium medium complexity/difficutly issue enhancement

Comments

@vtolstov
Copy link

How can i add some things to kernel cmdline when compose tree?
Or how i control cmdline when boot ostree system?

@cgwalters
Copy link
Member

ostree admin deploy --karg=. Which is used by e.g. the Fedora/CentOS Anaconda installer

@vtolstov
Copy link
Author

Thanks, i miss it with using rpm-ostree =(.
This is really hard use rpm-ostree without ostree admin =).
But not ostree admin upgrade works fine, because i'm deploy ref via ostree admin deploy and it not complain about unknown refspec

@vtolstov
Copy link
Author

vtolstov commented Sep 7, 2016

Last qeustion - i'm add custom cmdline with treefile (dracut additional cmdline and specify kernel cmdline to dracut). Why after composing tree i don't have this options in dracut config and grub entries does not contains this line?

@cgwalters cgwalters changed the title specify additional cmdline to kernel when compose tree Support default kernel arguments Sep 7, 2016
@cgwalters
Copy link
Member

We don't currently support that, but we could.

@cgwalters
Copy link
Member

@paulvt
Copy link

paulvt commented Feb 26, 2018

Another thing to note is that --karg allows one to update or set a kernel boot argument, but not to remove one.
For know, I use --karg=foo= to at least clear it, but the relevant part of the kernel does complain it cannot handle the value ''.

@dustymabe dustymabe added the jira label Oct 12, 2018
@dustymabe dustymabe added the difficulty/medium medium complexity/difficutly issue label Nov 7, 2018
@dustymabe
Copy link
Contributor

Marking this as medium difficulty, although I suspect it might lean towards hard. @cgwalters WDYT?

@cgwalters
Copy link
Member

Marking this as medium difficulty, although I suspect it might lean towards hard. @cgwalters WDYT?

As a general rule I think for ostree/rpm-ostree, the difficulty level is weighted to a much greater degree by the person's knowledge (e.g. bootloaders, C or Rust, whether it requires learning the test framework etc.) compared to other projects. I understand the goal of labeling the difficulty level of issues, but I'm not sure it's worth trying to figure out the exact levels here. If someone wants to dive in they should feel free to ask questions on an issue I'd say.

@dustymabe
Copy link
Contributor

Yep. It's hard to get a standard metric. I'm just trying to get a ballpark estimate so that we can get an idea and group issues into buckets. Maybe there will be some easier medium tasks and some harder medium tasks, but that's probably ok.

Since we have ~150 open issues, if we have buckets of good-first-issue and difficulty/medium tasks then we have a starting point and also a ramp up for new contributors.

If you'd like me to stop this endeavor I will.

@rfairley
Copy link
Member

Just to give a little input, I do like the good-first-issue and difficulty/medium split to roughly differentiate the size of the change. good-first-issue usually means a 1-10 line change, mostly involving rearranging existing logic and possibly adding a test, and difficulty/medium might be adding something new but still only touches one or two components. But I can see how the difficulty/medium would get easier once one is familiar with the codebase, so the size of the change doesn't necessarily indicate difficulty.

I find the difficulty/medium label is still handy for quickly looking up issues that should be straightforward but more involved than the good-first-issue type - as a "next step" once one has done a good-first-issue and is more familiar with the codebase.

I agree that asking is the best way to get an idea of the difficulty and if one has the specific prereq. knowledge for it. difficulty/medium might just be a way to group those tasks that one might consider doing after completing a good-first-issue.

@cgwalters
Copy link
Member

I have absolutely no problem with you or anyone trying to classify the issues! I just feel like for me personally the benefit/time ratio is too low to worry too much about whether an issue is medium/high or whatever.

@dustymabe
Copy link
Contributor

+1

I'll stop asking for input, but will reserve the right to be slightly or significantly wrong in my estimates :)

@rfairley
Copy link
Member

rfairley commented Mar 14, 2019

Some thoughts after reading over the code around kargs:

We have mentioned having OSTree commits contain the default kargs. Could this take the form of a file containing the default kargs which gets committed to the ostree, e.g. /usr/lib/ostree/kargs? OSTree would read the default kargs from that file during a deployment, and append the kargs to the state file at "/run/ostree/staged-deployment", and the BLS fragment on reboot.

For rpm-ostree treefiles, I'm thinking we could add a field e.g. default-kargs or just kargs, where the user specifies a list of key-value pairs for each karg (arg, value). The key-value pairs would be written to /usr/lib/ostree/kargs at compose time, and that file would be committed to the ostree.

This still means mangling the defaults with any kargs specified with ostree admin deploy --karg= or rpm-ostree kargs - I'm not sure of how to keep those separate other than storing them as suggested previously. There are other ways we could make the mangling more visible, e.g. a switch to print out the default, user-specified, and mangled kargs during ostree admin --karg= during the deploy, or have additional fields containing the default and user kargs to the state file in /run.

If the user wanted to completely override the default kargs, we could also support /etc/ostree/kargs which would shadow /usr/lib/ostree/kargs.

How does the file idea sound?

@cgwalters
Copy link
Member

Maybe /usr/lib/ostree-boot/kargs? Today that gets copied into /boot but we could teach the library to skip that one file?

Another bikeshed issue I see here is: what is the file format of /usr/lib/ostree/kargs? Newline-separated plain text? JSON? Do we need to care about kargs with non-UTF-8 data?

If the user wanted to completely override the default kargs, we could also support /etc/ostree/kargs which would shadow /usr/lib/ostree/kargs.

Well this gets tricky since today one can configure kernel args, they live the deployment's BLS fragments in /boot. But that's the "merged" state, so it mixes user-supplied and system default which we want to get away from. So probably indeed /etc/ostree/kargs would make sense.

There's a very special hazard with this though which is trying to do an upgrade from an existing commit to one which uses this - if the "source of truth" of kargs switches to /{/usr,/etc}/ostree/kargs then we would drop any kargs which the user explicitly configured in their previous deployment.

Maybe what we need to do is add something like:

# ostree: generated from /usr/lib/ostree/kargs and /etc/ostree/kargs
options rd.lvm.lv=sb/root root=/dev/mapper/sb-root ostree=/ostree/boot.0/fedora-silverblue/78f3e4c34baaa9af28885bb3b6d92db7e59b73a9261d68a566de1c66230534dc/0 coreos.oem.id=qemu

And that comment acts as a marker that says "use deployment for source of truth on upgrades, not the merge deployment's kargs"?

@rfairley
Copy link
Member

Maybe /usr/lib/ostree-boot/kargs? Today that gets copied into /boot but we could teach the library to skip that one file?

Sounds good to me! Makes sense to keep the files relating to boot in ostree-boot where it'll be seen close to the other boot files.

what is the file format of /usr/lib/ostree/kargs? Newline-separated plain text? JSON? Do we need to care about kargs with non-UTF-8 data?

Had been wondering between those formats, was also thinking the kargs file could be a keyfile (to the Desktop Entry Specification). I think during parsing to a GKeyFile this would help enforce a definite "key-value pairs only, one per line" format. Though validating JSON could accomplish that too, and it'd be clean to work with translating from the treefile.

Is the the encoding of the kernel parameters dependent on the locale of the system, or is there software that might specially need non-UTF-8 in the kargs? If we did support non-UTF-8, would plain text be a better option (with some switch to specify the encoding of the kargs)?

# ostree: generated from /usr/lib/ostree/kargs and /etc/ostree/kargs

If we had this comment be a marker, would libostree delete that comment and apply the new kargs if the user did rpm-ostree kargs or ostree admin deploy --kargs=? Then with the comment not present, the merge deployment becomes the source of truth (like it is today). If the comment is present, then OSTree would regenerate from the deployment (i.e. /usr/lib/ostree/kargs and /etc/ostree/kargs).

To reset the source of truth, we could also have a command like rpm-ostree kargs --reset or rpm-ostree kargs --regenerate which would rewrite the BLS config from /usr/lib/ostree/kargs and /etc/ostree/kargs.

@rfairley
Copy link
Member

rfairley commented Apr 5, 2019

Just another question, which isn't blocking the initial patch I'm working on, but came up while thinking about the design:

Should the host config (/etc/ostree/kargs) have an equivalent of rpm-ostree kargs --delete when merging/overriding with the base config (/usr/lib/ostree-boot/kargs)? I'm not sure of a specific need for this, but I wonder if a user might want full control of the kargs through their host config to override and delete kargs in the base config, while using the etc/usr configs as a source of truth. That way the host would still be "subscribed" to updates to the /usr/lib/ostree-boot/kargs file in newer ostrees. We could also support the --append behavior easily as well if we did this.

I imagine /etc/ostree/kargs would need a format like the following to support that:

d root=FOO # d <=> --delete
d KEY=VAL
r rd.lvm.lv=sb/root # r <=> --replace
a coreos.oem.id=qemu # a <=> --append
...

or

[kargs]
delete="root=FOO KEY=VAL ..."
replace="rd.lvm.lv=sb/root ..."
append="coreos.oem.id=qemu ..."

If the user did use rpm-ostree kargs --{append,delete,replace} or ostree admin --karg*, then the merge deployment would become the source of truth.

@rfairley rfairley linked a pull request Apr 8, 2019 that will close this issue
2 tasks
rfairley pushed a commit to rfairley/ostree that referenced this issue Apr 11, 2019
Instead of merging kargs from the previous deployment, by default
regenerate kargs from the following config files:

/etc/ostree/kargs (host config)
/usr/lib/ostree-boot/kargs (base config)

The base config is sourced from the repo at the commit (revision)
being deployed, so that newly committed kargs will take effect
immediately after upgrading. The host config is sourced from the
merged /etc configuration of the new deployment, so that host
edits as well as edits to /usr/etc/ostree/kargs are reflected.

Kernel arguments present in the base config are appended to
kernel arguments in the host config.

Using the commands that modify kargs (of the form `ostree admin
deploy --karg*`) will cause kargs in later deployments to be copied
from the merge deployment, rather than regenerate from the config
files.

Resolves: ostreedev#479
@rfairley
Copy link
Member

Thinking about rpm-ostree integration (Re: #479 (comment)):

For rpm-ostree treefiles, I'm thinking we could add a field e.g. default-kargs or just kargs, where the user specifies a list of key-value pairs for each karg (arg, value). The key-value pairs would be written to /usr/lib/ostree/kargs at compose time, and that file would be committed to the ostree.

It looks like an easier way to add /usr/lib/ostree-boot/kargs at compose time is to use the add-files field (https://github.com/projectatomic/rpm-ostree/blob/master/docs/manual/treefile.md#treefile). Will test this out.

rfairley pushed a commit to rfairley/ostree that referenced this issue Apr 12, 2019
Instead of merging kargs from the previous deployment, by default
regenerate kargs from the following config files:

/etc/ostree/kargs (host config)
/usr/lib/ostree-boot/kargs (base config)

The base config is sourced from the repo at the commit (revision)
being deployed, so that newly committed kargs will take effect
immediately after upgrading. The host config is sourced from the
merged /etc configuration of the new deployment, so that host
edits as well as edits to /usr/etc/ostree/kargs are reflected.

Kernel arguments present in the base config are appended to
kernel arguments in the host config.

Using the commands that modify kargs (of the form `ostree admin
deploy --karg*`) will cause kargs in later deployments to be copied
from the merge deployment, rather than regenerate from the config
files.

Resolves: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 22, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 23, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 23, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 23, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 24, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 24, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 24, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 24, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Also add support for `ostree admin instutil set-kargs` so that installer
programs using this command (such as Anaconda) remain managed by the
kargs.d directories from the first deployment.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 24, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Also add support for `ostree admin instutil set-kargs` so that installer
programs using this command (such as Anaconda) remain managed by the
kargs.d directories from the first deployment.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 24, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=VALUE ANOTHERKEY SAMEKEY=VALUE2 FIRSTKEY=1 SAMEKEY=VALUE3 SECONDKEY=2 KEY= KEY.KEY-KEY_KEY="some space-separated values"
```

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Also add support for `ostree admin instutil set-kargs` so that installer
programs using this command (such as Anaconda) remain managed by the
kargs.d directories from the first deployment.

Closes: ostreedev#479
rfairley pushed a commit to rfairley/ostree that referenced this issue May 24, 2019
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=FOO KEYFLAG ANOTHERKEY=VALUE1 ANOTHERKEY=VALUE2
```

Snippets are read in alphanumeric order of the karg snippet filename
when generating the final kernel options from the host and base config
directories. Ordering may be specified by prefixing a number, e.g.
`/etc/ostree/kargs.d/4000_localhost`.

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Also add support for `ostree admin instutil set-kargs` so that installer
programs using this command (such as Anaconda) remain managed by the
kargs.d directories from the first deployment.

Closes: ostreedev#479
@rfairley
Copy link
Member

In #1836 I was initially planning on optimizing ostree admin deploy --karg=, --karg-append=, etc. (which COSA uses since removing Anaconda https://github.com/coreos/coreos-assembler/pull/556/files#diff-2d426a046eb99541d19814f8fac698bbR54) to write snippets to /etc/ostree/kargs.d in order to modify kargs. However in the case of checking existence of this directory before doing a reboot (coreos/ignition-dracut#86), this would trigger an unnecessary reboot even if Ignition did not write snippets there.

(I didn't realize this when suggesting it at https://github.com/coreos/ignition-dracut/issues/81#issuecomment-494888494).

One way to get around this could be to have COSA bake the kargs snippets in a new commit, i.e. under /usr/lib/ostree-boot/kargs.d (or use add-files in the FCOS treefile) to avoid the /etc/ostree/kargs.d path. However this is restrictive - there should really be a way to specify snippets in FCOS at install time without needing a new commit (i.e. write in /etc/ostree/kargs.d), and without needing to specify kargs snippets through an Ignition config.

Ignition could write a magic file e.g. /etc/ostree/kargs.d/0000_ignition-reboot - however we want to avoid special handling in Ignition. Users also shouldn't be required to write to a special directory in their Ignition config e.g. /etc/ostree/kargs.d/ignition/<user's kargs snippets here> for the needed reboot to happen (if the reboot was triggered on /etc/ostree/kargs.d/ignition instead).

@cgwalters
Copy link
Member

Was thinking about this more since doing factory reset support.

One model might be to suggest people to add default kernel arguments into the kernel binary; this is already supported with CONFIG_CMDLINE. For distributions like Fedora that want to build a generic kernel image that might be used multiple ways (e.g. FCOS vs other systems), it probably wouldn't be hard to patch the kernel to reserve some fixed space for arguments that one could write into the binary. Or, maybe instead we support "re-linking" the binary with some default args?

This would break Secure Boot signatures, but on the other hand, not validating kernel arguments is often an easy way to execute arbitrary code too....

@cgwalters
Copy link
Member

When FCOS ships kargs, FCOS should still ship 1 karg per file (or possibly group dependent ones) in /usr/lib/ostree-boot/kargs.d

The current model is now /usr/lib/modules/<kver> - if we defined a file format there, it could actually also apply to traditional systems.

@nullr0ute
Copy link

This would break Secure Boot signatures, but on the other hand, not validating kernel arguments is often an easy way to execute arbitrary code too....

You can deal with validation of kernel args to ensure they don't change with IMA/tpm2.

agners pushed a commit to agners/ostree that referenced this issue Oct 14, 2020
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=FOO KEYFLAG ANOTHERKEY=VALUE1 ANOTHERKEY=VALUE2
```

Snippets are read in alphanumeric order of the karg snippet filename
when generating the final kernel options from the host and base config
directories. Ordering may be specified by prefixing a number, e.g.
`/etc/ostree/kargs.d/4000_localhost`.

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Also add support for `ostree admin instutil set-kargs` so that installer
programs using this command (such as Anaconda) remain managed by the
kargs.d directories from the first deployment.

Closes: ostreedev#479

[rebased to master]
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
agners pushed a commit to agners/ostree that referenced this issue Oct 22, 2020
Add the following config directories for setting default kernel
arguments:

/etc/ostree/kargs.d (host config)
/usr/lib/ostree-boot/kargs.d (base config)

These directories contain files whose contents consist of a karg
snippet, which is a collection kernel parameter keys and values.
Example of a snippet:

```
KEY=FOO KEYFLAG ANOTHERKEY=VALUE1 ANOTHERKEY=VALUE2
```

Snippets are read in alphanumeric order of the karg snippet filename
when generating the final kernel options from the host and base config
directories. Ordering may be specified by prefixing a number, e.g.
`/etc/ostree/kargs.d/4000_localhost`.

The bootconfig key `ostree-kargs-generated-from-config` indicates
whether the kargs were generated by ostree from the kargs.d directories
(`true`), or copied from the previous deployment (`false`). Editing the
kargs through the command line (e.g. `ostree admin deploy --karg=`) will
set the flag to `false`, and kargs will be copied from the previous
deployment for subsequent deployments.

Also add support for `ostree admin instutil set-kargs` so that installer
programs using this command (such as Anaconda) remain managed by the
kargs.d directories from the first deployment.

Closes: ostreedev#479

[rebased to master]
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty/medium medium complexity/difficutly issue enhancement
Projects
None yet
7 participants