Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatibility with Secure Boot & Lockdown #50

Open
KyleGospo opened this issue May 24, 2022 · 4 comments
Open

Incompatibility with Secure Boot & Lockdown #50

KyleGospo opened this issue May 24, 2022 · 4 comments

Comments

@KyleGospo
Copy link
Contributor

KyleGospo commented May 24, 2022

On Linux distros with Secure Boot enabled Kernel Lockdown can prevent access to /sys/kernel/debug/*, rendering system76-scheduler unable to tune the scheduler:

May 24 09:59:37 daedalus system76-scheduler[240248]: failed to set value in /sys/kernel/debug/sched/latency_ns: Operation not permitted (os error 1)
May 24 09:59:37 daedalus system76-scheduler[240248]: failed to set value in /sys/kernel/debug/sched/min_granularity_ns: Operation not permitted (os error 1)
May 24 09:59:37 daedalus system76-scheduler[240248]: failed to set value in /sys/kernel/debug/sched/wakeup_granularity_ns: Operation not permitted (os error 1)
May 24 09:59:37 daedalus system76-scheduler[240248]: failed to set value in /sys/kernel/debug/sched/preempt: Operation not permitted (os error 1)

Outside of a kernel patch to add new params outside of debug there may not be a way around this as those params can only be tweaked at boot in this scenario from what I can tell. Might just need to update documentation to warn the user about this.

@bdaase
Copy link

bdaase commented Oct 15, 2022

What are the implications of this inability to tweaks these values (I am wondering since I see the above log messages)? Do we still expect to see improvements from system76-scheduler?

@mmstick
Copy link
Member

mmstick commented Oct 16, 2022

Applications can only do what the kernel permits, so if the kernel doesn't allow it, it can't be done.

@mbana
Copy link

mbana commented Oct 16, 2022

Hello, if you find a solution to this, please let me know. I doubt it.

Enabling SecureBoot does not allow one to write to debugfs.

Perhaps, enabling writing to to debugfs can be enabled by adding a udev rule. I'm not sure.

What is the Kernel config parameter that prohibits writing to debugfs whilst SecureBoot is enabled?

@skewballfox
Copy link

What is the Kernel config parameter that prohibits writing to debugfs whilst SecureBoot is enabled?

probably already found this out but I'm pretty sure it's lockdown. you can get the current state of lockdown via cat /sys/kernel/security/lockdown and access it's man page via man lockdown 7. if it's in integrity mode I think debugfs is read-only.

I'm seeing similar issues for linux-zen and qemu, so it might be worthwhile to search through there previous issues/comments to see if anyone found a solution that doesn't just involve disabling it, but so far I haven't found anything to indicate you could use a udev rule to work around this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants