are you trying to provide a filter for boot cmdline flags or what?
-
-
Replying to @tehjh
Yes, there's some stuff we want to be able to block that could otherwise be overridden by early command line parsing
1 reply 0 retweets 0 likes -
Replying to @mjg59
but if someone can mess with the command line, can't they majorly screw up the entire boot process anyway?
1 reply 0 retweets 0 likes -
-
I mean yeah they can DoS it, but…
1 reply 0 retweets 0 likes -
Replying to @mjg59
does that mean you're fine with someone being able to set stuff like "root=" but not some other things?
2 replies 0 retweets 0 likes -
taking a step back, your premise is "we get the cmdline from the bootloader, and the bootloader is trusted, but we want the bootloader to be able to load a cmdline from disk that can't be verified and just shove it into the kernel", right?
2 replies 0 retweets 1 like -
Replying to @tehjh
We can't assert that the command line is trusted because there are too many cases where you need to modify parameters
1 reply 0 retweets 0 likes -
Replying to @mjg59
it sounds to me like part of the problem is that the cmdline contains multiple things mixed together and you don't know which part is from where? whether it's from the distro or a config file on the system (which I guess you don't want to trust) or a hint about where the disk is
1 reply 0 retweets 0 likes -
would it be possible to let the user store a custom cmdline as long as they edit it from a context that runs before any untrusted userspace and let the TPM verify that (using the PCRs)?
1 reply 0 retweets 0 likes
then the kernel cmdline as delivered from the bootloader to the kernel could consist of a distro-signed base cmdline, a TPM-attested user config, and a very narrow set of whitelisted hints for locating the disk that update-grub is allowed to generate automatically
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.