LWN: Comments on "4.20/5.0 Merge window part 1"

4.20/5.0 Merge window part 1

Wol — Sat, 10 Nov 2018 09:09:54 +0000

Teenage Angst, the Galaxy, and part of everything :-)

Cheers,
Wol

LED patterns

robbe — Thu, 08 Nov 2018 14:43:19 +0000

I must admit that I thought: when will BPF programs drive this?

4.20/5.0 Merge window part 1

fartman — Wed, 31 Oct 2018 15:37:12 +0000

It might be interesting to explore BPF as an alternative for grabbing information from the kernel, instead of resorting to netlink (and it solves the problem of parsing things in userspace, and is fast enough). The files on virtual fs can remain for human readability and legacy tools.

4.20/5.0 Merge window part 1

fartman — Wed, 31 Oct 2018 15:17:28 +0000

I can see why, probably don't want to deviate in that NETLINK_CRYPTO has already been the place for that kind of thing now.

The problem to me appears to be the mixed granularity of procfs and sysfs. The former often has files varying in representation and results in more data being read than you need to, being slow. sysfs is granular with file-per-datum but when you need to collect a lot of things it quickly gets expensive.

If you had some sort of readv where you could submit what files to read together, as some sort of megaread, and it took a new iovec type where one could specify file descriptors to read from, the sysfs model would work well, and you would only need to make the kernel fetch what you need to.

It's still perhaps expensive in that you need to open all these files, but since that happens only ones per initialization (and all reads can be coalesced into one), i think it would help a lot. Then move all the snowflake files that don't belong in /proc to /sys/kernel/subsystem.

Ofcourse, someone needs to do this work, and since netlink is good enough, I don't think it would happen.

4.20/5.0 Merge window part 1

montjoie — Wed, 31 Oct 2018 14:20:50 +0000

My first patch for cryptostat was using a /sys/kernel/crypto, but the crypto maintainer said to use netlink.
It seems that the rules for all crypto management is to use netlink.

4.20/5.0 Merge window part 1

fartman — Tue, 30 Oct 2018 19:30:01 +0000

but netlink is also tied to network namespaces, don't you feel that's a little odd for something like crypto?

4.20/5.0 Merge window part 1

nhippi — Tue, 30 Oct 2018 15:51:01 +0000

Linux 4.20, serves the best clouds

4.20/5.0 Merge window part 1

johnsoda — Tue, 30 Oct 2018 15:16:52 +0000

When releasing the 3.0 kernel, part of the reasoning that Linus states was that he couldn't comfortably count that high.

Now, we are at the point where, does he consider 4.20 as being "Too high?"

4.20/5.0 Merge window part 1

naptastic — Mon, 29 Oct 2018 20:47:21 +0000

Why not both? :)

4.20/5.0 Merge window part 1

nilsmeyer — Mon, 29 Oct 2018 10:06:38 +0000

I'd prefer 5.0 and "Linux 2000" in keeping with "Linux for Workgroups" released some time ago ;)

4.20/5.0 Merge window part 1

mtaht — Sat, 27 Oct 2018 21:49:46 +0000

I'd really like there to be a 4.20 release. There's all sorts of in-jokes to be made.

I'd call it: smokey salmon.

4.20/5.0 Merge window part 1

pbonzini — Sat, 27 Oct 2018 10:19:35 +0000

Debugfs is a mishmash of interfaces, some of which might even let you get arbitrary code execution in the firmware; statistics can be retrieved and logged in production systems and it would be nice if production systems could avoid mounting debugfs altogether.

It is also not particularly efficient if you want to log thousands of statistics every second.

4.20/5.0 Merge window part 1

lkundrak — Sat, 27 Oct 2018 10:06:43 +0000

My first thought when I saw the crypto stats thing was: "Doesn't this belong in debugfs?" Why is a proc file or a netlink protocol better than debugfs for this sort of thing?

I suppose it's mostly used for debugging and with debugfs you don't have to stick to a stable interface.

4.20/5.0 Merge window part 1

pbonzini — Sat, 27 Oct 2018 09:40:51 +0000

I like the crypto statistics. It'd probably be good to have that for KVM too, instead of the current debugfs hack...

4.20/5.0 Merge window part 1

jhoblitt — Fri, 26 Oct 2018 21:58:43 +0000

The "LED pattern driver" looks useful -- this is something that I expect to be popular on RPIs.

Crypto side channels

abatters — Fri, 26 Oct 2018 19:52:07 +0000

> obtaining statistics from the cryptographic subsystem

Could this be used in a side channel attack on crypto algorithms?