Re: [PATCH v6 10/18] x86/power/64: Remove VLA usage

2018-07-25 Thread Rafael J. Wysocki 
On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook  wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
> shash directly and allocating the descriptor in heap memory (which should
> be fine: the tfm has already been allocated there too).
>
> [1] 
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook 
> Acked-by: Pavel Machek 

I think I can queue this up if there are no objections from others.

Do you want me to do that?

> ---
>  arch/x86/power/hibernate_64.c | 36 ---
>  1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
> index 67ccf64c8bd8..f8e3b668d20b 100644
> --- a/arch/x86/power/hibernate_64.c
> +++ b/arch/x86/power/hibernate_64.c
> @@ -233,29 +233,35 @@ struct restore_data_record {
>   */
>  static int get_e820_md5(struct e820_table *table, void *buf)
>  {
> -   struct scatterlist sg;
> -   struct crypto_ahash *tfm;
> +   struct crypto_shash *tfm;
> +   struct shash_desc *desc;
> int size;
> int ret = 0;
>
> -   tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
> +   tfm = crypto_alloc_shash("md5", 0, 0);
> if (IS_ERR(tfm))
> return -ENOMEM;
>
> -   {
> -   AHASH_REQUEST_ON_STACK(req, tfm);
> -   size = offsetof(struct e820_table, entries) + sizeof(struct 
> e820_entry) * table->nr_entries;
> -   ahash_request_set_tfm(req, tfm);
> -   sg_init_one(, (u8 *)table, size);
> -   ahash_request_set_callback(req, 0, NULL, NULL);
> -   ahash_request_set_crypt(req, , buf, size);
> -
> -   if (crypto_ahash_digest(req))
> -   ret = -EINVAL;
> -   ahash_request_zero(req);
> +   desc = kmalloc(sizeof(struct shash_desc) + crypto_shash_descsize(tfm),
> +  GFP_KERNEL);
> +   if (!desc) {
> +   ret = -ENOMEM;
> +   goto free_tfm;
> }
> -   crypto_free_ahash(tfm);
>
> +   desc->tfm = tfm;
> +   desc->flags = 0;
> +
> +   size = offsetof(struct e820_table, entries) +
> +   sizeof(struct e820_entry) * table->nr_entries;
> +
> +   if (crypto_shash_digest(desc, (u8 *)table, size, buf))
> +   ret = -EINVAL;
> +
> +   kzfree(desc);
> +
> +free_tfm:
> +   crypto_free_shash(tfm);
> return ret;
>  }
>
> --
> 2.17.1
>

Re: PBKDF2 support in the linux kernel

2018-05-27 Thread Rafael J. Wysocki 
On Saturday, May 26, 2018 7:12:36 AM CEST Herbert Xu wrote:
> On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote:
> > Hi all,
> > The request is that, we'd like to generate a symmetric key derived from
> > user provided passphase(not rely on any third-party library). May I know if
> > there is a PBKDF2(Password-Based Key Derivation Function 2) support in the
> > kernel? (https://tools.ietf.org/html/rfc2898#5.2)
> > We have hmac sha1 in the kernel, do we have plan to port/implement
> > corresponding PBKDF2 in the kernel too?
> 
> The rule for adding crypto code to the kernel is simple, there
> must be an in-kernel user of the algorithm.

So we are talking about an in-kernel user here.

Again, the PBKDF2 user would be hibernation.  It could either take a key from
user space, which would require a key-generating user-space component to be
present in the initramfs (I guess no issue for a regular distro, but I can
imagine cases when it may be a difficulty), or take a passphrase from user
space and generate a key by itself (that's what we would like to use PBKDF2
for).

We would prefer the latter for various reasons (convenience mostly, but also
not having to rely on user space to do the right thing).

Thanks,
Rafael

Re: PBKDF2 support in the linux kernel

2018-05-24 Thread Rafael J. Wysocki 
On Thursday, May 24, 2018 11:36:04 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki:
> 
> Hi Rafael,
> 
> > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
> > > 
> > > Hi Rafael,
> > 
> > Hi Stephan,
> > 
> > > > So the problem is that Yu would like to use this for hibernation
> > > > encryption
> > > > done entirely in the kernel.
> > > 
> > > But why do you need to perform PBKDF in kernel space?
> > > 
> > > If you retain the password information in the kernel, you could retain the
> > > derived key instead of the passcode.
> > > 
> > > If, however, you ask for the user password during resume, you need some
> > > user space component to query that password. The PBKDF can also be
> > > handled in user space along with the query.
> > 
> > In principle it is possible to pass a key to the kernel from user
> > space, but that doesn't guarantee the key to be a really good one.  It
> > depends on a user space component to do the right thing and IMO that is
> > risky.
> > 
> > And please note that the information contained in hibernation images may
> > be extremely sensitive (keys and similar).
> > 
> > > Or how do you want to handle the passcode?
> > 
> > The idea is to write a passphrase to the kernel via something like sysfs,
> > generate a key from it on the fly and store the key.
> 
> But what is the difference between a passcode and the key derived from it. 
> The 
> derived key should only spread the assumed entropy in the passcode evenly. In 
> addition with its iteration count, it shall ensure that offline brute force 
> attacks of the passcode using stored protected data is made hard.
> 
> So, I do not see why it is risky to do the PBKDF in user space and then hand 
> the key to the kernel at runtime. It does not really matter if the attacker 
> sees the plaintext key or the passcode. If the attacker can access the kernel/
> user communication channel, we have a problem in any case.

OK, we'll follow this advice, thanks!

Best,
Rafael

Re: PBKDF2 support in the linux kernel

2018-05-24 Thread Rafael J. Wysocki 
On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
> 
> Hi Rafael,

Hi Stephan,

> > So the problem is that Yu would like to use this for hibernation encryption
> > done entirely in the kernel.
> 
> But why do you need to perform PBKDF in kernel space?
> 
> If you retain the password information in the kernel, you could retain the 
> derived key instead of the passcode.
> 
> If, however, you ask for the user password during resume, you need some user 
> space component to query that password. The PBKDF can also be handled in user 
> space along with the query.

In principle it is possible to pass a key to the kernel from user
space, but that doesn't guarantee the key to be a really good one.  It
depends on a user space component to do the right thing and IMO that is
risky.

And please note that the information contained in hibernation images may
be extremely sensitive (keys and similar).

> Or how do you want to handle the passcode?

The idea is to write a passphrase to the kernel via something like sysfs,
generate a key from it on the fly and store the key.

> > 
> > The exact use case is to generate a symmetric encryption key out of a
> > passphrase.  Is there a recommended way to do that using the algorithms
> > already implemented in the kernel?
> 
> For example, dmcrypt uses PBKDF2 for its operation. And this PBKDF is done in 
> user space by libcryptsetup that utilizes a crypto lib, commonly libgcrypt.

I know that.  We can do that here too in principle, but I'd prefer all crypto
to take place in the kernel in this particular case.

Thanks,
Rafael

Re: PBKDF2 support in the linux kernel

2018-05-24 Thread Rafael J. Wysocki 
On Thursday, May 24, 2018 7:57:37 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
> 
> Hi Eric,
> 
> > 
> > "Not having to rely on any third-party library" is not an excuse to add
> > random code to the kernel, which runs in a privileged context.  Please do
> > PBKDF2 in userspace instead.
> 
> I second that. Besides, if you really need to rely on the kernel crypto API 
> to 
> do that because you do not want to add yet another crypto lib, libkcapi has a 
> PBKDF2 implementation that uses the kernel crypto API via AF_ALG. I.e. the 
> kernel crypto API is used and yet the PBKDF logic is in user space.
> 
> http://www.chronox.de/libkcapi.html

So the problem is that Yu would like to use this for hibernation encryption
done entirely in the kernel.

The exact use case is to generate a symmetric encryption key out of a
passphrase.  Is there a recommended way to do that using the algorithms
already implemented in the kernel?

Thanks,
Rafael

Re: [PATCH v4 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

2017-10-02 Thread Rafael J. Wysocki 
On Monday, October 2, 2017 11:12:42 AM CEST Jiri Slaby wrote:
> These are all functions which are invoked from elsewhere, so we annotate
> them as global using the new SYM_FUNC_START. And their ENDPROC's by
> SYM_FUNC_END.
> 
> And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
> the last users.
> 
> Signed-off-by: Jiri Slaby <jsl...@suse.cz>
> Cc: "H. Peter Anvin" <h...@zytor.com>
> Cc: Thomas Gleixner <t...@linutronix.de>
> Cc: Ingo Molnar <mi...@redhat.com>
> Cc: x...@kernel.org
> Cc: Herbert Xu <herb...@gondor.apana.org.au>
> Cc: "David S. Miller" <da...@davemloft.net>
> Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
> Cc: Len Brown <len.br...@intel.com>
> Cc: Pavel Machek <pa...@ucw.cz>
> Cc: Matt Fleming <m...@codeblueprint.co.uk>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
> Cc: Juergen Gross <jgr...@suse.com>
> Cc: linux-crypto@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org
> ---
>  arch/x86/boot/compressed/efi_thunk_64.S|  4 +-
>  arch/x86/boot/compressed/head_64.S | 16 
>  arch/x86/crypto/aes-i586-asm_32.S  |  8 ++--
>  arch/x86/crypto/aes-x86_64-asm_64.S|  4 +-
>  arch/x86/crypto/aes_ctrby8_avx-x86_64.S| 12 +++---
>  arch/x86/crypto/aesni-intel_asm.S  | 44 
> +++---
>  arch/x86/crypto/aesni-intel_avx-x86_64.S   | 24 ++--
>  arch/x86/crypto/blowfish-x86_64-asm_64.S   | 16 
>  arch/x86/crypto/camellia-aesni-avx-asm_64.S| 24 ++--
>  arch/x86/crypto/camellia-aesni-avx2-asm_64.S   | 24 ++--
>  arch/x86/crypto/camellia-x86_64-asm_64.S   | 16 
>  arch/x86/crypto/cast5-avx-x86_64-asm_64.S  | 16 
>  arch/x86/crypto/cast6-avx-x86_64-asm_64.S  | 24 ++--
>  arch/x86/crypto/chacha20-avx2-x86_64.S |  4 +-
>  arch/x86/crypto/chacha20-ssse3-x86_64.S|  8 ++--
>  arch/x86/crypto/crc32-pclmul_asm.S |  4 +-
>  arch/x86/crypto/crc32c-pcl-intel-asm_64.S  |  4 +-
>  arch/x86/crypto/crct10dif-pcl-asm_64.S |  4 +-
>  arch/x86/crypto/des3_ede-asm_64.S  |  8 ++--
>  arch/x86/crypto/ghash-clmulni-intel_asm.S  |  8 ++--
>  arch/x86/crypto/poly1305-avx2-x86_64.S |  4 +-
>  arch/x86/crypto/poly1305-sse2-x86_64.S |  8 ++--
>  arch/x86/crypto/salsa20-x86_64-asm_64.S| 12 +++---
>  arch/x86/crypto/serpent-avx-x86_64-asm_64.S| 24 ++--
>  arch/x86/crypto/serpent-avx2-asm_64.S  | 24 ++--
>  arch/x86/crypto/serpent-sse2-x86_64-asm_64.S   |  8 ++--
>  arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S   |  8 ++--
>  arch/x86/crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S  |  4 +-
>  arch/x86/crypto/sha1-mb/sha1_x8_avx2.S |  4 +-
>  arch/x86/crypto/sha1_avx2_x86_64_asm.S |  4 +-
>  arch/x86/crypto/sha1_ni_asm.S  |  4 +-
>  arch/x86/crypto/sha1_ssse3_asm.S   |  4 +-
>  arch/x86/crypto/sha256-avx-asm.S   |  4 +-
>  arch/x86/crypto/sha256-avx2-asm.S  |  4 +-
>  .../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S|  8 ++--
>  .../crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S   |  4 +-
>  arch/x86/crypto/sha256-mb/sha256_x8_avx2.S |  4 +-
>  arch/x86/crypto/sha256-ssse3-asm.S |  4 +-
>  arch/x86/crypto/sha256_ni_asm.S|  4 +-
>  arch/x86/crypto/sha512-avx-asm.S   |  4 +-
>  arch/x86/crypto/sha512-avx2-asm.S  |  4 +-
>  .../crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S|  8 ++--
>  .../crypto/sha512-mb/sha512_mb_mgr_submit_avx2.S   |  4 +-
>  arch/x86/crypto/sha512-mb/sha512_x4_avx2.S |  4 +-
>  arch/x86/crypto/sha512-ssse3-asm.S |  4 +-
>  arch/x86/crypto/twofish-avx-x86_64-asm_64.S| 24 ++--
>  arch/x86/crypto/twofish-x86_64-asm_64-3way.S   |  8 ++--
>  arch/x86/crypto/twofish-x86_64-asm_64.S|  8 ++--
>  arch/x86/entry/entry_64.S  | 10 ++---
>  arch/x86/entry/entry_64_compat.S   |  8 ++--
>  arch/x86/kernel/acpi/wakeup_64.S   |  8 ++--
>  arch/x86/kernel/head_64.S  | 12 +++---
>  arch/x86/lib/checksum_32.S |  8 ++--
>  arch/x86/lib/clear_page_64.S   | 12 +++---
>  arch/x86/lib/cmpxchg16b_emu.S  |  4 +-
>  arch/x86/lib/cmpxchg

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-17 Thread Rafael J. Wysocki 
On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches  wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning for that directory tree and pr_warn is
> not used in tools/.
>
> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Sorry about asking if that has been asked already.

Wouldn't it be slightly less intrusive to simply redefined
pr_warning() as a synonym for pr_warn()?

Thanks,
Rafael

Re: [V6 PATCH 0/7] ACPI: Introduce support for _CCA object

2015-06-15 Thread Rafael J. Wysocki 
-platform.c | 60 +---
  drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +
  drivers/scsi/megaraid/megaraid_sas_fp.c   |  8 +++
  drivers/scsi/ufs/unipro.h |  8 +++
  include/acpi/acpi_bus.h   | 37 -
  include/linux/acpi.h  |  5 ++
  include/linux/property.h  |  2 +
  15 files changed, 228 insertions(+), 89 deletions(-)

I've queued up the series for 4.2, thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

2015-05-22 Thread Rafael J. Wysocki 
On Wednesday, May 20, 2015 05:09:14 PM Suravee Suthikulpanit wrote:
 This patch implements support for ACPI _CCA object, which is introduced in
 ACPIv5.1, can be used for specifying device DMA coherency attribute.
 
 The parsing logic traverses device namespace to parse coherency
 information, and stores it in acpi_device_flags. Then uses it to call
 arch_setup_dma_ops() when creating each device enumerated in DSDT
 during ACPI scan.
 
 This patch also introduces acpi_dma_is_coherent(), which provides
 an interface for device drivers to check the coherency information
 similarly to the of_dma_is_coherent().
 
 Signed-off-by: Mark Salter msal...@redhat.com
 Signed-off-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
 ---
  drivers/acpi/Kconfig |  3 +++
  drivers/acpi/acpi_platform.c |  2 +-
  drivers/acpi/glue.c  |  5 +
  drivers/acpi/scan.c  | 35 +++
  include/acpi/acpi_bus.h  | 37 -
  include/linux/acpi.h |  5 +
  6 files changed, 85 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
 index ab2cbb5..212735f 100644
 --- a/drivers/acpi/Kconfig
 +++ b/drivers/acpi/Kconfig
 @@ -54,6 +54,9 @@ config ACPI_GENERIC_GSI
  config ACPI_SYSTEM_POWER_STATES_SUPPORT
   bool
  
 +config ACPI_CCA_REQUIRED
 + bool
 +
  config ACPI_SLEEP
   bool
   depends on SUSPEND || HIBERNATION
 diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
 index 4bf7559..06a67d5 100644
 --- a/drivers/acpi/acpi_platform.c
 +++ b/drivers/acpi/acpi_platform.c
 @@ -103,7 +103,7 @@ struct platform_device 
 *acpi_create_platform_device(struct acpi_device *adev)
   pdevinfo.res = resources;
   pdevinfo.num_res = count;
   pdevinfo.fwnode = acpi_fwnode_handle(adev);
 - pdevinfo.dma_mask = DMA_BIT_MASK(32);
 + pdevinfo.dma_mask = acpi_check_dma(adev, NULL) ? DMA_BIT_MASK(32) : 0;
   pdev = platform_device_register_full(pdevinfo);
   if (IS_ERR(pdev))
   dev_err(adev-dev, platform device creation failed: %ld\n,
 diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
 index 39c485b..b9657af 100644
 --- a/drivers/acpi/glue.c
 +++ b/drivers/acpi/glue.c
 @@ -13,6 +13,7 @@
  #include linux/slab.h
  #include linux/rwsem.h
  #include linux/acpi.h
 +#include linux/dma-mapping.h
  
  #include internal.h
  
 @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device 
 *acpi_dev)
   struct list_head *physnode_list;
   unsigned int node_id;
   int retval = -EINVAL;
 + bool coherent;
  
   if (has_acpi_companion(dev)) {
   if (acpi_dev) {
 @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device 
 *acpi_dev)
   if (!has_acpi_companion(dev))
   ACPI_COMPANION_SET(dev, acpi_dev);
  
 + if (acpi_check_dma(acpi_dev, coherent))
 + arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
 +

Well, so is this going to work for PCI too after all?

   acpi_physnode_link_name(physical_node_name, node_id);
   retval = sysfs_create_link(acpi_dev-dev.kobj, dev-kobj,
  physical_node_name);


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

2015-05-22 Thread Rafael J. Wysocki 
On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
 On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
  On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
  Not sure if this went out earlier. So I am resending.
 
  On 5/22/15 16:56, Rafael J. Wysocki wrote:
  diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
  index 39c485b..b9657af 100644
  --- a/drivers/acpi/glue.c
  +++ b/drivers/acpi/glue.c
  @@ -13,6 +13,7 @@
#include linux/slab.h
#include linux/rwsem.h
#include linux/acpi.h
  +#include linux/dma-mapping.h
 
#include internal.h
 
  @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct 
  acpi_device *acpi_dev)
  struct list_head *physnode_list;
  unsigned int node_id;
  int retval = -EINVAL;
  +   bool coherent;
 
  if (has_acpi_companion(dev)) {
  if (acpi_dev) {
  @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct 
  acpi_device *acpi_dev)
  if (!has_acpi_companion(dev))
  ACPI_COMPANION_SET(dev, acpi_dev);
 
  +   if (acpi_check_dma(acpi_dev, coherent))
  +   arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
  +
  Well, so is this going to work for PCI too after all?
 
 
  No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
  (patch 3/6 in V4) will be submitted separately. We are working on
  cleaning up and up-streaming the PCI ACPI support for ARM64.
 
  OK, but acpi_bind_one() is called for PCI devices too.  Won't that be a 
  problem?
 
 
  
 In this case, we would be going through the following call path:
 
-- pci_device_add()
 |-- pci_dma_configure() ** 1 **
 |-- device_add()
   |-- platform_notify()
 |-- acpi_platform_notify()
  |-- acpi_bind_one() ** 2 **
 
 At (1), we would be calling arch_setup_dma_ops() with the PCI host 
 bridge _CCA information. So, it should have already taken care of 
 setting up device coherency here.
 
 At (2), if there is no acpi_dev for endpoint devices (which I believe 
 this is normally the case), it would return early and skip 
 arch_setup_dma_ops().

That's not correct.  There may be ACPI companions for endpoint devices too.


 At (2), if there is an acpi_dev, the coherent_dma flag should have 
 already been setup by the acpi_init_device_object during ACPI scan.

That one sets the flag for the *ACPI* *companion* of the device, which
I'm still thinking is pointless, isn't it?


 However, I am not certain about this case since I don't have the DSDT 
 containing  PCI endpoint devices to test with.

Every x86 PC has them (as far as I can say), but in that case there's no
_CCA and they are all coherent.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

2015-05-22 Thread Rafael J. Wysocki 
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
 Not sure if this went out earlier. So I am resending.
 
 On 5/22/15 16:56, Rafael J. Wysocki wrote:
  diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
  index 39c485b..b9657af 100644
  --- a/drivers/acpi/glue.c
  +++ b/drivers/acpi/glue.c
  @@ -13,6 +13,7 @@
#include linux/slab.h
#include linux/rwsem.h
#include linux/acpi.h
  +#include linux/dma-mapping.h
  
#include internal.h
  
  @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct 
  acpi_device *acpi_dev)
struct list_head *physnode_list;
unsigned int node_id;
int retval = -EINVAL;
  + bool coherent;
  
if (has_acpi_companion(dev)) {
if (acpi_dev) {
  @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct 
  acpi_device *acpi_dev)
if (!has_acpi_companion(dev))
ACPI_COMPANION_SET(dev, acpi_dev);
  
  + if (acpi_check_dma(acpi_dev, coherent))
  + arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
  +
  Well, so is this going to work for PCI too after all?
 
 
 No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA 
 (patch 3/6 in V4) will be submitted separately. We are working on 
 cleaning up and up-streaming the PCI ACPI support for ARM64.

OK, but acpi_bind_one() is called for PCI devices too.  Won't that be a problem?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot

2013-10-17 Thread Rafael J. Wysocki 
On Sunday, September 15, 2013 08:56:46 AM Lee, Chun-Yi wrote:
 Hi experts,
 
 This patchset is the implementation for signature verification of hibernate
 snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader
 generate key-pair in UEFI secure boot environment, then pass it to kernel
 for sign/verify S4 image.
 
 Due to there have potential threat from the S4 image hacked, it may causes
 kernel lost the trust in UEFI secure boot. Hacker attack the S4 snapshot
 image in swap partition through whatever exploit from another trusted OS,
 and the exploit may don't need physical access machine.
 
 So, this patchset give the ability to kernel for parsing RSA private key
 from EFI bootloader, then using the private key to generate the signature
 of S4 snapshot image. Kernel put the signature to snapshot header, and
 verify the signature when kernel try to recover snapshot image to memory.

I wonder what the status of this work is?  Is it considered ready for inclusion
or are you still going to work on it and resubmit?

Rafael

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

2013-07-20 Thread Rafael J. Wysocki 
On Saturday, July 20, 2013 05:06:29 AM Rafael J. Wysocki wrote:
 On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
  On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
   On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd like to apply.

With that patch applied, new device objects are created to avoid 
binding the
processor driver directly to the cpu system device objects, because that
apparently confuses udev and it starts to ignore the cpu modalias once 
the
driver has been bound to any of those objects.

I've verified in the meantime that this indeed is the case.

A link to the patch in question: 
https://patchwork.kernel.org/patch/2830561/

Greg, I asked you some time ago whether or not it was possible for udev 
to stop
autoloading modules that matched the cpu modalias after a driver had 
been bound
to the cpu system device objects and you said no.  However, this time 
I can
say with certainty that that really is the case.  So, the question now 
is
whether or not we can do anything in the kernel to avoid that confusion 
in udev
instead of applying the patch linked above (which is beyond ugly in my 
not so
humble opinion)?
   
   udev isn't doing any module loading, 'modprobe' is just being called for
   any new module alias that shows up in the system, and all of the drivers
   that match it then get loaded.
  
  The problem is that that doesn't happen when a driver is bound to the
  cpu system device objects.  modprobe is just not called for modules that
  match the cpu modalias in that case.
  
  If I call modprobe manually for any of the modules in question, it loads
  and works no problem.
 
 OK, I know what's up.  udev has no rule that would allow it to load stuff on
 the basis of MODALIAS if DRIVER is set in the event properties.
 
 So, the following rule needs to be added to udev rules for things to work
 as before:
 
 DRIVER==processor, ENV{MODALIAS}==?*, IMPORT{builtin}=kmod load 
 $env{MODALIAS}
 
 To be precise, I added a file called 80-drivers.rules to /etc/udev/rules.d/

Well, that wasn't a good idea, because the original 80-drivers.rules didn't
work then, but I renamed the new file (in /etc/udev/rules.d/) to 80-cpu.rules
and put this line (alone) into it:

ACTION=add, SUBSYSTEM==cpu, ENV{MODALIAS}==?*, IMPORT{builtin}=kmod load 
$env{MODALIAS}

After that change everything works happily again.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

2013-07-19 Thread Rafael J. Wysocki 
On Thursday, July 18, 2013 04:44:20 PM H. Peter Anvin wrote:
 On 07/18/2013 03:17 PM, Rafael J. Wysocki wrote:
 
  alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crct10dif_pclmul
 
  This should cause udev to load the crct10dif_pclml module when cpu
  support the PCLMULQDQ (feature code 0081).  I did my testing during
  development on 3.10 and the module was indeed loaded.
 
  However, I found that the following commit under 3.11-rc1 broke
  the mechanism after some bisection.
 
  commit ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
  Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
  Date:   Fri May 3 00:26:22 2013 +0200
 
   ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
   non-modular, resides in the ACPI core and handles the enumeration
   and hotplug of processors and one that implements the rest of the
   existing processor driver functionality.
   Rafael, can you check and see if this can be fixed so those
  optimized
  crypto modules for Intel cpu that support them can be loaded?
  
  I think this is an ordering issue between udev startup and the time when
  devices are registered.
  
  I wonder what happens if you put those modules into the initramfs image?
  
 
 OK, this bothers me on some pretty deep level... a set of changes
 exclusively in drivers/acpi breaking functionality which had nothing to
 do with ACPI, specifically CPU-feature-based module loading.

Well, they are not exclusively in drivers/acpi, they are in drivers/base/cpu.c
too and that most likely is the responsible part.

 Please let me know what the investigation comes up with, or if I need to
 get more directly involved.

I will.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

2013-07-19 Thread Rafael J. Wysocki 
On Friday, July 19, 2013 11:08:49 AM Tim Chen wrote:
 On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote:
  This should cause udev to load the crct10dif_pclml module when cpu
  support the PCLMULQDQ (feature code 0081).  I did my testing during
  development on 3.10 and the module was indeed loaded.
 
  However, I found that the following commit under 3.11-rc1 broke
  the mechanism after some bisection.
 
  commit ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
  Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
  Date:   Fri May 3 00:26:22 2013 +0200
 
   ACPI / processor: Use common hotplug infrastructure
   
   Split the ACPI processor driver into two parts, one that is
   non-modular, resides in the ACPI core and handles the 
  enumeration
   and hotplug of processors and one that implements the rest of 
  the
   existing processor driver functionality.
   
  Rafael, can you check and see if this can be fixed so those 
  optimized
  crypto modules for Intel cpu that support them can be loaded?
 
 I think this is an ordering issue between udev startup and the time 
 when 
 devices are registered.

Something that can be fixed?
   
   I'm sure it can be fixes, but I'm not sure whether it's a udev bug or real
   breakage in the kernel yet.  I need to figure out that part.
  
  OK
  
  I wonder if the appended patch makes the issue go away for you?
  
 
 Rafael, the patch did fix the cpu feature based module loading issue.
 Thanks for your quick response.

Alas, this is not the one I'd like to apply.

With that patch applied, new device objects are created to avoid binding the
processor driver directly to the cpu system device objects, because that
apparently confuses udev and it starts to ignore the cpu modalias once the
driver has been bound to any of those objects.

I've verified in the meantime that this indeed is the case.

A link to the patch in question: https://patchwork.kernel.org/patch/2830561/

Greg, I asked you some time ago whether or not it was possible for udev to stop
autoloading modules that matched the cpu modalias after a driver had been bound
to the cpu system device objects and you said no.  However, this time I can
say with certainty that that really is the case.  So, the question now is
whether or not we can do anything in the kernel to avoid that confusion in udev
instead of applying the patch linked above (which is beyond ugly in my not so
humble opinion)?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

2013-07-19 Thread Rafael J. Wysocki 
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
 On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
  Alas, this is not the one I'd like to apply.
  
  With that patch applied, new device objects are created to avoid binding the
  processor driver directly to the cpu system device objects, because that
  apparently confuses udev and it starts to ignore the cpu modalias once the
  driver has been bound to any of those objects.
  
  I've verified in the meantime that this indeed is the case.
  
  A link to the patch in question: https://patchwork.kernel.org/patch/2830561/
  
  Greg, I asked you some time ago whether or not it was possible for udev to 
  stop
  autoloading modules that matched the cpu modalias after a driver had been 
  bound
  to the cpu system device objects and you said no.  However, this time I 
  can
  say with certainty that that really is the case.  So, the question now is
  whether or not we can do anything in the kernel to avoid that confusion in 
  udev
  instead of applying the patch linked above (which is beyond ugly in my not 
  so
  humble opinion)?
 
 udev isn't doing any module loading, 'modprobe' is just being called for
 any new module alias that shows up in the system, and all of the drivers
 that match it then get loaded.

The problem is that that doesn't happen when a driver is bound to the
cpu system device objects.  modprobe is just not called for modules that
match the cpu modalias in that case.

If I call modprobe manually for any of the modules in question, it loads
and works no problem.

 How is it a problem if a module is attempted to be loaded that is
 already loaded?  How is it a problem if a different module is loaded for
 a device already bound to a driver?  Both of those should be total
 no-ops for the kernel.

Precisely, but that's not what happens in practice, hence my question.

The situation is this:

- With 3.11-rc1 modules that match the CPU modalias are not loaded
  automatically (that is, modprobe is not called for them by udev) after
  the processor module is loaded.
- With 3.10 they are loaded automatically at any time.
- With the patch at https://patchwork.kernel.org/patch/2830561/ on top of
  3.11-rc1 the situation is the same as for 3.10.

Therefore we have a kernel regression from 3.10 (with respect to the existing
user space which is udev) in 3.11-rc1 3.10 and the patch at
https://patchwork.kernel.org/patch/2830561/ makes that regression go away.

However, that patch is totally voodoo programming, so I wonder if there is any
saner alternative or we really need to do voodoo programming in the kernel to
work around udev's confusion.

 But, I don't know anything about the cpu code, how is loading a module
 causing problems?  That sounds like it needs to be fixes, as any root
 user can load modules whenever they want, you can't protect the kernel
 from doing that.

Yes, that needs to be fixed, but I don't know *why* it is a problem in the
first place.  I'd like to understand what's going on, because I don't
right now.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

2013-07-19 Thread Rafael J. Wysocki 
On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
 On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
  On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
   Alas, this is not the one I'd like to apply.
   
   With that patch applied, new device objects are created to avoid binding 
   the
   processor driver directly to the cpu system device objects, because that
   apparently confuses udev and it starts to ignore the cpu modalias once the
   driver has been bound to any of those objects.
   
   I've verified in the meantime that this indeed is the case.
   
   A link to the patch in question: 
   https://patchwork.kernel.org/patch/2830561/
   
   Greg, I asked you some time ago whether or not it was possible for udev 
   to stop
   autoloading modules that matched the cpu modalias after a driver had been 
   bound
   to the cpu system device objects and you said no.  However, this time I 
   can
   say with certainty that that really is the case.  So, the question now is
   whether or not we can do anything in the kernel to avoid that confusion 
   in udev
   instead of applying the patch linked above (which is beyond ugly in my 
   not so
   humble opinion)?
  
  udev isn't doing any module loading, 'modprobe' is just being called for
  any new module alias that shows up in the system, and all of the drivers
  that match it then get loaded.
 
 The problem is that that doesn't happen when a driver is bound to the
 cpu system device objects.  modprobe is just not called for modules that
 match the cpu modalias in that case.
 
 If I call modprobe manually for any of the modules in question, it loads
 and works no problem.

OK, I know what's up.  udev has no rule that would allow it to load stuff on
the basis of MODALIAS if DRIVER is set in the event properties.

So, the following rule needs to be added to udev rules for things to work
as before:

DRIVER==processor, ENV{MODALIAS}==?*, IMPORT{builtin}=kmod load 
$env{MODALIAS}

To be precise, I added a file called 80-drivers.rules to /etc/udev/rules.d/
with the following contents:

ACTION==remove, GOTO=drivers_end

DRIVER==processor, ENV{MODALIAS}==?*, IMPORT{builtin}=kmod load 
$env{MODALIAS}

LABEL=drivers_end

but I'm not sure how to propagate this to the udev maintainers.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LZO irreversible output?

2010-02-03 Thread Rafael J. Wysocki 
On Wednesday 03 February 2010, Nigel Cunningham wrote:
 Hi all.
 
 (Not sent to LKML yesterday; no reply from linux-crypto yet, so resending).
 
 A while back now, I stopped supplying the LZF compression algorithm with
 TuxOnIce and made LZO the default algorithm. Around the same time, we
 started getting occasional errors when reading images; decompression
 failures.
 
 I've finally managed to find the time to properly look at this, and have
 managed to find a data page that LZO compresses, but seems to be unable
 to decompress back to the original contents. I'm wondering whether this
 is because I'm doing something wrong, or because there really is some
 data the LZO (or the kernel implementation) can't do reversible
 compression on.

Well, FWIW, we have never had any problems with the userland LZO in s2disk,
so if anything is wrong with LZO here, I guess it's the kernel code.

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html