[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions



On Sat, 2020-04-18 at 23:15 +0000, brian m. carlson wrote:
> On 2020-04-18 at 21:59:35, Ben Hutchings wrote:
> > Control: tag -1 wontfix
> > 
> > On Sat, 2020-04-18 at 18:50 +0000, brian m. carlson wrote:
> > > Package: src:linux
> > > Version: 5.5.17-1
> > > Severity: important
> > > 
> > > By default, Debian ships kernels such that when booted with Secure Boot,
> > > that a user cannot hibernate their computer.  However, the combination
> > > Alt-SysRq-x is documented in the wiki (which is linked to from the
> > > kernel) to lift these restrictions and allow the user to hibernate.
> > > 
> > > However, in this kernel version that does not work, and the user must
> > > either disable secure boot or forego hibernation.  When pressing
> > > Alt-SysRq-x, the following is printed:
> > > 
> > >   sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z)
> > [...]
> > 
> > This was an intentional change listed in the changelog, fixing bug
> > #947021.  Thanks for mentioning the wiki; I'll update that to reflect
> > current reality.
> 
> It looks like Ubuntu allows people physically present to use the key
> still with their proposed patch.  Is there a reason that patch can't be
> applied here?

They tried that, then gave up.

> > If you can't live with the restrictions of Secure Boot, you'll have to
> > turn it off.
> 
> Can you explain why this restriction is required in the first place?
> Other operating systems use Secure Boot and allow hibernation, so it
> can't be that it's an intrinsic limitation.

Loading a Linux hibernation image replaces the running kernel,
similarly to kexec.  Other operating systems probably implement it
differently.

> I'd like to have the behavior where I know that my boot process hasn't
> been tampered with, but I don't need to be locked out of my system or
> have important features turned off.  Surely that's a valid use case that
> should be supported.

These two features are not compatible, and until someone fixes that
you'll have to choose one or the other.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: