LWN: Comments on "5.8 Merge window, part 1"

5.8 Merge window, part 1

nix — Sun, 21 Jun 2020 22:18:50 +0000

I heard about that incident. I've never dared use pstore on non-disposable hardware since.

I suspect this is too paranoid of me -- but it still feels nicer to be able to use a blockdev. (Or it would if all my disks weren't fully partitioned already -- I don't imagine it would work on USB mass storage... expecting *that* to work in panic state seems like asking a lot.)

5.8 Merge window, part 1

grawity — Thu, 11 Jun 2020 10:48:34 +0000

Perhaps they don't think it's important to have built-in because good apps exist? The strongSwan app works very well in my experience (...except for outer IPv6), supports prepared profiles (.sswan files), and so on.

Native IKEv2 on Windows in contrast is always troublesome for me, to the point I wish it wasn't there and I wouldn't feel bad about installing a standalone client.

5.8 Merge window, part 1

wahern — Wed, 10 Jun 2020 02:28:23 +0000

What's the deal with Android and IKEv2? I have an up-to-date Pixel 3 but there's no native IKEv2 support, AFAICT. This site, https://www.watchguard.com/help/docs/help-center/en-US/Co..., make it sounds like *some* flavors of Android support IKEv2 out-of-the-box.

I want to switch over to IKEv2 completely as basic road warrior VPN configurations are simpler--no L2TP, no duplicative auth, etc. It's supported natively by all the common user platforms, including Windows, iOS, and macOS, except Android.

5.8 Merge window, part 1

hailfinger — Tue, 09 Jun 2020 19:59:35 +0000

The IPsec changes are more than just RFC 8229 (TCP Encapsulation of IKE and IPsec Packets) support:

- RFC 8229 in IPv4 is already supported since Linux 5.6 (see https://lwn.net/Articles/811198/ ). It's a great way to establish an IPsec tunnel even if the network only allows ports 80/TCP and 443/TCP like some public hotspots do.

- RFC 8229 in IPv6 support (ESP/IKE in TCP in IPv6) is new. It helps establishing IPsec tunnels to IPv6 servers even in restricted networks.

- You now can embed ESP in UDP in IPv6 packets. Once this feature lands in an Android kernel, you can finally use IPsec apps to connect to IPv6-only VPN gateways (direct use of ESP is unavailable to apps). This feature also enables users behind crappy ISP-provided DSL/cable routers to connect to dual-stack or IPv6-only IPsec gateways (quite a lot of those routers drop ESP).

I have been eagerly waiting for these changes for years. Cisco was able to run IPsec over TCP (admittedly nonstandard, but it worked) for over a decade before Linux got the feature, and they have been marketing it ever since as one of the unique selling points of their IPsec solution. Yes, running e.g. TCP over IPsec over TCP has funny side effects, but it beats not being able to connect at all. Some other VPN solutions (WireGuard) require third-party tooling to run over TCP, but with RFC 8226 support IPsec finally surpasses that.

5.8 Merge window, part 1

mjg59 — Mon, 08 Jun 2020 08:04:34 +0000

The "delete from view without reallocating" is actually a reasonable approach to not rewriting an entire flash block every time someone touches a variable. The problem was that the platform wouldn't trigger garbage collection until it detected it was out of space, and if you were *very* close to being out of space the firmware would run out of space before the garbage collection code ran.

There's not actually a good answer here. EFI firmware updates need to be in SMM because that's the only mechanism Intel provide to allow authenticated writes to flash, and SMM can't run without all cores being in SMM, so if you do a variable update and need to rewrite an entire block of flash you're going to halt the OS for long enough that things will be unhappy. Getting into a situation where you allow the OS to make the machine unbootable obviously isn't a great answer to that (https://lore.kernel.org/patchwork/patch/300747/ is arguably more egregious in this respect), but the singular bug that actually led us to this point is an understandable one.

(The -ENOSPC behaviour is accompanied by the kernel then attempting to create a variable it knows is too big in order to force the firmware to do a garbage collection run on next boot. If you boot via the UEFI boot stub then the kernel will do this while still in UEFI boot services, which should trigger the garbage collection before the kernel starts. As a result, this *should* now be largely invisible to users without putting systems at risk, but obviously we have no way whatsoever kf knowing how firmware actually works before we try it)

5.8 Merge window, part 1

amacater — Mon, 08 Jun 2020 05:55:32 +0000

That one bricked my Thinkpad - my main machine. Luckily, I was at a tech conference among friends and a couple of EFI experts where somebody suggested a complete reflash of the BIOS, someone else had an external USB that could fake a floppy - after one of the most panic stricken 3/4 hours of my life, it all worked. Many years later, it's beside me on the table, still working. Thanks MiniDebConf Cambridge

5.8 Merge window, part 1

flussence — Mon, 08 Jun 2020 05:46:02 +0000

Extremely badly behaved AMI firmware; deleting EFI vars only hid them from view without deallocating space in nvram. After a few panics happened on one buggy kernel version it started returning -ENOSPC for efivarfs operations.

At the time I also had `installkernel` set up to update the efibootmgr entries during make install, which made everything worse - couldn't change the default boot to a known-good entry, it was stuck on the bad one.

5.8 Merge window, part 1

ebiederm — Sun, 07 Jun 2020 16:35:56 +0000

We have had kexec on panic for years. So this is doable without pstore.

I am just a little astonished. Last round this was tested (admittedly with more data because people wanted a kernel core dump) using drivers in the kernel to write to on a kernel panic only worked on developers machines. Under actual read world failure conditions the kernel was always too compromised to successfully (safely?) write to a block device.

The listed driver restrictions might be enough to make the code reliable in a crash scenario. I would love to see a report on their testing.

5.8 Merge window, part 1

josh — Sun, 07 Jun 2020 13:37:32 +0000

I would be interested in hearing the details on what went wrong.

5.8 Merge window, part 1

flussence — Sun, 07 Jun 2020 01:59:08 +0000

This would be a massive improvement over the current state of affairs; I've tried using the EFI backend before on a headless server and it worked great for a while, until one day it didn't and then fixing it required a screwdriver.

5.8 Merge window, part 1

darwi — Sun, 07 Jun 2020 00:37:30 +0000

> The "pstore" mechanism, which stashes away system-state information in case of a panic, has gained a new back-end that stores data to a block device. See this commit for documentation.

This is amazing for debuggability on x86 laptops, which typically lack standardized ways of saving the kernel log on panic. I hope more and more block drivers implement the necessary hooks for this.

Documentation for "gate" action

knurd — Fri, 05 Jun 2020 18:03:58 +0000

> The new "gate" action […] This action is naturally undocumented […]

TWIMC: documentation for features like this often gets added to iproute2 (together with the userland support for the feature), that's why the man page for the gate action can be found here: https://git.kernel.org/pub/scm/network/iproute2/iproute2....