Hi All,
I was going through libkcapi APIs to see if it can be used for DRBG CAVS
validation. But I am thinking it cannot be.
I also found cavs_driver.pl, this seems to depend on some kernel mode driver.
Is it like I need to testmgr.c kind of an interface and that should be accessed
by user mod
On Tue, May 26, 2020 at 05:21:04PM +0300, Tero Kristo wrote:
> In case buffers are copied from userspace, directly accessing the page
> will most likely fail because it hasn't been mapped into the kernel
> memory space. Fix the issue by forcing a kmap / kunmap within the
> cleanup functionality.
>
From: Daniel Jordan
[ Upstream commit ec9c7d19336ee98ecba8de80128aa405c45feebb ]
Exercising CPU hotplug on a 5.2 kernel with recent padata fixes from
cryptodev-2.6.git in an 8-CPU kvm guest...
# modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
# echo 0 > /sys/devices/system/cpu/cp
From: Daniel Jordan
[ Upstream commit 065cf577135a4977931c7a1e1edf442bfd9773dd ]
With the removal of the padata timer, padata_do_serial no longer
needs special CPU handling, so remove it.
Signed-off-by: Daniel Jordan
Cc: Herbert Xu
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
Cc: li
From: Daniel Jordan
[ Upstream commit ec9c7d19336ee98ecba8de80128aa405c45feebb ]
Exercising CPU hotplug on a 5.2 kernel with recent padata fixes from
cryptodev-2.6.git in an 8-CPU kvm guest...
# modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
# echo 0 > /sys/devices/system/cpu/cp
From: Daniel Jordan
[ Upstream commit ec9c7d19336ee98ecba8de80128aa405c45feebb ]
Exercising CPU hotplug on a 5.2 kernel with recent padata fixes from
cryptodev-2.6.git in an 8-CPU kvm guest...
# modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
# echo 0 > /sys/devices/system/cpu/cp
From: Daniel Jordan
[ Upstream commit 065cf577135a4977931c7a1e1edf442bfd9773dd ]
With the removal of the padata timer, padata_do_serial no longer
needs special CPU handling, so remove it.
Signed-off-by: Daniel Jordan
Cc: Herbert Xu
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
Cc: li
From: Daniel Jordan
[ Upstream commit 065cf577135a4977931c7a1e1edf442bfd9773dd ]
With the removal of the padata timer, padata_do_serial no longer
needs special CPU handling, so remove it.
Signed-off-by: Daniel Jordan
Cc: Herbert Xu
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
Cc: li
From: Daniel Jordan
[ Upstream commit ec9c7d19336ee98ecba8de80128aa405c45feebb ]
Exercising CPU hotplug on a 5.2 kernel with recent padata fixes from
cryptodev-2.6.git in an 8-CPU kvm guest...
# modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
# echo 0 > /sys/devices/system/cpu/cp
From: Daniel Jordan
[ Upstream commit 065cf577135a4977931c7a1e1edf442bfd9773dd]
With the removal of the padata timer, padata_do_serial no longer
needs special CPU handling, so remove it.
Signed-off-by: Daniel Jordan
Cc: Herbert Xu
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
Cc: lin
On 5/26/20 3:39 AM, Stephen Rothwell wrote:
> Hi all,
>
> News: there will be no linux-next release tomorrow.
>
> Changes since 20200525:
>
on i386:
when CONFIG_IPV6 is not set/enabled:
CC drivers/crypto/chelsio/chcr_ktls.o
In file included from ../include/linux/tcp.h:19:0,
Hi, Christoph
On 2020/5/26 下午10:46, Christoph Hellwig wrote:
On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote:
Some platform devices appear as PCI but are actually on the AMBA bus,
and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
Here introducing PCI_FIXUP_IOMMU, w
On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote:
> Some platform devices appear as PCI but are actually on the AMBA bus,
> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
> is allocated, instead o
In case buffers are copied from userspace, directly accessing the page
will most likely fail because it hasn't been mapped into the kernel
memory space. Fix the issue by forcing a kmap / kunmap within the
cleanup functionality.
Signed-off-by: Tero Kristo
---
v3:
- Added PageSlab() check to the
<20200123101000.GB24255@Red>
References: <20200526031956.1897-2-longpe...@huawei.com>
<20200123101000.GB24255@Red>
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: dbaf0624ffa5 ("crypto: add virtio-crypto driver").
The bot has test
<20200123101000.GB24255@Red>
References: <20200526031956.1897-3-longpe...@huawei.com>
<20200123101000.GB24255@Red>
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: dbaf0624ffa5 ("crypto: add virtio-crypto driver").
The bot has test
On 14/05/2020 15:50, Tero Kristo wrote:
From: Keerthy
The Security Accelerator Ultra Lite (SA2UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
* Encryption and authentication for secure boot
* Encryption and authentication of content in applications
re
On 26/05/2020 16:07, Herbert Xu wrote:
On Tue, May 26, 2020 at 03:57:10PM +0300, Tero Kristo wrote:
Btw, any word on the TI sa2ul series I posted a while back? I see it has
been marked as deferred in patchwork but I am not quite sure what that
means... deferred until what? I have also been thin
On Tue, May 26, 2020 at 03:57:10PM +0300, Tero Kristo wrote:
>
> Btw, any word on the TI sa2ul series I posted a while back? I see it has
> been marked as deferred in patchwork but I am not quite sure what that
> means... deferred until what? I have also been thinking of creating a
> drivers/crypto
On 26/05/2020 15:35, Herbert Xu wrote:
On Tue, May 26, 2020 at 03:27:38PM +0300, Tero Kristo wrote:
I think it would make sense to use that, however as I am just fixing an
existing bug here, would it be ok if I just fix your above comment and post
v3? I can convert this later to sg_miter and ta
On Tue, May 26, 2020 at 03:27:38PM +0300, Tero Kristo wrote:
>
> I think it would make sense to use that, however as I am just fixing an
> existing bug here, would it be ok if I just fix your above comment and post
> v3? I can convert this later to sg_miter and take a shot at moving this to
> lib/s
On 22/05/2020 16:12, Herbert Xu wrote:
On Mon, May 11, 2020 at 02:19:09PM +0300, Tero Kristo wrote:
In case buffers are copied from userspace, directly accessing the page
will most likely fail because it hasn't been mapped into the kernel
memory space. Fix the issue by forcing a kmap / kunmap wi
On 2020/5/25 下午9:43, Joerg Roedel wrote:
On Tue, May 12, 2020 at 12:08:29PM +0800, Zhangfei Gao wrote:
Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_final after iommu_fwnode is allo
> -Original Message-
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> Sent: Tuesday, May 26, 2020 11:20 AM
> To: linux-crypto@vger.kernel.org
> Cc: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; LABBE Corentin ; Gonglei
> (Arei) ; Herbert Xu
> ; Micha
Calling pci_fixup_iommu in iommu_fwspec_init, which alloc
iommu_fwnode. Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_iommu after iommu_fwnode is allocated.
Signed-off-by: Zhangfei Gao
Some platform devices appear as PCI but are actually on the AMBA bus,
and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
down iommu probing as all
Some platform devices appear as PCI but are actually on the AMBA bus,
and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
down iommu probing as all
On Tue, May 26, 2020 at 05:24:03PM +0800, Longpeng (Mike, Cloud Infrastructure
Service Product Dept.) wrote:
>
>
> On 2020/5/26 17:01, Markus Elfring wrote:
> … Thus release specific resources before
> >>>
> >>> Is there a need to improve also this information another bit?
> >>>
> >> You me
> I respect your work, but please let us to focus on the code itself. I think
> experts in this area know what these patches want to solve after look at the
> code.
I suggest to reconsider such a view.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/s
On 2020/5/26 17:01, Markus Elfring wrote:
… Thus release specific resources before
>>>
>>> Is there a need to improve also this information another bit?
>>>
>> You mean the last two paragraph is redundant ?
>
> No.
>
> I became curious if you would like to choose a more helpful informatio
>>> … Thus release specific resources before
>>
>> Is there a need to improve also this information another bit?
>>
> You mean the last two paragraph is redundant ?
No.
I became curious if you would like to choose a more helpful information
according to the wording “specific resources”.
Regards,
>> I suggest to move the addition of such input parameter validation
>> to a separate update step.
>>
> Um...The 'src_nents' will be used as a loop condition,
> so validate it here is needed ?
Would you prefer to add such checking as the first update in
another small patch series?
Regards,
Markus
Hi Markus,
On 2020/5/26 15:19, Markus Elfring wrote:
>> The system'll crash when the users insmod crypto/tcrypto.ko with mode=155
>> ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory
>> of request structure.
>
> Wording adjustments:
> * … system will crash …
> * … It is
Hi Markus,
On 2020/5/26 15:03, Markus Elfring wrote:
>> Fix it by sg_next() on calculation of src/dst scatterlist.
>
> Wording adjustment:
> … by calling the function “sg_next” …
>
OK, thanks.
>
> …
>> +++ b/drivers/crypto/virtio/virtio_crypto_algs.c
>> @@ -350,13 +350,18 @@ __virtio_crypto_sk
> The system'll crash when the users insmod crypto/tcrypto.ko with mode=155
> ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory
> of request structure.
Wording adjustments:
* … system will crash …
* … It is caused by reusing the …
> when these memory will be used again.
Eric Curtin wrote:
> Hope I'm not bothering you. I'm looking for a masters thesis idea, ...
> I'm really liking this
> new QUIC (UDP) protocol as an alternative to TCP over TLS. And with
> the growth of new modern secure protocols like Wireguard. I was
> wondering, would it be an idea to do a mo
> Fix it by sg_next() on calculation of src/dst scatterlist.
Wording adjustment:
… by calling the function “sg_next” …
…
> +++ b/drivers/crypto/virtio/virtio_crypto_algs.c
> @@ -350,13 +350,18 @@ __virtio_crypto_skcipher_do_req(struct
> virtio_crypto_sym_request *vc_sym_req,
…
> src_nents
37 matches
Mail list logo
