Re: linux-next: Tree for Oct 26 (crypto/acompress.ko)
Hi, On Wed, Oct 26, 2016 at 07:54:00PM -0400, Paul Gortmaker wrote: > So, no EXPORT_SYMBOL, and any .config which has ACOMP2=m will fail. I sent a patch for this: https://patchwork.kernel.org/patch/9396503/ Regards, -- Giovanni -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] libkcapi v0.12.0 released
Am Mittwoch, 26. Oktober 2016, 22:05:28 CEST schrieb Jeffrey Walton: Hi Jeffrey, > > The Linux kernel exports a network interface of type AF_ALG to allow user > > space to utilize the kernel crypto API. libkcapi uses this network > > interface and exports an easy to use API so that a developer does not > > need to consider the low-level network interface handling. > > > > The library does not implement any low level cipher algorithms. All > > consumer requests are sent to the kernel for processing. Results from the > > kernel crypto API are returned to the consumer via the library API. > > > > The kernel interface and therefore this library can be used by > > unprivileged > > processes. > > > > The library code archive also provides a drop-in replacement for the > > command line tools of sha*sum, fipscheck/fipshmac and sha512hmac. > > > > The source code and the documentation is available at [1]. > > That looks awesome Stephan. > > How can user code reliably detect when the API is available? Are there The detection is done through the various _init calls such as kcapi_cipher_init. They will return an error if AF_ALG is not available. According to the documentation these calls return: * @return 0 upon success; ENOENT - algorithm not available; * -EOPNOTSUPP - AF_ALG family not available; * -EINVAL - accept syscall failed * -ENOMEM - cipher handle cannot be allocated Technically, the bind operation will fail if the respective AF_ALG interface is not available. > any preprocessor macros to guard code paths in userland? What are the There are no special guards. If AF_ALG is available, all user space processes can use it. > preprocessor macros we can use to guard it? I am not entirely sure I understand the question. > > Jeff Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] libkcapi v0.12.0 released
> The Linux kernel exports a network interface of type AF_ALG to allow user > space to utilize the kernel crypto API. libkcapi uses this network interface > and exports an easy to use API so that a developer does not need to consider > the low-level network interface handling. > > The library does not implement any low level cipher algorithms. All consumer > requests are sent to the kernel for processing. Results from the kernel crypto > API are returned to the consumer via the library API. > > The kernel interface and therefore this library can be used by unprivileged > processes. > > The library code archive also provides a drop-in replacement for the command > line tools of sha*sum, fipscheck/fipshmac and sha512hmac. > > The source code and the documentation is available at [1]. That looks awesome Stephan. How can user code reliably detect when the API is available? Are there any preprocessor macros to guard code paths in userland? What are the preprocessor macros we can use to guard it? Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] libkcapi v0.12.0 released
Hi, The Linux kernel exports a network interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this network interface and exports an easy to use API so that a developer does not need to consider the low-level network interface handling. The library does not implement any low level cipher algorithms. All consumer requests are sent to the kernel for processing. Results from the kernel crypto API are returned to the consumer via the library API. The kernel interface and therefore this library can be used by unprivileged processes. The library code archive also provides a drop-in replacement for the command line tools of sha*sum, fipscheck/fipshmac and sha512hmac. The source code and the documentation is available at [1]. [1] http://www.chronox.de/libkcapi.html Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: fix AEAD tag memory handling
Hi Herbert,
for this patch, I have updated the testing for libkcapi accordingly and all
tests pass. I will push the libkcapi code 0.12 with that test code change
out shortly. Using the current upstream version of 0.11.1 will show failures
as it expects the correct recv return code. As stated below, that return
code has changed which implies that some of the tests will fail.
---8<---
For encryption, the AEAD ciphers require AAD || PT as input and generate
AAD || CT || Tag as output and vice versa for decryption. Prior to this
patch, the AF_ALG interface for AEAD ciphers requires the buffer to be
present as input for encryption. Similarly, the output buffer for
decryption required the presence of the tag buffer too. This implies
that the kernel reads / writes data buffers from/to user space
even though this operation is not required.
This patch changes the AF_ALG AEAD interface to be consistent with the
in-kernel AEAD cipher memory requirements.
In addition, the code now handles the situation where the provided
output buffer is too small by reducing the size of the processed
input buffer accordingly. Due to this handling, the changes are
transparent to user space with one exception: the return code of recv
indicates the processed of output buffer size. That output buffer has a
different size compared to before the patch which implies that the
return code of recv will also be different. For example, a decryption
operation uses 16 bytes AAD, 16 bytes CT and 16 bytes tag, the AF_ALG
AEAD interface before showed a recv return code of 48 (bytes) whereas
after this patch, the return code is 32 since the tag is not returned
any more.
Reported-by: Mat Martineau
Signed-off-by: Stephan Mueller
---
crypto/algif_aead.c | 77 ++---
1 file changed, 55 insertions(+), 22 deletions(-)
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 80a0f1a..c54bcb8 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -81,7 +81,11 @@ static inline bool aead_sufficient_data(struct aead_ctx *ctx)
{
unsigned as = crypto_aead_authsize(crypto_aead_reqtfm(&ctx->aead_req));
- return ctx->used >= ctx->aead_assoclen + as;
+ /*
+* The minimum amount of memory needed for an AEAD cipher is
+* the AAD and in case of decryption the tag.
+*/
+ return ctx->used >= ctx->aead_assoclen + (ctx->enc ? 0 : as);
}
static void aead_reset_ctx(struct aead_ctx *ctx)
@@ -426,12 +430,15 @@ static int aead_recvmsg_async(struct socket *sock, struct
msghdr *msg,
goto unlock;
}
- used = ctx->used;
- outlen = used;
-
if (!aead_sufficient_data(ctx))
goto unlock;
+ used = ctx->used;
+ if (ctx->enc)
+ outlen = used + as;
+ else
+ outlen = used - as;
+
req = sock_kmalloc(sk, reqlen, GFP_KERNEL);
if (unlikely(!req))
goto unlock;
@@ -445,7 +452,7 @@ static int aead_recvmsg_async(struct socket *sock, struct
msghdr *msg,
aead_request_set_ad(req, ctx->aead_assoclen);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
aead_async_cb, sk);
- used -= ctx->aead_assoclen + (ctx->enc ? as : 0);
+ used -= ctx->aead_assoclen;
/* take over all tx sgls from ctx */
areq->tsgl = sock_kmalloc(sk, sizeof(*areq->tsgl) * sgl->cur,
@@ -461,7 +468,7 @@ static int aead_recvmsg_async(struct socket *sock, struct
msghdr *msg,
areq->tsgls = sgl->cur;
/* create rx sgls */
- while (iov_iter_count(&msg->msg_iter)) {
+ while (outlen > usedpages && iov_iter_count(&msg->msg_iter)) {
size_t seglen = min_t(size_t, iov_iter_count(&msg->msg_iter),
(outlen - usedpages));
@@ -491,16 +498,20 @@ static int aead_recvmsg_async(struct socket *sock, struct
msghdr *msg,
last_rsgl = rsgl;
- /* we do not need more iovecs as we have sufficient memory */
- if (outlen <= usedpages)
- break;
-
iov_iter_advance(&msg->msg_iter, err);
}
- err = -EINVAL;
+
/* ensure output buffer is sufficiently large */
- if (usedpages < outlen)
- goto free;
+ if (usedpages < outlen) {
+ size_t less = outlen - usedpages;
+
+ if (used < less) {
+ err = -EINVAL;
+ goto unlock;
+ }
+ used -= less;
+ outlen -= less;
+ }
aead_request_set_crypt(req, areq->tsgl, areq->first_rsgl.sgl.sg, used,
areq->iv);
@@ -571,6 +582,7 @@ static int aead_recvmsg_sync(struct socket *sock, struct
msghdr *msg, int flags)
goto unlock;
}
+ /* data length provided by caller via sendmsg/sendpage
Re: linux-next: Tree for Oct 26 (crypto/acompress.ko)
On Wed, Oct 26, 2016 at 10:48 AM, Randy Dunlap wrote: > On 10/25/16 19:51, Stephen Rothwell wrote: >> Hi all, >> >> There will probably be no linux-next releases next week while I attend >> the Kernel Summit. >> >> Changes since 20161025: >> > > on x864_64: > > ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined! > ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined! > ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined! > > > Full randconfig file is attached. crypto/acompress.o > crypto/Makefile:obj-$(CONFIG_CRYPTO_ACOMP2) += acompress.o crypto/Kconfig:config CRYPTO_ACOMP2 crypto/Kconfig: tristate paul@builder:~/git/linux-head$ git grep crypto_acomp_scomp_alloc_ctx crypto/acompress.c: return crypto_acomp_scomp_alloc_ctx(req); crypto/scompress.c:struct acomp_req *crypto_acomp_scomp_alloc_ctx(struct acomp_req *req) include/crypto/internal/scompress.h:struct acomp_req *crypto_acomp_scomp_alloc_ctx(struct acomp_req *req); paul@builder:~/git/linux-head$ So, no EXPORT_SYMBOL, and any .config which has ACOMP2=m will fail. Paul. -- > > -- > ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
On Tue, Oct 25, 2016 at 07:38:55AM +0200, LABBE Corentin wrote: > On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote: > > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote: > > > Since SID's content is constant over reboot, > > > > That's not true, at least not across all the Allwinner SoCs, and > > especially not on the A10 and A20 that this driver supports. > > > > On my cubieboard2 (A20) > hexdump -C > /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem > 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0200 > cubiedev ~ # reboot > cubiedev ~ # hexdump -C > /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem > 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0200 > > So clearly for me its constant. It's constant across reboots, but not across devices. Each device have a different SID content, therefore it's a relevant source of entropy in the system. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH 2/3] crypto: testmgr - Add missing tests for internal sha256-mb implementation
Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.
Signed-off-by: Marcelo Cerri
---
crypto/testmgr.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index d999373..58f903d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2309,6 +2309,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+ .alg = "__intel_sha256-mb",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3758,6 +3762,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+ .alg = "mcryptd(__intel_sha256-mb)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] crypto: testmgr - Add missing tests for internal sha512-mb implementation
Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.
Signed-off-by: Marcelo Cerri
---
crypto/testmgr.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 58f903d..cfafd24 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2313,6 +2313,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+ .alg = "__intel_sha512-mb",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3766,6 +3770,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+ .alg = "mcryptd(__intel_sha512-mb)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] crypto: testmgr - Add missing tests for internal sha*-mb implementations
This series adds null tests for all sha*-mb internal algorithms so they can be used in FIPS mode without further problems. Since they are 3 separated modules I decided to use a separated commit for each one. Marcelo Cerri (3): crypto: testmgr - Add missing tests for internal sha1-mb implementation crypto: testmgr - Add missing tests for internal sha256-mb implementation crypto: testmgr - Add missing tests for internal sha512-mb implementation crypto/testmgr.c | 24 1 file changed, 24 insertions(+) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] crypto: testmgr - Add missing tests for internal sha1-mb implementation
Add null tests for the internal algorithm to avoid errors when running
in FIPS mode.
Signed-off-by: Marcelo Cerri
---
crypto/testmgr.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ded50b6..d999373 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2305,6 +2305,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.test = alg_test_null,
.fips_allowed = 1,
}, {
+ .alg = "__intel_sha1-mb",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ansi_cprng",
.test = alg_test_cprng,
.suite = {
@@ -3750,6 +3754,10 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "mcryptd(__intel_sha1-mb)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "md4",
.test = alg_test_hash,
.suite = {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AEAD Question
Am Mittwoch, 26. Oktober 2016, 18:17:14 CEST schrieb Juan Pablo Nariño Mendoza: Hi Juan, > Sorry in advance for making what shall be a basic question for this > list, but I have really ran out of ideas. > > Can someone explain me please, how does the memory layout and sg lists > work for the IPSec case, with generated IV case? > > As I understand, it is like this (ascii art) > > AD | IV Space | Plain Text | Auth Tag > ^ ^ > > asg sg The memory layout is correct when using the RFC4106 cipher. How you partition your physical memory with the SGL is your choice as long as your data in the SGL is lined up as you mentioned above. > > But I am having the AD overwritten, and the AUTH tag and encryption is > not correct? Could someone please point me in the right direction? > Thank you again Maybe the src and dst SGL somehow partially overlap? > > Regards > > Juan > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AEAD Question
Sorry in advance for making what shall be a basic question for this list, but I have really ran out of ideas. Can someone explain me please, how does the memory layout and sg lists work for the IPSec case, with generated IV case? As I understand, it is like this (ascii art) AD | IV Space | Plain Text | Auth Tag ^ ^ || asg sg But I am having the AD overwritten, and the AUTH tag and encryption is not correct? Could someone please point me in the right direction? Thank you again Regards Juan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for Oct 26 (crypto/acompress.ko)
On 10/25/16 19:51, Stephen Rothwell wrote: > Hi all, > > There will probably be no linux-next releases next week while I attend > the Kernel Summit. > > Changes since 20161025: > on x864_64: ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined! ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined! ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined! Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.9.0-rc2 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEBUG_RODATA=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_KERNEL_LZ4=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_TREE_RCU_TRACE=y CONFIG_RCU_BOOST=y CONFIG_RCU_KTHREAD_PRIO=1 CONFIG_RCU_BOOST_DELAY=500 CONFIG_RCU_NOCB_CPU=y # CONFIG_RCU_NOCB_CPU_NONE is not set CONFIG_RCU_NOCB_CPU_ZERO=y # CONFIG_RCU_NOCB_CPU_ALL is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_NMI_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_NUMA_BALANCING is not set CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_CGROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_RT_GROUP_SCHED is not set # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set CONFIG_USER_NS=y CONFIG_PID_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set CONFIG_RD_LZMA=y # CONFIG_RD_XZ is not set CONFIG_RD_LZO=y # CONFIG_RD_LZ4 is not set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is
Re: ARM-CE aes encryption on uneven blocks
Then what is the role of the "for" structure? Why not do just a single encryption/decryption call? Regards, Cata >From: Hamid Nassiby >Sent: Wednesday, October 26, 2016 10:16 AM >To: Cata Vasile >Cc: linux-crypto@vger.kernel.org >Subject: Re: ARM-CE aes encryption on uneven blocks > >Hi,> >Based on my old experience with "struct crypto_alg" based drivers, the >data you receive there, is padded beforehand(in the upper layers); >Therefore the plaintext contains integral multiple of AES block size >of data and based on the number of blocks, the crypto transform can be >computed.> >Regards, >Hamid> >On Mon, Oct 24, 2016 at 6:11 PM, Cata Vasile wrote: >> >> Hi, >> >> I'm trying to understand the code for AES encryption from ARM-CE. >> From the aes-glue.S calls I understand that the encryption primitives >> receive the number of blocks, but have no way of determining the number of >> bytes to encrypt, if for example the plaintext does not have a length of a >> multiple of AES block size. >> How does, for example, ecb_encrypt() also encrypt the last remaining bytes >> in the plaintext if it is not a multiple of AES block size if It can never >> deduce the full plaintext size? >> >> Catalin Vasile-- >> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at >> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Fmajordomo-info.html&data=01%7C01%7Ccata.vasile%40nxp.com%7C4c5ecc69183f40e96faf08d3fd701bab%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=vVYloLYwzQl3keXvz%2FMdV3d2ruHmn26F%2FfY%2FA7GG8wA%3D&reserved=0 >-- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] chcr: Remove malloc/free
On 21-10-2016 07:50, Herbert Xu wrote: > On Thu, Oct 13, 2016 at 04:39:35PM +0530, Harsh Jain wrote: >> Remove malloc/free in crypto operation and allocate memory via cra_ctxsize. >> Added new structure chcr_wr to populate Work Request Header. >> Fixes: 324429d74127 (chcr: Support for Chelsio's Crypto Hardware) > Do you mean the reqsize as opposed to ctxsize since the latter is > shared by all tfm users? It's reqsize for hash algos (chcr_ahash_req_ctx struct ) and ctxsize for Cipher algos(ablk_ctx struct),As rrkey(reverse round key) is also same for all tfm. > > In any case, your patch doesn't seem to change the size setting? Added new variables in old structure. Size setting related code is unchanged. In v2 will break the patch to smaller one. > > Cheers, -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [cryptodev:master 41/47] ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
Hi, On Wed, Oct 26, 2016 at 08:47:16AM +0800, kbuild test robot wrote: > >> ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined! > >> ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined! > >> ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined! Thanks for the report. There is a problem with a dependency between acomp and scomp. This patch should fix the issue. Giovanni ---8<--- Subject: [PATCH] crypto: acomp - fix dependency in Makefile Fix dependency between acomp and scomp that appears when acomp is built as module Signed-off-by: Giovanni Cabiddu --- crypto/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/crypto/Makefile b/crypto/Makefile index 5c83f3d..82ffeee 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -50,8 +50,9 @@ rsa_generic-y += rsa_helper.o rsa_generic-y += rsa-pkcs1pad.o obj-$(CONFIG_CRYPTO_RSA) += rsa_generic.o -obj-$(CONFIG_CRYPTO_ACOMP2) += acompress.o -obj-$(CONFIG_CRYPTO_ACOMP2) += scompress.o +crypto_acompress-y := acompress.o +crypto_acompress-y += scompress.o +obj-$(CONFIG_CRYPTO_ACOMP2) += crypto_acompress.o cryptomgr-y := algboss.o testmgr.o -- -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM-CE aes encryption on uneven blocks
Hi, Based on my old experience with "struct crypto_alg" based drivers, the data you receive there, is padded beforehand(in the upper layers); Therefore the plaintext contains integral multiple of AES block size of data and based on the number of blocks, the crypto transform can be computed. Regards, Hamid On Mon, Oct 24, 2016 at 6:11 PM, Cata Vasile wrote: > > Hi, > > I'm trying to understand the code for AES encryption from ARM-CE. > From the aes-glue.S calls I understand that the encryption primitives receive > the number of blocks, but have no way of determining the number of bytes to > encrypt, if for example the plaintext does not have a length of a multiple of > AES block size. > How does, for example, ecb_encrypt() also encrypt the last remaining bytes in > the plaintext if it is not a multiple of AES block size if It can never > deduce the full plaintext size? > > Catalin Vasile-- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
