Clean up kernel argument parsing

[cgwalters]

ref #1314 (comment)_

Basically while we can use OstreeKernelArgs here, it'd probably be good to add a new native rust implementation in general.

We already have kernel.rs so let's add this stuff there.

[bshephar]

I was reading the comment that you linked on that thread, and you mentioned that we should use to_utf8_lossy, I assume you mean from_utf8_lossy (https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8_lossy). I just wonder whether we would actually want those replacement chars in the parsed output. A possible implementation of that could look like:
bshephar@eea1bf2

But I'm not convinced we actually do want that. Maybe it would be better to just unwrap the Err from read_to_string if there are non-UTF8 chars in the file?

[cgwalters]

I think we need to be pretty conservative with what types of errors we make fatal. For data we control (or is directly provided as input to us) we can reasonably impose hard constraints.

The obvious case is a malformed TOML for one of our config file, we wouldn't want to just try to stumble on with a potentially invalid config.

But it also needs to be relatively easy for users to work around in emergency situations (and for a config file they could "hot patch" it with a usroverlay or so).

I would really hope no one in reality has non-UTF8 in the kernel command line, and in theory one could hot patch there too with a bind mount over /proc/cmdline.

But the key difference is that for /proc/cmdline it is a big bag of data, only a small portion of which we read, so we shouldn't fail on unrelated issues.

[bshephar]

Right, yeah, that makes sense. So if the non UTF8 char happened to be in data that we didn't care about, then ideally we shouldn't fail. I see what you're going for. So, in that case, then yeah, we probably do want to parse the file like I proposed in that commit. Then just make sure we have validated all of the cmdline options that we care about.

That would allow us to be more deliberate about our specific failure scenarios.

[jeckersb]

I started on this briefly before I disappeared on PTO, but the general idea I ran with is that everything is just &[u8] because that's how the kernel parses it. The range of allowable things is actually crazy when reading through the code.

[jeckersb]

Expanding a bit... it's mostly handled in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/cmdline.c?id=e8d780dcd957d80725ad5dd00bab53b856429bc0#n227

The algorithm is basically:

• Scan forward until you find the first unquoted isspace() byte. That's the end of the param.
• If you encounter an = along the way, note where. That's where it will terminate the key and split for the value. Any future = are not treated as special.
• The value is unquoted only in as much as " is removed from the first or last byte. You can still have " in the middle of the value.

So in theory you could successfully get it to parse something wild like """="some"thing="i n s a n e" where key=""" and value=some"thing="i n s a n e. It would just ignore it since it doesn't know about """, but it would parse it...

[cgwalters]

@jeckersb can you elaborate, is this a lot harder than what's in https://github.com/containers/composefs-rs/blob/main/crates/composefs-boot/src/cmdline.rs ?

We could just make that pub (and hopefully add unit tests) and/or copy it into this repo