Hi Varad,
Thanks for your review!
On Thu, Apr 15, 2021 at 02:08:32PM +0200, Varad Gautam wrote:
> Hi Joey,
>
> On 4/9/21 4:46 AM, Lee, Chun-Yi wrote:
> > This patch adds the logic for checking the CodeSigning extended
> > key usage when verifying signature of kernel module or
> > kexec PE binary
Qualcomm crypto engine does not handle the following scenarios and
will issue an abort. In such cases, pass on the transformation to
a fallback algorithm.
- DES3 algorithms with all three keys same.
- AES192 algorithms.
- 0 length messages.
Signed-off-by: Thara Gopinath
---
v1->v2:
- Up
Add register programming sequence for enabling AEAD
algorithms on the Qualcomm crypto engine.
Signed-off-by: Thara Gopinath
---
v2->v3:
- Made qce_be32_to_cpu_array truly be32 to cpu endian by using
be32_to_cpup
instead of cpu_to_be32p. Also remove the (u32 *) typcasting of ar
Introduce support to enable following algorithms in Qualcomm Crypto Engine.
- authenc(hmac(sha1),cbc(des))
- authenc(hmac(sha1),cbc(des3_ede))
- authenc(hmac(sha256),cbc(des))
- authenc(hmac(sha256),cbc(des3_ede))
- authenc(hmac(sha256),cbc(aes))
- ccm(aes)
- rfc4309(ccm(aes))
Signed-off-by: Thar
rf4309 is the specification that uses aes ccm algorithms with IPsec
security packets. Add a submode to identify rfc4309 ccm(aes) algorithm
in the crypto driver.
Reviewed-by: Bjorn Andersson
Signed-off-by: Thara Gopinath
---
v1->v2:
- Moved up the QCE_ENCRYPT AND QCE_DECRYPT bit position
Remove various redundant checks in qce_auth_cfg. Also allow qce_auth_cfg
to take auth_size as a parameter which is a required setting for ccm(aes)
algorithms
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/common.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
Enable support for AEAD algorithms in Qualcomm CE driver. The first three
patches in this series are cleanups and add a few missing pieces required
to add support for AEAD algorithms. Patch 4 introduces supported AEAD
transformations on Qualcomm CE. Patches 5 and 6 implements the h/w
infrastruct
Qualcomm crypto engine allows for IV registers and status register
to be concatenated to the output. This option is enabled by setting the
RESULTS_DUMP field in GOPROC register. This is useful for most of the
algorithms to either retrieve status of operation or in case of
authentication algorithms
MAC_FAILED gets set in the status register if authenthication fails
for ccm algorithms(during decryption). Add support to catch and flag
this error.
Reviewed-by: Bjorn Andersson
Signed-off-by: Thara Gopinath
---
v1->v2:
- Split the error checking for -ENXIO and -EBADMSG into if-else cla
Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> In some cases, you can use the device_link infrastructure to deal
> with dependencies between devices. Not sure if this would help
> in your case, but have a look at device_link_add() etc in drivers/base/core.c
I'll need to actually t
> From: Chris von Recklinghausen
> Sent: Friday, April 16, 2021 6:17 AM
> ...
> Hibernation fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> The check is intended to detect whether the E820 memory map provided
> by the
On Fri, Apr 16, 2021 at 09:16:55AM -0400, Chris von Recklinghausen wrote:
> Hibernation fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
Doesn't the commit title need to be prefixed with something like "x86/power"?
> The ch
On Fri, Apr 16, 2021 at 06:06:42PM +0200, Ard Biesheuvel wrote:
> CONFIG_CRYPTO_SHA256 denotes the generic C implementation of the SHA-256
> shash algorithm, which is selected as the default crypto shash provider
> for fsverity. However, fsverity has no strict link time dependency, and
> the same s
On Fri, Apr 16, 2021 at 06:06:41PM +0200, Ard Biesheuvel wrote:
> Even if FS encryption has strict functional dependencies on various
> crypto algorithms and chaining modes. those dependencies could potentially
> be satisified by other implementations than the generic ones, and no link
> time depen
On 4/19/21 1:10 PM, Andy Lutomirski wrote:
>
>> On Apr 19, 2021, at 10:58 AM, Dave Hansen wrote:
>>
>> On 4/19/21 10:46 AM, Brijesh Singh wrote:
>>> - guest wants to make gpa 0x1000 as a shared page. To support this, we
>>> need to psmash the large RMP entry into 512 4K entries. The psmash
>>>
On Mon, Apr 19, 2021 at 04:16:13AM +, Mothershead, Hailey wrote:
> Hello,
>
> The patch quoted below causes the kernel to panic when fips is enabled with:
>
>alg: ecdh: test failed on vector 2, err=-14
>Kernel panic - not syncing: alg: self-tests for ecdh-generic (ecd
> On Apr 19, 2021, at 11:33 AM, Dave Hansen wrote:
>
> On 4/19/21 11:10 AM, Andy Lutomirski wrote:
>> I’m confused by this scenario. This should only affect physical pages
>> that are in the 2M area that contains guest memory. But, if we have a
>> 2M direct map PMD entry that contains kernel
On 4/19/21 11:10 AM, Andy Lutomirski wrote:
> I’m confused by this scenario. This should only affect physical pages
> that are in the 2M area that contains guest memory. But, if we have a
> 2M direct map PMD entry that contains kernel data and guest private
> memory, we’re already in a situation in
> On Apr 19, 2021, at 10:58 AM, Dave Hansen wrote:
>
> On 4/19/21 10:46 AM, Brijesh Singh wrote:
>> - guest wants to make gpa 0x1000 as a shared page. To support this, we
>> need to psmash the large RMP entry into 512 4K entries. The psmash
>> instruction breaks the large RMP entry into 512 4
On 4/19/21 10:46 AM, Brijesh Singh wrote:
> - guest wants to make gpa 0x1000 as a shared page. To support this, we
> need to psmash the large RMP entry into 512 4K entries. The psmash
> instruction breaks the large RMP entry into 512 4K entries without
> affecting the previous validation. Now the w
On Mon, Apr 19, 2021 at 10:25:01AM -0500, Brijesh Singh wrote:
> To my understanding, we don't group 512 4K entries into a 2M for the
> kernel address range. We do this for the userspace address through
> khugepage daemon. If page tables get out of sync then it will cause an
> RMP violation, the Pa
On 4/19/21 7:32 AM, Borislav Petkov wrote:
> On Wed, Mar 24, 2021 at 12:04:10PM -0500, Brijesh Singh wrote:
>> A write from the hypervisor goes through the RMP checks. When the
>> hypervisor writes to pages, hardware checks to ensures that the assigned
>> bit in the RMP is zero (i.e page is share
On 4/18/21 9:27 PM, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
[ ... ]
> drivers/watchdog/renesas_wdt.c| 2 +-
> 48 files chan
On Wed, Mar 24, 2021 at 12:04:10PM -0500, Brijesh Singh wrote:
> A write from the hypervisor goes through the RMP checks. When the
> hypervisor writes to pages, hardware checks to ensures that the assigned
> bit in the RMP is zero (i.e page is shared). If the page table entry that
> gives the sPA i
On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
wrote:
> Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
>
> > soc_device_match() should only be used as a last resort, to identify
> > systems that cannot be identified otherwise. Typically this is used for
> > quirks, which
On 2021/4/16 19:26, Herbert Xu wrote:
On Sat, Apr 10, 2021 at 05:49:17PM +0800, Hui Tang wrote:
Currently, an invalid dma address may be unmapped when calling
'xx_data_clr_all' in error path, so check dma address of sqe in/out
whether it has been mapped before calling 'dma_free_coherent' or
'
Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
> > This is going to need quite some more work to be acceptable, in my
> > opinion, but I think it should be possible.
>
> In general, this is very hard to do, IMHO. Some drivers may be used on
> multiple platforms, some of them
Hi Dominique,
CC Arnd (soc_device_match() author)
On Mon, Apr 19, 2021 at 7:03 AM Dominique MARTINET
wrote:
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo
> > Update all the code that use soc_device_match
>
> A single patch might be difficult to accept for
Hi Alice,
CC Arnd (soc_device_match() author)
On Mon, Apr 19, 2021 at 6:28 AM Alice Guo (OSS) wrote:
> From: Alice Guo
>
> In i.MX8M boards, the registration of SoC device is later than caam
> driver which needs it. Caam driver needs soc_device_match to provide
> -EPROBE_DEFER when no SoC devic
> -Original Message-
> From: Dominique MARTINET
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS)
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
>
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo
> >
> > Upda
30 matches
Mail list logo
