Discussion: kernel cmdline changes

[vulpes2]

There are a bunch of kernel cmdline args that we could potentially consider removing:

• net.ifnames=0 disables predictable network interface device naming, which doesn't seem to provide any benefit as far as I can tell
• ipv6.disable=1 Is there any network devices that don't work with IPv6?
• deferred_probe_timeout=30 helpful for debugging but doesn't seem to be required for normal booting anymore, at least not on v6.6 + sc7180 (trogdor)
• clk_ignore_unused=1 same as above
• noresume disables hibernation, probably fine to keep it for now
• apparmor=0 docker supposedly doesn't play nice with apparmor, but I was never able to confirm this since the docker documentation doesn't instruct users to disable apparmor on distros with it enabled by default.

[hexdump0815]

let me try to remember where those options came from:

• net.ifnames=0 - came from me getting tired of different and partially very long network interface names on various systems, with this option its always eth0, wlan0 etc. which i consider easier to understand and handle - the long names might make sense on servers with lots of maybe different kinds of interfaces but for the target systems of those images i considered the shorter and simpler names a plus ... is there any real benefit from the longer and more complex names except having one kernel cmdline option less?
• ipv6.disable=1 - came from me assuming disabling ipv6 to be potentially safer as with it enabled each system gets its unique ipv6 address for instance behind an ipv6 capable router and might be accessible vs. not really so with only ipv4 and behind a nat ... i think this assumption could be wrong maybe? i did not really do anything deeper with ipv6 yet i must admit although i wanted to get deeper into it since decades, but so far everything around me worked perfectly fine with ipv4 ... around this topic there is also misc: ipv6 disabled for what reason? imagebuilder#15 and odroid_u3: problem: NetworkManager error message flood in syslog imagebuilder#72
• deferred_probe_timeout=30 - this was temporarily required for some devices on some systems to probe properly, but if things are working well now it can go for sure
• clk_ignore_unused=1 - same as the last one, it is still required on windows-on-arm snapdragon devices though
• noresume - i do not remember the exact reason for this one anymore, but i think some systems end in nowhere if they accidently get hibernated and this was to stay on the safe side
• apparmor=0 - initially apparmor was not part of the kernel config and i added it later on request from Enable AppArmor by default #11 but disabled it on the kernel cmdline to get back to the old state - what speaks for/against it?

[vulpes2]

1. The predictable network interface names are meant to be reliable and persistent to a specific device across reboots. There is no way to tell if eth0 is still going to be that specific ethernet interface after a reboot, if you have multiple ethernet interfaces connected to the system. This is the same reason why using things like /dev/sda1 in fstab is a really bad idea, it mostly works until it doesn't. There is no reason to cripple a more reliable naming scheme just because the interface names are a few characters shorter. More details can be found on the Debian wiki: https://wiki.debian.org/NetworkInterfaceNames
2. If your ISP supports IPv6, you will indeed get some globally-routable unique IPv6 addresses for every IPv6 enabled device you have on your network. However, the address being globally routable doesn't mean it's actually reachable, as most routers will have a sane default stateful firewall to avoid exposing your devices to the internet without your knowledge. NAT is not a firewall, the actual security on your gateway for IPv4 is generally provided by a stateful firewall too, which rejects incoming packets by default unless a connection has been established recently from a client device on your network, and it operates the same way for IPv6. I have encountered sites and servers that are only reachable over IPv6, and although it may be rare, some ISPs may have IPv6-only setups too, particularly for cellular networks. I don't see a reason to keep it disabled by default based on fear and uncertainty. More details: https://serverfault.com/questions/782627/udp-hole-punching-still-required-in-ipv6-even-without-nat
3. deferred_probe_timeout=30 and clk_ignore_unused=1 can stay to be on the safer side, removing them will likely generate more "device doesn't boot anymore" tickets.
4. noresume can definitely stay, I have no objections since hibernation is rarely ever relevant to these arm based devices anyway.
5. AppArmor support was first introduced in Ubuntu 7.04, and is turned on by default in Ubuntu 7.10 and later. Debian Buster or later also have it enabled by default. From my experience it doesn't really cause the level of headaches as SELinux does, so unless there's been a lot of reported issues caused by AppArmor specifically, I don't see a reason to keep a security feature disabled by default. I've been running v6.6 on wormdingler without disabling AppArmor and everything seems fine to me so far.

[hexdump0815]

1. ok - i'm fine with trying to drop this one
2. i'm still not fully convinced - as far as i understand it with ipv4 and nat only a connection from inside the nat will create and entry in the nat table and as such will create only then some path back from the outside to the machine and this should prevent access from the outside quite well without any kind of firewalling ... for ipv6 as i understand it some firewalling will be required and i'm not sure if i really trust all those cheap routers out there to do this properly ... on the other hand most distributions enable ipv6 by default (and that also for a good reason), so maybe it might make sense to just go with the flow
3. maybe we can even try to go without them on trogdor and see if it works meanwhile - your testing sounds promising
4. lets keep it then - there is no real harm or problem with having it
5. i'm fine with trying without this one as well

regarding 2. - it is maybe time to switch to https://github.com/alpernebbi/depthcharge-tools for handling the booting of the 64bit arm chromebooks, so that it gets easier to adjust the kernel cmdline parameters ... its a proper debian package, postmarketos is using it as well and its well maintained too i think ...

i'll prepare the change of the kernel cmdline parameters in all my kernel build repos and the imagebuilder repos (grub, extlinux.conf etc. where needed) during the next days, so that the next set of images i plan to build during the next weeks maybe will have them in already

[vulpes2]

Thanks for considering my suggestions. Don't get me wrong, I generally don't trust consumer grade routers either, most of my networking stuff are running mainline OpenWrt, which has a proper firewall. However, I feel like if Debian and Ubuntu aren't disabling IPv6 by default, we probably shouldn't either.

About depthcharge-tools, I'll try tinkering with it later this week and see if I can get it working. The ability to automate the kpart image generation process would be very nice indeed.

[thenameisluk]

so hi funny story

after making minecraft java turorial i was having some fun with building a kelner for the first time
and i found out that disabling ipv6 is the root cause of my random crash issue
didn't really seam related at first but after checking (trying different configurations) ye this is the reason
even the maintainer didn't expect this to be an issue

but actually it is not the only place where it causes a problem, there is also lxc

maj 31 23:00:29 chluk systemd[1]: Starting lxc-net.service - LXC network bridge setup...
maj 31 23:00:29 chluk lxc-net[7343]: /usr/libexec/lxc/lxc-net: 141: cannot create /proc/sys/net/ipv6/conf/lxcbr0/accept_dad: Directory nonexistent
maj 31 23:00:29 chluk lxc-net[7343]: /usr/libexec/lxc/lxc-net: 66: cannot create /proc/sys/net/ipv6/conf/all/forwarding: Directory nonexistent

personally i do not believe disabling ipv6 poses any more security risk than connecting to wifi in cafe
+in order to for example connect to device via ssh using ipv6 user still has to enable it on their device
afaik most if not all modern distros have it enabled by default (ipv6, not ssh)

i would not recommend leaving it disabled since it may (and has already) cause stuff to break without a clear reason
like with the minecraft issue i've had with that crash for no reason
and it probably isn't sth we or any random developer wants to deal with, trying to solve an issue caused by some random kelner cmd

[hexdump0815]

this topic is still open as it will need quite a bit more testing and some things sorted out (like maybe using depthchargetools) and as a result some more time is required to get this forward which i currently do not have ... but this topic is still on my list and not forgotten - things are moving on, but sometimes slow :)

[vulpes2]

Same on my end, still haven't had time to look into the depthcharge tools yet, will probably get to it at some point.

[thenameisluk]

i tried doing depthchargetools but i couldn't find any well made instruction/documentation i could follow

will try to get it working later but for now will keep just repeating lest few steps of kelner compilation and flashing it