Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Mat Martineau]

On Fri, 11 Aug 2017, Andrew Zaborowski wrote:


HI,

On 11 August 2017 at 02:48, Mat Martineau
 wrote:

The last round of reviews for AF_ALG akcipher left off at an impasse around
a year ago: the consensus was that hardware key support was needed, but that
requirement was in conflict with the "always have a software fallback" rule
for the crypto subsystem. For example, a private key securely generated by
and stored in a TPM could not be copied out for use by a software algorithm.
Has anything come about to resolve this impasse?

There were some patches around to add keyring support by associating a key
ID with an akcipher socket, but that approach ran in to a mismatch between
the proposed keyring API for the verify operation and the semantics of
AF_ALG verify.

AF_ALG is best suited for crypto use cases where a socket is set up once and
there are lots of reads and writes to justify the setup cost. With
asymmetric crypto, the setup cost is high when you might only use the socket
for a brief time to do one verify or encrypt operation.


Would that time be shorter when going through the keyctl API?



There's a certain amount of work to be done for a one-off crypto operation 
no matter what the API is: load a key, set up the operation, provide the 
input, read the output, and clean up. keyctl() handles that "one-off" case 
with a smaller sequence of system calls, but is not as good for streaming.



In any case there will be situations, similar to the lightweight TLS
implementation use case, where this isn't a factor.



Given the efficiency and hardware key issues, AF_ALG seems to be mismatched
with asymmetric crypto.


The hardware key support would obviously be a benefit but it's
orthogonal to this I believe.  That issue is not specific to akcipher
either, there will be hardware-only symmetric keys that can't be used
with current ALG_IF.

The ALG_IF API provides a slightly lower level access to the
algorithms listed in /proc/crypto than the keyctl API and I don't see
the reason that some of those algorithms should not be available.


I also would like to have more of those algorithms exposed to userspace, 
and I'd like to make sure the API is a good fit. There was extensive 
discussion of AF_ALG akcipher last year. v8 of the patch set updates the 
implementation but doesn't address the API concerns that kept the previous 
versions from being merged, so we seem to be at just as much of an impasse 
as before.


--
Mat Martineau
Intel OTC

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Marcel Holtmann]

Hi Stephan,

>> AF_ALG is best suited for crypto use cases where a socket is set up once
>> and there are lots of reads and writes to justify the setup cost. With
>> asymmetric crypto, the setup cost is high when you might only use the
>> socket for a brief time to do one verify or encrypt operation.
> 
> To me, the entire AF_ALG purpose is solely to export hardware support to user 
> space. That said, if user space wants an accelerator, a socket would be 
> opened 
> once followed by numerous read/write requests.
> 
> Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring 
> and I planned to port it to the current implementation. But I thought I offer 
> a small patch focusing on the externalization of the akcipher API first.
> 
> I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to 
> each other. The statement I made for the KPP AF_ALG RFC applies here too:
> 
> """
> I am aware and in fact supported development of the DH support in the keys
> subsystem. The question will be raised whether the AF_ALG KPP interface is
> superfluous in light of the keys DH support. My answer is that AF_ALG KPP is
> orthogonal to the keys DH support. The keys DH support use case is that
> the keys are managed inside the kernel and thus has the focus on the
> key management. Contrary, AF_ALG KPP does not really focus on key management
> but simply externalizes the DH/ECDH support found in the kernel including
> hardware acceleration. User space is in full control of the key life cycle.
> This way, AF_ALG could be used to complement user-space network protocol
> implementations like TLS or IKE to offload the resource intense DH
> calculations to accelerators.
> “""

we do not need two interfaces for doing the same thing. Especially not one that 
can not handle hardware backed keys. And more important if you can not abstract 
an accelerator that doesn’t expose the private key at all.

If you only have a hammer, everything looks like a nail. Luckily we have more 
tools than just a hammer :)

Regards

Marcel

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Marcel Holtmann]

Hi Stephan,

>>> The last round of reviews for AF_ALG akcipher left off at an impasse
>>> around a year ago: the consensus was that hardware key support was
>>> needed, but that requirement was in conflict with the "always have a
>>> software fallback" rule for the crypto subsystem. For example, a private
>>> key securely generated by and stored in a TPM could not be copied out for
>>> use by a software algorithm. Has anything come about to resolve this
>>> impasse?
>>> 
>>> There were some patches around to add keyring support by associating a key
>>> ID with an akcipher socket, but that approach ran in to a mismatch
>>> between the proposed keyring API for the verify operation and the
>>> semantics of AF_ALG verify.
>>> 
>>> AF_ALG is best suited for crypto use cases where a socket is set up once
>>> and there are lots of reads and writes to justify the setup cost. With
>>> asymmetric crypto, the setup cost is high when you might only use the
>>> socket for a brief time to do one verify or encrypt operation.
>>> 
>>> Given the efficiency and hardware key issues, AF_ALG seems to be
>>> mismatched with asymmetric crypto. Have you looked at the proposed
>>> keyctl() support for crypto operations?
>> we have also seen hardware now where the private key will never leave the
>> crypto hardware. They public and private key is only generated for key
>> exchange purposes and later on discarded again. Asymmetric ciphers are
>> really not a good fit for AF_ALG and they should be solely supported via
>> keyctl.
> 
> Thanks for the reminder. I have looked at that but I am unsure about whether 
> this one covers asym crypto appropriately, too.
> 
> The issue is that some hardware may only offer accelerators without a full 
> blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you 
> propose to cover raw primitives with keyctl?

where is such a hardware? And what is the usage of it? Look at what we are 
using asymmetric crypto for at the moment. It is either for sign and verify 
with secure boot etc. Or it is for key exchange purposes.

The asymmetric crypto is a means to an end. If it is not for certification 
verification, then it for is creating a symmetric key to be used with a 
symmetric cipher. We have the the asymmetric_keys subsystem for representing 
the nature of this crypto. Also the list of asymmetric ciphers is a lot smaller 
than the symmetric ones.

What raw primitives? When we are using for example ECDH for Bluetooth where you 
need to create a pairwise symmetric key, then what you really want from the 
cryptographic primitives is this:

1) Create public/private key pair
2) Give public key to applications and store the private key safely
3) Retrieve public key from remote side and challenge
4) Compute key exchange magic (like DH) from remote public key
5) Tell the key generator to throw away the private key

So I do not want to load any private key into the kernel. I want the kernel to 
give me a public key and allow me to feed the key exchange primitive with the 
remote public key. This is clearly not AF_ALG. We had this discussion during 
the KPP design and I made it clear multiple times that this is totally 
different.

This is clearly keyctl area of interfaces since the main operation is key 
generation. I am not saying that keyctl is perfect just yet, but we are working 
on it. We however have to accept that it is more suitable than AF_ALG. You will 
never have stream based data feed into an asymmetric cipher. That is what 
stream ciphers are for.

Regards

Marcel

Re: [PATCH v5 2/5] lib: Add zstd modules

[Chris Mason]

On 08/10/2017 03:25 PM, Hugo Mills wrote:

On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote:

On 08/10/2017 04:30 AM, Eric Biggers wrote:


Theses benchmarks are misleading because they compress the whole file as a
single stream without resetting the dictionary, which isn't how data will
typically be compressed in kernel mode.  With filesystem compression the data
has to be divided into small chunks that can each be decompressed independently.
That eliminates one of the primary advantages of Zstandard (support for large
dictionary sizes).


I did btrfs benchmarks of kernel trees and other normal data sets as
well.  The numbers were in line with what Nick is posting here.
zstd is a big win over both lzo and zlib from a btrfs point of view.

It's true Nick's patches only support a single compression level in
btrfs, but that's because btrfs doesn't have a way to pass in the
compression ratio.  It could easily be a mount option, it was just
outside the scope of Nick's initial work.


Could we please not add more mount options? I get that they're easy
to implement, but it's a very blunt instrument. What we tend to see
(with both nodatacow and compress) is people using the mount options,
then asking for exceptions, discovering that they can't do that, and
then falling back to doing it with attributes or btrfs properties.
Could we just start with btrfs properties this time round, and cut out
the mount option part of this cycle.

In the long run, it'd be great to see most of the btrfs-specific
mount options get deprecated and ultimately removed entirely, in
favour of attributes/properties, where feasible.



It's a good point, and as was commented later down I'd just do mount -o 
compress=zstd:3 or something.


But I do prefer properties in general for this.  My big point was just 
that next step is outside of Nick's scope.


-chris

Re: [PATCH v8 4/4] crypto: algif_akcipher - enable compilation

[Stephan Mueller]

Am Freitag, 11. August 2017, 14:56:18 CEST schrieb Tudor Ambarus:

Hi Tudor,

> Any reason why you keep this patch separately?
> I think you can squash this patch with patch 3/4.

There is no real reason. If you think it makes sense to add it to patch 3, I 
will do that.

Thanks.


Ciao
Stephan

Re: [PATCH v8 4/4] crypto: algif_akcipher - enable compilation

[Tudor Ambarus]

Hi, Stephan,

On 08/10/2017 09:40 AM, Stephan Müller wrote:

Add the Makefile and Kconfig updates to allow algif_akcipher to be
compiled.

Signed-off-by: Stephan Mueller
---
  crypto/Kconfig  | 9 +
  crypto/Makefile | 1 +
  2 files changed, 10 insertions(+)


Any reason why you keep this patch separately?
I think you can squash this patch with patch 3/4.

Cheers,
ta

Re: [PATCH v8 3/4] crypto: AF_ALG -- add asymmetric cipher

[Tudor Ambarus]

Hi, Stephan,

On 08/10/2017 09:40 AM, Stephan Müller wrote:

This patch adds the user space interface for asymmetric ciphers. The
interface allows the use of sendmsg as well as vmsplice to provide data.

The akcipher interface implementation uses the common AF_ALG interface
code regarding TX and RX SGL handling.

Signed-off-by: Stephan Mueller 
---
  crypto/algif_akcipher.c | 466 
  include/crypto/if_alg.h |   2 +
  2 files changed, 468 insertions(+)
  create mode 100644 crypto/algif_akcipher.c

diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
new file mode 100644
index ..1b36eb0b6e8f
--- /dev/null
+++ b/crypto/algif_akcipher.c
@@ -0,0 +1,466 @@
+/*
+ * algif_akcipher: User-space interface for asymmetric cipher algorithms
+ *
+ * Copyright (C) 2017, Stephan Mueller 
+ *
+ * This file provides the user-space API for asymmetric ciphers.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * The following concept of the memory management is used:
+ *
+ * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL is
+ * filled by user space with the data submitted via sendpage/sendmsg. Filling
+ * up the TX SGL does not cause a crypto operation -- the data will only be
+ * tracked by the kernel. Upon receipt of one recvmsg call, the caller must
+ * provide a buffer which is tracked with the RX SGL.
+ *
+ * During the processing of the recvmsg operation, the cipher request is
+ * allocated and prepared. As part of the recvmsg operation, the processed
+ * TX buffers are extracted from the TX SGL into a separate SGL.
+ *
+ * After the completion of the crypto operation, the RX SGL and the cipher
+ * request is released. The extracted TX SGL parts are released together with
+ * the RX SGL release.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


I like that you ordered these alphabetically. Is there a reason why
crypto/scatterwalk.h is not after crypto/if_alg.h?


+
+struct akcipher_tfm {
+   struct crypto_akcipher *akcipher;
+   bool has_key;
+};
+
+static int akcipher_sendmsg(struct socket *sock, struct msghdr *msg,
+   size_t size)
+{
+   return af_alg_sendmsg(sock, msg, size, 0);
+}
+
+static int _akcipher_recvmsg(struct socket *sock, struct msghdr *msg,
+size_t ignored, int flags)
+{
+   struct sock *sk = sock->sk;
+   struct alg_sock *ask = alg_sk(sk);
+   struct sock *psk = ask->parent;
+   struct alg_sock *pask = alg_sk(psk);
+   struct af_alg_ctx *ctx = ask->private;
+   struct akcipher_tfm *akc = pask->private;
+   struct crypto_akcipher *tfm = akc->akcipher;
+   struct af_alg_async_req *areq;
+   int err = 0;


initialization not needed.


+   int maxsize;
+   size_t len = 0;


initialization not needed. len will be initialized in af_alg_get_rsgl.

Also, size_t could be 32 or 64 bit wide. Could you declare the size_t
variables before the int ones? This will avoid stack padding on 64bit
systems if one adds a new int variable in the same place where the ints
are now.


+   size_t used = 0;


initialization to zero not needed. You can directly initialize to
ctx->used or don't initialize at all.


+
+   maxsize = crypto_akcipher_maxsize(tfm);
+   if (maxsize < 0)
+   return maxsize;
+
+   /* Allocate cipher request for current operation. */
+   areq = af_alg_alloc_areq(sk, sizeof(struct af_alg_async_req) +
+crypto_akcipher_reqsize(tfm));
+   if (IS_ERR(areq))
+   return PTR_ERR(areq);
+
+   /* convert iovecs of output buffers into RX SGL */
+   err = af_alg_get_rsgl(sk, msg, flags, areq, maxsize, );
+   if (err)
+   goto free;
+
+   /* ensure output buffer is sufficiently large */
+   if (len < maxsize) {
+   err = -EMSGSIZE;
+   goto free;
+   }
+
+   /*
+* Create a per request TX SGL for this request which tracks the
+* SG entries from the global TX SGL.
+*/
+   used = ctx->used;
+   areq->tsgl_entries = af_alg_count_tsgl(sk, used, 0);
+   if (!areq->tsgl_entries)
+   areq->tsgl_entries = 1;
+   areq->tsgl = sock_kmalloc(sk, sizeof(*areq->tsgl) * areq->tsgl_entries,
+ GFP_KERNEL);
+   if (!areq->tsgl) {
+   err = -ENOMEM;
+   goto free;
+   }
+   sg_init_table(areq->tsgl, areq->tsgl_entries);
+   af_alg_pull_tsgl(sk, used, areq->tsgl, 0);
+
+   /* Initialize the crypto operation */
+   

[no subject]

[администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки 2017

спасибо
системы администратор 

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Andrew Zaborowski]

HI,

On 11 August 2017 at 02:48, Mat Martineau
 wrote:
> The last round of reviews for AF_ALG akcipher left off at an impasse around
> a year ago: the consensus was that hardware key support was needed, but that
> requirement was in conflict with the "always have a software fallback" rule
> for the crypto subsystem. For example, a private key securely generated by
> and stored in a TPM could not be copied out for use by a software algorithm.
> Has anything come about to resolve this impasse?
>
> There were some patches around to add keyring support by associating a key
> ID with an akcipher socket, but that approach ran in to a mismatch between
> the proposed keyring API for the verify operation and the semantics of
> AF_ALG verify.
>
> AF_ALG is best suited for crypto use cases where a socket is set up once and
> there are lots of reads and writes to justify the setup cost. With
> asymmetric crypto, the setup cost is high when you might only use the socket
> for a brief time to do one verify or encrypt operation.

Would that time be shorter when going through the keyctl API?

In any case there will be situations, similar to the lightweight TLS
implementation use case, where this isn't a factor.

>
> Given the efficiency and hardware key issues, AF_ALG seems to be mismatched
> with asymmetric crypto.

The hardware key support would obviously be a benefit but it's
orthogonal to this I believe.  That issue is not specific to akcipher
either, there will be hardware-only symmetric keys that can't be used
with current ALG_IF.

The ALG_IF API provides a slightly lower level access to the
algorithms listed in /proc/crypto than the keyctl API and I don't see
the reason that some of those algorithms should not be available.

Best regards

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Stephan Mueller]

Am Freitag, 11. August 2017, 02:48:37 CEST schrieb Mat Martineau:

Hi Mat,

> 
> AF_ALG is best suited for crypto use cases where a socket is set up once
> and there are lots of reads and writes to justify the setup cost. With
> asymmetric crypto, the setup cost is high when you might only use the
> socket for a brief time to do one verify or encrypt operation.

To me, the entire AF_ALG purpose is solely to export hardware support to user 
space. That said, if user space wants an accelerator, a socket would be opened 
once followed by numerous read/write requests.

Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring 
and I planned to port it to the current implementation. But I thought I offer 
a small patch focusing on the externalization of the akcipher API first.

I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to 
each other. The statement I made for the KPP AF_ALG RFC applies here too:

"""
I am aware and in fact supported development of the DH support in the keys
subsystem. The question will be raised whether the AF_ALG KPP interface is
superfluous in light of the keys DH support. My answer is that AF_ALG KPP is
orthogonal to the keys DH support. The keys DH support use case is that
the keys are managed inside the kernel and thus has the focus on the
key management. Contrary, AF_ALG KPP does not really focus on key management
but simply externalizes the DH/ECDH support found in the kernel including
hardware acceleration. User space is in full control of the key life cycle.
This way, AF_ALG could be used to complement user-space network protocol
implementations like TLS or IKE to offload the resource intense DH
calculations to accelerators.
"""

Ciao
Stephan

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Stephan Müller]

Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann:

Hi Marcel,

> > 
> > The last round of reviews for AF_ALG akcipher left off at an impasse
> > around a year ago: the consensus was that hardware key support was
> > needed, but that requirement was in conflict with the "always have a
> > software fallback" rule for the crypto subsystem. For example, a private
> > key securely generated by and stored in a TPM could not be copied out for
> > use by a software algorithm. Has anything come about to resolve this
> > impasse?
> > 
> > There were some patches around to add keyring support by associating a key
> > ID with an akcipher socket, but that approach ran in to a mismatch
> > between the proposed keyring API for the verify operation and the
> > semantics of AF_ALG verify.
> > 
> > AF_ALG is best suited for crypto use cases where a socket is set up once
> > and there are lots of reads and writes to justify the setup cost. With
> > asymmetric crypto, the setup cost is high when you might only use the
> > socket for a brief time to do one verify or encrypt operation.
> > 
> > Given the efficiency and hardware key issues, AF_ALG seems to be
> > mismatched with asymmetric crypto. Have you looked at the proposed
> > keyctl() support for crypto operations?
> we have also seen hardware now where the private key will never leave the
> crypto hardware. They public and private key is only generated for key
> exchange purposes and later on discarded again. Asymmetric ciphers are
> really not a good fit for AF_ALG and they should be solely supported via
> keyctl.

Thanks for the reminder. I have looked at that but I am unsure about whether 
this one covers asym crypto appropriately, too.

The issue is that some hardware may only offer accelerators without a full 
blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you 
propose to cover raw primitives with keyctl?

Ciao
Stephan