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
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
On Thu, 4 Jun 2020 13:01:37 -0600
Chris Murphy 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
On Thu, Jun 4, 2020 at 11:58 AM stan via devel
wrote:
>
> On Thu, 4 Jun 2020 10:13:59 -0600
> Chris Murphy 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
On Thu, 4 Jun 2020 10:13:59 -0600
Chris Murphy 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
On Thu, Jun 4, 2020 at 4:03 AM Marius Schwarz 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,
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
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
On Wed, Jun 3, 2020 at 9:37 PM John M. Harris Jr 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
On Wed, Jun 3, 2020 at 9:30 PM John M. Harris Jr 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
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
> 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
> >
> >
> >
> > > > If kernel lockdown
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 wrote:
> > >
> > >
> > > >
> > > > I would expect
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 Wed, 2020-06-03 at 15:31 -0600, Chris Murphy wrote:
> On Wed, Jun 3, 2020 at 1:07 PM 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 wrote:
>
On Wed, Jun 3, 2020 at 1:07 PM 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 wrote:
> > >
> > > >
> > > > I would expect that using an encrypted
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 wrote:
> >
> > >
> > > I would expect that using an encrypted partition for swap should be
> > > sufficient to allow it
On Wed, Jun 3, 2020 at 12:18 AM John M. Harris Jr 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
>
> > > If kernel lockdown is what disables this, we should look at fixing kernel
> > > lockdown so that it doesn't break
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
> 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
On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr 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,
On Tue, Jun 2, 2020 at 10:35 PM Samuel Sieb wrote:
>
> On 6/2/20 9:25 PM, Chris Murphy wrote:
> > On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr
> > 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
> >>> 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 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
On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb 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
On 6/2/20 9:25 PM, Chris Murphy wrote:
On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr 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
wrote:
On 20-05-30 21:02:11, Chris Murphy wrote:
...
Full disk encryption doesn't
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
On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr 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
> > wrote:
> >
> > >
> > >
> > > On 20-05-30 21:02:11, Chris Murphy wrote:
> > >
> > > ...
> > >
> > > > Full disk encryption
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
> 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
> > >
>
>
>
> > > >You can test
On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:
> On Sat, May 30, 2020 at 9:26 PM Tony Nelson
> wrote:
>
> >
> >
> > On 20-05-30 21:02:11, Chris Murphy wrote:
> >
> > ...
> >
> > > Full disk encryption doesn't adequately secure the hibernation image
> > > either. Authenticated
On Sat, May 30, 2020 at 9:26 PM Tony Nelson
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
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.
--
Hi
> -Original Message-
> From: Zbigniew Jędrzejewski-Szmek
> Sent: Sunday, May 31, 2020 6:01 AM
>
> On Sat, May 30, 2020 at 12:31:26AM +, Mark Pearson wrote:
> > > I've just taken a Lenovo T500, installed GNOME Workstation and gone into
> > > hibernation. It took about 30 seconds
On Sat, May 30, 2020 at 12:31:26AM +, 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?
>
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).
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
On Sat, May 30, 2020 at 5:46 PM Marius Schwarz 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
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
On Sat, May 30, 2020 at 4:23 pm, Chris Murphy
wrote:
I only see it in the "Power Button Action" menu.
OK... I stand corrected.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Sat, May 30, 2020 at 8:53 AM Michael Catanzaro wrote:
>
> On Sat, May 30, 2020 at 1:36 am, Chris Murphy
> 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
On Sat, May 30, 2020 at 1:36 am, Chris Murphy
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
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
On Sat, 30 May 2020 at 12:57, Dominique Martinet 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),
> > >
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
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
On Sat, 30 May 2020 at 11:32, Vitaly Zaitsev via devel
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
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
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
On Fri, May 29, 2020 at 9:12 PM John M. Harris Jr 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
> > >You can test hibernation right
> > > now, and it will work. When you boot back up, it'll have everything just
> > >
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
> 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
> -Original Message-
> From: John M. Harris Jr
> 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
On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr 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
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
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
51 matches
Mail list logo
