On (05/02/17 09:58), Paul Wouters wrote:
>I think you want to use Opportunistic IPsec, eg see
>https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec
I dont think that what I want is opportunistic ipsec..
taking an extreme example, I can set up the ipsec tunnels with
esp-null for *.5001
I have a question about linux support for IPsec PFP (as defined in
rfc 4301). I am assuming this exists, and is accessible from uspace,
in which case I need some hints on how to set it up.
Assuming I have a server listening at port 5001 that I want to
secure via ipsec. Suppose I want to make sure
On (03/15/17 10:08), Dmitry Vyukov wrote:
> After I've applied the patch these reports stopped to happen, and I
> have not seem any other reports that look relevant.
> However, it there was one, but it looks like a different issue and it
> was probably masked by massive amounts of original deadlock
On (03/14/17 09:14), Dmitry Vyukov wrote:
> Another one now involving rds_tcp_listen_stop
:
> kworker/u4:1/19 is trying to acquire lock:
> (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
> include/net/sock.h:1460 [inline]
> (sk_lock-AF_INET){+.+.+.}, at: []
> rds_tcp_listen_stop+0x5c/0x150 net/rds
On (08/25/16 16:49), Herbert Xu wrote:
>
> On Fri, Aug 19, 2016 at 03:21:24PM -0400, Sowmini Varadhan wrote:
> >7271b33cb87e80f3a416fb031ad3ca87f0bea80a is the first bad commit
> This bisection doesn't make much sense as this patch just causes
> cryptd to be
On (08/25/16 16:49), Herbert Xu wrote:
> This bisection doesn't make much sense as this patch just causes
> cryptd to be used a little more more frequently. But it does
> point the finger at cryptd.
:
> So we have list corruption here, possibly caused by use-after-free.
> I did spot one bug in
Hi Herbert,
In the process of testing ipsec I ran into panics (details below)
with the algorithm
"aead rfc4106(gcm(aes)) 0x1234567890123456789012345678901234567890 64"
git-bisect analyzed this down to
7271b33cb87e80f3a416fb031ad3ca87f0bea80a is the first bad commit
commit 7271b33cb87e80f
On (05/04/16 12:08), Steffen Klassert wrote:
> > > Sowmini, could you please doublecheck with your test setup?
> >
> > Don't bother, my patch was crap. Here's one that's more likely
> > to work:
>
> This one is much better, works here :)
The patch seems to work, but the caveat is that the origi
On (05/04/16 10:32), Herbert Xu wrote:
>
> Please base it on cryptodev.
>
Looks like this got fixed in cryptodev by commit cece762f6f3c
("lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access")
Thanks,
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
t
On (05/03/16 16:12), Herbert Xu wrote:
>
> Sorry, but your patch doesn't apply against the current tree at all.
> Please rebase it if it is still needed.
Hello,
I had based my patch off of net-next, which is where I do my work.
I'd be happy to rebase it on the "current tree",
but given that mp
Commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") added
mpi_write_to_sgl() which generates traps due to unaligned
access on some platforms like sparc. Fix this by using
the get_unaligned* and put_unaligned* functions.
Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Si
Hi Anatoly,
after commit c1e9b3b0eea1 ("hwrng: n2 - Attach on T5/M5, T7/M7 SPARC CPUs")
I get a *lot* of console noise on my T5-2, of the form:
n2rng f028f21c: Selftest failed on unit 0
n2rng f028f21c: Test buffer slot 0 [0x]
n2rng f028f21c: Test buffer slot 1 [0xe63f56d6a22eb116
On (12/08/15 12:32), Steffen Klassert wrote:
>
> Would be nice if you could share the results. Comments are
Sure, not a problem. Give me some time though, I'm also looking
into the skb_cow_data and other memory-management issues that
were flagged on this thread.
I'll have all this info by netde
On (12/07/15 09:40), Steffen Klassert wrote:
>
> I've pushed it to
>
> https://git.kernel.org/cgit/linux/kernel/git/klassert/linux-stk.git/log/?h=net-next-ipsec-offload
>
> It is just example code, nothing that I would show usually.
> But you asked for it, so here is it :)
that's fine, I dont e
On (12/03/15 14:33), David Miller wrote:
>
> Doesn't skb_cow_data() contribute significantly to the ESP base cost,
> especially for TCP packets?
Indeed. For esp-null, it's about half of the total time spent
in esp_output (for one run that I just instrumented with perf
tracepoints 2.5 ms compared
On (12/03/15 09:45), Steffen Klassert wrote:
> pcrypt(echainiv(authenc(hmac(sha1-ssse3),cbc-aes-aesni)))
>
> Result:
>
> iperf -c 10.0.0.12 -t 60
>
> Client connecting to 10.0.0.12, TCP port 5001
> TCP window size: 45.0 KByte (default)
On (12/02/15 14:01), Tom Herbert wrote:
> No, please don't persist is this myopic "we'll get to IPv6 later"
> model! IPv6 is a real protocol, it has significant deployment of the
> Internet, and there are now whole data centers that are IPv6 only
> (e.g. FB), and there are plenty of use cases of IP
On (12/02/15 13:44), Tom Herbert wrote:
> > IPv6 would be an interesting academic exercise, but it's going
> > to be a while before we get RDS-TCP to go over IPv6.
> >
> Huh? Who said anything about RDS-TCP? I thought you were trying to
> improve IPsec performance...
yes, and it would be nice to f
On (12/02/15 13:07), Tom Herbert wrote:
> That's easy enough to add to flow dissector, but is SPI really
> intended to be used an L4 entropy value? We would need to consider the
yes. To quote https://en.wikipedia.org/wiki/Security_Parameter_Index
"This works like port numbers in TCP and UDP connec
On (12/02/15 12:41), David Laight wrote:
> You are getting 0.7 Gbps with ass-ccm-a-128, scale the esp-null back to
> that and it would use 7/18*71 = 27% of the cpu.
> So 69% of the cpu in the a-128 case is probably caused by the
> encryption itself.
> Even if the rest of the code cost nothing you'd
On (12/02/15 12:41), David Laight wrote:
>
> Also what/how are you measuring cpu use.
> I'm not sure anything on Linux gives you a truly accurate value
> when processes are running for very short periods.
I was using mpstat, while running iperf. Should I be using
something else? or running it for
On (12/02/15 11:56), David Laight wrote:
> > Gbps peak cpu util
> > esp-null 1.8 71%
> > aes-gcm-c-2561.6 79%
> > aes-ccm-a-1280.7 96%
> >
> > That trend made me think that if we can get esp-null to be as close
> > as possible to GSO/GRO, the rest will follow
On (12/02/15 07:53), Steffen Klassert wrote:
>
> I'm currently working on a GRO/GSO codepath for IPsec too. The GRO part
> works already. I decapsulate/decrypt the packets on layer2 with a esp GRO
> callback function and reinject them into napi_gro_receive(). So in case
> the decapsulated packet i
On (12/01/15 16:56), David Ahern wrote:
>
> Using iperf3 and AH with NULL algorithm between 2 peers connected by
> a 10G link.
>
I'm using esp-null, not AH, and iperf2, which I understand is
quite different from, and more aggressive than, iperf3 (though I'm not
sure that it matters for this sin
On (12/01/15 10:50), Rick Jones wrote:
>
> Something of a longshot, but are you sure you are still getting
> effective CKO/GRO on the receiver?
Good question. With ipsec, GRO (like GSO) gets implicitly disabled.
But when I explictly disable GRO on receiver, leaving only GSO
on sender, I can stil
On (12/01/15 10:17), Rick Jones wrote:
>
> What do the perf profiles show? Presumably, loss of TSO/GSO means
> an increase in the per-packet costs, but if the ipsec path
> significantly increases the per-byte costs...
For ESP-null, there's actually very little work to do - we just
need to add th
On (12/01/15 10:18), Tom Herbert wrote:
> > 8.5-9.5 Gbps clear traffic, TSO disabled, so GSO, GRO is in effect
> > 3-4 Gbps clear traffic, with both TSO/GSO disabled
> > 1.8-2 Gbps for esp-null.
>
> Are you losing checksum offload also?
I tried with both checksum offload on and off
tcp segment is available),
set things up for xfrm_output_one and trigger the esp_output
A 1-bit hole in sk_buff is used to track an skb that needs xfrm (might
not need to burn that bit, but using it for now)
Signed-off-by: Sowmini Varadhan
---
include/linux/skbuff.h |6
I instrumented iperf with and without ipsec, just using esp-null,
and 1 thread, to keep things simple. I'm seeing some pretty dismal
performance numbers with ipsec, and trying to think of ways to
improve this. Here are my findings, please share feedback.
I suspect that a big part of the problem
On (11/24/15 12:20), Hannes Frederic Sowa wrote:
> There are some crypto acclerators out there so that putting tls into the
> kernel would give a net benefit, because otherwise user space has to
> copy data into the kernel for device access and back to user space until
> it can finally be send out
On (11/23/15 13:43), Dave Watson wrote:
>
> For kcm, opfd is the fd you would pass along in kcm_attach.
> For rds, it looks like you'd want to use opfd as the sock instead of
> the new one created by sock_create_kern in rds_tcp_conn_connect.
I see.
It's something to consider, and it would certai
On (11/23/15 09:43), Dave Watson wrote:
> Currently gcm(aes) represents ~80% of our SSL connections.
>
> Userspace interface:
>
> 1) A transform and op socket are created using the userspace crypto interface
> 2) Setsockopt ALG_SET_AUTHSIZE is called
> 3) Setsockopt ALG_SET_KEY is called twice, s
On (10/21/15 06:22), David Miller wrote:
> memcpy() _never_ works for avoiding unaligned accessed.
>
> I repeat, no matter what you do, no matter what kinds of casts or
> fancy typing you use, memcpy() _never_ works for this purpose.
:
> There is one and only one portable way to access unaligned
On (10/21/15 06:54), Sowmini Varadhan wrote:
> But __alignof__(*p) is 8 on sparc, and without the patch I get
> all types of unaligned access. So what do you suggest as the fix?
Even though the alignment is, in fact, 8 (and that comes from
struct xfrm_lifetime_cfg), if uspace is firmly at
On (10/21/15 08:57), Steffen Klassert wrote:
> > --- a/net/xfrm/xfrm_user.c
> > +++ b/net/xfrm/xfrm_user.c
> > @@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, const
> > struct km_event *c)
> > if (attr == NULL)
> > goto out_free_skb;
> >
> >
alignment values into consideration when doing kzalloc()
Signed-off-by: Sowmini Varadhan
---
crypto/asymmetric_keys/x509_public_key.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_public_key.c
ind
On sparc, deleting established SAs (e.g., by restarting ipsec
at the peer) results in unaligned access messages via
xfrm_del_sa -> km_state_notify -> xfrm_send_state_notify().
Use an aligned pointer to xfrm_usersa_info for this case.
Signed-off-by: Sowmini Varadhan
---
net/xfrm/xfrm_
A two-part patchset that fixes some "unaligned access" warnings
that showed up my sparc test machines with ipsec set up.
Sowmini Varadhan (2):
crypto/x509: Fix unaligned access in x509_get_sig_params()
Fix unaligned access in xfrm_notify_sa() for DELSA
crypto/asymm
needs to make sure that desc is pointing
at an aligned value past the digest_size, and kzalloc appropriately,
taking alignment values into consideration.
Signed-off-by: Sowmini Varadhan
---
crypto/asymmetric_keys/pkcs7_verify.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff
On (10/12/15 21:32), Herbert Xu wrote:
>
> .. pkcs7_verify definitely
> shouldn't place the structure after the digest without aligning the
> pointer. So something like your patch is needed (but please use
> alignof instead of sizeof). Also don't put in digest_size but
> instead align the pointe
On (10/12/15 21:32), Herbert Xu wrote:
> Thanks. We have two bugs here. First of all pkcs7_verify definitely
> shouldn't place the structure after the digest without aligning the
> pointer. So something like your patch is needed (but please use
> alignof instead of sizeof). Also don't put in di
On (10/08/15 21:15), Herbert Xu wrote:
> > desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
> > - sinfo->sig.digest_size = digest_size = crypto_shash_digestsize(tfm);
> > + sinfo->sig.digest_size = digest_size =
> > + ALIGN(crypto_shash_digestsize(tfm), siz
Hi,
I'm getting a lot of unaligned access messages each time I
do "modprobe [-r] " on sparc:
Kernel unaligned access at TPC[6ad9b4] pkcs7_verify+0x1ec/0x5e0
Kernel unaligned access at TPC[6a5484] crypto_shash_finup+0xc/0x5c
Kernel unaligned access at TPC[6a5390] crypto_shash_update+0xc/0x54
Ker
I was trying to follow the example for IPsec transport mode at
http://www.ipsec-howto.org/x304.html with a 4.1 kernel,
and I find that using 3des_cbc does not work - packets get dropped
at the receiver after decryption: e.g., for a ping, the decrypted
packet has a mangled icmp header, and is dro
44 matches
Mail list logo
