Cpufreq_ext Being Worked On For BPF-Based CPU Frequency Scaling

[phoronix]

Phoronix: Cpufreq_ext Being Worked On For BPF-Based CPU Frequency Scaling

The newly-merged sched_ext allows for the Linux kernel scheduler to be made more extensible by allowing BPF programs to be loaded to affect the kernel's scheduling behavior. There's now a similar take on CPU frequency scaling: cpufreq_ext. There's a "request for comments" patch series on cpufreq_ext for making extensible CPU frequency scaling algorithm adaptations with BPF...

https://www.phoronix.com/news/cpufreq_ext-RFC

[fong38]

Really excited to see what devs will be able to cook up with all those bpf-based subsystems.

[unic0rn]

Really excited to see what devs will be able to cook up with all those bpf-based subsystems.

Likely quite a few security holes.

[ahrs]

Likely quite a few security holes.

I'm not sure it's possible to create security flaws with BPF, everything all gets verified by the kernel. Unless you mean logic errors causing the wrong policies to be applied, or not take effect, etc. I could foresee a lot of that and fun and games trying to work out why something is not boosting correctly, or one application is getting more priority than another and you don't know why, etc.

[numacross]

I'm not sure it's possible to create security flaws with BPF, everything all gets verified by the kernel.

You're making a dangerous assumption that this verification step is infallible, it's not - CVE-2022-23222 - kernel/bpf/verifier.c in the Linux kernel through 5.15.14 allows local users to gain privileges because of the availability of pointer arithmetic via certain *_OR_NULL pointer types.
Bugs happen and get fixed, but BPF is still a potential security risk.

[ahrs]

You're making a dangerous assumption that this verification step is infallible, it's not - CVE-2022-23222 - kernel/bpf/verifier.c in the Linux kernel through 5.15.14 allows local users to gain privileges because of the availability of pointer arithmetic via certain *_OR_NULL pointer types.
Bugs happen and get fixed, but BPF is still a potential security risk.

I was assuming the verification is sound, yes. Almost everything in the kernel is a potential security risk if a programmer makes a mistake.

[intelfx]

Bugs happen and get fixed, but BPF is still a potential security risk.

Everything in software is a potential security risk. The only computer that creates no security risks is one that's powered off. So, why single out BPF?

[numacross]

Everything in software is a potential security risk. The only computer that creates no security risks is one that's powered off. So, why single out BPF?

Yup, everything in software is a potential security risk. What's important is the scope and magnitude of that risk.
Because BPF lives in the kernel and takes user-provided programs it has to be very, very carefully designed and implemented. My example was that even such a great design isn't flawlessly implemented, at least not in the beginning.

[intelfx]

Yup, everything in software is a potential security risk. What's important is the scope and magnitude of that risk.
Because BPF lives in the kernel and takes user-provided programs it has to be very, very carefully designed and implemented. My example was that even such a great design isn't flawlessly implemented, at least not in the beginning.

It's pretty obvious that both sched_ext BPF programs and cpufreq_ext BPF programs are privileged (i.e. only root can load them). So: what exactly in context of this article constitutes "a potential security risk" specifically worth singling out?

[billyswong]

As long as people aren't downloading and installing BPF stuff from random internet websites casually, thing is going to be okay. BPF is not going to be more dangerous than DKMS.