* Re: [PATCH 3/3] ARM: mxs: dts: Enable DCP for MXS
From: Lothar Waßmann @ 2013-09-26 11:36 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-crypto, Fabio Estevam, Herbert Xu, Shawn Guo,
David S. Miller, linux-arm-kernel
In-Reply-To: <1380194306-5243-3-git-send-email-marex@denx.de>
Hi,
Marek Vasut writes:
> Enable the DCP by default on both i.MX23 and i.MX28.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> To: linux-crypto@vger.kernel.org
> ---
> arch/arm/boot/dts/imx23.dtsi | 4 +++-
> arch/arm/boot/dts/imx28.dtsi | 5 +++--
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> index 87faa6e..0630a9a 100644
> --- a/arch/arm/boot/dts/imx23.dtsi
> +++ b/arch/arm/boot/dts/imx23.dtsi
> @@ -337,8 +337,10 @@
> };
>
> dcp@80028000 {
> + compatible = "fsl,mxs-dcp";
> reg = <0x80028000 0x2000>;
> - status = "disabled";
> + interrupts = <53 54>;
> + status = "okay";
> };
AFAICT the policy seems to be that nodes, that are always enabled
don't get a 'status' property at all.
> pxp@8002a000 {
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 918d419..8b5ad60 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -782,9 +782,10 @@
> };
>
> dcp: dcp@80028000 {
> + compatible = "fsl,mxs-dcp";
> reg = <0x80028000 0x2000>;
> - interrupts = <52 53 54>;
> - compatible = "fsl-dcp";
>
What about drivers/crypto/dcp.c that is currently using this property?
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: Pavel Machek @ 2013-09-26 12:06 UTC (permalink / raw)
To: joeyli
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <1380192218.32302.69.camel@linux-s257.site>
Hi!
> For the symmetric key solution, I will try HMAC (Hash Message
> Authentication Code). It's already used in networking, hope the
> performance is not too bad to a big image.
Kernel already supports crc32 of the hibernation image, you may want
to take a look how that is done.
Maybe you want to replace crc32 with cryptographics hash (sha1?) and
then use only hash for more crypto? That way speed of whatever crypto
you do should not be an issue.
Actually...
Is not it as simple as storing hash of hibernation image into NVRAM
and then verifying the hash matches the value in NVRAM on next
startup? No encryption needed.
And that may even be useful for non-secure-boot people, as it ensures
you boot right image after resume, boot it just once, etc...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
From: Marek Vasut @ 2013-09-26 12:07 UTC (permalink / raw)
To: Fabio Estevam
Cc: linux-crypto, Herbert Xu, linux-arm-kernel@lists.infradead.org,
David S. Miller, Shawn Guo
In-Reply-To: <CAOMZO5AU_R5aeHKbkGRGuyXsVOVdUwdF5oZXdEZZYs442nFnEA@mail.gmail.com>
Dear Fabio Estevam,
> Hi Marek,
>
> On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut <marex@denx.de> wrote:
> > Add support for the MXS DCP block. The driver currently supports
> > SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
> > CRC32 is not yet supported.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > ---
> >
> > drivers/crypto/Kconfig | 17 +
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/mxs-dcp.c | 1082
> > ++++++++++++++++++++++++++++++++++++++++++++++
>
> What about the existing DCP driver at drivers/crypto/dcp.c ?
I was not aware of that one.
> Why do we need to have two drivers for the same IP block? It looks
> confusing to have both.
Sure, I agree. I reviewed the one in mainline just now and I see some
deficiencies of the dcp.c driver:
1) It only supports AES_CBC (mine does support AES_ECB, AES_CBC, SHA1 and SH256)
2) The driver was apparently never ran behind anyone working with MXS. ie.:
-> Restarting the DCP block is not done via mxs_reset_block()
-> The DT name is not "fsl,dcp" or "fsl,mxs-dcp" as other MXS drivers
3) What are those ugly new IOCTLs in the dcp.c driver?
4) The VMI IRQ is never used, yet it even calls the IRQ handler, this is bogus
-> The DCP always triggers the dcp_irq upon DMA completion
-> VMI IRQ is not handled in the handler at all as I see it
5) The IRQ handler can't use usual completion() in the driver because that'd
trigger "scheduling while atomic" oops, yes?
Finally, because the dcp.c driver only supports AES128 CBC, it depends on kernel
_always_ passing the DCP scatterlist such that each of it's elements is 16-bytes
long. If each of the elements is 16 bytes, there is no problem and the DCP will
operate correctly. That is because the DCP has the following limitations:
-> For AES128, each buffer in the DMA chain must be multiple of 16 bytes.
-> For SHA1/SHA256, each buffer in the DMA chain must by multiple of 64 bytes
BUT only the last buffer in the DMA chain can be shorter.
So, in the AES128 case, if the hardware is passed two (4 bytes + 12 bytes for
example) DMA descriptors instead of single 16 bytes descriptor, the DCP will
simply stall or produce incorrect result. This can happen if the user of the
async crypto API passes such a scatterlist.
It is true this is not caught by the in-kernel crypto tests, because they mostly
trigger the software fallback in this driver, since this driver only supports 16
byte key (klen == 16 , see crypto/testmgr.h). It can be triggered by modifying
the crypto tests so that they pass two buffers, multiple of 16 bytes in total,
but each of them not multiple of 16 bytes.
I ran into many such problems when I was developing this driver I submitted
here, I managed to trigger those by running the Cryptodev [1] tests [2] against
this driver as well as testing the performance of this driver via
Cryptodev/OpenSSL combination:
$ openssl speed sha1
$ openssl speed sha256
$ openssl speed aes-128-cbc
I also measured the performance via OpenSSL encryption/decryption. On larger
files, the performance of encryption/decryption via DCP, even with fixups for
unaligned buffers and the overhead of userspace-kernel-userspace switches due to
cryptodev is still higher than software implementation:
$ time openssl enc -aes-128-ecb -in $IFILE -out $OFILE -k "test" -nosalt
$ time openssl enc -d -aes-128-ecb -in $OFILE -out $DFILE -k "test" -nosalt
Also, since OpenSSH uses OpenSSL, this helped my testing too.
[1] http://cryptodev-linux.org/
[2] https://github.com/nmav/cryptodev-linux/tree/master/tests
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 3/3] ARM: mxs: dts: Enable DCP for MXS
From: Marek Vasut @ 2013-09-26 12:08 UTC (permalink / raw)
To: Lothar Waßmann
Cc: linux-crypto, Fabio Estevam, Herbert Xu, Shawn Guo,
David S. Miller, linux-arm-kernel
In-Reply-To: <21060.7210.127710.800708@ipc1.ka-ro>
Dear Lothar Waßmann,
> Hi,
>
> Marek Vasut writes:
> > Enable the DCP by default on both i.MX23 and i.MX28.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > To: linux-crypto@vger.kernel.org
> > ---
> >
> > arch/arm/boot/dts/imx23.dtsi | 4 +++-
> > arch/arm/boot/dts/imx28.dtsi | 5 +++--
> > 2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> > index 87faa6e..0630a9a 100644
> > --- a/arch/arm/boot/dts/imx23.dtsi
> > +++ b/arch/arm/boot/dts/imx23.dtsi
> > @@ -337,8 +337,10 @@
> >
> > };
> >
> > dcp@80028000 {
> >
> > + compatible = "fsl,mxs-dcp";
> >
> > reg = <0x80028000 0x2000>;
> >
> > - status = "disabled";
> > + interrupts = <53 54>;
> > + status = "okay";
> >
> > };
>
> AFAICT the policy seems to be that nodes, that are always enabled
> don't get a 'status' property at all.
This is new to me, thanks for letting me know!
As for the current DCP, please see my reply to Fabio in this thread.
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
From: Lothar Waßmann @ 2013-09-26 12:13 UTC (permalink / raw)
To: Marek Vasut; +Cc: linux-crypto, Herbert Xu, linux-arm-kernel, David S. Miller
In-Reply-To: <1380194306-5243-2-git-send-email-marex@denx.de>
Hi Marek,
some small comments below.
Marek Vasut writes:
> diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> new file mode 100644
> index 0000000..c2b35c7
> --- /dev/null
> +++ b/drivers/crypto/mxs-dcp.c
[...]
> +/* AES 128 ECB and AES 128 CBC */
> +static struct crypto_alg dcp_aes_algs[] = {
> + [0] = {
> + .cra_name = "ecb(aes)",
> + .cra_driver_name = "ecb-aes-dcp",
> + .cra_priority = 400,
> + .cra_alignmask = 15,
> + .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
> + CRYPTO_ALG_ASYNC |
> + CRYPTO_ALG_NEED_FALLBACK,
> + .cra_init = mxs_dcp_aes_fallback_init,
> + .cra_exit = mxs_dcp_aes_fallback_exit,
> + .cra_blocksize = AES_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct dcp_async_ctx),
> + .cra_type = &crypto_ablkcipher_type,
> + .cra_module = THIS_MODULE,
> + .cra_u = {
> + .ablkcipher = {
> + .min_keysize = AES_MIN_KEY_SIZE,
> + .max_keysize = AES_MAX_KEY_SIZE,
> + .setkey = mxs_dcp_aes_setkey,
> + .encrypt = mxs_dcp_aes_ecb_encrypt,
> + .decrypt = mxs_dcp_aes_ecb_decrypt
> + }
missing ',' after '}'
> + }
dto.
> + },
> + [1] = {
> + .cra_name = "cbc(aes)",
> + .cra_driver_name = "cbc-aes-dcp",
> + .cra_priority = 400,
> + .cra_alignmask = 15,
> + .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
> + CRYPTO_ALG_ASYNC |
> + CRYPTO_ALG_NEED_FALLBACK,
> + .cra_init = mxs_dcp_aes_fallback_init,
> + .cra_exit = mxs_dcp_aes_fallback_exit,
> + .cra_blocksize = AES_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct dcp_async_ctx),
> + .cra_type = &crypto_ablkcipher_type,
> + .cra_module = THIS_MODULE,
> + .cra_u = {
> + .ablkcipher = {
> + .min_keysize = AES_MIN_KEY_SIZE,
> + .max_keysize = AES_MAX_KEY_SIZE,
> + .setkey = mxs_dcp_aes_setkey,
> + .encrypt = mxs_dcp_aes_cbc_encrypt,
> + .decrypt = mxs_dcp_aes_cbc_decrypt,
> + .ivsize = AES_BLOCK_SIZE,
> + }
dto.
> + }
dto.
> + },
> +};
> +
> +/* SHA1 */
> +static struct ahash_alg dcp_sha1_alg = {
> + .init = dcp_sha_init,
> + .update = dcp_sha_update,
> + .final = dcp_sha_final,
> + .finup = dcp_sha_finup,
> + .digest = dcp_sha_digest,
> + .halg = {
> + .digestsize = SHA1_DIGEST_SIZE,
> + .base = {
> + .cra_name = "sha1",
> + .cra_driver_name = "sha1-dcp",
> + .cra_priority = 400,
> + .cra_alignmask = 63,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> + .cra_blocksize = SHA1_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct dcp_async_ctx),
> + .cra_module = THIS_MODULE,
> + .cra_init = dcp_sha_cra_init,
> + .cra_exit = dcp_sha_cra_exit,
> + }
dto.
> + }
dto.
> +};
> +
> +/* SHA256 */
> +static struct ahash_alg dcp_sha256_alg = {
> + .init = dcp_sha_init,
> + .update = dcp_sha_update,
> + .final = dcp_sha_final,
> + .finup = dcp_sha_finup,
> + .digest = dcp_sha_digest,
> + .halg = {
> + .digestsize = SHA256_DIGEST_SIZE,
> + .base = {
> + .cra_name = "sha256",
> + .cra_driver_name = "sha256-dcp",
> + .cra_priority = 400,
> + .cra_alignmask = 63,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> + .cra_blocksize = SHA256_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct dcp_async_ctx),
> + .cra_module = THIS_MODULE,
> + .cra_init = dcp_sha_cra_init,
> + .cra_exit = dcp_sha_cra_exit,
> + }
dto.
> + }
dto.
> +static const struct of_device_id mxs_dcp_dt_ids[] = {
> + {.compatible = "fsl,mxs-dcp", .data = NULL,},
>
missing spaces after '{' and before '}'
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: Michal Marek @ 2013-09-26 12:21 UTC (permalink / raw)
To: Pavel Machek
Cc: joeyli, Alan Stern, 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, Josh Boyer, Vojtech Pavlik,
Matt Fleming, James Bottomley, Greg KH, JKosina-IBi9RG/b67k,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537-tWAi6jLit6GreWDznjuHag@public.gmane.org>
On 26.9.2013 14:06, Pavel Machek wrote:
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
I think that part of the exercise is to minimize the number of writes to
the NVRAM. The hash changes with every hibernation, obviously.
Michal
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: Vojtech Pavlik @ 2013-09-26 12:22 UTC (permalink / raw)
To: Pavel Machek
Cc: joeyli, Alan Stern, 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, Josh Boyer, 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: <20130926120621.GA7537-tWAi6jLit6GreWDznjuHag@public.gmane.org>
On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
Well, yes, one could skip the CRC when the signing is enabled to gain a
little speedup.
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
First, there is no encryption going on. Only doing a HMAC (digest (hash)
using a key) of the image.
Second, since NVRAM is accessible through efivarsfs, storing the hash in
NVRAM wouldn't prevent an attacker from modifying the hash to match a
modified image.
There is a reason why the key for the HMAC is stored in the NVRAM in a
BootServices variable that isn't accessible from the OS and is
write-protected on hardware level from the OS.
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
The HMAC approach isn't much more complicated, and it gives you all
these benefits even with secure boot disabled.
--
Vojtech Pavlik
Director SUSE Labs
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: Vojtech Pavlik @ 2013-09-26 12:23 UTC (permalink / raw)
To: Michal Marek
Cc: Pavel Machek, joeyli, Alan Stern, 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, Josh Boyer, Matt Fleming,
James Bottomley, Greg KH, JKosina-IBi9RG/b67k, Rusty Russell,
Herbert Xu, David S. Miller, H. Peter Anvin, Gary Lin,
Vivek Goyal
In-Reply-To: <524426C3.1050501-AlSwsSmVLrQ@public.gmane.org>
On Thu, Sep 26, 2013 at 02:21:23PM +0200, Michal Marek wrote:
> > Is not it as simple as storing hash of hibernation image into NVRAM
> > and then verifying the hash matches the value in NVRAM on next
> > startup? No encryption needed.
>
> I think that part of the exercise is to minimize the number of writes to
> the NVRAM. The hash changes with every hibernation, obviously.
The key should, too.
--
Vojtech Pavlik
Director SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
From: Veli-Pekka Peltola @ 2013-09-26 12:37 UTC (permalink / raw)
To: Marek Vasut; +Cc: linux-crypto, Herbert Xu, linux-arm-kernel, David S. Miller
In-Reply-To: <1380194306-5243-2-git-send-email-marex@denx.de>
Hi Marek,
> + To compile this driver as a module, choose M here: the module
> + will be called atmel-sha.
This is probably wrong?
--
Veli-Pekka Peltola
^ permalink raw reply
* Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
From: Fabio Estevam @ 2013-09-26 12:48 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-crypto, Herbert Xu, linux-arm-kernel@lists.infradead.org,
David S. Miller
In-Reply-To: <1380194306-5243-2-git-send-email-marex@denx.de>
On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut <marex@denx.de> wrote:
> +config CRYPTO_DEV_MXS_DCP
> + tristate "Support for Freescale MXS DCP"
> + depends on ARCH_MXS
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + select CRYPTO_CBC
> + select CRYPTO_ECB
> + select CRYPTO_AES
> + select CRYPTO_BLKCIPHER
> + select CRYPTO_ALGAPI
> + help
> + The Freescale i.MX23/i.MX28 has SHA1/SHA256 and AES128 CBC/ECB
> + co-processor on the die.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called atmel-sha.
Actually it will be called 'mxs-dcp'.
> + * There can even be only one instance of the MXS DCP due to the
> + * design of Linux Crypto API.
Is this true? Usually we don't want to create a global struct.
> +
> +/* AES 128 ECB and AES 128 CBC */
> +static struct crypto_alg dcp_aes_algs[] = {
> + [0] = {
No need for explicitely add this [0]
> + .cra_name = "ecb(aes)",
> + .cra_driver_name = "ecb-aes-dcp",
> + .cra_priority = 400,
> + .cra_alignmask = 15,
> + .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
> + CRYPTO_ALG_ASYNC |
> + CRYPTO_ALG_NEED_FALLBACK,
> + .cra_init = mxs_dcp_aes_fallback_init,
> + .cra_exit = mxs_dcp_aes_fallback_exit,
> + .cra_blocksize = AES_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct dcp_async_ctx),
> + .cra_type = &crypto_ablkcipher_type,
> + .cra_module = THIS_MODULE,
> + .cra_u = {
> + .ablkcipher = {
> + .min_keysize = AES_MIN_KEY_SIZE,
> + .max_keysize = AES_MAX_KEY_SIZE,
> + .setkey = mxs_dcp_aes_setkey,
> + .encrypt = mxs_dcp_aes_ecb_encrypt,
> + .decrypt = mxs_dcp_aes_ecb_decrypt
> + }
> + }
> + },
> + [1] = {
Same here.
> +static int mxs_dcp_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct dcp *sdcp = NULL;
> + int i, ret;
> +
> + struct resource *iores;
> + int dcp_vmi_irq, dcp_irq;
> +
> + mutex_lock(&global_mutex);
> + if (global_sdcp) {
> + dev_err(dev, "Only one DCP instance allowed!\n");
> + ret = -ENODEV;
> + goto err_mutex;
> + }
> +
> + iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + dcp_vmi_irq = platform_get_irq(pdev, 0);
> + dcp_irq = platform_get_irq(pdev, 1);
> + if (!iores || dcp_vmi_irq < 0 || dcp_irq < 0) {
No need to check for !iores here.
You use it inside devm_ioremap_resource, which already does this checking.
> + /*
> + * We do not enable context switching. Give the context buffer a
> + * pointer to an illegal address so if context switching is
> + * inadvertantly enabled, the DCP will return an error instead of
> + * trashing good memory. The DCP DMA cannot access ROM, so any ROM
> + * address will do.
> + */
> + writel(0xffff0000, sdcp->base + MXS_DCP_CONTEXT);
Can you use a define instead of this hardcoded number?
> +static int mxs_dcp_remove(struct platform_device *pdev)
> +{
> + struct dcp *sdcp;
> + int i;
> +
> + sdcp = platform_get_drvdata(pdev);
> +
> + kthread_stop(sdcp->thread[DCP_CHAN_HASH_SHA]);
> + kthread_stop(sdcp->thread[DCP_CHAN_CRYPTO]);
> +
> + platform_set_drvdata(pdev, NULL);
> +
> + dma_free_coherent(sdcp->dev, sizeof(struct dcp_coherent_block),
> + sdcp->coh, sdcp->coh_phys);
> +
> + if (sdcp->caps & MXS_DCP_CAPABILITY1_SHA256)
> + crypto_unregister_ahash(&dcp_sha256_alg);
> +
> + if (sdcp->caps & MXS_DCP_CAPABILITY1_SHA1)
> + crypto_unregister_ahash(&dcp_sha1_alg);
> +
> + if (sdcp->caps & MXS_DCP_CAPABILITY1_AES128) {
> + for (i = ARRAY_SIZE(dcp_aes_algs); i >= 0; i--)
> + crypto_unregister_alg(&dcp_aes_algs[i]);
> + }
> +
> + mutex_lock(&global_mutex);
> + global_sdcp = NULL;
> + mutex_unlock(&global_mutex);
The order of the resources removal does not look correct here.
It should match the order of the error path in probe.
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mxs_dcp_dt_ids[] = {
> + {.compatible = "fsl,mxs-dcp", .data = NULL,},
In the other mxs/imx drivers we use:
.compatible = "fsl,<soc>-dcp"
You also need to provide a devicetree documentation for this binding.
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, mxs_dcp_dt_ids);
> +
> +static struct platform_driver mxs_dcp_driver = {
> + .probe = mxs_dcp_probe,
> + .remove = mxs_dcp_remove,
> + .driver = {
> + .name = "mxs-dcp",
> + .owner = THIS_MODULE,
> + .of_match_table = mxs_dcp_dt_ids,
> + },
> +};
> +
> +module_platform_driver(mxs_dcp_driver);
> +
> +MODULE_AUTHOR("Marek Vasut <marex@denx.de>");
> +MODULE_DESCRIPTION("Freescale MXS DCP Driver");
> +MODULE_LICENSE("GPL");
Could also add MODULE_ALIAS.
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
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 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: Alan Stern, 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, 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: <20130926120621.GA7537-tWAi6jLit6GreWDznjuHag@public.gmane.org>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: Alan Stern, 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, 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: <20130926120621.GA7537-tWAi6jLit6GreWDznjuHag@public.gmane.org>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
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 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 12:56 UTC (permalink / raw)
To: Pavel Machek
Cc: 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, James Bottomley, Greg KH, JKosina,
Rusty Russell, Herbert Xu, David S. Miller, H. Peter Anvin,
Michal Marek, Gary Lin, Vivek Goyal
In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz>
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.
In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.
Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere.
>
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.
That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.
>
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
>
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
>
> Pavel
The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable.
If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime.
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 13:20 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Pavel Machek, 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, 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: <20130926122210.GA30225@suse.cz>
於 四，2013-09-26 於 14:22 +0200，Vojtech Pavlik 提到：
> On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
>
> > > For the symmetric key solution, I will try HMAC (Hash Message
> > > Authentication Code). It's already used in networking, hope the
> > > performance is not too bad to a big image.
> >
> > Kernel already supports crc32 of the hibernation image, you may want
> > to take a look how that is done.
> >
> > Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> > then use only hash for more crypto? That way speed of whatever
> crypto
> > you do should not be an issue.
>
> Well, yes, one could skip the CRC when the signing is enabled to gain
> a
> little speedup.
In current kernel, CRC is for check the integrity of LZO compressed
image, the purpose is different to check the integrity of snapshot
image.
So, CRC will not in non-compress hibernate or userspace hibernate code
path
On the other hand, attacker can easily change the CRC code in the header
of LZO hibernate image.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 13:20 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Pavel Machek, Alan Stern, 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, Josh Boyer, 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: <20130926122210.GA30225-AlSwsSmVLrQ@public.gmane.org>
於 四，2013-09-26 於 14:22 +0200，Vojtech Pavlik 提到：
> On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
>
> > > For the symmetric key solution, I will try HMAC (Hash Message
> > > Authentication Code). It's already used in networking, hope the
> > > performance is not too bad to a big image.
> >
> > Kernel already supports crc32 of the hibernation image, you may want
> > to take a look how that is done.
> >
> > Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> > then use only hash for more crypto? That way speed of whatever
> crypto
> > you do should not be an issue.
>
> Well, yes, one could skip the CRC when the signing is enabled to gain
> a
> little speedup.
In current kernel, CRC is for check the integrity of LZO compressed
image, the purpose is different to check the integrity of snapshot
image.
So, CRC will not in non-compress hibernate or userspace hibernate code
path
On the other hand, attacker can easily change the CRC code in the header
of LZO hibernate image.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 13:20 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Pavel Machek, 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, 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: <20130926122210.GA30225@suse.cz>
於 四，2013-09-26 於 14:22 +0200，Vojtech Pavlik 提到：
> On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
>
> > > For the symmetric key solution, I will try HMAC (Hash Message
> > > Authentication Code). It's already used in networking, hope the
> > > performance is not too bad to a big image.
> >
> > Kernel already supports crc32 of the hibernation image, you may want
> > to take a look how that is done.
> >
> > Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> > then use only hash for more crypto? That way speed of whatever
> crypto
> > you do should not be an issue.
>
> Well, yes, one could skip the CRC when the signing is enabled to gain
> a
> little speedup.
In current kernel, CRC is for check the integrity of LZO compressed
image, the purpose is different to check the integrity of snapshot
image.
So, CRC will not in non-compress hibernate or userspace hibernate code
path
On the other hand, attacker can easily change the CRC code in the header
of LZO hibernate image.
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
From: joeyli @ 2013-09-26 13:20 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Pavel Machek, 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, 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: <20130926122210.GA30225@suse.cz>
於 四，2013-09-26 於 14:22 +0200，Vojtech Pavlik 提到：
> On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
>
> > > For the symmetric key solution, I will try HMAC (Hash Message
> > > Authentication Code). It's already used in networking, hope the
> > > performance is not too bad to a big image.
> >
> > Kernel already supports crc32 of the hibernation image, you may want
> > to take a look how that is done.
> >
> > Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> > then use only hash for more crypto? That way speed of whatever
> crypto
> > you do should not be an issue.
>
> Well, yes, one could skip the CRC when the signing is enabled to gain
> a
> little speedup.
In current kernel, CRC is for check the integrity of LZO compressed
image, the purpose is different to check the integrity of snapshot
image.
So, CRC will not in non-compress hibernate or userspace hibernate code
path
On the other hand, attacker can easily change the CRC code in the header
of LZO hibernate image.
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 13:20 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Pavel Machek, 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, 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: <20130926122210.GA30225@suse.cz>
於 四，2013-09-26 於 14:22 +0200，Vojtech Pavlik 提到：
> On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
>
> > > For the symmetric key solution, I will try HMAC (Hash Message
> > > Authentication Code). It's already used in networking, hope the
> > > performance is not too bad to a big image.
> >
> > Kernel already supports crc32 of the hibernation image, you may want
> > to take a look how that is done.
> >
> > Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> > then use only hash for more crypto? That way speed of whatever
> crypto
> > you do should not be an issue.
>
> Well, yes, one could skip the CRC when the signing is enabled to gain
> a
> little speedup.
In current kernel, CRC is for check the integrity of LZO compressed
image, the purpose is different to check the integrity of snapshot
image.
So, CRC will not in non-compress hibernate or userspace hibernate code
path
On the other hand, attacker can easily change the CRC code in the header
of LZO hibernate image.
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