* Re: [PATCH 1/3] crypto: dcp - Use devm_ioremap_resource()
From: Herbert Xu @ 2013-09-23 20:09 UTC (permalink / raw)
To: Fabio Estevam; +Cc: tobias.rauter, linux-crypto, Fabio Estevam
In-Reply-To: <1379871747-17570-1-git-send-email-festevam@gmail.com>
On Sun, Sep 22, 2013 at 02:42:25PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Using devm_ioremap_resource() can make the code simpler and smaller.
>
> When devm_ioremap_resource() is used there is no need to explicitely check the
> error returned by platform_get_resource().
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: dcp: Check the return value from devm_ioremap_resource()
From: Fabio Estevam @ 2013-09-23 21:12 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
devm_ioremap_resource() may fail, so better check its return value and propagate
it in the case of error.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/crypto/dcp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 7b77c84..247ab80 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -734,6 +734,8 @@ static int dcp_probe(struct platform_device *pdev)
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev->dcp_regs_base = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(dev->dcp_regs_base))
+ return PTR_ERR(dev->dcp_regs_base);
dcp_set(dev, DCP_CTRL_SFRST, DCP_REG_CTRL);
udelay(10);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v4] crypto: caam - map src buffer before access
From: Horia Geantă @ 2013-09-24 9:07 UTC (permalink / raw)
To: Kim Phillips; +Cc: yashpal.dutta, linux-crypto, stable
In-Reply-To: <20130923135134.23a7462d143b8e2a1f0cc165@linaro.org>
On 9/23/2013 9:51 PM, Kim Phillips wrote:
> On Sat, 21 Sep 2013 14:26:35 +0530
> Yashpal Dutta <yashpal.dutta@freescale.com> wrote:
>
>> KMap the buffers before copying trailing bytes during hmac into a session
>> temporary buffer. This is required if pinned buffer from user-space is send
>> during hmac and is safe even if hmac request is generated from within kernel.
> it may be "safe" but it adversely affects performance for AF_ALG users,
> no?
>
> why does ocf-linux need this, and not AF_ALG? Is a patch to ocf-linux
> more appropriate here?
SW hashing (crypto/ahash.c, crypto/shash.c) do the kmap/kunmap.
Crypto engine drivers should do this too. Either by themselves or
(probably better) try to use existing support in crypto/scatterwalk.c
At the interface level, AF_ALG issues get_user_pages via
af_alg_make_sg(), similar to what ocf-linux does.
>
>> Cc:stable@vger.kernel.org
> fyi, this violates the following rule in
> Documentation/stable_kernel_rules.txt:
>
> - It or an equivalent fix must already exist in Linus' tree (upstream).
AFAICT, rules are more flexible, at least that's my understanding.
Adding a Cc:stable in the signed-off area is more convenient, since it
provides for automatic inclusion in -stable tree (once patch reaches
Linus' tree):
- To have the patch automatically included in the stable tree, add the tag
Cc: stable@vger.kernel.org
in the sign-off area. Once the patch is merged it will be applied to
the stable tree without anything else needing to be done by the author
or subsystem maintainer.
Horia
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: David Howells @ 2013-09-25 21:04 UTC (permalink / raw)
To: Lee, Chun-Yi
Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
opensuse-kernel-stAJ6ESoqRxg9hUCZPvPmw, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH,
JKosina-IBi9RG/b67k, Rusty Russell, Herbert Xu, David S. Miller,
H. Peter Anvin, Michal Marek, Gary Lin, Vivek Goyal,
Lee, Chun-Yi
In-Reply-To: <1379206621-18639-1-git-send-email-jlee-IBi9RG/b67k@public.gmane.org>
I have pushed some keyrings patches that will likely affect this to:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
I intend to ask James to pull these into his next branch. If he's happy to do
so, I can look at pulling at least your asymmetric keys patch on top of them.
It'd be helpful if you could see if you need to make any updates.
David
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: Alan Stern @ 2013-09-25 21:25 UTC (permalink / raw)
To: David Howells
Cc: Lee, Chun-Yi, linux-kernel, linux-security-module, linux-efi,
linux-pm, linux-crypto, opensuse-kernel, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal, Lee, Chun-Yi
In-Reply-To: <29408.1380143073@warthog.procyon.org.uk>
On Wed, 25 Sep 2013, David Howells wrote:
> I have pushed some keyrings patches that will likely affect this to:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
> I intend to ask James to pull these into his next branch. If he's happy to do
> so, I can look at pulling at least your asymmetric keys patch on top of them.
This suggests a point that I raised at the Linux Plumbers conference:
Why are asymmetric keys used for verifying the hibernation image? It
seems that a symmetric key would work just as well. And it would be a
lot quicker to generate, because it wouldn't need any high-precision
integer computations.
Alan Stern
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: James Bottomley @ 2013-09-25 22:16 UTC (permalink / raw)
To: Alan Stern
Cc: David Howells, Lee, Chun-Yi, linux-kernel, linux-security-module,
linux-efi, linux-pm, linux-crypto, opensuse-kernel,
Rafael J. Wysocki, Matthew Garrett, Len Brown, Pavel Machek,
Josh Boyer, Vojtech Pavlik, Matt Fleming, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal, Lee, Chun-Yi
In-Reply-To: <Pine.LNX.4.44L0.1309251723001.26508-100000@netrider.rowland.org>
On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask James to pull these into his next branch. If he's happy to do
> > so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> This suggests a point that I raised at the Linux Plumbers conference:
>
> Why are asymmetric keys used for verifying the hibernation image? It
> seems that a symmetric key would work just as well. And it would be a
> lot quicker to generate, because it wouldn't need any high-precision
> integer computations.
The reason is the desire to validate that the previous kernel created
something which it passed on to the current kernel (in this case, the
hibernation image) untampered with. To do that, something must be
passed to the prior kernel that can be validated but *not* recreated by
the current kernel.
The scheme for doing this is a public/private key pair generated for
each boot incarnation N as a pair P_N (public key) and K_N (private
key). Then the Nth boot incarnation gets P_{N-1} and K_N (the boot
environment holds P_N in inaccessible BS variables for passing into the
next kernel) so the Nth kernel can validate information from the N-1th
kernel using P_{N-1} and create information for passing on in a
validated fashion to the next kernel using K_N.
This scheme doesn't work with symmetric keys unless you have a
modification I haven't seen?
James
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: Pavel Machek @ 2013-09-26 0:27 UTC (permalink / raw)
To: James Bottomley
Cc: Alan Stern, David Howells, Lee, Chun-Yi,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
opensuse-kernel-stAJ6ESoqRxg9hUCZPvPmw, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Josh Boyer, Vojtech Pavlik,
Matt Fleming, Greg KH, JKosina-IBi9RG/b67k, Rusty Russell,
Herbert Xu, David S. Miller, H. Peter Anvin, Michal Marek,
Gary Lin, Vivek Goyal, Lee, Chun-Yi
In-Reply-To: <1380147414.18835.36.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> > On Wed, 25 Sep 2013, David Howells wrote:
> >
> > > I have pushed some keyrings patches that will likely affect this to:
> > >
> > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> > >
> > > I intend to ask James to pull these into his next branch. If he's happy to do
> > > so, I can look at pulling at least your asymmetric keys patch on top of them.
> >
> > This suggests a point that I raised at the Linux Plumbers conference:
> >
> > Why are asymmetric keys used for verifying the hibernation image? It
> > seems that a symmetric key would work just as well. And it would be a
> > lot quicker to generate, because it wouldn't need any high-precision
> > integer computations.
>
> The reason is the desire to validate that the previous kernel created
> something which it passed on to the current kernel (in this case, the
> hibernation image) untampered with. To do that, something must be
> passed to the prior kernel that can be validated but *not* recreated by
> the current kernel.
I don't get this. Why is it important that current kernel can't
recreate the signature?
Current kernel is not considered malicious (if it were, you have worse
problems).
Pavel
PS: And yes, it would be nice to have
Documentation/power/swsusp-uefi.txt (or something) explaining the
design.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: Alan Stern @ 2013-09-26 1:11 UTC (permalink / raw)
To: James Bottomley
Cc: David Howells, Lee, Chun-Yi, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
opensuse-kernel-stAJ6ESoqRxg9hUCZPvPmw, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, Greg KH, JKosina-IBi9RG/b67k,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal, Lee, Chun-Yi
In-Reply-To: <1380147414.18835.36.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
On Wed, 25 Sep 2013, James Bottomley wrote:
> > Why are asymmetric keys used for verifying the hibernation image? It
> > seems that a symmetric key would work just as well. And it would be a
> > lot quicker to generate, because it wouldn't need any high-precision
> > integer computations.
>
> The reason is the desire to validate that the previous kernel created
> something which it passed on to the current kernel (in this case, the
> hibernation image) untampered with. To do that, something must be
> passed to the prior kernel that can be validated but *not* recreated by
> the current kernel.
As Pavel pointed out, this seems like a futile approach. If the
current kernel is going to do the validating, then of course it can
create something that it will validate.
Or to put it another way, how come you don't trust the current kernel
not to modify the image but you do trust it to validate the image?
> The scheme for doing this is a public/private key pair generated for
> each boot incarnation N as a pair P_N (public key) and K_N (private
> key). Then the Nth boot incarnation gets P_{N-1} and K_N (the boot
Where does it get them from? Some place in the firmware, presumably.
> environment holds P_N in inaccessible BS variables for passing into the
> next kernel) so the Nth kernel can validate information from the N-1th
> kernel using P_{N-1} and create information for passing on in a
> validated fashion to the next kernel using K_N.
So kernel N gets P_{N-1} and an image that has been signed by K_{N-1}.
What's to prevent kernel N from creating a bogus pair of keys (K',P')
and a bogus image, signing that image with K', and then pretending it
got P' from the firmware instead of P_{N-1}?
However... Let's assume that you _do_ trust kernel N. Then consider
this alternative approach:
A symmetric key S_N is created for boot incarnation N. Kernel N
receives S_{N-1} from the firmware and uses it to verify the signature
attached to the hibernation image. When kernel N wants to create the
next hibernation image, it signs the image with S_N (also obtained
from the firmware).
> This scheme doesn't work with symmetric keys unless you have a
> modification I haven't seen?
Obviously these two schemes are different. Do these differences have
any security implications?
Alan Stern
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 1:36 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
opensuse-kernel-stAJ6ESoqRxg9hUCZPvPmw, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH,
JKosina-IBi9RG/b67k, Rusty Russell, Herbert Xu, David S. Miller,
H. Peter Anvin, Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <29408.1380143073-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
於 三，2013-09-25 於 22:04 +0100，David Howells 提到：
> I have pushed some keyrings patches that will likely affect this to:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
Thanks for your point out, I will respin my asymmetric keys patch base
on this tree.
> I intend to ask James to pull these into his next branch. If he's happy to do
> so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> It'd be helpful if you could see if you need to make any updates.
>
> David
>
In LPC, Alan and Vojtech raised another thinking is using symmetric key
to protect the hash of snapshot. It's simpler then using RSA private key
to sign it.
Even finally we use the symmetric key solution, I will still respin and
resent the patch for add the leading zero byte:
[PATCH V4 07/15] asymmetric keys: explicitly add the leading zero byte
to encoded message
I think keys-devel tree need it.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 1:36 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, Rafael J. Wysocki, Matthew Garrett,
Len Brown, Pavel Machek, Josh Boyer, Vojtech Pavlik, Matt Fleming,
James Bottomley, Greg KH, JKosina, Rusty Russell, Herbert Xu,
David S. Miller, H. Peter Anvin, Michal Marek, Gary Lin,
Vivek Goyal
In-Reply-To: <29408.1380143073@warthog.procyon.org.uk>
於 三，2013-09-25 於 22:04 +0100，David Howells 提到：
> I have pushed some keyrings patches that will likely affect this to:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
Thanks for your point out, I will respin my asymmetric keys patch base
on this tree.
> I intend to ask James to pull these into his next branch. If he's happy to do
> so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> It'd be helpful if you could see if you need to make any updates.
>
> David
>
In LPC, Alan and Vojtech raised another thinking is using symmetric key
to protect the hash of snapshot. It's simpler then using RSA private key
to sign it.
Even finally we use the symmetric key solution, I will still respin and
resent the patch for add the leading zero byte:
[PATCH V4 07/15] asymmetric keys: explicitly add the leading zero byte
to encoded message
I think keys-devel tree need it.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 1:36 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, Rafael J. Wysocki, Matthew Garrett,
Len Brown, Pavel Machek, Josh Boyer, Vojtech Pavlik, Matt Fleming,
James Bottomley, Greg KH, JKosina, Rusty Russell, Herbert Xu,
David S. Miller, H. Peter Anvin, Michal Marek, Gary Lin,
Vivek Goyal
In-Reply-To: <29408.1380143073@warthog.procyon.org.uk>
於 三，2013-09-25 於 22:04 +0100，David Howells 提到：
> I have pushed some keyrings patches that will likely affect this to:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
Thanks for your point out, I will respin my asymmetric keys patch base
on this tree.
> I intend to ask James to pull these into his next branch. If he's happy to do
> so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> It'd be helpful if you could see if you need to make any updates.
>
> David
>
In LPC, Alan and Vojtech raised another thinking is using symmetric key
to protect the hash of snapshot. It's simpler then using RSA private key
to sign it.
Even finally we use the symmetric key solution, I will still respin and
resent the patch for add the leading zero byte:
[PATCH V4 07/15] asymmetric keys: explicitly add the leading zero byte
to encoded message
I think keys-devel tree need it.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 1:36 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, Rafael J. Wysocki, Matthew Garrett,
Len Brown, Pavel Machek, Josh Boyer, Vojtech Pavlik, Matt Fleming,
James Bottomley, Greg KH, JKosina, Rusty Russell, Herbert Xu,
David S. Miller, H. Peter Anvin, Michal Marek, Gary Lin,
Vivek Goyal
In-Reply-To: <29408.1380143073@warthog.procyon.org.uk>
於 三，2013-09-25 於 22:04 +0100，David Howells 提到：
> I have pushed some keyrings patches that will likely affect this to:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
Thanks for your point out, I will respin my asymmetric keys patch base
on this tree.
> I intend to ask James to pull these into his next branch. If he's happy to do
> so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> It'd be helpful if you could see if you need to make any updates.
>
> David
>
In LPC, Alan and Vojtech raised another thinking is using symmetric key
to protect the hash of snapshot. It's simpler then using RSA private key
to sign it.
Even finally we use the symmetric key solution, I will still respin and
resent the patch for add the leading zero byte:
[PATCH V4 07/15] asymmetric keys: explicitly add the leading zero byte
to encoded message
I think keys-devel tree need it.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 1:36 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, Rafael J. Wysocki, Matthew Garrett,
Len Brown, Pavel Machek, Josh Boyer, Vojtech Pavlik, Matt Fleming,
James Bottomley, Greg KH, JKosina, Rusty Russell, Herbert Xu,
David S. Miller, H. Peter Anvin, Michal Marek, Gary Lin,
Vivek Goyal
In-Reply-To: <29408.1380143073@warthog.procyon.org.uk>
於 三，2013-09-25 於 22:04 +0100，David Howells 提到：
> I have pushed some keyrings patches that will likely affect this to:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
Thanks for your point out, I will respin my asymmetric keys patch base
on this tree.
> I intend to ask James to pull these into his next branch. If he's happy to do
> so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> It'd be helpful if you could see if you need to make any updates.
>
> David
>
In LPC, Alan and Vojtech raised another thinking is using symmetric key
to protect the hash of snapshot. It's simpler then using RSA private key
to sign it.
Even finally we use the symmetric key solution, I will still respin and
resent the patch for add the leading zero byte:
[PATCH V4 07/15] asymmetric keys: explicitly add the leading zero byte
to encoded message
I think keys-devel tree need it.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
From: joeyli @ 2013-09-26 1:43 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, David Howells, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Josh Boyer, Vojtech Pavlik,
Matt Fleming, James Bottomley, Greg KH, JKosina, Rusty Russell,
Herbert Xu, David S. Miller, H. Peter Anvin, Michal Marek,
Gary Lin, Vivek Goyal
In-Reply-To: <20130918134535.GA3748@amd.pavel.ucw.cz>
於 三，2013-09-18 於 15:45 +0200，Pavel Machek 提到：
> On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > hash algorithm will be used during signature generation of snapshot.
>
> This series is big enough already... and who is going to test it?
The hash config not just for testing, it's relate to the performance and
secure between different hash algorithms.
There have person raised in LPC say he don't like SHA algorithm.
> There's no need to make hash configurable. Just select one that works.
>
> Pavel
>
SHA1 has good performance, and SHA512 has better security, which one you
like it?
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
From: joeyli @ 2013-09-26 1:43 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, David Howells, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Josh Boyer, Vojtech Pavlik,
Matt Fleming, James Bottomley, Greg KH, JKosina, Rusty Russell,
Herbert Xu, David S. Miller, H. Peter Anvin, Michal Marek,
Gary Lin, Vivek Goyal
In-Reply-To: <20130918134535.GA3748@amd.pavel.ucw.cz>
於 三，2013-09-18 於 15:45 +0200，Pavel Machek 提到：
> On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > hash algorithm will be used during signature generation of snapshot.
>
> This series is big enough already... and who is going to test it?
The hash config not just for testing, it's relate to the performance and
secure between different hash algorithms.
There have person raised in LPC say he don't like SHA algorithm.
> There's no need to make hash configurable. Just select one that works.
>
> Pavel
>
SHA1 has good performance, and SHA512 has better security, which one you
like it?
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
From: joeyli @ 2013-09-26 1:43 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
opensuse-kernel-stAJ6ESoqRxg9hUCZPvPmw, David Howells,
Rafael J. Wysocki, Matthew Garrett, Len Brown, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH,
JKosina-IBi9RG/b67k, Rusty Russell, Herbert Xu, David S. Miller,
H. Peter Anvin, Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130918134535.GA3748-tWAi6jLit6GreWDznjuHag@public.gmane.org>
於 三，2013-09-18 於 15:45 +0200，Pavel Machek 提到：
> On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > hash algorithm will be used during signature generation of snapshot.
>
> This series is big enough already... and who is going to test it?
The hash config not just for testing, it's relate to the performance and
secure between different hash algorithms.
There have person raised in LPC say he don't like SHA algorithm.
> There's no need to make hash configurable. Just select one that works.
>
> Pavel
>
SHA1 has good performance, and SHA512 has better security, which one you
like it?
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
From: joeyli @ 2013-09-26 1:43 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, David Howells, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Josh Boyer, Vojtech Pavlik,
Matt Fleming, James Bottomley, Greg KH, JKosina, Rusty Russell,
Herbert Xu, David S. Miller, H. Peter Anvin, Michal Marek,
Gary Lin, Vivek Goyal
In-Reply-To: <20130918134535.GA3748@amd.pavel.ucw.cz>
於 三，2013-09-18 於 15:45 +0200，Pavel Machek 提到：
> On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > hash algorithm will be used during signature generation of snapshot.
>
> This series is big enough already... and who is going to test it?
The hash config not just for testing, it's relate to the performance and
secure between different hash algorithms.
There have person raised in LPC say he don't like SHA algorithm.
> There's no need to make hash configurable. Just select one that works.
>
> Pavel
>
SHA1 has good performance, and SHA512 has better security, which one you
like it?
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
From: joeyli @ 2013-09-26 1:43 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, David Howells, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Josh Boyer, Vojtech Pavlik,
Matt Fleming, James Bottomley, Greg KH, JKosina, Rusty Russell,
Herbert Xu, David S. Miller, H. Peter Anvin, Michal Marek,
Gary Lin, Vivek Goyal
In-Reply-To: <20130918134535.GA3748@amd.pavel.ucw.cz>
於 三，2013-09-18 於 15:45 +0200，Pavel Machek 提到：
> On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > hash algorithm will be used during signature generation of snapshot.
>
> This series is big enough already... and who is going to test it?
The hash config not just for testing, it's relate to the performance and
secure between different hash algorithms.
There have person raised in LPC say he don't like SHA algorithm.
> There's no need to make hash configurable. Just select one that works.
>
> Pavel
>
SHA1 has good performance, and SHA512 has better security, which one you
like it?
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 2:19 UTC (permalink / raw)
To: Alan Stern
Cc: David Howells, linux-kernel, linux-security-module, linux-efi,
linux-pm, linux-crypto, opensuse-kernel, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <Pine.LNX.4.44L0.1309251723001.26508-100000@netrider.rowland.org>
於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到：
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask James to pull these into his next branch. If he's happy to do
> > so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> This suggests a point that I raised at the Linux Plumbers conference:
>
> Why are asymmetric keys used for verifying the hibernation image? It
> seems that a symmetric key would work just as well. And it would be a
> lot quicker to generate, because it wouldn't need any high-precision
> integer computations.
>
> Alan Stern
>
>
Per my understood, it's like add salt to snapshot when generate
signature, then remove the salt when store the snapshot to swap. (or
pass snapshot to userland).
Let me explain the symmetric key solution base on my understand:
+ EFI stub kernel generate a hash value from a random seed, then store
it to EFi boot varaible. It should protected by UEFI secure boot
environment.
+ When hibernate launched:
- Kernel create the snapshot image of memory. It's included the
random hash value(salt) that generated in EFI stub stage.
- Then kernel hash the snapshot image, put the hash to snapshot
header, just like current asymmetric keys solution.
- Kernel erase the salt in snapshot image before it go to swap or
pass to userspace tool.
+ When hibernate resume:
- Kernel or userspace tool load the snapshot(without salt) from swap
to temporary memory space.
- Kernel fill the salt back to snapshot image in memory, hash it.
- Kernel compare the hash with the hash that put in snapshot header.
- Verification done! The follow-up action as current solution.
Please current me if I missed anything.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 2:19 UTC (permalink / raw)
To: Alan Stern
Cc: David Howells, linux-kernel, linux-security-module, linux-efi,
linux-pm, linux-crypto, opensuse-kernel, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <Pine.LNX.4.44L0.1309251723001.26508-100000@netrider.rowland.org>
於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到：
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask James to pull these into his next branch. If he's happy to do
> > so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> This suggests a point that I raised at the Linux Plumbers conference:
>
> Why are asymmetric keys used for verifying the hibernation image? It
> seems that a symmetric key would work just as well. And it would be a
> lot quicker to generate, because it wouldn't need any high-precision
> integer computations.
>
> Alan Stern
>
>
Per my understood, it's like add salt to snapshot when generate
signature, then remove the salt when store the snapshot to swap. (or
pass snapshot to userland).
Let me explain the symmetric key solution base on my understand:
+ EFI stub kernel generate a hash value from a random seed, then store
it to EFi boot varaible. It should protected by UEFI secure boot
environment.
+ When hibernate launched:
- Kernel create the snapshot image of memory. It's included the
random hash value(salt) that generated in EFI stub stage.
- Then kernel hash the snapshot image, put the hash to snapshot
header, just like current asymmetric keys solution.
- Kernel erase the salt in snapshot image before it go to swap or
pass to userspace tool.
+ When hibernate resume:
- Kernel or userspace tool load the snapshot(without salt) from swap
to temporary memory space.
- Kernel fill the salt back to snapshot image in memory, hash it.
- Kernel compare the hash with the hash that put in snapshot header.
- Verification done! The follow-up action as current solution.
Please current me if I missed anything.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 2:19 UTC (permalink / raw)
To: Alan Stern
Cc: David Howells, linux-kernel, linux-security-module, linux-efi,
linux-pm, linux-crypto, opensuse-kernel, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <Pine.LNX.4.44L0.1309251723001.26508-100000@netrider.rowland.org>
於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到：
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask James to pull these into his next branch. If he's happy to do
> > so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> This suggests a point that I raised at the Linux Plumbers conference:
>
> Why are asymmetric keys used for verifying the hibernation image? It
> seems that a symmetric key would work just as well. And it would be a
> lot quicker to generate, because it wouldn't need any high-precision
> integer computations.
>
> Alan Stern
>
>
Per my understood, it's like add salt to snapshot when generate
signature, then remove the salt when store the snapshot to swap. (or
pass snapshot to userland).
Let me explain the symmetric key solution base on my understand:
+ EFI stub kernel generate a hash value from a random seed, then store
it to EFi boot varaible. It should protected by UEFI secure boot
environment.
+ When hibernate launched:
- Kernel create the snapshot image of memory. It's included the
random hash value(salt) that generated in EFI stub stage.
- Then kernel hash the snapshot image, put the hash to snapshot
header, just like current asymmetric keys solution.
- Kernel erase the salt in snapshot image before it go to swap or
pass to userspace tool.
+ When hibernate resume:
- Kernel or userspace tool load the snapshot(without salt) from swap
to temporary memory space.
- Kernel fill the salt back to snapshot image in memory, hash it.
- Kernel compare the hash with the hash that put in snapshot header.
- Verification done! The follow-up action as current solution.
Please current me if I missed anything.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 2:19 UTC (permalink / raw)
To: Alan Stern
Cc: David Howells, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
opensuse-kernel-stAJ6ESoqRxg9hUCZPvPmw, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH,
JKosina-IBi9RG/b67k, Rusty Russell, Herbert Xu, David S. Miller,
H. Peter Anvin, Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <Pine.LNX.4.44L0.1309251723001.26508-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到：
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask James to pull these into his next branch. If he's happy to do
> > so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> This suggests a point that I raised at the Linux Plumbers conference:
>
> Why are asymmetric keys used for verifying the hibernation image? It
> seems that a symmetric key would work just as well. And it would be a
> lot quicker to generate, because it wouldn't need any high-precision
> integer computations.
>
> Alan Stern
>
>
Per my understood, it's like add salt to snapshot when generate
signature, then remove the salt when store the snapshot to swap. (or
pass snapshot to userland).
Let me explain the symmetric key solution base on my understand:
+ EFI stub kernel generate a hash value from a random seed, then store
it to EFi boot varaible. It should protected by UEFI secure boot
environment.
+ When hibernate launched:
- Kernel create the snapshot image of memory. It's included the
random hash value(salt) that generated in EFI stub stage.
- Then kernel hash the snapshot image, put the hash to snapshot
header, just like current asymmetric keys solution.
- Kernel erase the salt in snapshot image before it go to swap or
pass to userspace tool.
+ When hibernate resume:
- Kernel or userspace tool load the snapshot(without salt) from swap
to temporary memory space.
- Kernel fill the salt back to snapshot image in memory, hash it.
- Kernel compare the hash with the hash that put in snapshot header.
- Verification done! The follow-up action as current solution.
Please current me if I missed anything.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 2:19 UTC (permalink / raw)
To: Alan Stern
Cc: David Howells, linux-kernel, linux-security-module, linux-efi,
linux-pm, linux-crypto, opensuse-kernel, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Pavel Machek, Josh Boyer,
Vojtech Pavlik, Matt Fleming, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <Pine.LNX.4.44L0.1309251723001.26508-100000@netrider.rowland.org>
於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到：
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask James to pull these into his next branch. If he's happy to do
> > so, I can look at pulling at least your asymmetric keys patch on top of them.
>
> This suggests a point that I raised at the Linux Plumbers conference:
>
> Why are asymmetric keys used for verifying the hibernation image? It
> seems that a symmetric key would work just as well. And it would be a
> lot quicker to generate, because it wouldn't need any high-precision
> integer computations.
>
> Alan Stern
>
>
Per my understood, it's like add salt to snapshot when generate
signature, then remove the salt when store the snapshot to swap. (or
pass snapshot to userland).
Let me explain the symmetric key solution base on my understand:
+ EFI stub kernel generate a hash value from a random seed, then store
it to EFi boot varaible. It should protected by UEFI secure boot
environment.
+ When hibernate launched:
- Kernel create the snapshot image of memory. It's included the
random hash value(salt) that generated in EFI stub stage.
- Then kernel hash the snapshot image, put the hash to snapshot
header, just like current asymmetric keys solution.
- Kernel erase the salt in snapshot image before it go to swap or
pass to userspace tool.
+ When hibernate resume:
- Kernel or userspace tool load the snapshot(without salt) from swap
to temporary memory space.
- Kernel fill the salt back to snapshot image in memory, hash it.
- Kernel compare the hash with the hash that put in snapshot header.
- Verification done! The follow-up action as current solution.
Please current me if I missed anything.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: James Bottomley @ 2013-09-26 2:32 UTC (permalink / raw)
To: Pavel Machek
Cc: Alan Stern, David Howells, Lee, Chun-Yi,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
opensuse-kernel-stAJ6ESoqRxg9hUCZPvPmw, Rafael J. Wysocki,
Matthew Garrett, Len Brown, Josh Boyer, Vojtech Pavlik,
Matt Fleming, Greg KH, JKosina-IBi9RG/b67k, Rusty Russell,
Herbert Xu, David S. Miller, H. Peter Anvin, Michal Marek,
Gary Lin, Vivek Goyal, Lee, Chun-Yi
In-Reply-To: <20130926002730.GA26857-tWAi6jLit6GreWDznjuHag@public.gmane.org>
On Thu, 2013-09-26 at 02:27 +0200, Pavel Machek wrote:
> On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> > On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> > > On Wed, 25 Sep 2013, David Howells wrote:
> > >
> > > > I have pushed some keyrings patches that will likely affect this to:
> > > >
> > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> > > >
> > > > I intend to ask James to pull these into his next branch. If he's happy to do
> > > > so, I can look at pulling at least your asymmetric keys patch on top of them.
> > >
> > > This suggests a point that I raised at the Linux Plumbers conference:
> > >
> > > Why are asymmetric keys used for verifying the hibernation image? It
> > > seems that a symmetric key would work just as well. And it would be a
> > > lot quicker to generate, because it wouldn't need any high-precision
> > > integer computations.
> >
> > The reason is the desire to validate that the previous kernel created
> > something which it passed on to the current kernel (in this case, the
> > hibernation image) untampered with. To do that, something must be
> > passed to the prior kernel that can be validated but *not* recreated by
> > the current kernel.
>
> I don't get this. Why is it important that current kernel can't
> recreate the signature?
The thread model is an attack on the saved information (i.e. the suspend
image) between it being saved by the old kernel and used by the new one.
The important point isn't that the new kernel doesn't have access to
K_{N-1} it's that no-one does: the key is destroyed as soon as the old
kernel terminates however the verification public part P_{N-1} survives.
James
> Current kernel is not considered malicious (if it were, you have worse
> problems).
>
> Pavel
>
> PS: And yes, it would be nice to have
> Documentation/power/swsusp-uefi.txt (or something) explaining the
> design.
>
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 4:40 UTC (permalink / raw)
To: Pavel Machek
Cc: James Bottomley, Alan Stern, David Howells, linux-kernel,
linux-security-module, linux-efi, linux-pm, linux-crypto,
opensuse-kernel, Rafael J. Wysocki, Matthew Garrett, Len Brown,
Josh Boyer, Vojtech Pavlik, Matt Fleming, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926002730.GA26857@amd.pavel.ucw.cz>
於 四，2013-09-26 於 02:27 +0200，Pavel Machek 提到：
> On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> > On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> > > On Wed, 25 Sep 2013, David Howells wrote:
> > >
> > > > I have pushed some keyrings patches that will likely affect this to:
> > > >
> > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> > > >
> > > > I intend to ask James to pull these into his next branch. If he's happy to do
> > > > so, I can look at pulling at least your asymmetric keys patch on top of them.
> > >
> > > This suggests a point that I raised at the Linux Plumbers conference:
> > >
> > > Why are asymmetric keys used for verifying the hibernation image? It
> > > seems that a symmetric key would work just as well. And it would be a
> > > lot quicker to generate, because it wouldn't need any high-precision
> > > integer computations.
> >
> > The reason is the desire to validate that the previous kernel created
> > something which it passed on to the current kernel (in this case, the
> > hibernation image) untampered with. To do that, something must be
> > passed to the prior kernel that can be validated but *not* recreated by
> > the current kernel.
>
> I don't get this. Why is it important that current kernel can't
> recreate the signature?
>
> Current kernel is not considered malicious (if it were, you have worse
> problems).
>
Current boot kernel should not malicious especially when UEFI secure
boot enabled.
> Pavel
>
> PS: And yes, it would be nice to have
> Documentation/power/swsusp-uefi.txt (or something) explaining the
> design.
>
Thanks for your suggestion, I will write the swsusp-uefi.txt to
explaining the design in next version.
Thanks a lot!
Joey Lee
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox