Hi Herbert,
On 8/26/20 9:19 AM, Herbert Xu wrote:
On Wed, Aug 26, 2020 at 08:57:17AM -0500, Denis Kenzior wrote:
I'm just waking up now, so I might seem dense, but for my education, can you
tell me why we need to set MSG_MORE when we issue just a single sendmsg
followed immediately by recv
Hi Herbert,
On 8/26/20 8:00 AM, Herbert Xu wrote:
On Wed, Aug 26, 2020 at 02:58:02PM +0200, Andrew Zaborowski wrote:
Running iwd's and ell's unit tests I can see that at least the
following algorithms give EINVAL errors:
ecb(aes)
cbc(aes)
ctr(aes)
The first one fails in recv() and only for
Hi James,
On 03/26/2019 09:25 AM, James Bottomley wrote:
Looking at the contents of linux/keys/trusted.h, it looks like the
wrong decision to move it. The contents are way too improperly named
and duplicative to be in a standard header. It's mostly actually TPM
code including a redefinition
Hi Nick,
So maybe I'm misunderstanding something, but the issue seems to be that
unsigned char is promoted to 'unsigned char *' by Clang and probably
unsigned int or int by gcc.
No. This is extremely well defined behavior in C. In C, integral
types are NEVER promoted to pointer to integer
Hi Nick,
So maybe I'm misunderstanding something, but the issue seems to be that
unsigned char is promoted to 'unsigned char *' by Clang and probably
unsigned int or int by gcc.
No. This is extremely well defined behavior in C. In C, integral
types are NEVER promoted to pointer to integer
Hi Nick,
Refer to
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf
for details.
Can you cite the relevant section?
Just pick any section that describes a TPM command. I randomly used
Section 10.3 for TPM Unbind. See the 'Incoming
Hi Nick,
Refer to
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf
for details.
Can you cite the relevant section?
Just pick any section that describes a TPM command. I randomly used
Section 10.3 for TPM Unbind. See the 'Incoming
Hi James,
From the links provided in the patch it seems that one cannot pass
char/float/short to va_start(). Fair enough. So if we make h3 an
unsigned int, the issue goes away, no?
For the current version of clang, yes. However, if we're fixing this
for good a char * pointer is the only
Hi James,
From the links provided in the patch it seems that one cannot pass
char/float/short to va_start(). Fair enough. So if we make h3 an
unsigned int, the issue goes away, no?
For the current version of clang, yes. However, if we're fixing this
for good a char * pointer is the only
Hi James,
So instead of having unsigned char h3, can't we simply have bool h3
or unsigned int h3?
Given the ambiguity in the standards, the safe thing that will work for
all time and all potential compilers is a char *
All right. You state this with certainty, but I'd still like you to
Hi James,
So instead of having unsigned char h3, can't we simply have bool h3
or unsigned int h3?
Given the ambiguity in the standards, the safe thing that will work for
all time and all potential compilers is a char *
All right. You state this with certainty, but I'd still like you to
Hi James,
So can't we simply use 'bool' or uint32 as the type for h3 instead
of re-ordering everything
The problem is the standard is ambiguious. The only thing that's
guaranteed to work for all time is a char *. If you want to keep the
order, what I'd suggest is inserting a dummy pointer
Hi James,
So can't we simply use 'bool' or uint32 as the type for h3 instead
of re-ordering everything
The problem is the standard is ambiguious. The only thing that's
guaranteed to work for all time is a char *. If you want to keep the
order, what I'd suggest is inserting a dummy pointer
Hi Nick,
@@ -123,7 +123,7 @@ static int TSS_rawhmac(unsigned char *digest, const
unsigned char *key,
*/
static int TSS_authhmac(unsigned char *digest, const unsigned char *key,
unsigned int keylen, unsigned char *h1,
- unsigned char *h2,
Hi Nick,
@@ -123,7 +123,7 @@ static int TSS_rawhmac(unsigned char *digest, const
unsigned char *key,
*/
static int TSS_authhmac(unsigned char *digest, const unsigned char *key,
unsigned int keylen, unsigned char *h1,
- unsigned char *h2,
David,
On 09/20/2018 11:45 AM, David Woodhouse wrote:
On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote:
Hi David,
Yes. It shouldn't be much code, either. You still have to check for X.509
DER since the kernel currently supports that.
For reasons of backward compatibility,
David,
On 09/20/2018 11:45 AM, David Woodhouse wrote:
On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote:
Hi David,
Yes. It shouldn't be much code, either. You still have to check for X.509
DER since the kernel currently supports that.
For reasons of backward compatibility,
Hi David,
On 09/18/2018 11:55 AM, David Howells wrote:
Denis Kenzior wrote:
In theory the PEM file already contains the type of the certificate, at least
at a high level. E.g. private, public, tpm. So if we accept PEM files
directly that could be potentially a faster way of determining
Hi David,
On 09/18/2018 11:55 AM, David Howells wrote:
Denis Kenzior wrote:
In theory the PEM file already contains the type of the certificate, at least
at a high level. E.g. private, public, tpm. So if we accept PEM files
directly that could be potentially a faster way of determining
Hi David,
It passes it to each parser in turn till one says it can parse it. It's not
ideal, but it seems to work - so far. Better would be to annotate it in some
way. I have considered annotating the type field so that the payload doesn't
have to have it added:
keyctl padd
Hi David,
It passes it to each parser in turn till one says it can parse it. It's not
ideal, but it seems to work - so far. Better would be to annotate it in some
way. I have considered annotating the type field so that the payload doesn't
have to have it added:
keyctl padd
Hi David,
On 09/18/2018 11:17 AM, David Woodhouse wrote:
On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote:
Hi David,
On 09/18/2018 10:50 AM, David Howells wrote:
Denis Kenzior wrote:
openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \
-out
Hi David,
On 09/18/2018 11:17 AM, David Woodhouse wrote:
On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote:
Hi David,
On 09/18/2018 10:50 AM, David Howells wrote:
Denis Kenzior wrote:
openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \
-out
Hi David,
On 09/18/2018 10:50 AM, David Howells wrote:
Denis Kenzior wrote:
openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \
-out /tmp/privkey.2048.der
You can use "... -out - | ..." instead.
Aha! okay, that is even more elegant. Yo
Hi David,
On 09/18/2018 10:50 AM, David Howells wrote:
Denis Kenzior wrote:
openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \
-out /tmp/privkey.2048.der
You can use "... -out - | ..." instead.
Aha! okay, that is even more elegant. Yo
Hi David,
On 09/18/2018 01:59 AM, David Woodhouse wrote:
On Wed, 2018-09-05 at 22:54 +0100, David Howells wrote:
Example usage for a PKCS#8 blob:
j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \
keyctl padd asymmetric foo @s`
The kernel expects a
Hi David,
On 09/18/2018 01:59 AM, David Woodhouse wrote:
On Wed, 2018-09-05 at 22:54 +0100, David Howells wrote:
Example usage for a PKCS#8 blob:
j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \
keyctl padd asymmetric foo @s`
The kernel expects a
Hi Stephan,
>>
This brings me to another proposal for read buffer sizing: AF_ALG akcipher
can guarantee that partial reads (where the read buffer is shorter than
the output of the crypto op) will work using the same semantics as
SOCK_DGRAM/SOCK_SEQPACKET. With those sockets, as much data as
Hi Stephan,
>>
This brings me to another proposal for read buffer sizing: AF_ALG akcipher
can guarantee that partial reads (where the read buffer is shorter than
the output of the crypto op) will work using the same semantics as
SOCK_DGRAM/SOCK_SEQPACKET. With those sockets, as much data as
29 matches
Mail list logo
