The SEV FW version >= 0.23 added a new command that can be used to query
the attestation report containing the SHA-256 digest of the guest memory
encrypted through the KVM_SEV_LAUNCH_UPDATE_{DATA, VMSA} commands and
sign the report with the Platform Endorsement Key (PEK).
See the SEV FW API spec s
On Fri, Dec 04, 2020 at 06:35:48PM +0100, Ard Biesheuvel wrote:
>
> Herbert recently made some changes for MSG_MORE support in the AF_ALG
> code, which permits a skcipher encryption to be split into several
> invocations of the skcipher layer without the need for this complexity
> on the side of th
On Fri, Dec 04 2020 at 20:27, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 04:08:27PM +0100, Thomas Gleixner wrote:
>> On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
>> > On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
>> >> The unmap comes from sg_miter_stop() and looking
On Fri, Dec 04, 2020 at 04:08:27PM +0100, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
> > On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
> >> The unmap comes from sg_miter_stop() and looking at the previous
> >> map/unmap cycles there are never nes
On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> Hi Chuck, Bruce,
>
> Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> gss_krb5_aes_encrypt() code looks like the attached.
>
> From what I can tell, in AES mode, the difference between the main cipher and
>
On Fri, 2020-12-04 at 18:03 +0100, laniel_fran...@privacyrequired.com
wrote:
> In this patch set, I replaced all calls to strstarts() by calls to
> str_has_prefix(). Indeed, the kernel has two functions to test if a
> string begins with an other:
> 1. strstarts() which returns a bool, so 1 if the s
On Fri, 4 Dec 2020 at 18:19, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > The tricky thing with CTS is that you have to ensure that the final
> > full and partial blocks are presented to the crypto driver as one
> > chunk, or it won't be able to perform the ciphertext stealing. This
> > m
Ard Biesheuvel wrote:
> The tricky thing with CTS is that you have to ensure that the final
> full and partial blocks are presented to the crypto driver as one
> chunk, or it won't be able to perform the ciphertext stealing. This
> might be the reason for the current approach. If the sunrpc code
On Fri, 4 Dec 2020 at 17:52, David Howells wrote:
>
> Bruce Fields wrote:
>
> > OK, I guess I don't understand the question. I haven't thought about
> > this code in at least a decade. What's an auxilary cipher? Is this a
> > question about why we're implementing something, or how we're
> > im
From: Francis Laniel
The two functions indicates if a string begins with a given prefix.
The only difference is that strstarts() returns a bool while str_has_prefix()
returns the length of the prefix if the string begins with it or 0 otherwise.
Signed-off-by: Francis Laniel
---
crypto/essiv.c
From: Francis Laniel
Hi.
First, I hope you are fine and the same for your relatives.
In this patch set, I replaced all calls to strstarts() by calls to
str_has_prefix().
Indeed, the kernel has two functions to test if a string begins with an other:
1. strstarts() which returns a bool, so 1 if
Bruce Fields wrote:
> OK, I guess I don't understand the question. I haven't thought about
> this code in at least a decade. What's an auxilary cipher? Is this a
> question about why we're implementing something, or how we're
> implementing it?
That's what the Linux sunrpc implementation call
On Fri, Dec 04, 2020 at 10:46:26AM -0500, Bruce Fields wrote:
> On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> > Hi Chuck, Bruce,
> >
> > Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> > gss_krb5_aes_encrypt() code looks like the attached.
> >
> > >Fro
> On Dec 4, 2020, at 10:46 AM, Bruce Fields wrote:
>
> On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
>> Hi Chuck, Bruce,
>>
>> Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
>> gss_krb5_aes_encrypt() code looks like the attached.
>>
>>> From what I c
On Fri, Dec 04, 2020 at 04:01:53PM +, David Howells wrote:
> Bruce Fields wrote:
>
> > > Reading up on CTS, I'm guessing the reason it's like this is that CTS is
> > > the
> > > same as the non-CTS, except for the last two blocks, but the non-CTS one
> > > is
> > > more efficient.
> >
> >
Bruce Fields wrote:
> > Reading up on CTS, I'm guessing the reason it's like this is that CTS is the
> > same as the non-CTS, except for the last two blocks, but the non-CTS one is
> > more efficient.
>
> CTS is cipher-text stealing, isn't it? I think it was Kevin Coffman
> that did that, and I
On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> Hi Chuck, Bruce,
>
> Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> gss_krb5_aes_encrypt() code looks like the attached.
>
> >From what I can tell, in AES mode, the difference between the main cipher and
>
On Fri, Dec 04, 2020 at 02:01:36PM +, David Howells wrote:
> Mickaël Salaün wrote:
>
> > > What would be easiest way to smoke test the changes?
> >
> > An easy way to test it is to enable the second trusted keyring to
> > dynamically load certificates in the kernel. Then we can create a hash
On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
>> The unmap comes from sg_miter_stop() and looking at the previous
>> map/unmap cycles there are never nested maps.
>>
>> [ 996.943030] cryptset-316 0d..4 73943317us : __k
Hi Chuck, Bruce,
Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
gss_krb5_aes_encrypt() code looks like the attached.
>From what I can tell, in AES mode, the difference between the main cipher and
the auxiliary cipher is that the latter is "cbc(aes)" whereas the former is
On 04/12/2020 15:09, David Howells wrote:
> Mickaël Salaün wrote:
>
>> +if (*desc)
>> +/* The hash is greater than MAX_HASH_LEN. */
>> +return -EINVAL;
>
> -ENOPKG might be better. It's not that the string is invalid, it's just that
> it's unsupported at the momen
On 04/12/2020 15:06, David Howells wrote:
> Mickaël Salaün wrote:
>
>> +#include
>
> Something like linux/types.h is probably a better choice.
Indeed.
>
> David
>
On 04/12/2020 15:05, David Howells wrote:
> Mickaël Salaün wrote:
>
>> When looking for a blacklisted hash, bin2hex() is used to transform a
>> binary hash to an ascii (lowercase) hexadecimal string. This string is
>> then search for in the description of the keys from the blacklist
>> keyring
Mickaël Salaün wrote:
> - KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> + GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
I may pull out some of the relatively trivial changes like this and add them
to my keys-fixes branch.
David
Mickaël Salaün wrote:
> + if (*desc)
> + /* The hash is greater than MAX_HASH_LEN. */
> + return -EINVAL;
-ENOPKG might be better. It's not that the string is invalid, it's just that
it's unsupported at the moment.
David
Mickaël Salaün wrote:
> +#include
Something like linux/types.h is probably a better choice.
David
Mickaël Salaün wrote:
> When looking for a blacklisted hash, bin2hex() is used to transform a
> binary hash to an ascii (lowercase) hexadecimal string. This string is
> then search for in the description of the keys from the blacklist
> keyring. When adding a key to the blacklist keyring,
> bla
On Thu, Dec 03, 2020 at 07:58:16AM +0800, kernel test robot wrote:
> All warnings (new ones prefixed by >>):
>
>lib/zstd/compress/zstd_double_fast.c: In function
> 'ZSTD_compressBlock_doubleFast_extDict_generic':
> >> lib/zstd/compress/zstd_double_fast.c:501:1: warning: the frame size of
> >
Mickaël Salaün wrote:
> > What would be easiest way to smoke test the changes?
>
> An easy way to test it is to enable the second trusted keyring to
> dynamically load certificates in the kernel. Then we can create a hash
> of a valid certificate (but not loaded yet) and sign it as explained in
On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
> On Thu, Dec 03 2020 at 18:38, Corentin Labbe wrote:
> > On Wed, Dec 02, 2020 at 09:59:36PM +0100, Thomas Gleixner wrote:
> >> On Wed, Dec 02 2020 at 20:55, Corentin Labbe wrote:
> >> > On Tue, Dec 01, 2020 at 04:15:08PM +0100, Thoma
On Thu, 3 Dec 2020 at 23:26, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When the SIMD portion of the driver is disabled, the compiler cannot
> figure out in advance if it will be called:
>
> ERROR: modpost: "crypto_aegis128_update_simd" [crypto/aegis128.ko] undefined!
>
> Add a conditional
The function derive_pub_key() should be calling memzero_explicit()
instead of memset() in case the complier decides to optimize away the
call to memset() because it "knows" no one is going to touch the memory
anymore.
Reported-by: Ilil Blum Shem-Tov
Tested-by: Ilil Blum Shem-Tov
Cc: stable
Sign
32 matches
Mail list logo
