+-- On Mon, 2 Oct 2017, Brijesh Singh wrote --+
| +static int sev_cmd_buffer_len(int cmd)
| +{
| + switch (cmd) {
| + case SEV_CMD_INIT: return sizeof(struct sev_data_init);
| + case SEV_CMD_PLATFORM_STATUS: return sizeof(struct sev_data_status);
| + case SEV_CMD_PEK_
+-- On Mon, 2 Oct 2017, Brijesh Singh wrote --+
| +int psp_dev_init(struct sp_device *sp)
| +{
| + struct device *dev = sp->dev;
| + struct psp_device *psp;
| + int ret;
| +
| + ret = -ENOMEM;
| + psp = psp_alloc_struct(sp);
| + if (!psp)
| + goto e_err;
| +
| +
The hardware expects that the keys, IVs (and inner/outer hashes)
are in the le32 format.
This patch changes all hardware interface declarations to use
the correct LE32 data format for each field.
In order to pass __CHECK_ENDIAN__ checks, crypto4xx_memcpy_le
has to be honest about the endianness o
This patch fixes a type mismatch error that I accidentally
introduced when I moved and refactored the dynamic_contents
helpers.
Signed-off-by: Christian Lamparter
---
drivers/crypto/amcc/crypto4xx_sa.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/amcc/cr
If the crypto4xx device is continuously loaded by dm-crypt
and ipsec work, it will start to work intermittent after a
few (between 20-30) seconds, hurting throughput and latency.
This patch contains various stability improvements in order
to fix this issue. So far, the hardware has survived more
t
If crypto4xx is used in conjunction with dm-crypt, the available
ring buffer elements are not enough to handle the load properly.
On an aes-cbc-essiv:sha256 encrypted swap partition the read
performance is abyssal: (tested with hdparm -t)
/dev/mapper/swap_crypt:
Timing buffered disk reads: 14 M
I used aes-cbc as a template for ofb. But sadly I forgot
to update set_key method to crypto4xx_setkey_aes_ofb().
this was caught by the testmgr:
alg: skcipher: Test 1 failed (invalid result) on encr. for ofb-aes-ppc4xx
: 76 49 ab ac 81 19 b2 46 ce e9 8e 9b 12 e9 19 7d
0010: 50 86 cb 9b
This patch adds aes-ccm support.
Signed-off-by: Christian Lamparter
---
drivers/crypto/amcc/crypto4xx_alg.c | 185 +++
drivers/crypto/amcc/crypto4xx_core.c | 23 +
drivers/crypto/amcc/crypto4xx_core.h | 8 ++
3 files changed, 216 insertions(+)
diff --git
This patch enhances existing interfaces and
functions to support AEAD ciphers in the next
patches.
Signed-off-by: Christian Lamparter
---
drivers/crypto/Kconfig | 4 +
drivers/crypto/amcc/crypto4xx_alg.c | 19 +--
drivers/crypto/amcc/crypto4xx_core.c | 217 +
Previously, If the crypto4xx driver used all available
security contexts, it would simply refuse new requests
with -EAGAIN. CRYPTO_TFM_REQ_MAY_BACKLOG was ignored.
in case of dm-crypt.c's crypt_convert() function this was
causing the following errors to manifest, if the system was
pushed hard enou
The hmac_mc parameter of set_dynamic_sa_command_1()
was defined but not used. On closer inspection it
turns out, it was never wired up.
Signed-off-by: Christian Lamparter
---
drivers/crypto/amcc/crypto4xx_alg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/amcc/crypto4xx_alg
Thanks to the big overhaul of crypto4xx_build_pd(), the request-local
sa_in, sa_out and state_record allocation can be simplified.
There's no need to setup any dma coherent memory anymore and
much of the support code can be removed.
Signed-off-by: Christian Lamparter
---
drivers/crypto/amcc/cry
This patch overhauls and fixes code related to crypto4xx_build_pd()
* crypto4xx_build_pd() did not handle chained source scatterlist.
This is fixed by replacing the buggy indexed-access of &src[idx]
with sg_next() in the gather array setup loop.
* The redundant is_hash, direction, save_iv
crypto4xx_core.c:179:6: warning: symbol 'crypto4xx_free_state_record'
was not declared. Should it be static?
crypto4xx_core.c:331:5: warning: symbol 'crypto4xx_get_n_gd'
was not declared. Should it be static?
crypto4xx_core.c:652:6: warning: symbol 'crypto4xx_return_pd'
was
This patch adds aes-gcm support to crypto4xx.
Signed-off-by: Christian Lamparter
---
drivers/crypto/amcc/crypto4xx_alg.c | 139 +++
drivers/crypto/amcc/crypto4xx_core.c | 22 ++
drivers/crypto/amcc/crypto4xx_core.h | 4 +
3 files changed, 165 insertions(+)
Hi Robin
I now see your patch and it does seem to be fix the problem.
On Thu, Sep 28, 2017 at 08:43:46AM -0700, Ashok Raj wrote:
> Hi Robin
>
>
> On Thu, Sep 28, 2017 at 05:59:11PM +0100, Robin Murphy wrote:
> > I hope our email server hasn't got blacklisted again... Said patch is
> > the top o
On Tue, Oct 03, 2017 at 07:33:08PM -0300, Marcelo Ricardo Leitner wrote:
> On Tue, Oct 03, 2017 at 10:25:22AM +0800, Jia-Ju Bai wrote:
> > The SCTP program may sleep under a spinlock, and the function call path is:
> > sctp_generate_t3_rtx_event (acquire the spinlock)
> > sctp_do_sm
> > sctp_
On Tue, Oct 03, 2017 at 01:26:43PM +0800, Herbert Xu wrote:
> On Mon, Oct 02, 2017 at 09:18:24PM -0700, Andy Lutomirski wrote:
> > > On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote:
> > >
> > > The SCTP program may sleep under a spinlock, and the function call path
> > > is:
> > > sctp_generate_t3_r
On Tue, Oct 03, 2017 at 10:25:22AM +0800, Jia-Ju Bai wrote:
> The SCTP program may sleep under a spinlock, and the function call path is:
> sctp_generate_t3_rtx_event (acquire the spinlock)
> sctp_do_sm
> sctp_side_effects
> sctp_cmd_interpreter
> sctp_make_init_ack
>
| From: Harsh Jain
| Sent: Tuesday, October 3, 2017 5:22 AM
|
| Hi Robin/Ashok,
|
| Find attached trace of DMA write error. I had a look on trace but didn't
| find anything suspicious.
|
| Let me know if you need more trace.
As a reminder, Harsh and Atul will be waking up in a few hours, so if th
On Tue, 2017-10-03 at 19:05 +0100, Robin Murphy wrote:
>
> Now, there are indeed plenty of drivers and subsystems which do work on
> lists of explicitly single pages - anything doing some variant of
> "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I
> don't think DMA API imp
On Tue, Oct 03, 2017 at 04:57:43PM +0200, Kamil Konieczny wrote:
> >> [...]
> >> +static struct ahash_alg algs_sha256[] = {
> >> +{
> >> + .init = s5p_hash_init,
> >> + .update = s5p_hash_update,
> >> + .final = s5p_hash_final,
> >> + .finup = s5p_hash_finu
On 03/10/17 13:55, David Woodhouse wrote:
> On Thu, 2017-09-28 at 15:14 +0100, Robin Murphy wrote:
>> The intel-iommu DMA ops fail to correctly handle scatterlists where
>> sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
>> appropriately based on the page-aligned portion of t
On Mon, Oct 2, 2017 at 10:26 PM, Herbert Xu wrote:
> On Mon, Oct 02, 2017 at 09:18:24PM -0700, Andy Lutomirski wrote:
>> > On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote:
>> >
>> > The SCTP program may sleep under a spinlock, and the function call path is:
>> > sctp_generate_t3_rtx_event (acquire t
On Thu, Sep 21, 2017 at 05:47:42PM +0530, suni...@techveda.org wrote:
> From: Suniel Mahesh
>
> Platform devices are expected to use wrapper functions,
> platform_{get,set}_drvdata() with platform_device as argument,
> for getting and setting the driver data. dev_{get,set}_drvdata()
> are using &
On 10/03/2017 11:17 AM, Borislav Petkov wrote:
...
No, please add my patch below to your set for the CRYPTO_DEV_CCP_DD
dependency as it is a separate thing. Your patch should concentrate only
on adding the PSP and its dependencies.
Sure, I will include your patch in my series. thanks
--
On Sun, Oct 01, 2017 at 03:05:11PM -0500, Brijesh Singh wrote:
> I think theoretically a 32-bit host OS can invoke a PSP commands but
> currently PSP interface is exposing only the SEV FW command. And SEV
Let's cross that bridge when we get to it.
> feature is available when we are in 64-bit mode
Hi, David,
On 10/03/2017 12:06 PM, David Howells wrote:
Tudor Ambarus wrote:
-static inline int dh_data_size(const struct dh *p)
+static inline unsigned int dh_data_size(const struct dh *p)
{
return p->key_size + p->p_size + p->g_size;
}
If this is a problem, do you need to do r
From: Harsh Jain
> Sent: 03 October 2017 07:46
> It multiply GF(2^128) elements in the ble format.
> It will be used by chelsio driver to fasten gf multiplication.
^ speed up ??
David
On 30.09.2017 21:50, Krzysztof Kozlowski wrote:
> On Wed, Sep 27, 2017 at 02:25:50PM +0200, Kamil Konieczny wrote:
>> Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW.
>> It uses the crypto framework asynchronous hash api.
>> It is based on omap-sham.c driver.
>> S5P has some HW diff
On Thu, 2017-09-28 at 15:14 +0100, Robin Murphy wrote:
> The intel-iommu DMA ops fail to correctly handle scatterlists where
> sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
> appropriately based on the page-aligned portion of the offset, but the
> mapping is set up relative
Simplify handling of memory allocation failures and remove
redundant log messages
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_cipher.c | 11 --
drivers/staging/ccree/ssi_driver.c | 1 -
drivers/staging/ccree/ssi_hash.c | 42 +---
Move over from using macro wrappers around to printk to
dev_err, dev_dbg and friends and clean up resulting fallout.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 226 ++
drivers/staging/ccree/ssi_buffer_mgr.c | 394 +++
On Mon, Oct 2, 2017 at 1:00 PM, Joe Perches wrote:
> On Mon, 2017-10-02 at 10:03 +0100, Gilad Ben-Yossef wrote:
>> Introduce a DEV macro to retrieve struct device from private
>> data structure in preparation to replacing custom logging
>> macros with proper dev_dbg and friends which require struc
Introduce a function to retrieve struct device from private
data structure in preparation to replacing custom logging
macros with proper dev_dbg and friends which require struct
device.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 11 ---
drivers/staging/ccre
The ccree cycle count mechanism was removed in
commit 7f821f0c6ffa ("staging: ccree: remove cycle count debug support")
but the sysfs interface lingered on. Remove it now.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_sysfs.c | 266 --
1 file c
The following patch set cleans up some code and builds upon this to replace
ccree custom logging macros with the generic device dev_* facilities,
handles the resulting fallout and further simplifies handling of
memory and allocation OOM error handling code path exposed by checkpatch
following the c
Tudor Ambarus wrote:
> -static inline int dh_data_size(const struct dh *p)
> +static inline unsigned int dh_data_size(const struct dh *p)
> {
> return p->key_size + p->p_size + p->g_size;
> }
If this is a problem, do you need to do range checking?
David
On 22/09/17 11:09, Herbert Xu wrote:
> On Fri, Aug 18, 2017 at 11:19:04AM +0200, Fabien Dessenne wrote:
>> The current crypto engine allows ablkcipher_request and ahash_request to
>> be enqueued. Extend this to aead_request.
>>
>> Signed-off-by: Fabien Dessenne
> I'd like to see the crypto_engine
39 matches
Mail list logo
