Hi All,
How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
userspace program.I check libkcapi library. It has test programs for
GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
Which of them is supported in crypto framework.
1) Encrypt-then-MAC (EtM)
Th
Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain:
Hi Harsh,
> Hi All,
>
> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
> userspace program.I check libkcapi library. It has test programs for
> GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
> Wh
On Mon, May 09, 2016 at 10:40:41PM +0100, Salvatore Benedetto wrote:
>
> + do {
> + if (tries++ >= MAX_TRIES)
> + goto err_retries;
> +
> + ecc_point_mult(pk, &curve->g, priv, NULL, curve->p, ndigits);
> +
> + } while (ecc_point_is_zero(pk));
You
On Thu, May 12, 2016 at 06:00:33PM +0300, Tudor Ambarus wrote:
>
> int rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
> const void *value, size_t vlen)
> {
> struct rsa_key *key = context;
> + const char *ptr = value;
> + int ret;
>
> - key->n = mpi_rea
Hi all,
I am working on SAMA5D3 board with atmel-aes driver, I have a question
about sg.
This board does not support XTS mode, however we want to add this
functionality.
As a recall XTS mode :
For a 512 bytes block:
1) We encrypt the given IV with the second part of the key [ECB].
2) We
On Thu, May 19, 2016 at 05:43:04PM -0700, Megha Dey wrote:
> From: Megha Dey
>
> Currently there are several checkpatch warnings in the sha1_mb.c file:
> 'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
> syntax of some multi-line comments are not correct. This patch fixes
> th
Hi,
You means to say like this
./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k
8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i
7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2
-l 16f4a
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Tuesday, May 31, 2016 7:55 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v5 3/3] crypto: kpp - Add ECDH software support
>
> On Mon, May 09, 2016 at 10:40:41PM +
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Tuesday, May 31, 2016 7:53 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v5 2/3] crypto: kpp - Add DH software implementation
>
> On Mon, May 09, 2016 at 10:40:4
Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain:
Hi Harsh,
> Hi,
>
> You means to say like this
>
> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k
> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb42
Hi,
Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add
some switch cases in tool to test digest and finup path of crypto
driver. Current implementation triggers only init/update/final.
Regards
Harsh Jain
On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller wrote:
> Am Dienstag,
Am Dienstag, 31. Mai 2016, 14:45:27 schrieb Harsh Jain:
Hi Harsh,
> Hi,
>
> Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add
> some switch cases in tool to test digest and finup path of crypto
> driver. Current implementation triggers only init/update/final.
You mean for h
Hi James,
> Could you pass this along to Linus as soon as possible, please? This
> alters a new keyctl function added in the current merge window to allow for
> a future extension planned for the next merge window.
Is this likely to go to Linus before -rc2? If not, we'll need to do things
diffe
On Fri, May 27, 2016 at 11:32:36AM +0200, Christophe Leroy wrote:
>
> + sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len,
> + &edesc->link_tbl[tbl_off])
> + if (sg_count == 1) {
> + /* Only one segment now, so no link tbl needed*/
On Fri, May 13, 2016 at 02:02:00PM +0200, Stephan Mueller wrote:
> Add the MODULE_ALIAS for the cra_driver_name of the different ciphers to
> allow an automated loading if a driver name is used.
>
> Signed-off-by: Stephan Mueller
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org
On Mon, May 16, 2016 at 02:53:36AM +0200, Stephan Mueller wrote:
> The CRYPTO_MSG_GETALG netlink message type provides a buffer to the
> kernel to retrieve information from the kernel. The data buffer will not
> provide any input and will not be read. Hence the nlmsg_parse is not
> applicable to th
On Tue, May 17, 2016 at 10:53:51AM -0700, Tadeusz Struk wrote:
> The sizeof(*ctx->dec_cd) and sizeof(*ctx->enc_cd) are equal,
> but we should use the correct one for freeing memory anyway.
>
> Signed-off-by: Tadeusz Struk
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~her
On Sat, May 21, 2016 at 02:03:38PM +0200, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linu
On Sat, May 21, 2016 at 01:36:43PM +0200, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linu
On Sun, May 22, 2016 at 11:05:51AM +0200, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbe
On Sun, May 22, 2016 at 11:05:56AM +0200, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbe
On Thu, May 19, 2016 at 06:06:45PM +0300, Horia Geantă wrote:
> v3:
> -DT maintainers - please ack patch 8/8 "arm64: dts: ls1043a: add crypto node"
> (to go into kernel 4.8 via crypto tree)
> -Fixed typo in pdb.h: s/be32/__be32
> -Appended Acks (from v2) into commit messages
> -Tested that current
On Thu, May 26, 2016 at 12:57:50PM +0200, Nicolai Stange wrote:
> mpi_set_buffer() has no in-tree users and similar functionality is provided
> by mpi_read_raw_data().
>
> Remove mpi_set_buffer().
>
> Signed-off-by: Nicolai Stange
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.o
On Thu, May 26, 2016 at 11:34:57AM +0200, Maxime Coquelin wrote:
> This patch fixes the following warning:
> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
> uninitialize
On Thu, May 26, 2016 at 01:05:31PM +0200, Nicolai Stange wrote:
> In mpi_read_raw_data(), unsigned nbits is calculated as follows:
>
> nbits = nbytes * 8;
>
> and redundantly cleared later on if nbytes == 0:
>
> if (nbytes > 0)
> ...
> else
> nbits = 0;
>
> Purge this redundant cle
On Thu, May 26, 2016 at 11:19:50PM +0200, Nicolai Stange wrote:
> mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a
> fair amount of common code.
>
> This patchset attempts to rewrite mpi_read_from_buffer() in order to implement
> it in terms of mpi_read_raw_data().
>
On Fri, May 27, 2016 at 01:49:40PM +0200, Krzysztof Kozlowski wrote:
> Bring some consistency by:
> 1. Replacing fixed-space indentation of structure members with just
>tabs.
> 2. Remove indentation in declaration of local variable between type and
>name. Driver was mixing usage of such in
On Fri, May 27, 2016 at 06:10:37AM -0400, Yendapally Reddy Dhananjaya Reddy
wrote:
> This patchset contains the hw random number generator support for the
> Broadcom's NSP SoC. The block is similar to the block available in
> bcm2835 with different default interrupt mask value. Due to lack of
> do
Hi Stephen,
Yes ,It's for Hash. The available API in library for hash update
"_kcapi_md_update" uses "MSG_MORE" flag always set. It will not
trigger driver's digest/finup implementation. We need something like
that
_kcapi_common_accept()
send(handle->opfd, buffer, len, 0); ==> flag = 0.
It will
Am Dienstag, 31. Mai 2016, 16:28:14 schrieb Harsh Jain:
Hi Harsh,
> Hi Stephen,
>
> Yes ,It's for Hash. The available API in library for hash update
> "_kcapi_md_update" uses "MSG_MORE" flag always set. It will not
> trigger driver's digest/finup implementation. We need something like
> that
>
The CTR DRBG code always set the key for each sym cipher invocation even
though the key has not been changed.
The patch ensures that the setkey is only invoked when a new key is
generated by the DRBG.
With this patch, the CTR DRBG performance increases by more than 150%.
Signed-off-by: Stephan M
Hi Herbert,
with that patch, the CTR DRBG is the fasted DRBG by orders of magnitude --
about 2 times faster than the HMAC DRBG (current default) and 1.5 times faster
than the Hash DRBG.
However, I am not too fond of the CTR DRBG due to the following that I already
mentioned some days ago. Quot
Hi,
1) User can use libkcapi to write program for finup/digest.
2) No, kernel test for finup (not sure).
3) We can test all callback of new hash tfm drivers added in kernel.
4) My driver had issue in finup path which is not caught by kcapi test
program :)
regards
Harsh Jain
regards
Harsh Jain
O
Add known answer tests to the testmgr for the KDF (SP800-108) cipher.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.c | 167 +++
crypto/testmgr.h | 111
2 files changed, 278 insertions(+)
diff --git a/c
Include KDF into Kconfig and Makefile for compilation.
Signed-off-by: Stephan Mueller
---
crypto/Kconfig | 7 +++
crypto/Makefile | 1 +
2 files changed, 8 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 1d33beb..89c1891 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@
Hi,
this patch set implements all three key derivation functions defined in
SP800-108.
The implementation is provided as a template for random number generators,
since a KDF can be considered a form of deterministic RNG where the key
material is used as a seed.
With the KDF implemented as a temp
The SP800-108 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.
All three KDF types specified in SP800-108 are implemented.
The code comments provide details about how to invoke the different KDF
types.
Signed-off-
This patch adds the ability to register templates for RNGs. RNGs are
"meta" mechanisms using raw cipher primitives. Thus, RNGs can now be
implemented as templates to allow the complete flexibility the kernel
crypto API provides.
Signed-off-by: Stephan Mueller
---
crypto/rng.c | 31 ++
Am Dienstag, 31. Mai 2016, 17:22:12 schrieb Harsh Jain:
Hi Harsh,
> Hi,
>
> 1) User can use libkcapi to write program for finup/digest.
> 2) No, kernel test for finup (not sure).
> 3) We can test all callback of new hash tfm drivers added in kernel.
> 4) My driver had issue in finup path which i
This patch implements an scomp backend for the lz4 compression algorithm.
This way, lz4 is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lz4.c | 91 +--
2 files changed, 82 insertions(+),
This patch adds tests to the test manager for algorithms exposed through
the acomp api
Signed-off-by: Giovanni Cabiddu
---
crypto/testmgr.c | 158 +-
1 files changed, 145 insertions(+), 13 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/t
Add a synchronous back-end (scomp) to acomp. This allows to easily expose
the already present compression algorithms in LKCF via acomp
Signed-off-by: Giovanni Cabiddu
---
crypto/Makefile |1 +
crypto/acompress.c | 49 +++-
crypto/scompress.c
This patch implements an scomp backend for the 842 compression algorithm.
This way, 842 is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/842.c | 82 +--
crypto/Kconfig |1 +
2 files changed, 80 insertions(+),
This patch implements an scomp backend for the deflate compression
algorithm. This way, deflate is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/deflate.c | 111 +-
2 files changed, 102 in
This patch implements an scomp backend for the lz4hc compression algorithm.
This way, lz4hc is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lz4hc.c | 92 +--
2 files changed, 83 insertions
Move hash to 0xe to free up the space for acomp/scomp/qdecomp
Signed-off-by: Giovanni Cabiddu
---
include/linux/crypto.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6e28c89..d844cbc 100644
--- a/include/l
This patch introduces acomp, an asynchronous compression api that uses
scatterlist buffers.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig | 10 ++
crypto/Makefile |2 +
crypto/acompress.c | 118
crypto/crypto_
This patch introduces qdecomp, an asynchronous decompression api.
qdecomp is a front-end for acomp and scomp algorithms which do not
not need additional vmalloc work space for decompression.
Signed-off-by: Giovanni Cabiddu
---
crypto/Makefile |1 +
crypto/acompress.c
The following patch set introduces acomp, a generic asynchronous
(de)compression api with support for SG lists.
We propose a new crypto type called crypto_acomp_type, a new struct acomp_alg
and struct crypto_acomp, together with number of helper functions to register
acomp type algorithms and alloc
This patch implements an scomp backend for the lzo compression algorithm.
This way, lzo is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lzo.c | 97 +++-
2 files changed, 83 insertions(+)
Hi Herb,
the following patchset introduces a new API for abstracting key-agreement
protocols such as DH and ECDH. It provides the primitives required for
implementing
the protocol, thus the name KPP (Key-agreement Protocol Primitives).
Regards,
Salvatore
Changes from v6:
* Remove len parameter
* Implement MPI based Diffie-Hellman under kpp API
* Test provided uses data generad by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig | 8 ++
crypto/Makefile | 2 +
crypto/dh.c | 223
crypto/testmgr.c
* Implement ECDH under kpp API
* Provide ECC software support for curve P-192 and
P-256.
* Add kpp test for ECDH with data generated by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig |5 +
crypto/Makefile |3 +
crypto/ecc.c| 1011
Add key-agreement protocol primitives (kpp) API which allows to
implement primitives required by protocols such as DH and ECDH.
The API is composed mainly by the following functions
* set_params() - It allows the user to set the parameters known to
both parties involved in the key-agreement ses
On Thu, 26 May 2016, David Howells wrote:
Mat Martineau wrote:
+struct keyctl_kdf_params {
+ char *name;
+ __u8 reserved[32]; /* Reserved for future use, must be 0 */
+};
+
#endif /* _LINUX_KEYCTL_H */
diff --git a/security/keys/compat.c b/security/keys/compat.c
index c8783b3..3
On 05/31/2016 03:19 AM, Herbert Xu wrote:
> On Fri, May 27, 2016 at 06:10:37AM -0400, Yendapally Reddy Dhananjaya Reddy
> wrote:
>> This patchset contains the hw random number generator support for the
>> Broadcom's NSP SoC. The block is similar to the block available in
>> bcm2835 with different
Hi Mat,
On 05/25/2016 05:45 PM, Mat Martineau wrote:
>
> On Sat, 14 May 2016, Tadeusz Struk wrote:
>
>> diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
>> index e00793d..6733df1 100644
>> --- a/crypto/algif_akcipher.c
>> +++ b/crypto/algif_akcipher.c
>> +static int asym_key_verify(
The LRNG with all its properties is documented in [1]. This
documentation covers the functional discussion as well as testing of all
aspects of entropy processing. In addition, the documentation explains
the conducted regression tests to verify that the LRNG is API and ABI
compatible with the legac
The Hyper-V Linux Integration Services use the VMBus implementation for
communication with the Hypervisor. VMBus registers its own interrupt
handler that completely bypasses the common Linux interrupt handling.
This implies that the interrupt entropy collector is not triggered.
This patch adds the
When selecting the LRNG for compilation, disable the legacy /dev/random
implementation.
The LRNG is a drop-in replacement for the legacy /dev/random which
implements the same in-kernel and user space API. Only the hooks of
/dev/random into other parts of the kernel need to be disabled.
Signed-off
Add LRNG compilation support.
Signed-off-by: Stephan Mueller
---
crypto/Kconfig | 10 ++
crypto/Makefile | 1 +
2 files changed, 11 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 1d33beb..9aaf96c 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1588,6 +1588,16 @@
This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 11 +--
include/crypto/drbg.h | 7 +++
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/crypto/drbg.
Hi Herbert, Ted,
The following patch set provides a different approach to /dev/random which
I call Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the legacy /dev/random is to provide
sufficient entropy during boot time as well as
Herbert Xu writes:
> On Thu, May 26, 2016 at 11:19:50PM +0200, Nicolai Stange wrote:
>> mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a
>> fair amount of common code.
>>
>> This patchset attempts to rewrite mpi_read_from_buffer() in order to
>> implement
>> it in t
On Tue, 2016-05-31 at 16:13 +0800, Herbert Xu wrote:
> On Thu, May 19, 2016 at 05:43:04PM -0700, Megha Dey wrote:
> > From: Megha Dey
> >
> > Currently there are several checkpatch warnings in the sha1_mb.c file:
> > 'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
> > syntax o
From: Megha Dey
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm.
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
This patch introduces a async interface for even the inner algo
From: Megha Dey
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a async interface for even the inner algo
From: Megha Dey
Currently there are several checkpatch warnings in the sha1_mb.c file:
'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
syntax of some multi-line comments are not correct. This patch fixes
these issues.
Signed-off-by: Megha Dey
---
arch/x86/crypto/sha-mb/sha1
I'll be a while going through this.
I was thinking about our earlier discussion where I was hammering on
the point that compressing entropy too early is a mistake, and just
now realized that I should have given you credit for my recent 4.7-rc1
patch 2a18da7a. The hash function ("good, fast AND ch
On Tue, May 31, 2016 at 10:09:39AM -0700, Florian Fainelli wrote:
>
> FYI, ARM Device Tree patches usually go via ARM SoC pull requests, so it
> is best if this is planned in advance. Can you make sure you document
> that there could be a merge conflict in your pull request to Linus?
Sure I can do
On 30 May 2016 at 21:32, LABBE Corentin wrote:
> Since the crypto engine has been converted to use crypto_async_request
> instead of ablkcipher_request, minor changes are needed to use it.
>
> Signed-off-by: LABBE Corentin
> ---
> drivers/crypto/omap-aes.c | 10 ++
> drivers/crypto/omap-
On 30 May 2016 at 21:32, LABBE Corentin wrote:
> The current crypto engine allow only ablkcipher_request to be enqueued.
> Thus denying any use of it for hardware that also handle hash algo.
>
> This patch convert all ablkcipher_request references to the
> more general crypto_async_request.
>
> Si
On Tue, 31 May 2016, David Howells wrote:
> Hi James,
>
> > Could you pass this along to Linus as soon as possible, please? This
> > alters a new keyctl function added in the current merge window to allow for
> > a future extension planned for the next merge window.
>
> Is this likely to go to
Please forgive my ignorance here...
I have test system with a VIA C7-M processor and PM-400 chipset. This
is one of those Thin Client/Internet of Things processor and chipsets
I test security libraries on (like OpenSSL, Cryptlib and Crypto++).
The processor includes the Padlock extensions. Padloc
This patchset will check if the cipher can support bulk mode, then dm-crypt
will handle different ways to send requests to crypto layer according to
cipher mode. For bulk mode, we can use sg table to map the whole bio and
send all scatterlists of one bio to crypto engine to encrypt or decrypt,
whic
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV in
Since the ecb(aes) cipher does not need to handle the IV things for encryption
or decryption, that means it can support for bulk block when handling data.
Thus this patch adds the CRYPTO_ALG_BULK flag for ecb(aes) cipher to improve
the hardware aes engine's efficiency.
Signed-off-by: Baolin Wang
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than
Jeffrey Walton wrote:
> Please forgive my ignorance here...
>
> I have test system with a VIA C7-M processor and PM-400 chipset. This
> is one of those Thin Client/Internet of Things processor and chipsets
> I test security libraries on (like OpenSSL, Cryptlib and Crypto++).
>
> The processor in
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.
For avoiding the duplicated code in __blk_bios_map_sg() function, add
one parameter to distinguish
Am Mittwoch, 1. Juni 2016, 12:59:43 schrieb Herbert Xu:
Hi Herbert,
> Jeffrey Walton wrote:
> > Please forgive my ignorance here...
> >
> > I have test system with a VIA C7-M processor and PM-400 chipset. This
> > is one of those Thin Client/Internet of Things processor and chipsets
> > I test
On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
>
> I thought via-rng.c covers the VIA Padlock RNG?
Indeed, you're quite right. In that case Jeffrey was the via-rng
driver loaded?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gond
82 matches
Mail list logo
