* Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Theodore Ts'o @ 2016-12-22 15:58 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kernel-hardening, Hannes Frederic Sowa, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9o=yLOLr2w3xYj2up-UW0tXtv=0A5ffiTiVCCHkv6Twxg@mail.gmail.com>
On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote:
> I find this compelling. We'll have one csprng for both
> get_random_int/long and for /dev/urandom, and we'll be able to update
> that silly warning on the comment of get_random_int/long to read
> "gives output of either rdrand quality or of /dev/urandom quality",
> which makes it more useful for other things. It introduces less error
> prone code, and it lets the RNG analysis be spent on just one RNG, not
> two.
>
> So, with your blessing, I'm going to move ahead with implementing a
> pretty version of this for v8.
Can we do this as a separate series, please? At this point, it's a
completely separate change from a logical perspective, and we can take
in the change through the random.git tree.
Changes that touch files that are normally changed in several
different git trees leads to the potential for merge conflicts during
the linux-next integration and merge window processes. Which is why
it's generally best to try to isolate changes as much as possible.
Cheers,
- Ted
^ permalink raw reply
* Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Theodore Ts'o @ 2016-12-22 15:54 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kernel-hardening, Andy Lutomirski, Netdev, LKML,
Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9r_zTHo=dxRRK6UrjJ_dKV14yYsZsxCc362z4CPoVkddw@mail.gmail.com>
On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > following up on what appears to be a random subject: ;)
> >
> > IIRC, ext4 code by default still uses half_md4 for hashing of filenames
> > in the htree. siphash seems to fit this use case pretty good.
>
> I saw this too. I'll try to address it in v8 of this series.
This is a separate issue, and this series is getting a bit too
complex. So I'd suggest pushing this off to a separate change.
Changing the htree hash algorithm is an on-disk format change, and so
we couldn't roll it out until e2fsprogs gets updated and rolled out
pretty broadley. In fact George sent me patches to add siphash as a
hash algorithm for htree a while back (for both the kernel and
e2fsprogs), but I never got around to testing and applying them,
mainly because while it's technically faster, I had other higher
priority issues to work on --- and see previous comments regarding
pixel peeping. Improving the hash algorithm by tens or even hundreds
of nanoseconds isn't really going to matter since we only do a htree
lookup on a file creation or cold cache lookup, and the SSD or HDD I/O
times will dominate. And from the power perspective, saving
microwatts of CPU power isn't going to matter if you're going to be
spinning up the storage device....
- Ted
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Jason A. Donenfeld @ 2016-12-22 15:53 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <1482421900.2673.3.camel@stressinduktion.org>
On Thu, Dec 22, 2016 at 4:51 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> This algorithm should be a non-seeded algorithm, because the hashes
> should be stable and verifiable by user space tooling. Thus this would
> need a hashing algorithm that is hardened against pre-image
> attacks/collision resistance, which siphash is not. I would prefer some
> higher order SHA algorithm for that actually.
Right. SHA-256, SHA-512/256, Blake2s, or Blake2b would probably be
good candidates for this.
^ permalink raw reply
* Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Hannes Frederic Sowa @ 2016-12-22 15:51 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9ok8iWfZybyDki13v6Xf3usRet1y8oUcDcy+5YwkARQPA@mail.gmail.com>
On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
> Hi Hannes,
>
> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
> > You don't want to give people new IPv6 addresses with the same stable
> > secret (across reboots) after a kernel upgrade. Maybe they lose
> > connectivity then and it is extra work?
>
> Ahh, too bad. So it goes.
If no other users survive we can put it into the ipv6 module.
> > The bpf hash stuff can be changed during this merge window, as it is
> > not yet in a released kernel. Albeit I would probably have preferred
> > something like sha256 here, which can be easily replicated by user
> > space tools (minus the problem of patching out references to not
> > hashable data, which must be zeroed).
>
> Oh, interesting, so time is of the essence then. Do you want to handle
> changing the new eBPF code to something not-SHA1 before it's too late,
> as part of a new patchset that can fast track itself to David? And
> then I can preserve my large series for the next merge window.
This algorithm should be a non-seeded algorithm, because the hashes
should be stable and verifiable by user space tooling. Thus this would
need a hashing algorithm that is hardened against pre-image
attacks/collision resistance, which siphash is not. I would prefer some
higher order SHA algorithm for that actually.
Bye,
Hannes
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Jason A. Donenfeld @ 2016-12-22 15:41 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <1482420815.2673.1.camel@stressinduktion.org>
Hi Hannes,
On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
> You don't want to give people new IPv6 addresses with the same stable
> secret (across reboots) after a kernel upgrade. Maybe they lose
> connectivity then and it is extra work?
Ahh, too bad. So it goes.
> The bpf hash stuff can be changed during this merge window, as it is
> not yet in a released kernel. Albeit I would probably have preferred
> something like sha256 here, which can be easily replicated by user
> space tools (minus the problem of patching out references to not
> hashable data, which must be zeroed).
Oh, interesting, so time is of the essence then. Do you want to handle
changing the new eBPF code to something not-SHA1 before it's too late,
as part of a new patchset that can fast track itself to David? And
then I can preserve my large series for the next merge window.
Jason
^ permalink raw reply
* Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Hannes Frederic Sowa @ 2016-12-22 15:33 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9pu-2CY2WRHevnpwo-9qnZcTpqQgC2voGFOpSjo+LPiUA@mail.gmail.com>
On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > As a first step, I'm considering adding a patch to move halfmd4.c
> > inside the ext4 domain, or at the very least, simply remove it from
> > linux/cryptohash.h. That'll then leave the handful of bizarre sha1
> > usages to consider.
>
> Specifically something like this:
>
> https://git.zx2c4.com/linux-dev/commit/?h=siphash&id=978213351f9633bd1e3d1fdc3f19d28e36eeac90
>
> That only leaves two more uses of "cryptohash" to consider, but they
> require a bit of help. First, sha_transform in net/ipv6/addrconf.c.
> That might be a straight-forward conversion to SipHash, but perhaps
> not; I need to look closely and think about it. The next is
> sha_transform in kernel/bpf/core.c. I really have no idea what's going
> on with the eBPF stuff, so that will take a bit longer to study. Maybe
> sha1 is fine in the end there? I'm not sure yet.
IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
You don't want to give people new IPv6 addresses with the same stable
secret (across reboots) after a kernel upgrade. Maybe they lose
connectivity then and it is extra work?
The bpf hash stuff can be changed during this merge window, as it is
not yet in a released kernel. Albeit I would probably have preferred
something like sha256 here, which can be easily replicated by user
space tools (minus the problem of patching out references to not
hashable data, which must be zeroed).
Bye,
Hannes
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Jason A. Donenfeld @ 2016-12-22 15:29 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9qZviooxOW+e=khazG0phSEWwZyKj=eayre_7hs8d+cQw@mail.gmail.com>
On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> As a first step, I'm considering adding a patch to move halfmd4.c
> inside the ext4 domain, or at the very least, simply remove it from
> linux/cryptohash.h. That'll then leave the handful of bizarre sha1
> usages to consider.
Specifically something like this:
https://git.zx2c4.com/linux-dev/commit/?h=siphash&id=978213351f9633bd1e3d1fdc3f19d28e36eeac90
That only leaves two more uses of "cryptohash" to consider, but they
require a bit of help. First, sha_transform in net/ipv6/addrconf.c.
That might be a straight-forward conversion to SipHash, but perhaps
not; I need to look closely and think about it. The next is
sha_transform in kernel/bpf/core.c. I really have no idea what's going
on with the eBPF stuff, so that will take a bit longer to study. Maybe
sha1 is fine in the end there? I'm not sure yet.
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Jason A. Donenfeld @ 2016-12-22 15:12 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <5c306c80-3499-8b92-21d0-c197f30ce326@stressinduktion.org>
On Thu, Dec 22, 2016 at 4:05 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> This change would need a new version of the ext4 super block, because
> you should not change existing file systems.
Right.
As a first step, I'm considering adding a patch to move halfmd4.c
inside the ext4 domain, or at the very least, simply remove it from
linux/cryptohash.h. That'll then leave the handful of bizarre sha1
usages to consider.
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Hannes Frederic Sowa @ 2016-12-22 15:05 UTC (permalink / raw)
To: Jason A. Donenfeld, kernel-hardening
Cc: Theodore Ts'o, Andy Lutomirski, Netdev, LKML,
Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9r_zTHo=dxRRK6UrjJ_dKV14yYsZsxCc362z4CPoVkddw@mail.gmail.com>
On 22.12.2016 14:10, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> following up on what appears to be a random subject: ;)
>>
>> IIRC, ext4 code by default still uses half_md4 for hashing of filenames
>> in the htree. siphash seems to fit this use case pretty good.
>
> I saw this too. I'll try to address it in v8 of this series.
This change would need a new version of the ext4 super block, because
you should not change existing file systems.
^ permalink raw reply
* [PATCH] crypto: qat - increase number of supported devices
From: Giovanni Cabiddu @ 2016-12-22 15:01 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, giovanni.cabiddu, Xin Zeng, Giovanni Cabiddu
From: Xin Zeng <xin.zeng@intel.com>
The unsigned long type for init_status and start_status in
service_hndl are not long enough to represent more than 64
acceleration devices. Use an array instead.
Signed-off-by: Xin Zeng <xin.zeng@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/adf_cfg_common.h | 1 +
drivers/crypto/qat/qat_common/adf_common_drv.h | 4 ++--
drivers/crypto/qat/qat_common/adf_init.c | 28 +++++++++++++++-----------
3 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_cfg_common.h b/drivers/crypto/qat/qat_common/adf_cfg_common.h
index 8c4f657..1211261 100644
--- a/drivers/crypto/qat/qat_common/adf_cfg_common.h
+++ b/drivers/crypto/qat/qat_common/adf_cfg_common.h
@@ -61,6 +61,7 @@
#define ADF_CFG_AFFINITY_WHATEVER 0xFF
#define MAX_DEVICE_NAME_SIZE 32
#define ADF_MAX_DEVICES (32 * 32)
+#define ADF_DEVS_ARRAY_SIZE BITS_TO_LONGS(ADF_MAX_DEVICES)
enum adf_cfg_val_type {
ADF_DEC,
diff --git a/drivers/crypto/qat/qat_common/adf_common_drv.h b/drivers/crypto/qat/qat_common/adf_common_drv.h
index 980e074..5c4c0a2 100644
--- a/drivers/crypto/qat/qat_common/adf_common_drv.h
+++ b/drivers/crypto/qat/qat_common/adf_common_drv.h
@@ -87,8 +87,8 @@ enum adf_event {
struct service_hndl {
int (*event_hld)(struct adf_accel_dev *accel_dev,
enum adf_event event);
- unsigned long init_status;
- unsigned long start_status;
+ unsigned long init_status[ADF_DEVS_ARRAY_SIZE];
+ unsigned long start_status[ADF_DEVS_ARRAY_SIZE];
char *name;
struct list_head list;
};
diff --git a/drivers/crypto/qat/qat_common/adf_init.c b/drivers/crypto/qat/qat_common/adf_init.c
index 888c667..26556c7 100644
--- a/drivers/crypto/qat/qat_common/adf_init.c
+++ b/drivers/crypto/qat/qat_common/adf_init.c
@@ -64,8 +64,8 @@ static void adf_service_add(struct service_hndl *service)
int adf_service_register(struct service_hndl *service)
{
- service->init_status = 0;
- service->start_status = 0;
+ memset(service->init_status, 0, sizeof(service->init_status));
+ memset(service->start_status, 0, sizeof(service->start_status));
adf_service_add(service);
return 0;
}
@@ -79,9 +79,13 @@ static void adf_service_remove(struct service_hndl *service)
int adf_service_unregister(struct service_hndl *service)
{
- if (service->init_status || service->start_status) {
- pr_err("QAT: Could not remove active service\n");
- return -EFAULT;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(service->init_status); i++) {
+ if (service->init_status[i] || service->start_status[i]) {
+ pr_err("QAT: Could not remove active service\n");
+ return -EFAULT;
+ }
}
adf_service_remove(service);
return 0;
@@ -163,7 +167,7 @@ int adf_dev_init(struct adf_accel_dev *accel_dev)
service->name);
return -EFAULT;
}
- set_bit(accel_dev->accel_id, &service->init_status);
+ set_bit(accel_dev->accel_id, service->init_status);
}
hw_data->enable_error_correction(accel_dev);
@@ -210,7 +214,7 @@ int adf_dev_start(struct adf_accel_dev *accel_dev)
service->name);
return -EFAULT;
}
- set_bit(accel_dev->accel_id, &service->start_status);
+ set_bit(accel_dev->accel_id, service->start_status);
}
clear_bit(ADF_STATUS_STARTING, &accel_dev->status);
@@ -259,14 +263,14 @@ void adf_dev_stop(struct adf_accel_dev *accel_dev)
list_for_each(list_itr, &service_table) {
service = list_entry(list_itr, struct service_hndl, list);
- if (!test_bit(accel_dev->accel_id, &service->start_status))
+ if (!test_bit(accel_dev->accel_id, service->start_status))
continue;
ret = service->event_hld(accel_dev, ADF_EVENT_STOP);
if (!ret) {
- clear_bit(accel_dev->accel_id, &service->start_status);
+ clear_bit(accel_dev->accel_id, service->start_status);
} else if (ret == -EAGAIN) {
wait = true;
- clear_bit(accel_dev->accel_id, &service->start_status);
+ clear_bit(accel_dev->accel_id, service->start_status);
}
}
@@ -317,14 +321,14 @@ void adf_dev_shutdown(struct adf_accel_dev *accel_dev)
list_for_each(list_itr, &service_table) {
service = list_entry(list_itr, struct service_hndl, list);
- if (!test_bit(accel_dev->accel_id, &service->init_status))
+ if (!test_bit(accel_dev->accel_id, service->init_status))
continue;
if (service->event_hld(accel_dev, ADF_EVENT_SHUTDOWN))
dev_err(&GET_DEV(accel_dev),
"Failed to shutdown service %s\n",
service->name);
else
- clear_bit(accel_dev->accel_id, &service->init_status);
+ clear_bit(accel_dev->accel_id, service->init_status);
}
hw_data->disable_iov(accel_dev);
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: qat - initialize cra_flags before register into kpp
From: Giovanni Cabiddu @ 2016-12-22 15:00 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, giovanni.cabiddu, Giovanni Cabiddu, Sushil Kumar
Initialize dh.base.cra_flags before registering the dh algorithm.
Without this fix, the registration of the dh algorithm might fail
if the qat driver is restarted.
Signed-off-by: Sushil Kumar <sushilx.kumar@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/qat_asym_algs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c b/drivers/crypto/qat/qat_common/qat_asym_algs.c
index 0d35dca..d3518e6 100644
--- a/drivers/crypto/qat/qat_common/qat_asym_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c
@@ -1343,6 +1343,7 @@ int qat_asym_algs_register(void)
ret = crypto_register_akcipher(&rsa);
if (ret)
goto unlock;
+ dh.base.cra_flags = 0;
ret = crypto_register_kpp(&dh);
}
unlock:
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: qat - modify format of dev top level debugfs entries
From: Giovanni Cabiddu @ 2016-12-22 15:00 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, giovanni.cabiddu, Pablo Marcos Oltra,
Giovanni Cabiddu
From: Pablo Marcos Oltra <pablo.marcos.oltra@intel.com>
Remove leading zeros in pci function number to be consistent
with output from lspci.
Signed-off-by: Pablo Marcos Oltra <pablo.marcos.oltra@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_c3xxx/adf_drv.c | 2 +-
drivers/crypto/qat/qat_c3xxxvf/adf_drv.c | 2 +-
drivers/crypto/qat/qat_c62x/adf_drv.c | 2 +-
drivers/crypto/qat/qat_c62xvf/adf_drv.c | 2 +-
drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 2 +-
drivers/crypto/qat/qat_dh895xccvf/adf_drv.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/qat/qat_c3xxx/adf_drv.c b/drivers/crypto/qat/qat_c3xxx/adf_drv.c
index 640c3fc..f172171 100644
--- a/drivers/crypto/qat/qat_c3xxx/adf_drv.c
+++ b/drivers/crypto/qat/qat_c3xxx/adf_drv.c
@@ -186,7 +186,7 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
/* Create dev top level debugfs entry */
- snprintf(name, sizeof(name), "%s%s_%02x:%02d.%02d",
+ snprintf(name, sizeof(name), "%s%s_%02x:%02d.%d",
ADF_DEVICE_NAME_PREFIX, hw_data->dev_class->name,
pdev->bus->number, PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
diff --git a/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c b/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c
index 949d77b..24ec908 100644
--- a/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c
+++ b/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c
@@ -170,7 +170,7 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
accel_pci_dev->sku = hw_data->get_sku(hw_data);
/* Create dev top level debugfs entry */
- snprintf(name, sizeof(name), "%s%s_%02x:%02d.%02d",
+ snprintf(name, sizeof(name), "%s%s_%02x:%02d.%d",
ADF_DEVICE_NAME_PREFIX, hw_data->dev_class->name,
pdev->bus->number, PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
diff --git a/drivers/crypto/qat/qat_c62x/adf_drv.c b/drivers/crypto/qat/qat_c62x/adf_drv.c
index 5b2d78a..58a984c9 100644
--- a/drivers/crypto/qat/qat_c62x/adf_drv.c
+++ b/drivers/crypto/qat/qat_c62x/adf_drv.c
@@ -186,7 +186,7 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
/* Create dev top level debugfs entry */
- snprintf(name, sizeof(name), "%s%s_%02x:%02d.%02d",
+ snprintf(name, sizeof(name), "%s%s_%02x:%02d.%d",
ADF_DEVICE_NAME_PREFIX, hw_data->dev_class->name,
pdev->bus->number, PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
diff --git a/drivers/crypto/qat/qat_c62xvf/adf_drv.c b/drivers/crypto/qat/qat_c62xvf/adf_drv.c
index 7540ce1..b9f3e0e 100644
--- a/drivers/crypto/qat/qat_c62xvf/adf_drv.c
+++ b/drivers/crypto/qat/qat_c62xvf/adf_drv.c
@@ -170,7 +170,7 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
accel_pci_dev->sku = hw_data->get_sku(hw_data);
/* Create dev top level debugfs entry */
- snprintf(name, sizeof(name), "%s%s_%02x:%02d.%02d",
+ snprintf(name, sizeof(name), "%s%s_%02x:%02d.%d",
ADF_DEVICE_NAME_PREFIX, hw_data->dev_class->name,
pdev->bus->number, PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
diff --git a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
index 4d2de28..2ce01f0 100644
--- a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
+++ b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
@@ -186,7 +186,7 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
/* Create dev top level debugfs entry */
- snprintf(name, sizeof(name), "%s%s_%02x:%02d.%02d",
+ snprintf(name, sizeof(name), "%s%s_%02x:%02d.%d",
ADF_DEVICE_NAME_PREFIX, hw_data->dev_class->name,
pdev->bus->number, PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
diff --git a/drivers/crypto/qat/qat_dh895xccvf/adf_drv.c b/drivers/crypto/qat/qat_dh895xccvf/adf_drv.c
index 60df986..26ab17b 100644
--- a/drivers/crypto/qat/qat_dh895xccvf/adf_drv.c
+++ b/drivers/crypto/qat/qat_dh895xccvf/adf_drv.c
@@ -170,7 +170,7 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
accel_pci_dev->sku = hw_data->get_sku(hw_data);
/* Create dev top level debugfs entry */
- snprintf(name, sizeof(name), "%s%s_%02x:%02d.%02d",
+ snprintf(name, sizeof(name), "%s%s_%02x:%02d.%d",
ADF_DEVICE_NAME_PREFIX, hw_data->dev_class->name,
pdev->bus->number, PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: qat - zero esram only for DH85x devices
From: Giovanni Cabiddu @ 2016-12-22 15:00 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, giovanni.cabiddu, Giovanni Cabiddu
Zero embedded ram in DH85x devices. This is not
needed for newer generations as it is done by HW.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/qat_hal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_hal.c b/drivers/crypto/qat/qat_common/qat_hal.c
index 1e480f1..8c4fd25 100644
--- a/drivers/crypto/qat/qat_common/qat_hal.c
+++ b/drivers/crypto/qat/qat_common/qat_hal.c
@@ -456,7 +456,7 @@ static int qat_hal_init_esram(struct icp_qat_fw_loader_handle *handle)
unsigned int csr_val;
int times = 30;
- if (handle->pci_dev->device == ADF_C3XXX_PCI_DEVICE_ID)
+ if (handle->pci_dev->device != ADF_DH895XCC_PCI_DEVICE_ID)
return 0;
csr_val = ADF_CSR_RD(csr_addr, 0);
@@ -716,7 +716,7 @@ int qat_hal_init(struct adf_accel_dev *accel_dev)
(void __iomem *)((uintptr_t)handle->hal_cap_ae_xfer_csr_addr_v +
LOCAL_TO_XFER_REG_OFFSET);
handle->pci_dev = pci_info->pci_dev;
- if (handle->pci_dev->device != ADF_C3XXX_PCI_DEVICE_ID) {
+ if (handle->pci_dev->device == ADF_DH895XCC_PCI_DEVICE_ID) {
sram_bar =
&pci_info->pci_bars[hw_data->get_sram_bar_id(hw_data)];
handle->hal_sram_addr_v = sram_bar->virt_addr;
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: qat - fix bar discovery for c62x
From: Giovanni Cabiddu @ 2016-12-22 15:00 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, giovanni.cabiddu, Giovanni Cabiddu
Some accelerators of the c62x series have only two bars.
This patch skips BAR0 if the accelerator does not have it.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_c62x/adf_drv.c | 2 +-
drivers/crypto/qat/qat_common/adf_accel_devices.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/qat_c62x/adf_drv.c b/drivers/crypto/qat/qat_c62x/adf_drv.c
index bc5cbc1..5b2d78a 100644
--- a/drivers/crypto/qat/qat_c62x/adf_drv.c
+++ b/drivers/crypto/qat/qat_c62x/adf_drv.c
@@ -233,7 +233,7 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
&hw_data->accel_capabilities_mask);
/* Find and map all the device's BARS */
- i = 0;
+ i = (hw_data->fuses & ADF_DEVICE_FUSECTL_MASK) ? 1 : 0;
bar_mask = pci_select_bars(pdev, IORESOURCE_MEM);
for_each_set_bit(bar_nr, (const unsigned long *)&bar_mask,
ADF_PCI_MAX_BARS * 2) {
diff --git a/drivers/crypto/qat/qat_common/adf_accel_devices.h b/drivers/crypto/qat/qat_common/adf_accel_devices.h
index e882253..33f0a62 100644
--- a/drivers/crypto/qat/qat_common/adf_accel_devices.h
+++ b/drivers/crypto/qat/qat_common/adf_accel_devices.h
@@ -69,6 +69,7 @@
#define ADF_ERRSOU5 (0x3A000 + 0xD8)
#define ADF_DEVICE_FUSECTL_OFFSET 0x40
#define ADF_DEVICE_LEGFUSE_OFFSET 0x4C
+#define ADF_DEVICE_FUSECTL_MASK 0x80000000
#define ADF_PCI_MAX_BARS 3
#define ADF_DEVICE_NAME_LENGTH 32
#define ADF_ETR_MAX_RINGS_PER_BANK 16
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: qat - replace hardcoded BIT(0) in vf_isr
From: Giovanni Cabiddu @ 2016-12-22 14:59 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, giovanni.cabiddu, Giovanni Cabiddu
Replace BIT(0) macro with proper definition in pf2vf path
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/adf_vf_isr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_vf_isr.c b/drivers/crypto/qat/qat_common/adf_vf_isr.c
index bf99e11..4a73fc7 100644
--- a/drivers/crypto/qat/qat_common/adf_vf_isr.c
+++ b/drivers/crypto/qat/qat_common/adf_vf_isr.c
@@ -148,7 +148,7 @@ static void adf_pf2vf_bh_handler(void *data)
INIT_WORK(&stop_data->work, adf_dev_stop_async);
queue_work(adf_vf_stop_wq, &stop_data->work);
/* To ack, clear the PF2VFINT bit */
- msg &= ~BIT(0);
+ msg &= ~ADF_PF2VF_INT;
ADF_CSR_WR(pmisc_bar_addr, hw_data->get_pf2vf_offset(0), msg);
return;
}
@@ -168,7 +168,7 @@ static void adf_pf2vf_bh_handler(void *data)
}
/* To ack, clear the PF2VFINT bit */
- msg &= ~BIT(0);
+ msg &= ~ADF_PF2VF_INT;
ADF_CSR_WR(pmisc_bar_addr, hw_data->get_pf2vf_offset(0), msg);
/* Re-enable PF2VF interrupts */
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: qat - fix comments describing adf_disable_sriov()
From: Giovanni Cabiddu @ 2016-12-22 14:59 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, giovanni.cabiddu, Ahsan Atta, Giovanni Cabiddu
From: Ahsan Atta <ahsan.atta@intel.com>
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/adf_sriov.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_sriov.c b/drivers/crypto/qat/qat_common/adf_sriov.c
index 9320ae1..b36d865 100644
--- a/drivers/crypto/qat/qat_common/adf_sriov.c
+++ b/drivers/crypto/qat/qat_common/adf_sriov.c
@@ -162,9 +162,9 @@ static int adf_enable_sriov(struct adf_accel_dev *accel_dev)
/**
* adf_disable_sriov() - Disable SRIOV for the device
- * @pdev: Pointer to pci device.
+ * @accel_dev: Pointer to accel device.
*
- * Function disables SRIOV for the pci device.
+ * Function disables SRIOV for the accel device.
*
* Return: 0 on success, error code otherwise.
*/
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: qat - fix indentation
From: Giovanni Cabiddu @ 2016-12-22 14:58 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, giovanni.cabiddu, Ahsan Atta, Giovanni Cabiddu
From: Ahsan Atta <ahsan.atta@intel.com>
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/adf_dev_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/qat_common/adf_dev_mgr.c b/drivers/crypto/qat/qat_common/adf_dev_mgr.c
index b3ebb25..8afac52 100644
--- a/drivers/crypto/qat/qat_common/adf_dev_mgr.c
+++ b/drivers/crypto/qat/qat_common/adf_dev_mgr.c
@@ -152,7 +152,7 @@ void adf_devmgr_update_class_index(struct adf_hw_device_data *hw_data)
ptr->hw_device->instance_id = i++;
if (i == class->instances)
- break;
+ break;
}
}
EXPORT_SYMBOL_GPL(adf_devmgr_update_class_index);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v6 1/2] sparc: fix a building error reported by kbuild
From: Anatoly Pugachev @ 2016-12-22 14:58 UTC (permalink / raw)
To: sparclinux@vger.kernel.org
Cc: Sam Ravnborg, linux-crypto@vger.kernel.org, Gonglei (Arei),
virtio-dev
In-Reply-To: <33183CC9F5247A488A2544077AF19020DA159386@DGGEMA505-MBX.china.huawei.com>
Guys,
so was it fixed or not?
I can not compile current git kernel:
linux-2.6$ git desc
v4.9-11937-g52bce91165e5
linux-2.6$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
linux-2.6$ git log --oneline arch/sparc/include/asm/topology_64.h | head -1
541cc39433a8 sparc: fix a building error reported by kbuild
linux-2.6$ make
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
<stdin>:1316:2: warning: #warning syscall pkey_mprotect not implemented [-Wcpp]
<stdin>:1319:2: warning: #warning syscall pkey_alloc not implemented [-Wcpp]
<stdin>:1322:2: warning: #warning syscall pkey_free not implemented [-Wcpp]
CHK include/generated/compile.h
GEN usr/initramfs_data.cpio".gz"
AS usr/initramfs_data.o
LD usr/built-in.o
CHK kernel/config_data.h
CC [M] drivers/crypto/virtio/virtio_crypto_mgr.o
In file included from ./arch/sparc/include/asm/topology.h:4:0,
from ./include/linux/topology.h:35,
from ./include/linux/gfp.h:8,
from ./include/linux/kmod.h:22,
from ./include/linux/module.h:13,
from drivers/crypto/virtio/virtio_crypto_mgr.c:21:
drivers/crypto/virtio/virtio_crypto_common.h: In function
‘virtio_crypto_get_current_node’:
./arch/sparc/include/asm/topology_64.h:45:44: error: implicit
declaration of function ‘cpu_data’
[-Werror=implicit-function-declaration]
#define topology_physical_package_id(cpu) (cpu_data(cpu).proc_id)
^
drivers/crypto/virtio/virtio_crypto_common.h:119:9: note: in expansion
of macro ‘topology_physical_package_id’
node = topology_physical_package_id(cpu);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./arch/sparc/include/asm/topology_64.h:45:57: error: request for
member ‘proc_id’ in something not a structure or union
#define topology_physical_package_id(cpu) (cpu_data(cpu).proc_id)
^
drivers/crypto/virtio/virtio_crypto_common.h:119:9: note: in expansion
of macro ‘topology_physical_package_id’
node = topology_physical_package_id(cpu);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:293: recipe for target
'drivers/crypto/virtio/virtio_crypto_mgr.o' failed
make[3]: *** [drivers/crypto/virtio/virtio_crypto_mgr.o] Error 1
scripts/Makefile.build:551: recipe for target 'drivers/crypto/virtio' failed
make[2]: *** [drivers/crypto/virtio] Error 2
scripts/Makefile.build:551: recipe for target 'drivers/crypto' failed
make[1]: *** [drivers/crypto] Error 2
Makefile:988: recipe for target 'drivers' failed
make: *** [drivers] Error 2
linux-2.6$
^ permalink raw reply
* Re: [PATCH 1/3] crypto: Change lz4 modules to work with new lz4 compressor module version
From: Sergey Senozhatsky @ 2016-12-22 13:25 UTC (permalink / raw)
To: Sven Schmidt
Cc: akpm, bongkyu.kim, sergey.senozhatsky, gregkh, linux-kernel,
Herbert Xu, linux-crypto
In-Reply-To: <1482259992-16680-2-git-send-email-4sschmid@informatik.uni-hamburg.de>
Cc Herbert and linux-crypto on this
https://marc.info/?l=linux-kernel&m=148226084823926
On (12/20/16 19:53), Sven Schmidt wrote:
>
> This patch updates the crypto modules using LZ4 compression to work with the
> new LZ4 kernel module version.
>
> Signed-off-by: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
> ---
> crypto/lz4.c | 93 +++++++--------------------------------------------------
> crypto/lz4hc.c | 94 +++++++---------------------------------------------------
> 2 files changed, 22 insertions(+), 165 deletions(-)
>
> diff --git a/crypto/lz4.c b/crypto/lz4.c
> index 99c1b2c..9fa217e 100644
> --- a/crypto/lz4.c
> +++ b/crypto/lz4.c
> @@ -23,53 +23,36 @@
> #include <linux/crypto.h>
> #include <linux/vmalloc.h>
> #include <linux/lz4.h>
> -#include <crypto/internal/scompress.h>
>
> struct lz4_ctx {
> void *lz4_comp_mem;
> };
>
> -static void *lz4_alloc_ctx(struct crypto_scomp *tfm)
> -{
> - void *ctx;
> -
> - ctx = vmalloc(LZ4_MEM_COMPRESS);
> - if (!ctx)
> - return ERR_PTR(-ENOMEM);
> -
> - return ctx;
> -}
> -
> static int lz4_init(struct crypto_tfm *tfm)
> {
> struct lz4_ctx *ctx = crypto_tfm_ctx(tfm);
>
> - ctx->lz4_comp_mem = lz4_alloc_ctx(NULL);
> - if (IS_ERR(ctx->lz4_comp_mem))
> + ctx->lz4_comp_mem = vmalloc(LZ4_MEM_COMPRESS);
> + if (!ctx->lz4_comp_mem)
> return -ENOMEM;
>
> return 0;
> }
>
> -static void lz4_free_ctx(struct crypto_scomp *tfm, void *ctx)
> -{
> - vfree(ctx);
> -}
> -
> static void lz4_exit(struct crypto_tfm *tfm)
> {
> struct lz4_ctx *ctx = crypto_tfm_ctx(tfm);
> -
> - lz4_free_ctx(NULL, ctx->lz4_comp_mem);
> + vfree(ctx->lz4_comp_mem);
> }
>
> -static int __lz4_compress_crypto(const u8 *src, unsigned int slen,
> - u8 *dst, unsigned int *dlen, void *ctx)
> +static int lz4_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
> + unsigned int slen, u8 *dst, unsigned int *dlen)
> {
> + struct lz4_ctx *ctx = crypto_tfm_ctx(tfm);
> size_t tmp_len = *dlen;
> int err;
>
> - err = lz4_compress(src, slen, dst, &tmp_len, ctx);
> + err = LZ4_compress_default(src, dst, slen, tmp_len, ctx->lz4_comp_mem);
>
> if (err < 0)
> return -EINVAL;
> @@ -78,29 +61,14 @@ static int __lz4_compress_crypto(const u8 *src, unsigned int slen,
> return 0;
> }
>
> -static int lz4_scompress(struct crypto_scomp *tfm, const u8 *src,
> - unsigned int slen, u8 *dst, unsigned int *dlen,
> - void *ctx)
> -{
> - return __lz4_compress_crypto(src, slen, dst, dlen, ctx);
> -}
> -
> -static int lz4_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
> - unsigned int slen, u8 *dst, unsigned int *dlen)
> -{
> - struct lz4_ctx *ctx = crypto_tfm_ctx(tfm);
> -
> - return __lz4_compress_crypto(src, slen, dst, dlen, ctx->lz4_comp_mem);
> -}
> -
> -static int __lz4_decompress_crypto(const u8 *src, unsigned int slen,
> - u8 *dst, unsigned int *dlen, void *ctx)
> +static int lz4_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
> + unsigned int slen, u8 *dst, unsigned int *dlen)
> {
> int err;
> size_t tmp_len = *dlen;
> size_t __slen = slen;
>
> - err = lz4_decompress_unknownoutputsize(src, __slen, dst, &tmp_len);
> + err = LZ4_decompress_safe(src, dst, __slen, tmp_len);
> if (err < 0)
> return -EINVAL;
>
> @@ -108,20 +76,6 @@ static int __lz4_decompress_crypto(const u8 *src, unsigned int slen,
> return err;
> }
>
> -static int lz4_sdecompress(struct crypto_scomp *tfm, const u8 *src,
> - unsigned int slen, u8 *dst, unsigned int *dlen,
> - void *ctx)
> -{
> - return __lz4_decompress_crypto(src, slen, dst, dlen, NULL);
> -}
> -
> -static int lz4_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
> - unsigned int slen, u8 *dst,
> - unsigned int *dlen)
> -{
> - return __lz4_decompress_crypto(src, slen, dst, dlen, NULL);
> -}
> -
> static struct crypto_alg alg_lz4 = {
> .cra_name = "lz4",
> .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
> @@ -135,39 +89,14 @@ static struct crypto_alg alg_lz4 = {
> .coa_decompress = lz4_decompress_crypto } }
> };
>
> -static struct scomp_alg scomp = {
> - .alloc_ctx = lz4_alloc_ctx,
> - .free_ctx = lz4_free_ctx,
> - .compress = lz4_scompress,
> - .decompress = lz4_sdecompress,
> - .base = {
> - .cra_name = "lz4",
> - .cra_driver_name = "lz4-scomp",
> - .cra_module = THIS_MODULE,
> - }
> -};
> -
> static int __init lz4_mod_init(void)
> {
> - int ret;
> -
> - ret = crypto_register_alg(&alg_lz4);
> - if (ret)
> - return ret;
> -
> - ret = crypto_register_scomp(&scomp);
> - if (ret) {
> - crypto_unregister_alg(&alg_lz4);
> - return ret;
> - }
> -
> - return ret;
> + return crypto_register_alg(&alg_lz4);
> }
>
> static void __exit lz4_mod_fini(void)
> {
> crypto_unregister_alg(&alg_lz4);
> - crypto_unregister_scomp(&scomp);
> }
>
> module_init(lz4_mod_init);
> diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
> index 75ffc4a..aa1265c 100644
> --- a/crypto/lz4hc.c
> +++ b/crypto/lz4hc.c
> @@ -22,53 +22,37 @@
> #include <linux/crypto.h>
> #include <linux/vmalloc.h>
> #include <linux/lz4.h>
> -#include <crypto/internal/scompress.h>
>
> struct lz4hc_ctx {
> void *lz4hc_comp_mem;
> };
>
> -static void *lz4hc_alloc_ctx(struct crypto_scomp *tfm)
> -{
> - void *ctx;
> -
> - ctx = vmalloc(LZ4HC_MEM_COMPRESS);
> - if (!ctx)
> - return ERR_PTR(-ENOMEM);
> -
> - return ctx;
> -}
> -
> static int lz4hc_init(struct crypto_tfm *tfm)
> {
> struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
>
> - ctx->lz4hc_comp_mem = lz4hc_alloc_ctx(NULL);
> - if (IS_ERR(ctx->lz4hc_comp_mem))
> + ctx->lz4hc_comp_mem = vmalloc(LZ4HC_MEM_COMPRESS);
> + if (!ctx->lz4hc_comp_mem)
> return -ENOMEM;
>
> return 0;
> }
>
> -static void lz4hc_free_ctx(struct crypto_scomp *tfm, void *ctx)
> -{
> - vfree(ctx);
> -}
> -
> static void lz4hc_exit(struct crypto_tfm *tfm)
> {
> struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
>
> - lz4hc_free_ctx(NULL, ctx->lz4hc_comp_mem);
> + vfree(ctx->lz4hc_comp_mem);
> }
>
> -static int __lz4hc_compress_crypto(const u8 *src, unsigned int slen,
> - u8 *dst, unsigned int *dlen, void *ctx)
> +static int lz4hc_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
> + unsigned int slen, u8 *dst, unsigned int *dlen)
> {
> + struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
> size_t tmp_len = *dlen;
> int err;
>
> - err = lz4hc_compress(src, slen, dst, &tmp_len, ctx);
> + err = LZ4_compress_HC(src, dst, slen, tmp_len, LZ4HC_DEFAULT_CLEVEL, ctx->lz4hc_comp_mem);
>
> if (err < 0)
> return -EINVAL;
> @@ -77,31 +61,14 @@ static int __lz4hc_compress_crypto(const u8 *src, unsigned int slen,
> return 0;
> }
>
> -static int lz4hc_scompress(struct crypto_scomp *tfm, const u8 *src,
> - unsigned int slen, u8 *dst, unsigned int *dlen,
> - void *ctx)
> -{
> - return __lz4hc_compress_crypto(src, slen, dst, dlen, ctx);
> -}
> -
> -static int lz4hc_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
> - unsigned int slen, u8 *dst,
> - unsigned int *dlen)
> -{
> - struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
> -
> - return __lz4hc_compress_crypto(src, slen, dst, dlen,
> - ctx->lz4hc_comp_mem);
> -}
> -
> -static int __lz4hc_decompress_crypto(const u8 *src, unsigned int slen,
> - u8 *dst, unsigned int *dlen, void *ctx)
> +static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
> + unsigned int slen, u8 *dst, unsigned int *dlen)
> {
> int err;
> size_t tmp_len = *dlen;
> size_t __slen = slen;
>
> - err = lz4_decompress_unknownoutputsize(src, __slen, dst, &tmp_len);
> + err = LZ4_decompress_safe(src, dst, __slen, (int)tmp_len);
> if (err < 0)
> return -EINVAL;
>
> @@ -109,20 +76,6 @@ static int __lz4hc_decompress_crypto(const u8 *src, unsigned int slen,
> return err;
> }
>
> -static int lz4hc_sdecompress(struct crypto_scomp *tfm, const u8 *src,
> - unsigned int slen, u8 *dst, unsigned int *dlen,
> - void *ctx)
> -{
> - return __lz4hc_decompress_crypto(src, slen, dst, dlen, NULL);
> -}
> -
> -static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
> - unsigned int slen, u8 *dst,
> - unsigned int *dlen)
> -{
> - return __lz4hc_decompress_crypto(src, slen, dst, dlen, NULL);
> -}
> -
> static struct crypto_alg alg_lz4hc = {
> .cra_name = "lz4hc",
> .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
> @@ -136,39 +89,14 @@ static struct crypto_alg alg_lz4hc = {
> .coa_decompress = lz4hc_decompress_crypto } }
> };
>
> -static struct scomp_alg scomp = {
> - .alloc_ctx = lz4hc_alloc_ctx,
> - .free_ctx = lz4hc_free_ctx,
> - .compress = lz4hc_scompress,
> - .decompress = lz4hc_sdecompress,
> - .base = {
> - .cra_name = "lz4hc",
> - .cra_driver_name = "lz4hc-scomp",
> - .cra_module = THIS_MODULE,
> - }
> -};
> -
> static int __init lz4hc_mod_init(void)
> {
> - int ret;
> -
> - ret = crypto_register_alg(&alg_lz4hc);
> - if (ret)
> - return ret;
> -
> - ret = crypto_register_scomp(&scomp);
> - if (ret) {
> - crypto_unregister_alg(&alg_lz4hc);
> - return ret;
> - }
> -
> - return ret;
> + return crypto_register_alg(&alg_lz4hc);
> }
>
> static void __exit lz4hc_mod_fini(void)
> {
> crypto_unregister_alg(&alg_lz4hc);
> - crypto_unregister_scomp(&scomp);
> }
>
> module_init(lz4hc_mod_init);
> --
> 2.1.4
>
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Jason A. Donenfeld @ 2016-12-22 13:10 UTC (permalink / raw)
To: kernel-hardening
Cc: Theodore Ts'o, Andy Lutomirski, Netdev, LKML,
Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <1482410840.2472.2.camel@stressinduktion.org>
On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> following up on what appears to be a random subject: ;)
>
> IIRC, ext4 code by default still uses half_md4 for hashing of filenames
> in the htree. siphash seems to fit this use case pretty good.
I saw this too. I'll try to address it in v8 of this series.
^ permalink raw reply
* Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Hannes Frederic Sowa @ 2016-12-22 12:47 UTC (permalink / raw)
To: Theodore Ts'o, kernel-hardening
Cc: Andy Lutomirski, Netdev, LKML, Linux Crypto Mailing List,
David Laight, Eric Dumazet, Linus Torvalds, Eric Biggers,
Tom Herbert, Andi Kleen, David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <20161222054125.lzxhd6ctovm3wk4p@thunk.org>
Hi Ted,
On Thu, 2016-12-22 at 00:41 -0500, Theodore Ts'o wrote:
> On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote:
> >
> > Funny -- while you guys were sending this back & forth, I was writing
> > my reply to Andy which essentially arrives at the same conclusion.
> > Given that we're all arriving to the same thing, and that Ted shot in
> > this direction long before we all did, I'm leaning toward abandoning
> > SipHash for the de-MD5-ification of get_random_int/long, and working
> > on polishing Ted's idea into something shiny for this patchset.
>
> here are my numbers comparing siphash (using the first three patches
> of the v7 siphash patches) with my batched chacha20 implementation.
> The results are taken by running get_random_* 10000 times, and then
> dividing the numbers by 10000 to get the average number of cycles for
> the call. I compiled 32-bit and 64-bit kernels, and ran the results
> using kvm:
>
> siphash batched chacha20
> get_random_int get_random_long get_random_int get_random_long
>
> 32-bit 270 278 114 146
> 64-bit 75 75 106 186
>
> > I did have two objections to this. The first was that my SipHash
> > construction is faster.
>
> Well, it's faster on everything except 32-bit x86. :-P
>
> > The second, and the more
> > important one, was that batching entropy up like this means that 32
> > calls will be really fast, and then the 33rd will be slow, since it
> > has to do a whole ChaCha round, because get_random_bytes must be
> > called to refill the batch.
>
> ... and this will take 2121 cycles on 64-bit x86, and 2315 cycles on a
> 32-bit x86. Which on a 2.3 GHz processor, is just under a
> microsecond. As far as being inconsistent on process startup, I very
> much doubt a microsecond is really going to be visible to the user. :-)
>
> The bottom line is that I think we're really "pixel peeping" at this
> point --- which is what obsessed digital photographers will do when
> debating the quality of a Canon vs Nikon DSLR by blowing up a photo by
> a thousand times, and then trying to claim that this is visible to the
> human eye. Or people who obsessing over the frequency response curves
> of TH-X00 headphones with Mahogony vs Purpleheart wood, when it's
> likely that in a blind head-to-head comparison, most people wouldn't
> be able to tell the difference....
>
> I think the main argument for using the batched getrandom approach is
> that it, I would argue, simpler than introducing siphash into the
> picture. On 64-bit platforms it is faster and more consistent, so
> it's basically that versus complexity of having to adding siphash to
> the things that people have to analyze when considering random number
> security on Linux. But it's a close call either way, I think.
following up on what appears to be a random subject: ;)
IIRC, ext4 code by default still uses half_md4 for hashing of filenames
in the htree. siphash seems to fit this use case pretty good.
xfs could also need an update, as they don't seed the directory hash
tables at all (but not sure if they are vulnerable). I should improve
[1] a bit.
[1] http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git;a=blo
b;f=src/dirhash_collide.c;h=55cec872d5061ac2ca0f56d1f11e6bf349d5bb97;hb
=HEAD
Bye,
Hannes
^ permalink raw reply
* Re: [RFC PATCH v2] crypto: Add IV generation algorithms
From: Binoy Jayan @ 2016-12-22 10:55 UTC (permalink / raw)
To: Herbert Xu
Cc: Milan Broz, Oded, Ofir, David S. Miller, linux-crypto, Mark Brown,
Arnd Bergmann, Linux kernel mailing list, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra
In-Reply-To: <20161222085509.GA2160@gondor.apana.org.au>
Hi Herbert,
On 22 December 2016 at 14:25, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote:
>>
>> By the move everything to cryptoAPI we are basically introducing some strange mix
>> of IV and modes there, I wonder how this is going to be maintained.
>> Anyway, Herbert should say if it is ok...
>
> Well there is precedent in how do the IPsec IV generation. In
> that case the IV generators too are completely specific to that
> application, i.e., IPsec. However, the way structured it allowed
> us to have one single entry path from the IPsec stack into the
> crypto layer regardless of whether you are using AEAD or traditional
> encryption/hashing algorithms.
>
> For IPsec we make the IV generators behave like normal AEAD
> algorithms, except that they take the sequence number as the IV.
>
> The goal here are obviously different. However, by employing
> the same method as we do in IPsec, it appears to me that you
> can effectively process multiple blocks at once instead of having
> to supply one block at a time due to the IV generation issue.
Thank you for clarifying that part.:)
So, I hope we can consider algorithms like lmk and tcw too as IV generation
algorithms, even though they manipulate encrypted data directly?
>> I really do not think the disk encryption key management should be moved
>> outside of dm-crypt. We cannot then change key structure later easily.
I agree with this too, only problem with this is when multiple keys are involved
(where the master key is split into 2 or more), and the key selection is made
with a modular division of the (512-byte) sector number by the number of keys.
> It doesn't have to live outside of dm-crypt. You can register
> these IV generators from there if you really want.
Sorry, but I didn't understand this part.
Thanks,
Binoy
^ permalink raw reply
* RE: dm-crypt optimization
From: Ofir Drang @ 2016-12-22 10:14 UTC (permalink / raw)
To: Herbert Xu, Binoy Jayan
Cc: Milan Broz, Oded Golombek, Arnd Bergmann, Mark Brown,
Alasdair Kergon, David S. Miller, private-kwg@linaro.org,
dm-devel@redhat.com, linux-crypto@vger.kernel.org, Rajendra,
Linux kernel mailing list, linux-raid@vger.kernel.org, Shaohua Li,
Mike Snitzer
In-Reply-To: <20161222085927.GB2160@gondor.apana.org.au>
-----Original Message-----
From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
Sent: Thursday, December 22, 2016 10:59 AM
To: Binoy Jayan
Cc: Milan Broz; Oded Golombek; Ofir Drang; Arnd Bergmann; Mark Brown; Alasdair Kergon; David S. Miller; private-kwg@linaro.org; dm-devel@redhat.com; linux-crypto@vger.kernel.org; Rajendra; Linux kernel mailing list; linux-raid@vger.kernel.org; Shaohua Li; Mike Snitzer
Subject: Re: dm-crypt optimization
On Thu, Dec 22, 2016 at 01:55:59PM +0530, Binoy Jayan wrote:
>>
>> > Support of bigger block sizes would be unsafe without additional
>> > mechanism that provides atomic writes of multiple sectors. Maybe it
>> > applies to 4k as well on some devices though...)
>>
>> Did you mean write to the crypto output buffers or the actual disk write?
>> I didn't quite understand how the block size for encryption affects
>> atomic writes as it is the block layer which handles them. As far as
>> dm-crypt is, concerned it just encrypts/decrypts a 'struct bio'
>> instance and submits the IO operation to the block layer.
>I think Milan's talking about increasing the real block size, which would obviously require the hardware to be able to write that out atomically, as otherwise it breaks the crypto.
>
>But if we can instead do the IV generation within the crypto API, then the block size won't be an issue at all. Because you can supply as many blocks as you want and they would be processed block-by-block.
>
>Now there is a disadvantage to this approach, and that is you have to wait for the whole thing to be encrypted before you can start doing the IO. I'm not sure how big a problem that is but if it is bad enough to affect performance, we can look into adding >some form of partial completion to the crypto API.
>
>Cheers,
But assuming we have hardware accelerator that know to handle the IV generation for each sector, it will make sense to send out to the hardware the maximum block size as this will allow us to better utilize the hardware and offload the software. So if possible we need to provide generic interface that will be able to optimize the hardware accelerates.
Thx Ofir
--
Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: dm-crypt optimization
From: Herbert Xu @ 2016-12-22 8:59 UTC (permalink / raw)
To: Binoy Jayan
Cc: Milan Broz, Oded, Ofir, Arnd Bergmann, Mark Brown,
Alasdair Kergon, David S. Miller, private-kwg, dm-devel,
linux-crypto, Rajendra, Linux kernel mailing list, linux-raid,
Shaohua Li, Mike Snitzer
In-Reply-To: <CAHv-k_-K9dOiM+Pm_wqVJrvmNYhjtS82-emKVZ8OjsoMHf+7hg@mail.gmail.com>
On Thu, Dec 22, 2016 at 01:55:59PM +0530, Binoy Jayan wrote:
>
> > Support of bigger block sizes would be unsafe without additional mechanism that provides
> > atomic writes of multiple sectors. Maybe it applies to 4k as well on some devices though...)
>
> Did you mean write to the crypto output buffers or the actual disk write?
> I didn't quite understand how the block size for encryption affects atomic
> writes as it is the block layer which handles them. As far as dm-crypt is,
> concerned it just encrypts/decrypts a 'struct bio' instance and submits the IO
> operation to the block layer.
I think Milan's talking about increasing the real block size, which
would obviously require the hardware to be able to write that out
atomically, as otherwise it breaks the crypto.
But if we can instead do the IV generation within the crypto API,
then the block size won't be an issue at all. Because you can
supply as many blocks as you want and they would be processed
block-by-block.
Now there is a disadvantage to this approach, and that is you
have to wait for the whole thing to be encrypted before you can
start doing the IO. I'm not sure how big a problem that is but
if it is bad enough to affect performance, we can look into adding
some form of partial completion to the crypto API.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH v2] crypto: Add IV generation algorithms
From: Herbert Xu @ 2016-12-22 8:55 UTC (permalink / raw)
To: Milan Broz
Cc: Binoy Jayan, Oded, Ofir, David S. Miller, linux-crypto,
Mark Brown, Arnd Bergmann, linux-kernel, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra
In-Reply-To: <d6d92865-98fa-4d02-035f-9080bc265c35@gmail.com>
On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote:
>
> By the move everything to cryptoAPI we are basically introducing some strange mix
> of IV and modes there, I wonder how this is going to be maintained.
> Anyway, Herbert should say if it is ok...
Well there is precedent in how do the IPsec IV generation. In
that case the IV generators too are completely specific to that
application, i.e., IPsec. However, the way structured it allowed
us to have one single entry path from the IPsec stack into the
crypto layer regardless of whether you are using AEAD or traditional
encryption/hashing algorithms.
For IPsec we make the IV generators behave like normal AEAD
algorithms, except that they take the sequence number as the IV.
The goal here are obviously different. However, by employing
the same method as we do in IPsec, it appears to me that you
can effectively process multiple blocks at once instead of having
to supply one block at a time due to the IV generation issue.
> I really do not think the disk encryption key management should be moved
> outside of dm-crypt. We cannot then change key structure later easily.
It doesn't have to live outside of dm-crypt. You can register
these IV generators from there if you really want.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
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