On Fri, 4 Dec 2020 at 22:30, Brijesh Singh wrote:
>
> 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 t
Hi Allen,
Thank you for the patch.
Please make sure to CC maintainers on changes to drivers they
maintain, otherwise it's hard to keep track. Thanks!
On Mon, Dec 7, 2020 at 11:02 AM Allen Pais wrote:
>
> From: Allen Pais
>
> In preparation for unconditionally passing the
> struct tasklet_struc
Hi Eyal,
On Tue, Dec 08, 2020 at 04:47:02PM +0200, Eyal Birger wrote:
> On Mon, Dec 7, 2020 at 4:07 PM Phil Sutter wrote:
> >
> > With an IPsec tunnel without dedicated interface, netfilter sees locally
> > generated packets twice as they exit the physical interface: Once as "the
> > inner packet
On 12/4/20 3:28 PM, Brijesh Singh wrote:
> 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
On Thu, 26 Nov 2020 11:51:47 +, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli
>
> Add device-tree bindings for Intel Keem Bay Offload and Crypto Subsystem
> (OCS) AES crypto driver.
>
> Signed-off-by: Daniele Alessandrelli
> Acked-by: Mark Gross
> ---
> .../crypto/intel,keemb
Hi Phil,
On Mon, Dec 7, 2020 at 4:07 PM Phil Sutter wrote:
>
> With an IPsec tunnel without dedicated interface, netfilter sees locally
> generated packets twice as they exit the physical interface: Once as "the
> inner packet" with IPsec context attached and once as the encrypted
> (ESP) packet.
Le 08/12/2020 à 15:00, Phil Sutter a écrit :
> Hi Nicolas,
>
> On Tue, Dec 08, 2020 at 10:02:16AM +0100, Nicolas Dichtel wrote:
>> Le 07/12/2020 à 14:43, Phil Sutter a écrit :
> [...]
>>> diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
>>> index aa4cdcf69d471..24af61c95b4d4 1006
The signed long type used for printing the number of bytes processed in
tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient
to cover the performance of common accelerated ciphers such as AES-NI
when benchmarked with sec=1. So switch to u64 instead.
While at it, fix up a missin
Ard Biesheuvel wrote:
> Apparently, it is permitted for gss_krb5_cts_crypt() to do a
> kmalloc(GFP_NOFS) in the context from where gss_krb5_aes_encrypt() is
> being invoked, and so I don't see why it wouldn't be possible to
> simply kmalloc() a scatterlist[] of the appropriate size, populate it
>
Hi All,
I am trying to read kernel audit messages specially generated by XFRM in user
space. I wrote Netlink client stub to read the audit message as below. But the
call recvfrom gets blocked indefinite.
Can any one tell me what am I doing wrong?
Regards,
Jayalakshmi
#include
#include
#inclu
On Tue, 8 Dec 2020 at 14:25, David Howells wrote:
>
> I wonder - would it make sense to reserve two arrays of scatterlist structs
> and a mutex per CPU sufficient to map up to 1MiB of pages with each array
> while the krb5 service is in use?
>
> That way sunrpc could, say, grab the mutex, map the
David Howells wrote:
> I wonder - would it make sense to reserve two arrays of scatterlist structs
> and a mutex per CPU sufficient to map up to 1MiB of pages with each array
> while the krb5 service is in use?
Actually, simply reserving a set per CPU is probably unnecessary. We could,
say, set
Hi Nicolas,
On Tue, Dec 08, 2020 at 10:02:16AM +0100, Nicolas Dichtel wrote:
> Le 07/12/2020 à 14:43, Phil Sutter a écrit :
[...]
> > diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
> > index aa4cdcf69d471..24af61c95b4d4 100644
> > --- a/net/xfrm/xfrm_interface.c
> > +++ b/net/x
I wonder - would it make sense to reserve two arrays of scatterlist structs
and a mutex per CPU sufficient to map up to 1MiB of pages with each array
while the krb5 service is in use?
That way sunrpc could, say, grab the mutex, map the input and output buffers,
do the entire crypto op in one go an
Ard Biesheuvel wrote:
Ard Biesheuvel wrote:
> > > > I wonder if it would help if the input buffer and output buffer didn't
> > > > have to correspond exactly in usage - ie. the output buffer could be
> > > > used at a slower rate than the input to allow for buffering inside the
> > > > crypto a
Le 07/12/2020 à 14:43, Phil Sutter a écrit :
> With an IPsec tunnel without dedicated interface, netfilter sees locally
> generated packets twice as they exit the physical interface: Once as "the
> inner packet" with IPsec context attached and once as the encrypted
> (ESP) packet.
>
> With xfrm_in
On Mon, 7 Dec 2020 at 15:15, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > > I wonder if it would help if the input buffer and output buffer didn't
> > > have to correspond exactly in usage - ie. the output buffer could be used
> > > at a slower rate than the input to allow for buffering i
17 matches
Mail list logo
