On 08/29/2013 06:27 PM, Joel Fernandes wrote:
> Add omap-des driver with platform data for OMAP4. Support added for DES
> ECB and CBC modes.
>
> Where possible, code is reused from omap-aes driver with changes made for
> adjusting key size, block size, removing non-existent encryption modes
> and
Add omap-des driver with platform data for OMAP4. Support added for DES
ECB and CBC modes.
Where possible, code is reused from omap-aes driver with changes made for
adjusting key size, block size, removing non-existent encryption modes
and adding support for OMAP4 platform data and offsets.
Tests
OMAP DES module supports 3DES operation where 3 64-bit keys are used to
perform a DES encrypt-decrypt-encrypt (ede) operation on a buffer.
Signed-off-by: Joel Fernandes
---
drivers/crypto/omap-des.c | 53 ---
1 file changed, 50 insertions(+), 3 deletio
OMAP4 and AM437x SoCs have a DES3DES module which is capable of performing DES
encrypt/decrypt and 3DES ede encrypt/decrypt operations. Following patch series
adds support for the same.
Tests have been performed with crypto/testmgr and all tests are successful.
Joel Fernandes (3):
crypto: omap-
Add config and build options for the newly added omap-des driver.
Signed-off-by: Joel Fernandes
---
drivers/crypto/Kconfig | 11 +++
drivers/crypto/Makefile | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e289afa..119a8e5 100
於 四，2013-08-29 於 23:32 +0200，Pavel Machek 提到：
> Hi!
>
> > > >- Bootloader store the public key to EFI boottime variable by itself
> > > >- Bootloader put The private key to S4SignKey EFI variable for
> > > > forward to
> > > > kernel.
> > >
> > > Is the UEFI NVRAM really suited for
Hi!
> > >- Bootloader store the public key to EFI boottime variable by itself
> > >- Bootloader put The private key to S4SignKey EFI variable for forward
> > > to
> > > kernel.
> >
> > Is the UEFI NVRAM really suited for such regular updates?
> >
>
> Yes, Matthew raised this conce
From: Jan-Simon Möller
v2: Fix bug in statement as pointed out by Herbert Xu. Kudos to pipacs.
Author: PaX Team
ML-Post:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142707.html
URL: http://llvm.linuxfoundation.org
Merge: Jan-Simon Möller
Description:
Fix for
This patch updates the nx-aes-ctr implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- "ibm,max-sg-len": maximum number of bytes of each scatter/gather
list.
- "ibm,max-sync-cop"
This patch includes one more parameter to nx_build_sg_lists() to skip
the given number of bytes from beginning of each sg list.
This is needed in order to implement the fixes for the AES modes to make
them able to process larger chunks of data.
Reviewed-by: Joy Latten
Signed-off-by: Marcelo Cerr
The NX CGM implementation doesn't support zero length messages and the
current implementation has two flaws:
- When the input data length is zero, it ignores the associated data.
- Even when both lengths are zero, it uses the Crypto API to encrypt a
zeroed block using ctr(aes) and because of
This series of patches contains fixes in several algorithms implemented
by the NX driver. The patches can be separated in three different
categories:
- Changes to split the data in several hyper calls to respect the
limits of data that the co-processador can handle. This affects
all AES m
From: Fionnuala Gunter
This patch updates the NX driver to perform several hyper calls when necessary
so that the length limits of scatter/gather lists are respected.
Reviewed-by: Joy Latten
Reviewed-by: Marcelo Cerri
Signed-off-by: Fionnuala Gunter
---
drivers/crypto/nx/nx-aes-xcbc.c | 107
This patch updates the nx-aes-gcm implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- "ibm,max-sg-len": maximum number of bytes of each scatter/gather
list.
- "ibm,max-sync-cop"
This patch updates the nx-aes-cbc implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- "ibm,max-sg-len": maximum number of bytes of each scatter/gather
list.
- "ibm,max-sync-cop"
Each call to the co-processor, with exception of the last call, needs to
send data that is multiple of block size. As consequence, any remaining
data is kept in the internal NX context.
This patch fixes a bug in the driver that causes it to save incorrect
data into the context when data is bigger
The NX XCBC implementation doesn't support zero length messages and
because of that NX is currently returning a hard-coded hash for zero
length messages. However this approach is incorrect since the hash value
also depends on which key is used.
This patch removes the hard-coded hash and replace it
From: Fionnuala Gunter
This patch updates the NX driver to perform several hyper calls when necessary
so that the length limits of scatter/gather lists are respected.
Reviewed-by: Marcelo Cerri
Signed-off-by: Joy Latten
Signed-off-by: Fionnuala Gunter
---
drivers/crypto/nx/nx-aes-ccm.c | 297
This patch updates the nx-aes-ecb implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- "ibm,max-sg-len": maximum number of bytes of each scatter/gather
list.
- "ibm,max-sync-cop"
On Thu, Aug 29, 2013 at 02:42:22PM +1000, Herbert Xu wrote:
> On Fri, Aug 23, 2013 at 05:01:07PM -0300, Marcelo Cerri wrote:
> > This patch updates the nx-aes-cbc implementation to perform several
> > hyper calls if needed in order to always respect the length limits for
> > scatter/gather lists.
>
20 matches
Mail list logo
