Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1005220

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

From "brian m. carlson" <sandals@crustytoothpaste.net>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
Date 2020-04-19 01:30 +0200
Message-ID <zX54m-759-9@gated-at.bofh.it> (permalink)
References <zX0R3-4nu-1@gated-at.bofh.it> <zX3OW-6qg-3@gated-at.bofh.it> <zX0R3-4nu-1@gated-at.bofh.it> <zX3OW-6qg-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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?

> 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.

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Back to linux.debian.bugs.dist | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions "brian m. carlson" <sandals@crustytoothpaste.net> - 2020-04-18 21:00 +0200
  Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions Ben Hutchings <ben@decadent.org.uk> - 2020-04-19 00:10 +0200
    Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions "brian m. carlson" <sandals@crustytoothpaste.net> - 2020-04-19 01:30 +0200
      Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions Ben Hutchings <ben@decadent.org.uk> - 2020-04-19 02:40 +0200

csiph-web