> -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
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
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
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
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
'
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 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 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 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 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 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 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 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 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 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 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 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 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 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
> 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
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
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
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
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(-)
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
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
30 matches
Mail list logo
