[RFC 0/2] Cipher infrastructure
by Tomasz Bursztyka
Hi,
Went quickly through the cipher proposal, to get a somehow working implementation.
Seems to work with aes, but not with arc4.
And now I wonder if we should not provide an initialization vector for some ciphers? (like arc4).
I thought I could set one IV per socket once, but it does not seems so. (thus there is
nothing related to IV in this RFC).
So, should I set iv elements in struct l_cipher, so I could set one one encrypting/decrypting?
It's just a bit annoying with cmsg handling, but I got nice example with libkapi (though this
one mandate the user to provide the iv. I tought we could handle randomly generated ones?)
libkapi is kind of nice as it uses vmsplice and so on. It's just a lot of code, I don't
think we want something that complex.
Tomasz Bursztyka (2):
cipher: Add a basic infrastructure for kernel based cipher operations
unit: Add unit test for the cipher infrastructure
Makefile.am | 11 ++-
ell/cipher.c | 215 +++++++++++++++++++++++++++++++++++++++++++++++++++++
ell/cipher.h | 51 +++++++++++++
ell/ell.h | 1 +
unit/test-cipher.c | 109 +++++++++++++++++++++++++++
5 files changed, 384 insertions(+), 3 deletions(-)
create mode 100644 ell/cipher.c
create mode 100644 ell/cipher.h
create mode 100644 unit/test-cipher.c
--
2.0.5
6 years, 11 months
[PATCH] genl: Initialize used memory to avoid valgrind report
by Jukka Rissanen
Valgrind reports following error for uninitialized memory usage:
==4725== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==4725== at 0x33F5EF6B5D: send (in /usr/lib64/libc-2.17.so)
==4725== by 0x40BF0E: can_write_data (genl.c:314)
==4725== by 0x417806: io_callback (io.c:138)
==4725== by 0x40A282: l_main_run (main.c:346)
==4725== by 0x401F69: main (main.c:160)
==4725== Address 0x4c3d092 is 18 bytes inside a block of size 40 alloc'd
==4725== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4725== by 0x40817D: l_malloc (util.c:62)
==4725== by 0x40C46A: msg_alloc.constprop.13 (genl.c:243)
==4725== by 0x40D454: l_genl_family_new (genl.c:641)
==4725== by 0x405A44: wiphy_init (wiphy.c:1492)
==4725== by 0x401EDD: main (main.c:154)
==4725==
---
ell/genl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ell/genl.c b/ell/genl.c
index d2c1784..2ef6a34 100644
--- a/ell/genl.c
+++ b/ell/genl.c
@@ -239,7 +239,7 @@ static struct l_genl_msg *msg_alloc(uint8_t cmd, uint8_t version, uint32_t size)
msg->len = NLMSG_HDRLEN + GENL_HDRLEN;
msg->size = msg->len + NLMSG_ALIGN(size);
- msg->data = l_malloc(msg->size);
+ msg->data = l_new(unsigned char, msg->size);
return l_genl_msg_ref(msg);
}
--
1.8.3.1
6 years, 11 months
[PATCH] cipher: RFC on an API for a cipher utility infrastructure
by Tomasz Bursztyka
---
Hi guys,
Here is a quick proposal on the cipher infra for ell. I followed what has
been done with checksums in ell, with obvious differences due to the ciphers
themselves. (2 different actions: encrypt/decrypt and the presence of a key)
I have open issues here:
l_cipher_reset() on its own might not be useful, should I add the possibilty
to change the key as well? Unless there is no cipher state to reset, and then
it's better not having such function. (I am not aware of the kernel cipher
internals, related to some state there so if one can enlight the issue here)
Alos, about encrypt/decrypt. Currently I am proposing to have those as they
will send the data, and we get it back via get_data() (function name it not
that great btw).
So:
- is having only encrypt/decrypt an option? (so send/recv would be done in
each functions). Though 2 blocking functions at a time... not great.
- or, what about enabling async access? Unless I miss something about the
crypto layer in the kernel, here the socket is blocking. So we could be
stalled at some point. checksum does the same, is there any plan to make it
async actually? like a function l_cipher_enable_async(), which would call the
right fcntl() and return the socket which we could use in the event loop.
ell/cipher.h | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 ell/cipher.h
diff --git a/ell/cipher.h b/ell/cipher.h
new file mode 100644
index 0000000..2a0ca2f
--- /dev/null
+++ b/ell/cipher.h
@@ -0,0 +1,52 @@
+/*
+ *
+ * Embedded Linux library
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifndef __ELL_CIPHER_H
+#define __ELL_CIPHER_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+struct l_cipher;
+
+enum l_cipher_type {
+ L_CIPHER_ARC4,
+ L_CIPHER_AES,
+};
+
+struct l_cipher *l_cipher_new(enum l_cipher_type type,
+ const void *key, size_t key_length);
+void l_cipher_free(struct l_cipher *cipher);
+
+void l_cipher_reset(struct l_cipher *cipher);
+
+void l_cipher_encrypt(struct l_cipher *cipher,
+ const void *data, size_t len);
+
+void l_cipher_decrypt(struct l_cipher *cipher,
+ const void *data, size_t len);
+
+void l_cipher_get_data(struct l_cipher *cipher,
+ void *data, size_t len);
+
+#endif /* __ELL_CIPHER_H */
--
2.0.5
6 years, 11 months
[PATCH 0/2] Introduce l_memdup function
by Jukka Rissanen
Hi,
this patch introduces new l_memdup() function in patch 1.
The new function is then used in patch 2. The genl.c was the only
place in the code base where such a change could be done (at least I
could not spot any other place having malloc+memcpy in the code after
quick review).
Cheers,
Jukka
Jukka Rissanen (2):
util: Add l_memdup function for allocation and copying a memory buffer
genl: Convert l_malloc + memcpy to use l_memdup
ell/genl.c | 4 +---
ell/util.c | 23 +++++++++++++++++++++++
ell/util.h | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
--
1.8.3.1
7 years
[PATCH] hashmap: Entry pointers were not freed when map was destroyed
by Jukka Rissanen
The l_hashmap_destroy() did not free the left over entry pointers
that were allocated in l_hashmap_insert(). If user did not remove
them by calling the l_hashmap_remove(), then the entries were left
in the hash which caused a memory leak.
---
ell/hashmap.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/ell/hashmap.c b/ell/hashmap.c
index 8cfe421..b60cc62 100644
--- a/ell/hashmap.c
+++ b/ell/hashmap.c
@@ -322,18 +322,23 @@ LIB_EXPORT void l_hashmap_destroy(struct l_hashmap *hashmap,
return;
for (i = 0; i < NBUCKETS; i++) {
- struct entry *entry, *head = &hashmap->buckets[i];
+ struct entry *entry, *next, *head = &hashmap->buckets[i];
if (!head->next)
continue;
- for (entry = head;; entry = entry->next) {
+ for (entry = head;; entry = next) {
if (destroy)
destroy(entry->value);
free_key(hashmap, entry->key);
- if (entry->next == head)
+ next = entry->next;
+
+ if (entry != head)
+ l_free(entry);
+
+ if (next == head)
break;
}
}
--
1.8.3.1
7 years