5:58 p.m.
Hi,
Fedora Workstation working group has been investigating the working
state of hibernation (suspend to disk) for about four months, and has
produced a draft status report on the findings so far. Present status,
impediments to support, and importantly, the specifics of how to
address those impediments, are described.
This is a draft, to reflect on-going work in this area. It's intended
to be short and consumable. Suggestions welcome. I include the
synopsis below for better visibility and list search.
https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
---
Synopsis:
The Fedora Workstation working group recognizes hibernation can be
useful, but due to impediments it's currently not practical to support
it. This is a recognition of the current state of affairs, but the
working group wishes hibernation could be relied upon, and thinks
there is a viable approach for limited support of hibernation in the
future. We encourage interested parties to pursue the needed
improvements. In the meantime, given that hibernation isn't currently
viable, the workstation WG decides that technical decisions will not
be constrained by it. Decisions about Workstation's 'out of the box'
configuration might conflict with the requirements of hibernation.
There are desired enhancements to performance and security that are
hindered by the status quo. The working group will re-evaluate when
the significant impediments have been adequately addressed.
We will support an install time means of enabling hibernation retained
via Custom partitioning. If the user chooses to create a swap
partition, the installer will include a resume=UUID kernel parameter
hint so that the kernel can find the hibernation image.
--
Chris Murphy
7:05 p.m.
On Friday, May 29, 2020 3:58:26 PM MST Chris Murphy wrote:
Hi,
Fedora Workstation working group has been investigating the working
state of hibernation (suspend to disk) for about four months, and has
produced a draft status report on the findings so far. Present status,
impediments to support, and importantly, the specifics of how to
address those impediments, are described.
This is a draft, to reflect on-going work in this area. It's intended
to be short and consumable. Suggestions welcome. I include the
synopsis below for better visibility and list search.
https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
---
Synopsis:
The Fedora Workstation working group recognizes hibernation can be
useful, but due to impediments it's currently not practical to support
it. This is a recognition of the current state of affairs, but the
working group wishes hibernation could be relied upon, and thinks
there is a viable approach for limited support of hibernation in the
future. We encourage interested parties to pursue the needed
improvements. In the meantime, given that hibernation isn't currently
viable, the workstation WG decides that technical decisions will not
be constrained by it. Decisions about Workstation's 'out of the box'
configuration might conflict with the requirements of hibernation.
There are desired enhancements to performance and security that are
hindered by the status quo. The working group will re-evaluate when
the significant impediments have been adequately addressed.
We will support an install time means of enabling hibernation retained
via Custom partitioning. If the user chooses to create a swap
partition, the installer will include a resume=UUID kernel parameter
hint so that the kernel can find the hibernation image.
I'm sorry, but this makes absolutely no sense. You can test hibernation right
now, and it will work. When you boot back up, it'll have everything just as
you left it. What systems is it broken on, those with Secure Boot? Is there
something in GNOME that has changed in the past few releases which broke it?
I've just taken a Lenovo T500, installed GNOME Workstation and gone into
hibernation. It took about 30 seconds to boot back in, but I was right where I
left off. What exactly is broken, and for what portion of users?
--
John M. Harris, Jr.
Splentity
7:25 p.m.
On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
I'm sorry, but this makes absolutely no sense.
Disliking the story is not the same thing as it not making sense.
There isn't much I can do about the former, but if you have a specific
area where there is a lack of clarity, I'll try to clear it up.
You can test hibernation right
now, and it will work. When you boot back up, it'll have everything just as
you left it. What systems is it broken on, those with Secure Boot?
Not broken, disabled. That's the policy both upstream and in Fedora.
Is there
something in GNOME that has changed in the past few releases which broke it?
No.
I've just taken a Lenovo T500, installed GNOME Workstation and
gone into
hibernation. It took about 30 seconds to boot back in, but I was right where I
left off. What exactly is broken, and for what portion of users?
I don't know the Lenovo T500 firmware setup defaults. If it conforms
to Microsoft Windows (8 or later) hardware certification
specifications, then UEFI Secure Boot is enabled by default. And it
mean you changed the defaults to get the results you're experiencing,
thereby disabling a significant feature the Fedora invested
significant resources to explicitly support.
--
Chris Murphy
10:11 p.m.
On Friday, May 29, 2020 5:25:23 PM MST Chris Murphy wrote:
On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
>
>
> I'm sorry, but this makes absolutely no sense.
Disliking the story is not the same thing as it not making sense.
There isn't much I can do about the former, but if you have a specific
area where there is a lack of clarity, I'll try to clear it up.
It's not that I don't like anything about this, it just doesn't seem to match
the reality of the situation.
>You can test hibernation right
> now, and it will work. When you boot back up, it'll have everything just
> as you left it. What systems is it broken on, those with Secure Boot?
Not broken, disabled. That's the policy both upstream and in Fedora.
Then why not just re-enable it? Why in the world is it disabled? If it's
disabled, why did it work when I ran `systemctl hibernate`? Why does it work
with KDE Spin out of box?
> I've just taken a Lenovo T500, installed GNOME Workstation
and gone into
> hibernation. It took about 30 seconds to boot back in, but I was right
> where I left off. What exactly is broken, and for what portion of users?
I don't know the Lenovo T500 firmware setup defaults. If it conforms
to Microsoft Windows (8 or later) hardware certification
specifications, then UEFI Secure Boot is enabled by default. And it
mean you changed the defaults to get the results you're experiencing,
thereby disabling a significant feature the Fedora invested
significant resources to explicitly support.
The Lenovo T500 is one of the first or second generation EFI devices. The only
settings that have been changed is the disabling of PXE and setting a boot
settings password. I have access to some newer hardware that has Secure Boot
that I can test with. I'll go and snag one of those now, and get a test
install of Workstation going.
I asked above, but it wasn't answered, and your answer to this has me a bit
confused. Is Secure Boot the issue that is blocking resume from working
properly? If so, I can ensure that Secure Boot is enabled on the hardware that
supports it, and try hibernation there.
Regardless, if that's the case, wouldn't it make more sense to keep
hibernation available in the UI where it's supported well, the systems without
Secure Boot? A trivial check for that could be false if BIOS, and false if
efivars doesn't show that it was booted with secure boot.
--
John M. Harris, Jr.
Splentity
2:36 a.m.
On Fri, May 29, 2020 at 9:12 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Friday, May 29, 2020 5:25:23 PM MST Chris Murphy wrote:
> On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr <johnmh(a)splentity.com>
> >You can test hibernation right
> > now, and it will work. When you boot back up, it'll have everything just
> > as you left it. What systems is it broken on, those with Secure Boot?
>
> Not broken, disabled. That's the policy both upstream and in Fedora.
Then why not just re-enable it? Why in the world is it disabled?
It's a security risk that is incompatible with having UEFI Secure Boot enabled.
The entire point of UEFI Secure Boot is to ensure cryptographic
verification that the kernel you're running is in fact a Fedora built
and signed kernel. Since resuming from hibernation completely replaces
memory contents with that of the image, if the hibernation image isn't
cryptographically signed too, it's an attack vector that permits
arbitrary code execution, including even in the kernel.
I will add a footnote clarifying this in draft 2.
The proper enhancement is signed and encrypted hibernation images. If
people want this to work, it's highly recommended they look into
picking up the stalled work in this area. There is hardware attrition
under way. And that means hibernation is getting tested less and less,
with fewer kernel and desktop bug reports. And testers. It's a real
going-concern problem.
If it's
disabled, why did it work when I ran `systemctl hibernate`? Why does it work
with KDE Spin out of box?
Your system doesn't have UEFI Secure Boot or it isn't enabled. With
Secure Boot enabled, hibernation is one of many things that is subject
to kernel lockdown across all of Fedora products including KDE.
https://lwn.net/Articles/706637/
I asked above, but it wasn't answered, and your answer to this
has me a bit
confused. Is Secure Boot the issue that is blocking resume from working
properly? If so, I can ensure that Secure Boot is enabled on the hardware that
supports it, and try hibernation there.
UEFI Secure Boot does not do the blocking. But it is used to enable
the kernel lockdown policy, and the lockdown policy inhibits various
things including hibernation. Specifically it will block both
hibernation entry and resume.
[ 0.850908] Lockdown: swapper/0: hibernation is restricted; see man
kernel_lockdown.7
$ sudo systemctl hibernate
Failed to hibernate system via logind: Sleep verb "hibernate" not supported
Which also results in this:
[109941.217325] Lockdown: systemd-logind: hibernation is restricted;
see man kernel_lockdown.7
Regardless, if that's the case, wouldn't it make more sense to keep
hibernation available in the UI where it's supported well, the systems without
Secure Boot? A trivial check for that could be false if BIOS, and false if
efivars doesn't show that it was booted with secure boot.
I don't know whether or when there will be any changes to UI. I think
it's already conditional now. The option to hibernate appears in the
GUI on my test system that can hibernate and doesn't appear on the
systems it's not supported on.
--
Chris Murphy
9:52 a.m.
On Sat, May 30, 2020 at 1:36 am, Chris Murphy <lists(a)colorremedies.com>
wrote:
I don't know whether or when there will be any changes to UI. I
think
it's already conditional now. The option to hibernate appears in the
GUI on my test system that can hibernate and doesn't appear on the
systems it's not supported on.
I think we don't expose hibernation in the UI at all, except as
low-power action to take when out of battery. (In that case, attempting
to hibernate, risking data loss, is better than power off for
guaranteed data loss.) Do you see it anywhere else...?
5:23 p.m.
On Sat, May 30, 2020 at 8:53 AM Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Sat, May 30, 2020 at 1:36 am, Chris Murphy <lists(a)colorremedies.com>
wrote:
> I don't know whether or when there will be any changes to UI. I think
> it's already conditional now. The option to hibernate appears in the
> GUI on my test system that can hibernate and doesn't appear on the
> systems it's not supported on.
I think we don't expose hibernation in the UI at all, except as
low-power action to take when out of battery. (In that case, attempting
to hibernate, risking data loss, is better than power off for
guaranteed data loss.) Do you see it anywhere else...?
I only see it in the "Power Button Action" menu. It's not there in
VM's, even if the VM has hibernation support enable. And it's not on
UEFI Secure Boot enabled computers. And it also goes away if I
swapoff.
--
Chris Murphy
6:45 p.m.
Am 30.05.20 um 09:36 schrieb Chris Murphy:
It's a security risk that is incompatible with having UEFI Secure Boot enabled.
The entire point of UEFI Secure Boot is to ensure cryptographic
verification that the kernel you're running is in fact a Fedora built
and signed kernel. Since resuming from hibernation completely replaces
memory contents with that of the image, if the hibernation image isn't
cryptographically signed too, it's an attack vector that permits
arbitrary code execution, including even in the kernel.
Anything you put unencrypted on a disk, is insecure. If you don't run
full disk encryption, nothing stops an attacker from simply change
whatever he likes on disk right away. If the system hibernates and you
boot the device with a different OS => change what ever you like.
Booting a signed kernel does not change that.Ā And in an attemptĀ to not
strech this again, we had this discussion for FDE already in the systemd
homed tree.
best regards,
Marius
8:02 p.m.
On Sat, May 30, 2020 at 5:46 PM Marius Schwarz <fedoradev(a)cloud-foo.de> wrote:
Am 30.05.20 um 09:36 schrieb Chris Murphy:
>
> It's a security risk that is incompatible with having UEFI Secure Boot enabled.
>
> The entire point of UEFI Secure Boot is to ensure cryptographic
> verification that the kernel you're running is in fact a Fedora built
> and signed kernel. Since resuming from hibernation completely replaces
> memory contents with that of the image, if the hibernation image isn't
> cryptographically signed too, it's an attack vector that permits
> arbitrary code execution, including even in the kernel.
>
>
Anything you put unencrypted on a disk, is insecure. If you don't run
full disk encryption, nothing stops an attacker from simply change
whatever he likes on disk right away.
Full disk encryption doesn't adequately secure the hibernation image
either. Authenticated encryption (signing as well as encryption) is
needed to verify the image hasn't been tampered. The upstream work,
cited in the document, gets into the details, and what additional work
is needed for the next revision.
--
Chris Murphy
10:25 p.m.
On 20-05-30 21:02:11, Chris Murphy wrote:
...
Full disk encryption doesn't adequately secure the hibernation
image
either. Authenticated encryption (signing as well as encryption) is
needed to verify the image hasn't been tampered.
What can an attacker do other than corrupt the data? It is encrypted.
With tamper detection, does a single bit changed deny the use of the
hibernated image?
In either case, what can an attacker accomplish?
The upstream work, cited in the document, gets into the details,
and what additional work is needed for the next revision.
Which reference is that? #5? It seemed short.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
1:45 p.m.
On Sat, May 30, 2020 at 9:26 PM Tony Nelson
<tonynelson(a)georgeanelson.com> wrote:
On 20-05-30 21:02:11, Chris Murphy wrote:
...
> Full disk encryption doesn't adequately secure the hibernation image
> either. Authenticated encryption (signing as well as encryption) is
> needed to verify the image hasn't been tampered.
What can an attacker do other than corrupt the data? It is encrypted.
You don't know, and neither do I. That's the problem.
With tamper detection, does a single bit changed deny the use of the
hibernated image?
I expect so. Even at a far lesser level of integrity, e.g. non-crypto
crc32c used by dm-integrity and Btrfs by default, a single bit flip is
detected and you get EIO on reads.
In either case, what can an attacker accomplish?
I have the same question, exposing me as (a) not a very good attacker,
and (b) not a cryptographer. Nevertheless I'm persuaded by the
argument that if I've signed up for signature verification of the
kernel and kernel modules at the start (UEFI Secure Boot), that it's a
bad idea to enable a loop hole where unauthenticated data is executed.
It doesn't matter if it's encrypted. It provides no error detection
mechanism. Such a loop hole in effect is an attack on the Secure Boot
paradigm.
And for now it's a difficult problem with limited resources committed
to resolving it. There are other ways to go about it, that also aren't
exactly easy but they might turn out to be more viable than AE
hibernation images.
> The upstream work, cited in the document, gets into the
details,
> and what additional work is needed for the next revision.
Which reference is that? #5? It seemed short.
I only provided a link to the most recent status. You need to click on
that link to get to the lkml email, and click on the link in there
too, and follow it to the patch set and ~18 email discussion. It's
short because it needs more work and the developer hasn't found enough
time to get back into it yet.
--
Chris Murphy
9:33 p.m.
On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:
On Sat, May 30, 2020 at 9:26 PM Tony Nelson
<tonynelson(a)georgeanelson.com> wrote:
>
>
> On 20-05-30 21:02:11, Chris Murphy wrote:
>
> ...
>
> > Full disk encryption doesn't adequately secure the hibernation image
> > either. Authenticated encryption (signing as well as encryption) is
> > needed to verify the image hasn't been tampered.
>
>
>
> What can an attacker do other than corrupt the data? It is encrypted.
You don't know, and neither do I. That's the problem.
We do know. Nothing, really.
> With tamper detection, does a single bit changed deny the use of the
> hibernated image?
I expect so. Even at a far lesser level of integrity, e.g. non-crypto
crc32c used by dm-integrity and Btrfs by default, a single bit flip is
detected and you get EIO on reads.
> In either case, what can an attacker accomplish?
I have the same question, exposing me as (a) not a very good attacker,
and (b) not a cryptographer. Nevertheless I'm persuaded by the
argument that if I've signed up for signature verification of the
kernel and kernel modules at the start (UEFI Secure Boot), that it's a
bad idea to enable a loop hole where unauthenticated data is executed.
It doesn't matter if it's encrypted. It provides no error detection
mechanism. Such a loop hole in effect is an attack on the Secure Boot
paradigm.
And for now it's a difficult problem with limited resources committed
to resolving it. There are other ways to go about it, that also aren't
exactly easy but they might turn out to be more viable than AE
hibernation images.
> > The upstream work, cited in the document, gets into the details,
> > and what additional work is needed for the next revision.
>
>
>
> Which reference is that? #5? It seemed short.
I only provided a link to the most recent status. You need to click on
that link to get to the lkml email, and click on the link in there
too, and follow it to the patch set and ~18 email discussion. It's
short because it needs more work and the developer hasn't found enough
time to get back into it yet.
--
Chris Murphy
A good option until then is to just take unsigned hibernation images and work
like literally every other system. There's no reason to take away this
functionality.
--
John M. Harris, Jr.
11:25 p.m.
On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:
> On Sat, May 30, 2020 at 9:26 PM Tony Nelson
> <tonynelson(a)georgeanelson.com> wrote:
>
> >
> >
> > On 20-05-30 21:02:11, Chris Murphy wrote:
> >
> > ...
> >
> > > Full disk encryption doesn't adequately secure the hibernation image
> > > either. Authenticated encryption (signing as well as encryption) is
> > > needed to verify the image hasn't been tampered.
> >
> >
> >
> > What can an attacker do other than corrupt the data? It is encrypted.
>
>
> You don't know, and neither do I. That's the problem.
We do know. Nothing, really.
You do not know the attacker, when possession was lost, what the
attacker knows, or how long they have access to ciphertext. And that's
because the attack hasn't happened yet. Yet you assert omniscience.
Gotcha.
A good option until then is to just take unsigned hibernation images
and work
like literally every other system. There's no reason to take away this
functionality.
Why do you think it's good to tell users we support UEFI Secure Boot,
but then provide attackers a loop hole to get around it?
--
Chris Murphy
11:34 p.m.
On 6/2/20 9:25 PM, Chris Murphy wrote:
On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr
<johnmh(a)splentity.com> wrote:
>
> On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:
>> On Sat, May 30, 2020 at 9:26 PM Tony Nelson
>> <tonynelson(a)georgeanelson.com> wrote:
>>
>>>
>>>
>>> On 20-05-30 21:02:11, Chris Murphy wrote:
>>>
>>> ...
>>>
>>>> Full disk encryption doesn't adequately secure the hibernation image
>>>> either. Authenticated encryption (signing as well as encryption) is
>>>> needed to verify the image hasn't been tampered.
>>>
>>>
>>>
>>> What can an attacker do other than corrupt the data? It is encrypted.
>>
>>
>> You don't know, and neither do I. That's the problem.
>
> We do know. Nothing, really.
You do not know the attacker, when possession was lost, what the
attacker knows, or how long they have access to ciphertext. And that's
because the attack hasn't happened yet. Yet you assert omniscience.
Gotcha.
I don't understand this concern either. How is it different than any
encrypted filesystem? If you don't trust the encryption, then what's
the point? What's the difference between an encrypted filesystem and an
encrypted hibernation image that makes the image so insecure?
12:27 a.m.
On Tue, Jun 2, 2020 at 10:35 PM Samuel Sieb <samuel(a)sieb.net> wrote:
On 6/2/20 9:25 PM, Chris Murphy wrote:
> On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr <johnmh(a)splentity.com>
wrote:
>>
>> On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:
>>> On Sat, May 30, 2020 at 9:26 PM Tony Nelson
>>> <tonynelson(a)georgeanelson.com> wrote:
>>>
>>>>
>>>>
>>>> On 20-05-30 21:02:11, Chris Murphy wrote:
>>>>
>>>> ...
>>>>
>>>>> Full disk encryption doesn't adequately secure the hibernation
image
>>>>> either. Authenticated encryption (signing as well as encryption) is
>>>>> needed to verify the image hasn't been tampered.
>>>>
>>>>
>>>>
>>>> What can an attacker do other than corrupt the data? It is encrypted.
>>>
>>>
>>> You don't know, and neither do I. That's the problem.
>>
>> We do know. Nothing, really.
>
> You do not know the attacker, when possession was lost, what the
> attacker knows, or how long they have access to ciphertext. And that's
> because the attack hasn't happened yet. Yet you assert omniscience.
> Gotcha.
I don't understand this concern either. How is it different than any
encrypted filesystem? If you don't trust the encryption, then what's
the point? What's the difference between an encrypted filesystem and an
encrypted hibernation image that makes the image so insecure?
You trust the encryption only to provide confidentiality of your data
from the attacker. Not as a means of detecting an attack on your data.
And also this isn't really just user data, the hibernation image is
the kernel. If it's really compromised, it's a complete end run around
the guarantees of Secure Boot so necessarily it can't be weaker than
that implementation or the whole implementation is weakened. If it's
easier to exploit via the hibernation image, that's what attackers
will do.
An encrypted file system, again provides only confidentiality. There's
no integrity check. In fact you are equally susceptible to data
integrity problems whether your data is encrypted or not. You'd need a
dm-integrity option enabled (an option that can be done at the same
time as cryptsetup now), or you need to use Btrfs. Depending on your
threat model you might need to use one of the cyptographic hash
functions (dm-integrity provides hmac:sha256; and btrfs provides
sha256 and blake2b, looks like keyed hashing support is decently
likely to happen there as well). The keyed hashing function provides
integrity but also provides authenticity. You need the key to produce
valid writes. If you don't have the key, the writes you produce would
be immediately detected as bogus by the key holder.
Ergo you can trust your attacker can't see in /usr. But you don't
know, with encryption alone if you can trust /usr. It pretty much
comes down to trusting the hardware ECC in the drive, if you don't
have something that provides integrity.
--
Chris Murphy
5:02 a.m.
Am 03.06.20 um 07:27 schrieb Chris Murphy:
You trust the encryption only to provide confidentiality of your
data
from the attacker. Not as a means of detecting an attack on your data.
And also this isn't really just user data, the hibernation image is
the kernel. If it's really compromised, it's a complete end run around
the guarantees of Secure Boot so necessarily it can't be weaker than
that implementation or the whole implementation is weakened. If it's
easier to exploit via the hibernation image, that's what attackers
will do.
making an unencrypted image tamper safe by signing it, is just
unnecessary work frpm the POV of security as it stays insecure:
a) an attacker can read the content and gain informations
b) he can change the data on disk and just wait for a reboot.
Signing the image for the pure integrity of the data structures to be
(technically) "safe" to load
is a whole different story and a gerneral good idea.Ā But don't mix
"safe" with "secure", it's not secure.
Best regards,
Marius
11:13 a.m.
On Thu, Jun 4, 2020 at 4:03 AM Marius Schwarz <fedoradev(a)cloud-foo.de> wrote:
Am 03.06.20 um 07:27 schrieb Chris Murphy:
> You trust the encryption only to provide confidentiality of your data
> from the attacker. Not as a means of detecting an attack on your data.
> And also this isn't really just user data, the hibernation image is
> the kernel. If it's really compromised, it's a complete end run around
> the guarantees of Secure Boot so necessarily it can't be weaker than
> that implementation or the whole implementation is weakened. If it's
> easier to exploit via the hibernation image, that's what attackers
> will do.
>
making an unencrypted image tamper safe by signing it, is just
unnecessary work frpm the POV of security as it stays insecure:
a) an attacker can read the content and gain informations
b) he can change the data on disk and just wait for a reboot.
Signing the image for the pure integrity of the data structures to be
(technically) "safe" to load
is a whole different story and a gerneral good idea. But don't mix
"safe" with "secure", it's not secure.
I'm confused. No one has suggested a signed but unencrypted hibernation image.
I don't see the distinction between safe and secure, these are general
purpose terms. A signed but not encrypted kernel is secure insofar as
if it's been tampered with, this can be detected and go to fail to
avoid using a possibly corrupt or compromised kernel.
To suggest that unencrypted files also aren't secure doesn't make
sense. They lack confidentiality, so you can say they aren't secure
from prying eyes, but it's vague to just say they aren't secure. It's
better to be more specific by indicating authenticity, integrity, or
confidentiality, or some combination.
Also, as it relates to authenticated encrypted hibernation images, the
upstream proposal is that since hibernation images can exist anywhere,
they should always be encrypted independently from swap, and therefore
not depend on whether swap is encrypted or how.
--
Chris Murphy
12:57 p.m.
On Thu, 4 Jun 2020 10:13:59 -0600
Chris Murphy <lists(a)colorremedies.com> wrote:
Also, as it relates to authenticated encrypted hibernation images,
the
upstream proposal is that since hibernation images can exist anywhere,
they should always be encrypted independently from swap, and therefore
not depend on whether swap is encrypted or how.
Just following the conversation for information purposes, but I have
questions. If systemd-boot were to be used as boot service, could the
hibernate image be written to /boot/efi in place of the kernel and
initramfs, or in parallel? Would systemd-boot be able to use it? Would
that satisfy the encrypted and signed requirements?
2:01 p.m.
On Thu, Jun 4, 2020 at 11:58 AM stan via devel
<devel(a)lists.fedoraproject.org> wrote:
On Thu, 4 Jun 2020 10:13:59 -0600
Chris Murphy <lists(a)colorremedies.com> wrote:
> Also, as it relates to authenticated encrypted hibernation images, the
> upstream proposal is that since hibernation images can exist anywhere,
> they should always be encrypted independently from swap, and therefore
> not depend on whether swap is encrypted or how.
Just following the conversation for information purposes, but I have
questions. If systemd-boot were to be used as boot service, could the
hibernate image be written to /boot/efi in place of the kernel and
initramfs, or in parallel? Would systemd-boot be able to use it? Would
that satisfy the encrypted and signed requirements?
No to all sadly.
On Linux, neither GRUB or sd-boot directly consume the hibernation
image to perform resume. Bootloader and firmware based hibernation
resumption is found on Windows and macOS (there are many hibernation
implementations on Windows). On Linux, this is a kernel feature, so
the bootloader loads kernel and initramfs and boots normally; the
kernel uses a kernel parameter hint(s) to discover the location of the
hibernation image within swap. And voila.
I think the kernel does have code to support Intel Rapid Start. This
is a firmware based hibernation resume implementation, so first the
firmware must support it. But honestly have no idea if it works
exactly like it does on Windows. At least on Windows it requires a
dedicated partition expressly for the hibernation image. And the
firmware's Intel Rapid Start function is given a hint at hibernate
time so i knows at next power on that it should resume from this
hibernation image directly.
Anyway, it would take work to build a generic implementation supported
in either bootloader.
--
Chris Murphy
2:33 p.m.
On Thu, 4 Jun 2020 13:01:37 -0600
Chris Murphy <lists(a)colorremedies.com> wrote:
> Just following the conversation for information purposes, but I
have
> questions. If systemd-boot were to be used as boot service, could
> the hibernate image be written to /boot/efi in place of the kernel
> and initramfs, or in parallel? Would systemd-boot be able to use
> it? Would that satisfy the encrypted and signed requirements?
No to all sadly.
On Linux, neither GRUB or sd-boot directly consume the hibernation
image to perform resume. Bootloader and firmware based hibernation
resumption is found on Windows and macOS (there are many hibernation
implementations on Windows). On Linux, this is a kernel feature, so
the bootloader loads kernel and initramfs and boots normally; the
kernel uses a kernel parameter hint(s) to discover the location of the
hibernation image within swap. And voila.
I think the kernel does have code to support Intel Rapid Start. This
is a firmware based hibernation resume implementation, so first the
firmware must support it. But honestly have no idea if it works
exactly like it does on Windows. At least on Windows it requires a
dedicated partition expressly for the hibernation image. And the
firmware's Intel Rapid Start function is given a hint at hibernate
time so i knows at next power on that it should resume from this
hibernation image directly.
Anyway, it would take work to build a generic implementation supported
in either bootloader.
Thanks for the information. Too bad.
9:41 p.m.
On Saturday, May 30, 2020 12:36:46 AM MST Chris Murphy wrote:
On Fri, May 29, 2020 at 9:12 PM John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
>
>
> On Friday, May 29, 2020 5:25:23 PM MST Chris Murphy wrote:
>
> > On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr
> > <johnmh(a)splentity.com>
> > >You can test hibernation right
> > >
> > > now, and it will work. When you boot back up, it'll have everything
> > > just
> > > as you left it. What systems is it broken on, those with Secure Boot?
> >
> >
> >
> > Not broken, disabled. That's the policy both upstream and in Fedora.
>
>
>
> Then why not just re-enable it? Why in the world is it disabled?
It's a security risk that is incompatible with having UEFI Secure Boot
enabled.
The entire point of UEFI Secure Boot is to ensure cryptographic
verification that the kernel you're running is in fact a Fedora built
and signed kernel. Since resuming from hibernation completely replaces
memory contents with that of the image, if the hibernation image isn't
cryptographically signed too, it's an attack vector that permits
arbitrary code execution, including even in the kernel.
I will add a footnote clarifying this in draft 2.
The proper enhancement is signed and encrypted hibernation images. If
people want this to work, it's highly recommended they look into
picking up the stalled work in this area. There is hardware attrition
under way. And that means hibernation is getting tested less and less,
with fewer kernel and desktop bug reports. And testers. It's a real
going-concern problem.
>If it's
>
> disabled, why did it work when I ran `systemctl hibernate`? Why does it
> work with KDE Spin out of box?
Your system doesn't have UEFI Secure Boot or it isn't enabled. With
Secure Boot enabled, hibernation is one of many things that is subject
to kernel lockdown across all of Fedora products including KDE.
https://lwn.net/Articles/706637/
> I asked above, but it wasn't answered, and your answer to this has me a
> bit confused. Is Secure Boot the issue that is blocking resume from
> working properly? If so, I can ensure that Secure Boot is enabled on the
> hardware that supports it, and try hibernation there.
UEFI Secure Boot does not do the blocking. But it is used to enable
the kernel lockdown policy, and the lockdown policy inhibits various
things including hibernation. Specifically it will block both
hibernation entry and resume.
[ 0.850908] Lockdown: swapper/0: hibernation is restricted; see man
kernel_lockdown.7
$ sudo systemctl hibernate
Failed to hibernate system via logind: Sleep verb "hibernate" not supported
Which also results in this:
[109941.217325] Lockdown: systemd-logind: hibernation is restricted;
see man kernel_lockdown.7
>
>
> Regardless, if that's the case, wouldn't it make more sense to keep
> hibernation available in the UI where it's supported well, the systems
> without Secure Boot? A trivial check for that could be false if BIOS,
> and false if efivars doesn't show that it was booted with secure boot.
I don't know whether or when there will be any changes to UI. I think
it's already conditional now. The option to hibernate appears in the
GUI on my test system that can hibernate and doesn't appear on the
systems it's not supported on.
--
Chris Murphy
In what way is it incompatible with UEFI Secure Boot? If the kernel and
initramfs are signed, and the resume image is for that kernel, how is this an
issue? What if swap is on LUKS?
If kernel lockdown is what disables this, we should look at fixing kernel
lockdown so that it doesn't break hibernation. This is definitely a security
decision that we shouldn't be imposing on the masses needlessly, in my
opinion.
--
John M. Harris, Jr.
11:27 p.m.
On 6/2/20 7:41 PM, John M. Harris Jr wrote:
In what way is it incompatible with UEFI Secure Boot? If the kernel
and
initramfs are signed, and the resume image is for that kernel, how is this an
issue? What if swap is on LUKS?
Do you understand how hibernation works? It doesn't matter if the
booting kernel is signed, everything will be replaced by what's on the
disk. The kernel you boot with does not even have to be the same one
the hibernated image was booted with. Someone could modify the
in-memory image of the kernel on the disk or change some process to be
running as root when it's resumed. So it completely bypasses any
protection that secure boot provides. I'm inclined to say let me have
that insecurity if I want, but I think there are rules about what's
allowed if secure boot is enabled.
I would expect that using an encrypted partition for swap should be
sufficient to allow it though.
11:45 p.m.
On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb <samuel(a)sieb.net> wrote:
I would expect that using an encrypted partition for swap should be
sufficient to allow it though.
Unfortunately not. Encryption provides no integrity or authenticity.
The original set of patches for signed and authenticated hibernation
images called for the use of an HMAC for signing, and upstream
considered this insufficient and asked why not use AES-GCM to provide
a real AE (authenticated encryption) model.
Not only is encryption alone inadequate, the signature verification
model should ensure that the hibernation image being restored was
created by the computer it is being restored to.
I am not a cryptographer. And I can't do a better job of explaining
it. But it's a problem. And my disappointment isn't relevant to the
security issue. It's relevant from a UX perspective I suppose.
But, I've also just spent two days trying to track down a new
hibernation bug, resulting in fatal hibernation entry. Even without
the Secure Boot issue, hibernation can be a problem that requires
resources that are not finite. I had this working reliably several
months ago, and I've exhausted my time and interest for now doing
kernel regression testing and have literally no idea why it's
consistently failing now. On three machines (one is a VM). I did
report it upstream, I haven't gotten a reply yet (normal).
There are two emails, bottom one is the first.
https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz3...
--
Chris Murphy
11:58 p.m.
On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote:
On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb <samuel(a)sieb.net>
wrote:
>
>
> I would expect that using an encrypted partition for swap should be
> sufficient to allow it though.
Unfortunately not. Encryption provides no integrity or authenticity.
The original set of patches for signed and authenticated hibernation
images called for the use of an HMAC for signing, and upstream
considered this insufficient and asked why not use AES-GCM to provide
a real AE (authenticated encryption) model.
In what way do you believe it's not sufficient?
Not only is encryption alone inadequate, the signature verification
model should ensure that the hibernation image being restored was
created by the computer it is being restored to.
Why?
I am not a cryptographer. And I can't do a better job of
explaining
it. But it's a problem. And my disappointment isn't relevant to the
security issue. It's relevant from a UX perspective I suppose.
It's a severe UX issue that you cannot use a standard feature of normal
systems, hibernation.
But, I've also just spent two days trying to track down a new
hibernation bug, resulting in fatal hibernation entry. Even without
the Secure Boot issue, hibernation can be a problem that requires
resources that are not finite. I had this working reliably several
months ago, and I've exhausted my time and interest for now doing
kernel regression testing and have literally no idea why it's
consistently failing now. On three machines (one is a VM). I did
report it upstream, I haven't gotten a reply yet (normal).
There are two emails, bottom one is the first.
https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz3gB4
Hf1Nkp0w(a)mail.gmail.com/
--
Chris Murphy
--
John M. Harris, Jr.
2:06 p.m.
On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote:
On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote:
> On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb <samuel(a)sieb.net> wrote:
>
> >
> > I would expect that using an encrypted partition for swap should be
> > sufficient to allow it though.
>
> Unfortunately not. Encryption provides no integrity or authenticity.
> The original set of patches for signed and authenticated hibernation
> images called for the use of an HMAC for signing, and upstream
> considered this insufficient and asked why not use AES-GCM to provide
> a real AE (authenticated encryption) model.
In what way do you believe it's not sufficient?
AES GCM Is generally *not* a good algorithm for disk encryption so I am
not sure why this is being brought up, HMAC is sufficient to verify
integrity.
In any case the problem is that adding integrity protection cannot be
done w/o losing some space on the disk, as you need to save the
integrity tag/hmac.
As to why just encryption is not sufficient that is because you can
easily play a number of replay attacks, corruption attacks, and
potentially even sectors-wap attacks with naive encryption schemes.
This can be sufficient to generate an attack vector in certain
circumstance once the machine boots up again.
(As an hypotetical if the attacker is able to observe which sector
contains the passwd file and can corrupt it or replace it with other
content that effectively gives it access with a known secret or a blank
password or whatnot, or maybe it can create corruption in the kernel in
such a way that it causes the machine to display a OOM that reveals
encryption keys, or... the possibilities are endless).
> Not only is encryption alone inadequate, the signature
verification
> model should ensure that the hibernation image being restored was
> created by the computer it is being restored to.
Why?
Evil maid attacks.
Because without a signature you could replace the whole image with a
completely functional one that you fully control.
Boot the system with a hybernation image generated on identical
hardware but with your own data, give your own decryption key, presto,
as soon as the hybernation image is restored the system is running your
image. From there you could be able to use, for example, keys stored in
the TPM or simply you capture the real password for the real image as
soon as the user returns to the machine to unlock it and transmit it,
and now you have access to the original disk image and all its
contents...
Again, possibilities abound.
> I am not a cryptographer. And I can't do a better job of
explaining
> it. But it's a problem. And my disappointment isn't relevant to the
> security issue. It's relevant from a UX perspective I suppose.
It's a severe UX issue that you cannot use a standard feature of normal
systems, hibernation.
A way to deal with hybernation o secure boot would be to *measure* the
hybernated image as the last action of hybernation and store the
measure in TPM. Fail to restore on boot if the TPM fails to check the
measured image. (Measure here effectively ends up being running an HMAC
on the whole disk image you want to restore and storing the results in
TPM).
> But, I've also just spent two days trying to track down a
new
> hibernation bug, resulting in fatal hibernation entry. Even without
> the Secure Boot issue, hibernation can be a problem that requires
> resources that are not finite. I had this working reliably several
> months ago, and I've exhausted my time and interest for now doing
> kernel regression testing and have literally no idea why it's
> consistently failing now. On three machines (one is a VM). I did
> report it upstream, I haven't gotten a reply yet (normal).
>
> There are two emails, bottom one is the first.
> https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz3gB4
> Hf1Nkp0w(a)mail.gmail.com/
> --
> Chris Murphy
--
John M. Harris, Jr.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
4:31 p.m.
On Wed, Jun 3, 2020 at 1:07 PM Simo Sorce <simo(a)redhat.com> wrote:
On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote:
> On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote:
> > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb <samuel(a)sieb.net> wrote:
> >
> > >
> > > I would expect that using an encrypted partition for swap should be
> > > sufficient to allow it though.
> >
> > Unfortunately not. Encryption provides no integrity or authenticity.
> > The original set of patches for signed and authenticated hibernation
> > images called for the use of an HMAC for signing, and upstream
> > considered this insufficient and asked why not use AES-GCM to provide
> > a real AE (authenticated encryption) model.
>
> In what way do you believe it's not sufficient?
AES GCM Is generally *not* a good algorithm for disk encryption so I am
not sure why this is being brought up, HMAC is sufficient to verify
integrity.
I don't know either. This is the discussion I'm referring to, for full context:
https://lkml.org/lkml/2019/1/9/828
--
Chris Murphy
5:26 p.m.
On Wed, 2020-06-03 at 15:31 -0600, Chris Murphy wrote:
On Wed, Jun 3, 2020 at 1:07 PM Simo Sorce <simo(a)redhat.com>
wrote:
> On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote:
> > On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote:
> > > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb <samuel(a)sieb.net>
wrote:
> > >
> > > > I would expect that using an encrypted partition for swap should be
> > > > sufficient to allow it though.
> > >
> > > Unfortunately not. Encryption provides no integrity or authenticity.
> > > The original set of patches for signed and authenticated hibernation
> > > images called for the use of an HMAC for signing, and upstream
> > > considered this insufficient and asked why not use AES-GCM to provide
> > > a real AE (authenticated encryption) model.
> >
> > In what way do you believe it's not sufficient?
>
> AES GCM Is generally *not* a good algorithm for disk encryption so I am
> not sure why this is being brought up, HMAC is sufficient to verify
> integrity.
I don't know either. This is the discussion I'm referring to, for full context:
https://lkml.org/lkml/2019/1/9/828
Alright it was just a question and not a strong suggestion, nothing to
see (I do not want to go down a rabbit hole here anyway it is not
relevant to this discussion).
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
5:53 p.m.
On 6/3/20 12:06 PM, Simo Sorce wrote:
On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote:
> Why?
Evil maid attacks.
Because without a signature you could replace the whole image with a
completely functional one that you fully control.
Boot the system with a hybernation image generated on identical
hardware but with your own data, give your own decryption key, presto,
as soon as the hybernation image is restored the system is running your
image. From there you could be able to use, for example, keys stored in
the TPM or simply you capture the real password for the real image as
soon as the user returns to the machine to unlock it and transmit it,
and now you have access to the original disk image and all its
contents...
Again, possibilities abound.
Thank you, that is a very clear explanation.
10:29 p.m.
On Wednesday, June 3, 2020 12:06:19 PM MST Simo Sorce wrote:
On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote:
> On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote:
>
> > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb <samuel(a)sieb.net> wrote:
> >
> >
> > >
> > > I would expect that using an encrypted partition for swap should be
> > > sufficient to allow it though.
> >
> >
> > Unfortunately not. Encryption provides no integrity or authenticity.
> > The original set of patches for signed and authenticated hibernation
> > images called for the use of an HMAC for signing, and upstream
> > considered this insufficient and asked why not use AES-GCM to provide
> > a real AE (authenticated encryption) model.
>
>
> In what way do you believe it's not sufficient?
AES GCM Is generally *not* a good algorithm for disk encryption so I am
not sure why this is being brought up, HMAC is sufficient to verify
integrity.
I was asking why encryption itself would not be sufficient, nothing to do with
AES-GCM, just to clarify.
In any case the problem is that adding integrity protection cannot
be
done w/o losing some space on the disk, as you need to save the
integrity tag/hmac.
As to why just encryption is not sufficient that is because you can
easily play a number of replay attacks, corruption attacks, and
potentially even sectors-wap attacks with naive encryption schemes.
This can be sufficient to generate an attack vector in certain
circumstance once the machine boots up again.
(As an hypotetical if the attacker is able to observe which sector
contains the passwd file and can corrupt it or replace it with other
content that effectively gives it access with a known secret or a blank
password or whatnot, or maybe it can create corruption in the kernel in
such a way that it causes the machine to display a OOM that reveals
encryption keys, or... the possibilities are endless).
All of these are possible through many other methods, but all of these require
physical access. Once you're talking about physical access, the threat model
changes entirely.
> > Not only is encryption alone inadequate, the signature
verification
> > model should ensure that the hibernation image being restored was
> > created by the computer it is being restored to.
>
>
> Why?
Evil maid attacks.
Because without a signature you could replace the whole image with a
completely functional one that you fully control.
This sounds like legitimate functionality that may be desired. Am I wrong?
Boot the system with a hybernation image generated on identical
hardware but with your own data, give your own decryption key, presto,
as soon as the hybernation image is restored the system is running your
image. From there you could be able to use, for example, keys stored in
the TPM or simply you capture the real password for the real image as
soon as the user returns to the machine to unlock it and transmit it,
and now you have access to the original disk image and all its
contents...
Again, possibilities abound.
> > I am not a cryptographer. And I can't do a better job of explaining
> > it. But it's a problem. And my disappointment isn't relevant to the
> > security issue. It's relevant from a UX perspective I suppose.
>
>
> It's a severe UX issue that you cannot use a standard feature of normal
> systems, hibernation.
A way to deal with hybernation o secure boot would be to *measure* the
hybernated image as the last action of hybernation and store the
measure in TPM. Fail to restore on boot if the TPM fails to check the
measured image. (Measure here effectively ends up being running an HMAC
on the whole disk image you want to restore and storing the results in
TPM).
The larger UX issue is that hibernation is disabled for ALL users just because
it doesn't work for users with Secure Boot, which are probably a minority when
it comes to those running Fedora, CentOS or RHEL, and I'm saying this as a
CentOS/RHEL sysadmin and Fedora user. I'd like to see some data on that before
saying for sure, of course.
> > But, I've also just spent two days trying to track down
a new
> > hibernation bug, resulting in fatal hibernation entry. Even without
> > the Secure Boot issue, hibernation can be a problem that requires
> > resources that are not finite. I had this working reliably several
> > months ago, and I've exhausted my time and interest for now doing
> > kernel regression testing and have literally no idea why it's
> > consistently failing now. On three machines (one is a VM). I did
> > report it upstream, I haven't gotten a reply yet (normal).
> >
> > There are two emails, bottom one is the first.
> > https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz
> > 3gB4 Hf1Nkp0w(a)mail.gmail.com/
--
John M. Harris, Jr.
10:45 p.m.
On Wed, Jun 3, 2020 at 9:30 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
The larger UX issue is that hibernation is disabled for ALL users just because
it doesn't work for users with Secure Boot,
This is not correct. Hibernation is enabled in the kernel, it's only
inhibited by lockdown, and Secure Boot being enabled is the trigger
for enabling lockdown.
[ 0.000000] Kernel is locked down from EFI Secure Boot mode; see
man kernel_lockdown.7
[ 0.857522] Lockdown: swapper/0: hibernation is restricted; see man
kernel_lockdown.7
--
Chris Murphy
12:52 a.m.
On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
In what way is it incompatible with UEFI Secure Boot?
Secure Boot does boot verification. Hibernation right now doesn't. And
that makes it a Secure Boot loophole. And that makes it incompatible
with Secure Boot.
It's not a new idea, it's been this way for a while. And so have the complaints.
https://lwn.net/Articles/523367/
<If the kernel and
initramfs are signed, and the resume image is for that kernel, how is
this an
issue?
The initramfs is not signed.
What if swap is on LUKS?
No signature. No integrity. It is a net reduction in the protection
provided by Secure Boot - e.g. it can't detect intentional corruption
that could crash the system or even cause more corruption and eventual
data loss as the system runs.
If kernel lockdown is what disables this, we should look at fixing
kernel
lockdown so that it doesn't break hibernation. This is definitely a security
decision that we shouldn't be imposing on the masses needlessly, in my
opinion.
Instead you propose imposing a loophole for attackers to easily deploy
malware needlessly. Do you really not see how this is an untenable
position for Fedora?
--
Chris Murphy
1:17 a.m.
On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote:
On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
> In what way is it incompatible with UEFI Secure Boot?
Secure Boot does boot verification. Hibernation right now doesn't. And
that makes it a Secure Boot loophole. And that makes it incompatible
with Secure Boot.
It's not a new idea, it's been this way for a while. And so have the
complaints. https://lwn.net/Articles/523367/
<If the kernel and
> initramfs are signed, and the resume image is for that kernel, how is this
> an issue?
The initramfs is not signed.
> What if swap is on LUKS?
No signature. No integrity. It is a net reduction in the protection
provided by Secure Boot - e.g. it can't detect intentional corruption
that could crash the system or even cause more corruption and eventual
data loss as the system runs.
> If kernel lockdown is what disables this, we should look at fixing kernel
> lockdown so that it doesn't break hibernation. This is definitely a
> security decision that we shouldn't be imposing on the masses
> needlessly, in my opinion.
Instead you propose imposing a loophole for attackers to easily deploy
malware needlessly. Do you really not see how this is an untenable
position for Fedora?
In my opinion, the threat model you're proposing here is absurd. If people can
create a valid kernel image that will be loaded from a LUKS container, we have
bigger problems.
--
John M. Harris, Jr.
2:08 a.m.
On Wed, Jun 3, 2020 at 12:18 AM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote:
> On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr <johnmh(a)splentity.com>
> > If kernel lockdown is what disables this, we should look at fixing kernel
> > lockdown so that it doesn't break hibernation. This is definitely a
> > security decision that we shouldn't be imposing on the masses
> > needlessly, in my opinion.
>
>
> Instead you propose imposing a loophole for attackers to easily deploy
> malware needlessly. Do you really not see how this is an untenable
> position for Fedora?
In my opinion, the threat model you're proposing here is absurd. If people can
create a valid kernel image that will be loaded from a LUKS container, we have
bigger problems.
Disk encryption isn't enabled by default. The no encryption case
obviously has to be considered.
And if it's enabled, the more likely attack vector is sabotage to
induce a crash or corrupt user data, rather than malware injection.
Since you don't know the nature of the attack, and neither do I,
neither one of us knows when the corruption manifests or how.
I also don't know all of the threat models the upstream developers are
accounting for. Did you read all of the referenced lkml emails? Do you
understand why there's a preference for AES-GCM, why they want to
secure the encryption key in the TPM, and why they want to use TPM
localities? And why they wanted it all simplified as well? Which, I
think is sortof funny actually because none of it is very simple. If
you understand those concerns and still have questions, you might
consider directing your concerns upstream.
--
Chris Murphy
10:36 p.m.
On Wednesday, June 3, 2020 12:08:44 AM MST Chris Murphy wrote:
On Wed, Jun 3, 2020 at 12:18 AM John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
>
>
> On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote:
>
> > On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr <johnmh(a)splentity.com>
>
>
>
> > > If kernel lockdown is what disables this, we should look at fixing
> > > kernel
> > > lockdown so that it doesn't break hibernation. This is definitely a
> > > security decision that we shouldn't be imposing on the masses
> > > needlessly, in my opinion.
> >
> >
> >
> >
> > Instead you propose imposing a loophole for attackers to easily deploy
> > malware needlessly. Do you really not see how this is an untenable
> > position for Fedora?
>
>
>
> In my opinion, the threat model you're proposing here is absurd. If people
> can create a valid kernel image that will be loaded from a LUKS
> container, we have bigger problems.
Disk encryption isn't enabled by default. The no encryption case
obviously has to be considered.
In my opinion, it's already considered. With no disk encryption, it could work
just as it does on every system without Secure Boot.
And if it's enabled, the more likely attack vector is sabotage
to
induce a crash or corrupt user data, rather than malware injection.
Since you don't know the nature of the attack, and neither do I,
neither one of us knows when the corruption manifests or how.
That would require physical access to begin with, and there are much more
interesting things you can do once you have physical access. On all desktop
systems I've used both personally and in enterprise rollouts, there are pins
you can short to give yourself access to the firmware configuration. Even
where there's "intrusion detection" and similar here, you can just delete
those records after getting in. At that point, you could replace any point of
the boot process, even potentially putting something like your own ME/AMT in.
Laptops often have pads that function in the same way. The physical access
requirement to abuse this means that it'd only affect specific enterprise
clients, and generally would not be in the threat model of end users of
Fedora. Once you have physical access, you can do a lot with any system.
I also don't know all of the threat models the upstream
developers are
accounting for. Did you read all of the referenced lkml emails? Do you
understand why there's a preference for AES-GCM, why they want to
secure the encryption key in the TPM, and why they want to use TPM
localities? And why they wanted it all simplified as well? Which, I
think is sortof funny actually because none of it is very simple. If
you understand those concerns and still have questions, you might
consider directing your concerns upstream.
I don't understand why, or where, there's a preference for AES-GCM. If you're
talking about using that for the boot image, you're just putting another key
the user is going to have to enter in front of them, which you've previously
complained about. Simply placing the key in the TPM is a bad idea, because
that leads to the exact same issue described above with physical access. While
it's true some implementations wipe the TPM when you reset the boot firmware's
settings, most do not. At that point, you've got the key from the TPM, you've
got the key needed to decrypt the image and you're now able to get to the data
on that system.
--
John M. Harris, Jr.
11:05 p.m.
On Wed, Jun 3, 2020 at 9:37 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Wednesday, June 3, 2020 12:08:44 AM MST Chris Murphy wrote:
> And if it's enabled, the more likely attack vector is
sabotage to
> induce a crash or corrupt user data, rather than malware injection.
> Since you don't know the nature of the attack, and neither do I,
> neither one of us knows when the corruption manifests or how.
That would require physical access to begin with, and there are much more
interesting things you can do once you have physical access.
Physical access is the topic. That is indicated in a UEFI Secure Boot
context as it's intended to protect against evil maid attack. While
bootloader malware (or bootkits) aren't only deployed by physical
access, it's perhaps Exhibit 1 example wise anyway.
On all desktop
systems I've used both personally and in enterprise rollouts, there are pins
you can short to give yourself access to the firmware configuration.
UEFI Secure Boot doesn't prevent you from gaining access to firmware
setup. It can cause some options in firmware setup to become
unavailable, e.g. compatibility support modules for presenting a
legacy BIOS. I'm skeptical that pin shorts permit you to gain access
to such things - but if so, it's clearly a vulnerability that should
be reported.
I don't understand why, or where, there's a preference for
AES-GCM. If you're
talking about using that for the boot image, you're just putting another key
the user is going to have to enter in front of them, which you've previously
complained about. Simply placing the key in the TPM is a bad idea, because
that leads to the exact same issue described above with physical access. While
it's true some implementations wipe the TPM when you reset the boot firmware's
settings, most do not. At that point, you've got the key from the TPM, you've
got the key needed to decrypt the image and you're now able to get to the data
on that system.
The authenticated encryption of the hibernation image is concerned
about specific attacks. As I said already, I don't know all of the
attacks the designers are trying to mitigate. But I expect they aren't
concerned with all possible attacks, rather the specific ones in the
domain they can mitigate: pilfering the hibernation image and
extracting secrets; modification of the image to corrupt it or cause
corruption while in use in unsuspecting ways. But probably they are
not concerned about the image being restored in a particular sequence
of events to that same machine whereby the information decrypted by
the resume process should be protect by other systems - not the AE
hibernation image scheme.
No one has the key from the TPM, that is not correct - it's unsealed
in certain cases and provided to the kernel - if the attacker has that
key for some reason then some other aspect of security has failed. It
is not the responsibility of one protection scheme to protect against
all attacks simultaneously. Just like it is not the responsibility of
the AE hibernation image scheme to ensure login authentication to a
desktop shell.
--
Chris Murphy
12:36 a.m.
On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote:
UEFI Secure Boot doesn't prevent you from gaining access to
firmware
setup. It can cause some options in firmware setup to become
unavailable, e.g. compatibility support modules for presenting a
legacy BIOS. I'm skeptical that pin shorts permit you to gain access
to such things - but if so, it's clearly a vulnerability that should
be reported.
This is by design. Generally, there's a marking on the silkscreen with
something like "PWD" or "PASSWD" to mark it.
--
John M. Harris, Jr.
6:32 p.m.
On 6/4/20 1:36 AM, John M. Harris Jr wrote:
On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote:
> UEFI Secure Boot doesn't prevent you from gaining access to firmware
> setup. It can cause some options in firmware setup to become
> unavailable, e.g. compatibility support modules for presenting a
> legacy BIOS. I'm skeptical that pin shorts permit you to gain access
> to such things - but if so, it's clearly a vulnerability that should
> be reported.
This is by design. Generally, there's a marking on the silkscreen with
something like "PWD" or "PASSWD" to mark it.
I seem to remember
reading that resetting the firmware away from secure
modes also wipes the secure TPM storage, so that you effectively wipe
the machine to factory-fresh state.
6:44 p.m.
On Friday, June 5, 2020 4:32:55 PM MST Przemek Klosowski via devel wrote:
On 6/4/20 1:36 AM, John M. Harris Jr wrote:
> On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote:
>
>> UEFI Secure Boot doesn't prevent you from gaining access to firmware
>> setup. It can cause some options in firmware setup to become
>> unavailable, e.g. compatibility support modules for presenting a
>> legacy BIOS. I'm skeptical that pin shorts permit you to gain access
>> to such things - but if so, it's clearly a vulnerability that should
>> be reported.
>
> This is by design. Generally, there's a marking on the silkscreen with
> something like "PWD" or "PASSWD" to mark it.
I seem to remember reading that resetting the firmware away from secure
modes also wipes the secure TPM storage, so that you effectively wipe
the machine to factory-fresh state.
On some systems, that is the case. I've found that it's pretty rare, but I
don't have any real data to base that on, it's anecdotal. That doesn't matter
for Fedora, you can still boot the same system you installed with Secure Boot
enabled without it enabled.
--
John M. Harris, Jr.
7:31 p.m.
New subject: [External] Re: Supporting hibernation in Workstation ed., draft
1
-----Original Message-----
From: John M. Harris Jr <johnmh(a)splentity.com>
Sent: Friday, May 29, 2020 8:06 PM
On Friday, May 29, 2020 3:58:26 PM MST Chris Murphy wrote:
> Hi,
>
> Fedora Workstation working group has been investigating the working
> state of hibernation (suspend to disk) for about four months, and has
> produced a draft status report on the findings so far. Present status,
> impediments to support, and importantly, the specifics of how to
> address those impediments, are described.
>
> This is a draft, to reflect on-going work in this area. It's intended
> to be short and consumable. Suggestions welcome. I include the
> synopsis below for better visibility and list search.
>
> https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
>
> ---
>
> Synopsis:
>
> The Fedora Workstation working group recognizes hibernation can be
> useful, but due to impediments it's currently not practical to support
> it. This is a recognition of the current state of affairs, but the
> working group wishes hibernation could be relied upon, and thinks
> there is a viable approach for limited support of hibernation in the
> future. We encourage interested parties to pursue the needed
> improvements. In the meantime, given that hibernation isn't currently
> viable, the workstation WG decides that technical decisions will not
> be constrained by it. Decisions about Workstation's 'out of the box'
> configuration might conflict with the requirements of hibernation.
> There are desired enhancements to performance and security that are
> hindered by the status quo. The working group will re-evaluate when
> the significant impediments have been adequately addressed.
>
> We will support an install time means of enabling hibernation retained
> via Custom partitioning. If the user chooses to create a swap
> partition, the installer will include a resume=UUID kernel parameter
> hint so that the kernel can find the hibernation image.
I'm sorry, but this makes absolutely no sense. You can test hibernation right
now, and it will work. When you boot back up, it'll have everything just as
you left it. What systems is it broken on, those with Secure Boot? Is there
something in GNOME that has changed in the past few releases which broke
it?
I've just taken a Lenovo T500, installed GNOME Workstation and gone into
hibernation. It took about 30 seconds to boot back in, but I was right where I
left off. What exactly is broken, and for what portion of users?
I can vouch that hibernate doesn't work on a bunch of platforms (including
the three that are part of the Lenovo+Fedora release). This is with secure
boot disabled, big enough swap etc. On my X1C7 the device just shuts down
and then it's as if you power cycled it when you power on again.
I started poking at it a bit (we even have a RH bug somewhere) but in the
end have gone with "hibernate isn't supported" as the way forward.
Happy to help with the exercise if there are any pointers or data needed,
guineau pig for testing etc. I didn't make much progress the last time I
looked at it š I haven't seen much customer demand for it to be
honest - but I appreciate the reasons why some would like it.
Mark
5:01 a.m.
New subject: [External] Re: Supporting hibernation in Workstation ed., draft
1
On Sat, May 30, 2020 at 12:31:26AM +0000, Mark Pearson wrote:
> I've just taken a Lenovo T500, installed GNOME Workstation
and gone into
> hibernation. It took about 30 seconds to boot back in, but I was right where I
> left off. What exactly is broken, and for what portion of users?
>
I can vouch that hibernate doesn't work on a bunch of platforms (including
the three that are part of the Lenovo+Fedora release). This is with secure
boot disabled, big enough swap etc. On my X1C7 the device just shuts down
and then it's as if you power cycled it when you power on again.
I started poking at it a bit (we even have a RH bug somewhere) but in the
end have gone with "hibernate isn't supported" as the way forward.
Can you post the bugzilla number? (Even if it is not public, at least
RH people can look at it.)
Happy to help with the exercise if there are any pointers or data
needed,
guineau pig for testing etc. I didn't make much progress the last time I
looked at it š I haven't seen much customer demand for it to be
honest - but I appreciate the reasons why some would like it.
Zbyszek
5:38 a.m.
New subject: [External] Re: Supporting hibernation in Workstation ed., draft
1
Hi
-----Original Message-----
From: Zbigniew JÄdrzejewski-Szmek <zbyszek(a)in.waw.pl>
Sent: Sunday, May 31, 2020 6:01 AM
On Sat, May 30, 2020 at 12:31:26AM +0000, Mark Pearson wrote:
> > I've just taken a Lenovo T500, installed GNOME Workstation and gone into
> > hibernation. It took about 30 seconds to boot back in, but I was right
where I
> > left off. What exactly is broken, and for what portion of users?
> >
> I can vouch that hibernate doesn't work on a bunch of platforms (including
> the three that are part of the Lenovo+Fedora release). This is with secure
> boot disabled, big enough swap etc. On my X1C7 the device just shuts down
> and then it's as if you power cycled it when you power on again.
>
> I started poking at it a bit (we even have a RH bug somewhere) but in the
> end have gone with "hibernate isn't supported" as the way forward.
Can you post the bugzilla number? (Even if it is not public, at least
RH people can look at it.)
Sure:
https://bugzilla.redhat.com/show_bug.cgi?id=1768623
Should be public - it's origins were around a trackpad issue during hibernate.
It's possible the problem is still there - we haven't reproduced it yet though.
Mark
4:24 a.m.
On 30.05.2020 00:58, Chris Murphy wrote:
We will support an install time means of enabling hibernation
retained
via Custom partitioning. If the user chooses to create a swap
partition, the installer will include a resume=UUID kernel parameter
hint so that the kernel can find the hibernation image.
I think, it will be okay, but only if user don't use LUKS full-disk
encryption.
Using an unencrypted swap is a serious security breach. Anyone can
extract LUKS passphrase from it.
N.B. Fedora has major issues with resuming from encrypted swap partitions.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:51 a.m.
On Sat, 30 May 2020 at 11:32, Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 30.05.2020 00:58, Chris Murphy wrote:
> We will support an install time means of enabling hibernation retained
> via Custom partitioning. If the user chooses to create a swap
> partition, the installer will include a resume=UUID kernel parameter
> hint so that the kernel can find the hibernation image.
I think, it will be okay, but only if user don't use LUKS full-disk
encryption.
Using an unencrypted swap is a serious security breach. Anyone can
extract LUKS passphrase from it.
N.B. Fedora has major issues with resuming from encrypted swap partitions.
What are the issues? I have full-disk encryption and
suspend-then-hibernate enabled (with secure boot disabled, of course),
and it resumes from hibernation without issues.
--
IƱaki Ćcar
5:42 a.m.
On 30.05.2020 11:51, IƱaki Ucar wrote:
What are the issues? I have full-disk encryption and
suspend-then-hibernate enabled (with secure boot disabled, of course),
and it resumes from hibernation without issues.
Do you have encrypted by LUKS swap partition?
Fedora cannot resume from encrypted by random passphrase (parameter tmp
from crypttab) swap partition.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:50 a.m.
Vitaly Zaitsev via devel wrote on Sat, May 30, 2020:
On 30.05.2020 11:51, IƱaki Ucar wrote:
> What are the issues? I have full-disk encryption and
> suspend-then-hibernate enabled (with secure boot disabled, of course),
> and it resumes from hibernation without issues.
Do you have encrypted by LUKS swap partition?
Fedora cannot resume from encrypted by random passphrase (parameter tmp
from crypttab) swap partition.
Well, yes, how do you expect that to possibly ever work? You'd need to
somehow tell the initrd to not regenerate a new luks key but instead
enter manually the old random one that you would have meticulously
copied out before going into hibernation.
If your swap is in a luks partition with a static passphrase (and
secureboot is disabled) then hibernate works just fine.
(my laptop wakes up on low power from sleep and switches to hibernate
automatically if it stays on suspend too long, this is quite awesome and
I think off-the-box behaviour for this machine. Wouldn't need that if
the battery wouldn't leak so much when in sleep in the first place,
admitedly, but I haven't had any recent laptop that could stay in sleep
mode for a week unfortunately :/)
--
Dominique
5:59 a.m.
On Sat, 30 May 2020 at 12:57, Dominique Martinet <asmadeus(a)codewreck.org> wrote:
Vitaly Zaitsev via devel wrote on Sat, May 30, 2020:
> On 30.05.2020 11:51, IƱaki Ucar wrote:
> > What are the issues? I have full-disk encryption and
> > suspend-then-hibernate enabled (with secure boot disabled, of course),
> > and it resumes from hibernation without issues.
>
> Do you have encrypted by LUKS swap partition?
>
> Fedora cannot resume from encrypted by random passphrase (parameter tmp
> from crypttab) swap partition.
Well, yes, how do you expect that to possibly ever work? You'd need to
somehow tell the initrd to not regenerate a new luks key but instead
enter manually the old random one that you would have meticulously
copied out before going into hibernation.
If your swap is in a luks partition with a static passphrase (and
secureboot is disabled) then hibernate works just fine.
(my laptop wakes up on low power from sleep and switches to hibernate
automatically if it stays on suspend too long, this is quite awesome and
I think off-the-box behaviour for this machine. Wouldn't need that if
the battery wouldn't leak so much when in sleep in the first place,
admitedly, but I haven't had any recent laptop that could stay in sleep
mode for a week unfortunately :/)
Exactly. Same here.
--
IƱaki Ćcar
7:40 a.m.
On 2020-05-30 12:59, IƱaki Ucar wrote:
> If your swap is in a luks partition with a static passphrase
(and
> secureboot is disabled) then hibernate works just fine.
Actually, I can tell that a swap partition as an LVM volume living on a luks
encrypted PV works perfectly fine.
Regards.
--
Roberto Ragusa mail at robertoragusa.it
6:26 a.m.
On 30.05.2020 12:50, Dominique Martinet wrote:
Well, yes, how do you expect that to possibly ever work?
TPM chip maybe.
If your swap is in a luks partition with a static passphrase (and
secureboot is disabled) then hibernate works just fine.
Great. The Fedora installer must create an encrypted swap if the user
has selected LUKS encryption for at least of one partition.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:34 a.m.
On Sat, 30 May 2020 00:58:26 +0200, Chris Murphy wrote:
The Fedora Workstation working group recognizes hibernation can be
useful, but due to impediments it's currently not practical to support
it.
TL;DR let's go the s2idle way as that is the only one which may work. But for
me it resumes immediately again (similar to the "suspend" Bugs below).
Also I had to do 'echo freeze >/sys/power/state' for s2idle as systemctl has
no such option (nor there is any GUI option for s3idle AFAIK).
------------------------------------------------------------------------------
The problem is "suspend" depends on computer BIOS, sometimes it does not work
and due to the BIOS it is difficult/impossible to debug:
Kernel fails to suspend due to rmi_smbus
https://bugzilla.redhat.com/show_bug.cgi?id=1480602
Cannot successfully suspend, machine starts again after a few seconds
https://bugzilla.redhat.com/show_bug.cgi?id=1781566
Bugs in "suspend" are also mentioned in the first article about "S3":
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
I agree hibernation also sometimes does not work for me (in 20% cases it just
suddenly reboots during resuming); X1 Carbon 6th gen (Red Hat one).
Having both suspend & resume was useful one had a chance at least one of them
works sometimes. If the 'out of the box' installations will no longer offer
the hibernation option it means less compatibility with hardware.
Jan
4:58 a.m.
On Sat, May 30, 2020 at 11:34:38AM +0200, Jan Kratochvil wrote:
Also I had to do 'echo freeze >/sys/power/state' for
s2idle as systemctl has
no such option (nor there is any GUI option for s3idle AFAIK).
SuspendState=freeze can be set through a configuration file.
See systemd-sleep.conf(5).
Zbyszek
1418
days inactive
1425
days old
50 comments
16 participants
participants (16)
-
Chris Murphy -
Dominique Martinet -
IƱaki Ucar -
Jan Kratochvil -
John M. Harris Jr -
Marius Schwarz -
Mark Pearson -
Michael Catanzaro -
Przemek Klosowski -
Roberto Ragusa -
Samuel Sieb -
Simo Sorce -
stan -
Tony Nelson -
Vitaly Zaitsev -
Zbigniew JÄdrzejewski-Szmek