Re: [PATCH 00/28] Reenable maybe-uninitialized warnings

2016-10-17 Thread Christoph Hellwig 
On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote:
> This is a set of patches that I hope to get into v4.9 in some form
> in order to turn on the -Wmaybe-uninitialized warnings again.

Hi Arnd,

I jsut complained to Geert that I was introducing way to many
bugs or pointless warnings for some compilers lately, but gcc didn't
warn me about them.  From a little research the lack of
-Wmaybe-uninitialized seems to be the reason for it, so I'm all
for re-enabling it.
--
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

[PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning

2016-10-17 Thread Arnd Bergmann 
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].

Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.

With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.

However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that
I had not addressed until then. This caused a lot of actual bugs to
get merged into mainline, and I sent several dozen patches for these
during the v4.9 development cycle. Most of these are actual bugs,
some are for correct code that is safe because it is only called
under external constraints that make it impossible to run into
the case that gcc sees, and in a few cases gcc is just stupid and
finds something that can obviously never happen.

I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got
(I can provide the combined patch for the other warnings if anyone
is interested), so I hope we can get the warning back and let people
catch the actual bugs earlier.

Note that the majority of the patches I created are for the third kind
of problem (stupid false-positives), for one of two reasons:
- some of them only get triggered in certain combinations of config
  options, so we don't always run into them, and
- the actual bugs tend to get addressed much quicker as they also
  lead to incorrect runtime behavior.

These 27 patches address the warnings that either occur in one of the more
common configurations (defconfig, allmodconfig, or something built by the
kbuild robot or kernelci.org), or they are about a real bug. It would be
good to get these all into v4.9 if we want to turn on the warning again.
I have tested these extensively with gcc-4.9 and gcc-6 and done a bit
of testing with gcc-5, and all of these should now be fine. gcc-4.8
is much worse about the false-positive warnings and is also fairly old
now, so I'm leaving the warning disabled with that version. gcc-4.7 and
older don't understand the -Wno-maybe-uninitialized option and are not
affected by this patch either way.

I have another (smaller) series of patches for warnings that are both
harmless and not as easy to trigger, and I will send them for inclusion
in v4.10.

Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann 
---
 Makefile   | 10 ++
 arch/arc/Makefile  |  4 +++-
 scripts/Makefile.ubsan |  4 
 3 files changed, 13 insertions(+), 5 deletions(-)

Cc: x...@kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Mauro Carvalho Chehab 
Cc: Martin Schwidefsky 
Cc: linux-s...@vger.kernel.org
Cc: Ilya Dryomov 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-...@lists.infradead.org
Cc: Herbert Xu 
Cc: linux-crypto@vger.kernel.org
Cc: "David S. Miller" 
Cc: net...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: ceph-de...@vger.kernel.org
Cc: linux-f2fs-de...@lists.sourceforge.net
Cc: linux-e...@vger.kernel.org
Cc: netfilter-de...@vger.kernel.org

diff --git a/Makefile b/Makefile
index 512e47a..43cd3d9 100644
--- a/Makefile
+++ b/Makefile
@@ -370,7 +370,7 @@ LDFLAGS_MODULE  =
 CFLAGS_KERNEL  =
 AFLAGS_KERNEL  =
 LDFLAGS_vmlinux =
-CFLAGS_GCOV= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
+CFLAGS_GCOV= -fprofile-arcs -ftest-coverage -fno-tree-loop-im  
-Wno-maybe-uninitialized
 CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
 
 
@@ -620,7 +620,6 @@ ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
-KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
@@ -629,15 +628,18 @@

[PATCH 15/28] crypto: aesni: avoid -Wmaybe-uninitialized warning

2016-10-17 Thread Arnd Bergmann 
The rfc4106 encrypy/decrypt helper functions cause an annoying
false-positive warning in allmodconfig if we turn on
-Wmaybe-uninitialized warnings again:

arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]

The problem seems to be that the compiler doesn't track the state of the
'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
section.

This reorganizes the code to avoid that variable and have the shared
code in a separate function to avoid some of the conditional branches.

The resulting functions are a bit longer but also slightly less complex,
leaving no room for speculation on the part of the compiler.

Cc: Herbert Xu 
Signed-off-by: Arnd Bergmann 
---
The conversion is nontrivial, and I have only build-tested it, so this
could use a careful review and testing.
---
 arch/x86/crypto/aesni-intel_glue.c | 121 ++---
 1 file changed, 73 insertions(+), 48 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_glue.c 
b/arch/x86/crypto/aesni-intel_glue.c
index 0ab5ee1..054155b 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -269,6 +269,34 @@ static void (*aesni_gcm_dec_tfm)(void *ctx, u8 *out,
u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
u8 *auth_tag, unsigned long auth_tag_len);
 
+static inline void aesni_do_gcm_enc_tfm(void *ctx, u8 *out,
+   const u8 *in, unsigned long plaintext_len, u8 *iv,
+   u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
+   u8 *auth_tag, unsigned long auth_tag_len)
+{
+   kernel_fpu_begin();
+   aesni_gcm_enc_tfm(ctx, out, in, plaintext_len, iv, hash_subkey,
+ aad, aad_len, auth_tag, auth_tag_len);
+   kernel_fpu_end();
+}
+
+static inline int aesni_do_gcm_dec_tfm(void *ctx, u8 *out,
+   const u8 *in, unsigned long ciphertext_len, u8 *iv,
+   u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
+   u8 *auth_tag, unsigned long auth_tag_len)
+{
+   kernel_fpu_begin();
+   aesni_gcm_dec_tfm(ctx, out, in, ciphertext_len, iv, hash_subkey, aad,
+ aad_len, auth_tag, auth_tag_len);
+   kernel_fpu_end();
+
+   /* Compare generated tag with passed in tag. */
+   if (crypto_memneq(in + ciphertext_len, auth_tag, auth_tag_len))
+   return -EBADMSG;
+
+   return 0;
+}
+
 static inline struct
 aesni_rfc4106_gcm_ctx *aesni_rfc4106_gcm_ctx_get(struct crypto_aead *tfm)
 {
@@ -879,7 +907,6 @@ static int rfc4106_set_authsize(struct crypto_aead *parent,
 
 static int helper_rfc4106_encrypt(struct aead_request *req)
 {
-   u8 one_entry_in_sg = 0;
u8 *src, *dst, *assoc;
__be32 counter = cpu_to_be32(1);
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
@@ -908,7 +935,6 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
req->src->offset + req->src->length <= PAGE_SIZE &&
sg_is_last(req->dst) &&
req->dst->offset + req->dst->length <= PAGE_SIZE) {
-   one_entry_in_sg = 1;
scatterwalk_start(_sg_walk, req->src);
assoc = scatterwalk_map(_sg_walk);
src = assoc + req->assoclen;
@@ -916,7 +942,23 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
if (unlikely(req->src != req->dst)) {
scatterwalk_start(_sg_walk, req->dst);
dst = scatterwalk_map(_sg_walk) + req->assoclen;
+
+   aesni_do_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, 
iv,
+ctx->hash_subkey, assoc, 
req->assoclen - 8,
+dst + req->cryptlen, auth_tag_len);
+
+   scatterwalk_unmap(dst - req->assoclen);
+   scatterwalk_advance(_sg_walk, req->dst->length);
+   scatterwalk_done(_sg_walk, 1, 0);
+   } else {
+   aesni_do_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, 
iv,
+ctx->hash_subkey, assoc, 
req->assoclen - 8,
+dst + req->cryptlen, auth_tag_len);
}
+
+   scatterwalk_unmap(assoc);
+   scatterwalk_advance(_sg_walk, req->src->length);
+   scatterwalk_done(_sg_walk, req->src == req->dst, 0);
} else {
/* Allocate memory for src, dst, assoc */
assoc = kmalloc(req->cryptlen + auth_tag_len + req->assoclen,
@@ -925,28 +967,14 @@ static int helper_rfc4106_encrypt(struct aead_request 
*req)

[PATCH 00/28] Reenable maybe-uninitialized warnings

2016-10-17 Thread Arnd Bergmann 
This is a set of patches that I hope to get into v4.9 in some form
in order to turn on the -Wmaybe-uninitialized warnings again.

After talking to Linus in person at Linaro Connect about this, I
spent some time on finding all the remaining warnings, and this
is the resulting patch series. More details are in the description
of the last patch that actually enables the warning.

Let me know if there are other warnings that I missed, and whether
you think these are still appropriate for v4.9 or not.
A couple of patches are non-obvious, and could use some more
detailed review.

Arnd

Arnd Bergmann (28):
  [v2] netfilter: nf_tables: avoid uninitialized variable warning
  [v2] mtd: mtk: avoid warning in mtk_ecc_encode
  [v2] infiniband: shut up a maybe-uninitialized warning
  f2fs: replace a build-time warning with runtime WARN_ON
  ext2: avoid bogus -Wmaybe-uninitialized warning
  NFSv4.1: work around -Wmaybe-uninitialized warning
  ceph: avoid false positive maybe-uninitialized warning
  staging: lustre: restore initialization of return code
  staging: lustre: remove broken dead code in
cfs_cpt_table_create_pattern
  UBI: fix uninitialized access of vid_hdr pointer
  block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized
  [media] rc: print correct variable for z8f0811
  [media] dib0700: fix uninitialized data on 'repeat' event
  iio: accel: sca3000_core: avoid potentially uninitialized variable
  crypto: aesni: avoid -Wmaybe-uninitialized warning
  pcmcia: fix return value of soc_pcmcia_regulator_set
  spi: fsl-espi: avoid processing uninitalized data on error
  drm: avoid uninitialized timestamp use in wait_vblank
  brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
  net: bcm63xx: avoid referencing uninitialized variable
  net/hyperv: avoid uninitialized variable
  x86: apm: avoid uninitialized data
  x86: mark target address as output in 'insb' asm
  x86: math-emu: possible uninitialized variable use
  s390: pci: don't print uninitialized data for debugging
  nios2: fix timer initcall return value
  rocker: fix maybe-uninitialized warning
  Kbuild: bring back -Wmaybe-uninitialized warning

 Makefile   |  10 +-
 arch/arc/Makefile  |   4 +-
 arch/nios2/kernel/time.c   |   1 +
 arch/s390/pci/pci_dma.c|   2 +-
 arch/x86/crypto/aesni-intel_glue.c | 121 +
 arch/x86/include/asm/io.h  |   4 +-
 arch/x86/kernel/apm_32.c   |   5 +-
 arch/x86/math-emu/Makefile |   4 +-
 arch/x86/math-emu/reg_compare.c|  16 +--
 drivers/block/rbd.c|   1 +
 drivers/gpu/drm/drm_irq.c  |   4 +-
 drivers/infiniband/core/cma.c  |  56 +-
 drivers/media/i2c/ir-kbd-i2c.c |   2 +-
 drivers/media/usb/dvb-usb/dib0700_core.c   |  10 +-
 drivers/mtd/nand/mtk_ecc.c |  19 ++--
 drivers/mtd/ubi/eba.c  |   2 +-
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |   3 +-
 drivers/net/ethernet/rocker/rocker_ofdpa.c |   4 +-
 drivers/net/hyperv/netvsc_drv.c|   2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |   2 +-
 drivers/pcmcia/soc_common.c|   2 +-
 drivers/spi/spi-fsl-espi.c |   2 +-
 drivers/staging/iio/accel/sca3000_core.c   |   2 +
 .../staging/lustre/lnet/libcfs/linux/linux-cpu.c   |   7 --
 drivers/staging/lustre/lustre/lov/lov_pack.c   |   2 +
 fs/ceph/super.c|   3 +-
 fs/ext2/inode.c|   7 +-
 fs/f2fs/data.c |   7 ++
 fs/nfs/nfs4session.c   |  10 +-
 net/netfilter/nft_range.c  |  10 +-
 scripts/Makefile.ubsan |   4 +
 31 files changed, 187 insertions(+), 141 deletions(-)

-- 
Cc: x...@kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Mauro Carvalho Chehab 
Cc: Martin Schwidefsky 
Cc: linux-s...@vger.kernel.org
Cc: Ilya Dryomov 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-...@lists.infradead.org
Cc: Herbert Xu 
Cc: linux-crypto@vger.kernel.org
Cc: "David S. Miller" 
Cc: net...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: ceph-de...@vger.kernel.org
Cc: linux-f2fs-de...@lists.sourceforge.net
Cc: linux-e...@vger.kernel.org
Cc: netfilter-de...@vger.kernel.org
2.9.0

--
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 resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

2016-10-17 Thread Stephan Mueller 
Am Montag, 17. Oktober 2016, 14:03:17 CEST schrieb Andy Lutomirski:

Hi Andy,

> On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller  
wrote:
> > Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski:
> > 
> > Hi Andy,
> > 
> >> Sure, but shouldn't that be a separate patch covering the whole hw_crypto
> >> core?
> > 
> > I think that you are right -- there are many more cases where a memset(0)
> > is warranted.
> > 
> > Do you want to make this change or should I send a patch?
> 
> Can you do it?  I have my work cut out for me making sure that all the
> known regressions get stomped quickly...

Sure, will do.

Thanks.

Ciao
Stephan
--
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 resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

2016-10-17 Thread Andy Lutomirski 
On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller  wrote:
> Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski:
>
> Hi Andy,
>>
>> Sure, but shouldn't that be a separate patch covering the whole hw_crypto
>> core?
>
> I think that you are right -- there are many more cases where a memset(0) is
> warranted.
>
> Do you want to make this change or should I send a patch?

Can you do it?  I have my work cut out for me making sure that all the
known regressions get stomped quickly...
--
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] hwrng: meson: Fix module autoload for OF registration

2016-10-17 Thread Javier Martinez Canillas 
Hello Fabio,

On 10/17/2016 04:45 PM, Fabio Estevam wrote:
> On Mon, Oct 17, 2016 at 5:40 PM, Javier Martinez Canillas
>  wrote:
> 
>> --- a/drivers/char/tpm/Kconfig
>> +++ b/drivers/char/tpm/Kconfig
>> @@ -32,7 +32,7 @@ config TCG_TIS_CORE
>>
>>  config TCG_TIS
>> tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO 
>> Interface"
>> -   depends on X86
>> +   depends on X86 || COMPILE_TEST
> 
> This is a separate change.
> 

Yes, I did a commit by mistake. Sorry about that.

Jason already pointed out and I posted a v2.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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] hwrng: meson: Fix module autoload for OF registration

2016-10-17 Thread Jason Gunthorpe 
On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote:

> Signed-off-by: Javier Martinez Canillas 
> 
>  drivers/char/hw_random/meson-rng.c | 1 +
>  drivers/char/tpm/Kconfig   | 2 +-

Looks like this patch should not have tpm in it.

Jason
--
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] hwrng: meson: Fix module autoload for OF registration

2016-10-17 Thread Fabio Estevam 
On Mon, Oct 17, 2016 at 5:40 PM, Javier Martinez Canillas
 wrote:

> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -32,7 +32,7 @@ config TCG_TIS_CORE
>
>  config TCG_TIS
> tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO 
> Interface"
> -   depends on X86
> +   depends on X86 || COMPILE_TEST

This is a separate change.
--
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

[PATCH v2] hwrng: meson: Fix module autoload for OF registration

2016-10-17 Thread Javier Martinez Canillas 
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias:  platform:meson-rng

After this patch:

$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias:  platform:meson-rng
alias:  of:N*T*Camlogic,meson-rngC*
alias:  of:N*T*Camlogic,meson-rng

Signed-off-by: Javier Martinez Canillas 

---

Changes in v2:
- Remove unrelated changes added by mistake. Suggested by Jason Gunthorpe.

 drivers/char/hw_random/meson-rng.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/hw_random/meson-rng.c 
b/drivers/char/hw_random/meson-rng.c
index 58bef39f7286..51864a509be7 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
{ .compatible = "amlogic,meson-rng", },
{},
 };
+MODULE_DEVICE_TABLE(of, meson_rng_of_match);
 
 static struct platform_driver meson_rng_driver = {
.probe  = meson_rng_probe,
-- 
2.7.4

--
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] hwrng: meson: Fix module autoload for OF registration

2016-10-17 Thread Javier Martinez Canillas 
Hello Jason,

On 10/17/2016 04:45 PM, Jason Gunthorpe wrote:
> On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote:
> 
>> Signed-off-by: Javier Martinez Canillas 
>>
>>  drivers/char/hw_random/meson-rng.c | 1 +
>>  drivers/char/tpm/Kconfig   | 2 +-
> 
> Looks like this patch should not have tpm in it.
>

Argh, yes. I had some unrelated changes in my staging area and did a
commit by mistake. Thanks a lot for pointing out and sorry for that.

I'll post a v2 without this.

> Jason
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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

[PATCH] hwrng: meson: Fix module autoload for OF registration

2016-10-17 Thread Javier Martinez Canillas 
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias:  platform:meson-rng

After this patch:

$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias:  platform:meson-rng
alias:  of:N*T*Camlogic,meson-rngC*
alias:  of:N*T*Camlogic,meson-rng

Signed-off-by: Javier Martinez Canillas 
---

 drivers/char/hw_random/meson-rng.c | 1 +
 drivers/char/tpm/Kconfig   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/meson-rng.c 
b/drivers/char/hw_random/meson-rng.c
index 58bef39f7286..51864a509be7 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
{ .compatible = "amlogic,meson-rng", },
{},
 };
+MODULE_DEVICE_TABLE(of, meson_rng_of_match);
 
 static struct platform_driver meson_rng_driver = {
.probe  = meson_rng_probe,
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 9faa0b1e7766..982ed2fe927c 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -32,7 +32,7 @@ config TCG_TIS_CORE
 
 config TCG_TIS
tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO 
Interface"
-   depends on X86
+   depends on X86 || COMPILE_TEST
select TCG_TIS_CORE
---help---
  If you have a TPM security chip that is compliant with the
-- 
2.7.4

--
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 resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

2016-10-17 Thread Stephan Mueller 
Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski:

Hi Andy,
> 
> Sure, but shouldn't that be a separate patch covering the whole hw_crypto
> core?

I think that you are right -- there are many more cases where a memset(0) is 
warranted.

Do you want to make this change or should I send a patch?

Ciao
Stephan
--
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 resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

2016-10-17 Thread Andy Lutomirski 
On Mon, Oct 17, 2016 at 10:17 AM, Stephan Mueller  wrote:
> Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski:
>
> Hi Andy,
>
>> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
>> index 9203f2d130c0..340f96e44642 100644
>> --- a/drivers/char/hw_random/core.c
>> +++ b/drivers/char/hw_random/core.c
>> @@ -84,14 +84,14 @@ static size_t rng_buffer_size(void)
>>
>>  static void add_early_randomness(struct hwrng *rng)
>>  {
>> - unsigned char bytes[16];
>>   int bytes_read;
>> + size_t size = min_t(size_t, 16, rng_buffer_size());
>>
>>   mutex_lock(_mutex);
>> - bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
>> + bytes_read = rng_get_data(rng, rng_buffer, size, 1);
>>   mutex_unlock(_mutex);
>>   if (bytes_read > 0)
>> - add_device_randomness(bytes, bytes_read);
>> + add_device_randomness(rng_buffer, bytes_read);
>
> Shouldn't there be a memset(0) of the rng_buffer at this point to avoid having
> such data lingering in memory?

Sure, but shouldn't that be a separate patch covering the whole hw_crypto core?

--Andy


-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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 resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

2016-10-17 Thread Stephan Mueller 
Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski:

Hi Andy,

> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 9203f2d130c0..340f96e44642 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -84,14 +84,14 @@ static size_t rng_buffer_size(void)
> 
>  static void add_early_randomness(struct hwrng *rng)
>  {
> - unsigned char bytes[16];
>   int bytes_read;
> + size_t size = min_t(size_t, 16, rng_buffer_size());
> 
>   mutex_lock(_mutex);
> - bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
> + bytes_read = rng_get_data(rng, rng_buffer, size, 1);
>   mutex_unlock(_mutex);
>   if (bytes_read > 0)
> - add_device_randomness(bytes, bytes_read);
> + add_device_randomness(rng_buffer, bytes_read);

Shouldn't there be a memset(0) of the rng_buffer at this point to avoid having 
such data lingering in memory?


Ciao
Stephan
--
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

[PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

2016-10-17 Thread Andy Lutomirski 
hw_random carefully avoids using a stack buffer except in
add_early_randomness().  This causes a crash in virtio_rng if
CONFIG_VMAP_STACK=y.

Reported-by: Matt Mullins 
Tested-by: Matt Mullins 
Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init")
Signed-off-by: Andy Lutomirski 
---

This fixes a crash in 4.9-rc1.

resending because I typoed the git send-email command.  I stealthily added
Matt's Tested-by, too.

 drivers/char/hw_random/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d130c0..340f96e44642 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -84,14 +84,14 @@ static size_t rng_buffer_size(void)
 
 static void add_early_randomness(struct hwrng *rng)
 {
-   unsigned char bytes[16];
int bytes_read;
+   size_t size = min_t(size_t, 16, rng_buffer_size());
 
mutex_lock(_mutex);
-   bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
+   bytes_read = rng_get_data(rng, rng_buffer, size, 1);
mutex_unlock(_mutex);
if (bytes_read > 0)
-   add_device_randomness(bytes, bytes_read);
+   add_device_randomness(rng_buffer, bytes_read);
 }
 
 static inline void cleanup_rng(struct kref *kref)
-- 
2.7.4

--
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

[PATCH -next] crypto: ccp - Fix non static symbol warning

2016-10-17 Thread Wei Yongjun 
From: Wei Yongjun 

Fixes the following sparse warning:

drivers/crypto/ccp/ccp-dev.c:44:6: warning:
 symbol 'ccp_error_codes' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/crypto/ccp/ccp-dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index cafa633..c25515a 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -41,7 +41,7 @@ struct ccp_tasklet_data {
 };
 
 /* Human-readable error strings */
-char *ccp_error_codes[] = {
+static char *ccp_error_codes[] = {
"",
"ERR 01: ILLEGAL_ENGINE",
"ERR 02: ILLEGAL_KEY_ID",

--
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

[PATCH -next] crypto: gcm - Fix error return code in crypto_gcm_create_common()

2016-10-17 Thread Wei Yongjun 
From: Wei Yongjun 

Fix to return error code -EINVAL from the invalid alg ivsize error
handling case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 crypto/gcm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/gcm.c b/crypto/gcm.c
index f624ac9..39c261d 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -672,11 +672,11 @@ static int crypto_gcm_create_common(struct 
crypto_template *tmpl,
ctr = crypto_spawn_skcipher_alg(>ctr);
 
/* We only support 16-byte blocks. */
+   err = -EINVAL;
if (crypto_skcipher_alg_ivsize(ctr) != 16)
goto out_put_ctr;
 
/* Not a stream cipher? */
-   err = -EINVAL;
if (ctr->base.cra_blocksize != 1)
goto out_put_ctr;

--
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 4/7] crypto: doc - fix separation of cipher / req API

2016-10-17 Thread Jani Nikula 
On Mon, 17 Oct 2016, Stephan Mueller  wrote:
> Am Montag, 17. Oktober 2016, 14:04:14 CEST schrieb Jani Nikula:
>
> Hi Jani,
>
>> The directive parameter is plural functions for a reason - you can
>> specify multiple functions in the same directive. Splitting this to
>> multiple directives causes the header file to be parsed again for each
>> directive.
>> 
>> IMO this can be fixed in a follow-up patch. Same for other patches in
>> this series.
>
> Thank you very much for the hint. I followed the path what the DocBook
> to Sphinx converter generated. I will change it in my patchset, but
> may I suggest that the converter tool (tmplcvt) should be fixed, too?

I don't think it's worth the trouble.

Now it's a straightforward docproc directive to Sphinx kernel-doc
directive extension conversion, with one-to-one mapping. It would be
quite a bit more complicated to gather all of the consecutive directives
together, in a rather quickly hacked up tool which we'll throw away once
all DocBooks have been converted over.

And as I said, I think you can fix this up afterwards too. It's not
broken, it's just a bit slower.

BR,
Jani.


-- 
Jani Nikula, 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 4/7] crypto: doc - fix separation of cipher / req API

2016-10-17 Thread Stephan Mueller 
Am Montag, 17. Oktober 2016, 14:04:14 CEST schrieb Jani Nikula:

Hi Jani,

> The directive parameter is plural functions for a reason - you can
> specify multiple functions in the same directive. Splitting this to
> multiple directives causes the header file to be parsed again for each
> directive.
> 
> IMO this can be fixed in a follow-up patch. Same for other patches in
> this series.

Thank you very much for the hint. I followed the path what the DocBook to 
Sphinx converter generated. I will change it in my patchset, but may I suggest 
that the converter tool (tmplcvt) should be fixed, too?

Ciao
Stephan
--
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

[RESEND][PATCH] crypto: caam: add support for iMX6UL

2016-10-17 Thread Marcus Folkesson 
i.MX6UL does only require three clocks to enable CAAM module.

Signed-off-by: Marcus Folkesson 
Acked-by: Rob Herring 
Reviewed-by: Horia Geantă 
---
 .../devicetree/bindings/crypto/fsl-sec4.txt| 20 +
 drivers/crypto/caam/ctrl.c | 35 --
 2 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt 
b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index adeca34..10a425f 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -123,6 +123,9 @@ PROPERTIES
 
 
 EXAMPLE
+
+iMX6QDL/SX requires four clocks
+
crypto@30 {
compatible = "fsl,sec-v4.0";
fsl,sec-era = <2>;
@@ -139,6 +142,23 @@ EXAMPLE
clock-names = "mem", "aclk", "ipg", "emi_slow";
};
 
+
+iMX6UL does only require three clocks
+
+   crypto: caam@214 {
+   compatible = "fsl,sec-v4.0";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x214 0x3c000>;
+   ranges = <0 0x214 0x3c000>;
+   interrupts = ;
+
+   clocks = < IMX6UL_CLK_CAAM_MEM>,
+< IMX6UL_CLK_CAAM_ACLK>,
+< IMX6UL_CLK_CAAM_IPG>;
+   clock-names = "mem", "aclk", "ipg";
+   };
+
 =
 Job Ring (JR) Node
 
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0ec112e..5abaf37 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -329,8 +329,8 @@ static int caam_remove(struct platform_device *pdev)
clk_disable_unprepare(ctrlpriv->caam_ipg);
clk_disable_unprepare(ctrlpriv->caam_mem);
clk_disable_unprepare(ctrlpriv->caam_aclk);
-   clk_disable_unprepare(ctrlpriv->caam_emi_slow);
-
+   if (!of_machine_is_compatible("fsl,imx6ul"))
+   clk_disable_unprepare(ctrlpriv->caam_emi_slow);
return 0;
 }
 
@@ -481,14 +481,16 @@ static int caam_probe(struct platform_device *pdev)
}
ctrlpriv->caam_aclk = clk;
 
-   clk = caam_drv_identify_clk(>dev, "emi_slow");
-   if (IS_ERR(clk)) {
-   ret = PTR_ERR(clk);
-   dev_err(>dev,
-   "can't identify CAAM emi_slow clk: %d\n", ret);
-   return ret;
+   if (!of_machine_is_compatible("fsl,imx6ul")) {
+   clk = caam_drv_identify_clk(>dev, "emi_slow");
+   if (IS_ERR(clk)) {
+   ret = PTR_ERR(clk);
+   dev_err(>dev,
+   "can't identify CAAM emi_slow clk: %d\n", ret);
+   return ret;
+   }
+   ctrlpriv->caam_emi_slow = clk;
}
-   ctrlpriv->caam_emi_slow = clk;
 
ret = clk_prepare_enable(ctrlpriv->caam_ipg);
if (ret < 0) {
@@ -509,11 +511,13 @@ static int caam_probe(struct platform_device *pdev)
goto disable_caam_mem;
}
 
-   ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
-   if (ret < 0) {
-   dev_err(>dev, "can't enable CAAM emi slow clock: %d\n",
-   ret);
-   goto disable_caam_aclk;
+   if (!of_machine_is_compatible("fsl,imx6ul")) {
+   ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
+   if (ret < 0) {
+   dev_err(>dev, "can't enable CAAM emi slow clock: 
%d\n",
+   ret);
+   goto disable_caam_aclk;
+   }
}
 
/* Get configuration properties from device tree */
@@ -829,7 +833,8 @@ caam_remove:
 iounmap_ctrl:
iounmap(ctrl);
 disable_caam_emi_slow:
-   clk_disable_unprepare(ctrlpriv->caam_emi_slow);
+   if (!of_machine_is_compatible("fsl,imx6ul"))
+   clk_disable_unprepare(ctrlpriv->caam_emi_slow);
 disable_caam_aclk:
clk_disable_unprepare(ctrlpriv->caam_aclk);
 disable_caam_mem:
-- 
2.8.0

--
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 4/7] crypto: doc - fix separation of cipher / req API

2016-10-17 Thread Jani Nikula 
On Sun, 16 Oct 2016, Stephan Mueller  wrote:
> Keep the cipher API and the request API function documentation in
> separate sections.
>
> Signed-off-by: Stephan Mueller 
> ---
>  Documentation/crypto/api-akcipher.rst | 25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/crypto/api-akcipher.rst 
> b/Documentation/crypto/api-akcipher.rst
> index 305e616..0d5899f 100644
> --- a/Documentation/crypto/api-akcipher.rst
> +++ b/Documentation/crypto/api-akcipher.rst
> @@ -25,32 +25,32 @@ Asymmetric Cipher API
>  .. kernel-doc:: include/crypto/akcipher.h
> :functions: crypto_akcipher_set_priv_key
>  
> -Asymmetric Cipher Request Handle
> -
> -
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: akcipher_request_alloc
> +   :functions: crypto_akcipher_maxsize
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: akcipher_request_free
> +   :functions: crypto_akcipher_encrypt
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: akcipher_request_set_callback
> +   :functions: crypto_akcipher_decrypt
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: akcipher_request_set_crypt
> +   :functions: crypto_akcipher_sign
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: crypto_akcipher_maxsize
> +   :functions: crypto_akcipher_verify

The directive parameter is plural functions for a reason - you can
specify multiple functions in the same directive. Splitting this to
multiple directives causes the header file to be parsed again for each
directive.

IMO this can be fixed in a follow-up patch. Same for other patches in
this series.

BR,
Jani.


> +
> +Asymmetric Cipher Request Handle
> +
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: crypto_akcipher_encrypt
> +   :functions: akcipher_request_alloc
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: crypto_akcipher_decrypt
> +   :functions: akcipher_request_free
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: crypto_akcipher_sign
> +   :functions: akcipher_request_set_callback
>  
>  .. kernel-doc:: include/crypto/akcipher.h
> -   :functions: crypto_akcipher_verify
> +   :functions: akcipher_request_set_crypt

-- 
Jani Nikula, 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

[PATCH] padata: Remove unused but set variables

2016-10-17 Thread Tobias Klauser 
Remove the unused but set variable pinst in padata_parallel_worker to
fix the following warning when building with 'W=1':

  kernel/padata.c: In function ‘padata_parallel_worker’:
  kernel/padata.c:68:26: warning: variable ‘pinst’ set but not used 
[-Wunused-but-set-variable]

Also remove the now unused variable pd which is only used to set pinst.

Signed-off-by: Tobias Klauser 
---
 kernel/padata.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/kernel/padata.c b/kernel/padata.c
index 7848f0566403..05316c9f32da 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -64,15 +64,11 @@ static int padata_cpu_hash(struct parallel_data *pd)
 static void padata_parallel_worker(struct work_struct *parallel_work)
 {
struct padata_parallel_queue *pqueue;
-   struct parallel_data *pd;
-   struct padata_instance *pinst;
LIST_HEAD(local_list);
 
local_bh_disable();
pqueue = container_of(parallel_work,
  struct padata_parallel_queue, work);
-   pd = pqueue->pd;
-   pinst = pd->pinst;
 
spin_lock(>parallel.lock);
list_replace_init(>parallel.list, _list);
-- 
2.9.0


--
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