Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Greg KH]

On Wed, Feb 24, 2016 at 01:10:55AM +0100, Thomas D. wrote:
> Hi,
> 
> I have applied Milan's patch on top of 4.1.18. I can reboot and open all
> of my LUKS-encrypted disks. "cryptsetup benchmark" also works.
> 
> However, don't we need all the recent changes from
> "crypto/algif_skcipher.c", too?

Can someone just backport the full patches in a proper format that I can
apply them in for the 3.14 and 3.10 kernels?  I told people that they
failed to apply, or at least I thought I did...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Thomas D.]

Hi,

I have applied Milan's patch on top of 4.1.18. I can reboot and open all
of my LUKS-encrypted disks. "cryptsetup benchmark" also works.

However, don't we need all the recent changes from
"crypto/algif_skcipher.c", too?


-Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 02/23/2016 04:02 PM, Milan Broz wrote:
> On 02/21/2016 05:40 PM, Milan Broz wrote:
>> > On 02/20/2016 03:33 PM, Thomas D. wrote:
>>> >> Hi,
>>> >>
>>> >> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected.
>>> >>
>>> >> v4.3.6 works. Looks like the patch set is only compatible with 
>>> >> >=linux-4.3.
>>> >>
>>> >> v3.12.54 works because it doesn't contain the patch in question.
>> > 
>> > Hi,
>> > 
>> > indeed, because whoever backported this patchset skipped two patches
>> > from series (because of skcipher interface file was introduced later).
> Ping?
> 
> I always thought that breaking userspace is not the way mainline kernel
> operates and here we break even stable tree...
> 
> Anyone planning to release new kernel version with properly backported 
> patches?
> There is already a lot of downstream distro bugs reported.

Hi Milan,

I'd really like to see an ack on your patch by one of the crypto/ maintainers
before putting it into a -stable release.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Milan Broz]

On 02/21/2016 05:40 PM, Milan Broz wrote:
> On 02/20/2016 03:33 PM, Thomas D. wrote:
>> Hi,
>>
>> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected.
>>
>> v4.3.6 works. Looks like the patch set is only compatible with >=linux-4.3.
>>
>> v3.12.54 works because it doesn't contain the patch in question.
> 
> Hi,
> 
> indeed, because whoever backported this patchset skipped two patches
> from series (because of skcipher interface file was introduced later).

Ping?

I always thought that breaking userspace is not the way mainline kernel
operates and here we break even stable tree...

Anyone planning to release new kernel version with properly backported patches?
There is already a lot of downstream distro bugs reported.

Thanks,
Milan

> 
> I tried to backport it (on 4.1.18 tree, see patch below) and it fixes the 
> problem
> for me.
> 
> Anyway, it is just quick test what is the problem, patch need proper review or
> backport from someone who knows the code better.
> 
> I will release stable cryptsetup soon that will work with new kernel even 
> without
> this patch but I would strongly recommend that stable kernels get these 
> compatibility
> backports as well to avoid breaking existing userspace.
> 
> Thanks,
> Milan
> -
> 
> This patch backports missing parts of crypto API compatibility changes:
> 
>   dd504589577d8e8e70f51f997ad487a4cb6c026f
>   crypto: algif_skcipher - Require setkey before accept(2)
> 
>   a0fa2d037129a9849918a92d91b79ed6c7bd2818
>   crypto: algif_skcipher - Add nokey compatibility path
> 
> --- crypto/algif_skcipher.c.orig  2016-02-21 16:44:27.172312990 +0100
> +++ crypto/algif_skcipher.c   2016-02-21 17:03:58.555785347 +0100
> @@ -31,6 +31,11 @@
>   struct scatterlist sg[0];
>  };
>  
> +struct skcipher_tfm {
> + struct crypto_ablkcipher *skcipher;
> + bool has_key;
> +};
> +
>  struct skcipher_ctx {
>   struct list_head tsgl;
>   struct af_alg_sgl rsgl;
> @@ -750,19 +755,136 @@
>   .poll   =   skcipher_poll,
>  };
>  
> +static int skcipher_check_key(struct socket *sock)
> +{
> + int err;
> + struct sock *psk;
> + struct alg_sock *pask;
> + struct skcipher_tfm *tfm;
> + struct sock *sk = sock->sk;
> + struct alg_sock *ask = alg_sk(sk);
> +
> + if (ask->refcnt)
> + return 0;
> +
> + psk = ask->parent;
> + pask = alg_sk(ask->parent);
> + tfm = pask->private;
> +
> + err = -ENOKEY;
> + lock_sock(psk);
> + if (!tfm->has_key)
> + goto unlock;
> +
> + if (!pask->refcnt++)
> + sock_hold(psk);
> +
> + ask->refcnt = 1;
> + sock_put(psk);
> +
> + err = 0;
> +
> +unlock:
> + release_sock(psk);
> +
> + return err;
> +}
> +
> +static int skcipher_sendmsg_nokey(struct socket *sock, struct msghdr *msg,
> +   size_t size)
> +{
> + int err;
> +
> + err = skcipher_check_key(sock);
> + if (err)
> + return err;
> +
> + return skcipher_sendmsg(sock, msg, size);
> +}
> +
> +static ssize_t skcipher_sendpage_nokey(struct socket *sock, struct page 
> *page,
> +int offset, size_t size, int flags)
> +{
> + int err;
> +
> + err = skcipher_check_key(sock);
> + if (err)
> + return err;
> +
> + return skcipher_sendpage(sock, page, offset, size, flags);
> +}
> +
> +static int skcipher_recvmsg_nokey(struct socket *sock, struct msghdr *msg,
> +   size_t ignored, int flags)
> +{
> + int err;
> +
> + err = skcipher_check_key(sock);
> + if (err)
> + return err;
> +
> + return skcipher_recvmsg(sock, msg, ignored, flags);
> +}
> +
> +static struct proto_ops algif_skcipher_ops_nokey = {
> + .family =   PF_ALG,
> +
> + .connect=   sock_no_connect,
> + .socketpair =   sock_no_socketpair,
> + .getname=   sock_no_getname,
> + .ioctl  =   sock_no_ioctl,
> + .listen =   sock_no_listen,
> + .shutdown   =   sock_no_shutdown,
> + .getsockopt =   sock_no_getsockopt,
> + .mmap   =   sock_no_mmap,
> + .bind   =   sock_no_bind,
> + .accept =   sock_no_accept,
> + .setsockopt =   sock_no_setsockopt,
> +
> + .release=   af_alg_release,
> + .sendmsg=   skcipher_sendmsg_nokey,
> + .sendpage   =   skcipher_sendpage_nokey,
> + .recvmsg=   skcipher_recvmsg_nokey,
> + .poll   =   skcipher_poll,
> +};
> +
>  static void *skcipher_bind(const char *name, u32 type, u32 mask)
>  {
> - return crypto_alloc_ablkcipher(name, type, mask);
> + struct skcipher_tfm *tfm;
> + struct crypto_ablkcipher *skcipher;
> +
> + tfm = kzalloc(sizeof(*tfm), GFP_KERNEL);
> + if (!tfm)
> + return ERR_PTR(-ENOMEM);
> +
> + skcipher = 

[PATCH] crypto: algif_hash - correctly handle algos without state

[Sasha Levin]

Algorithms without state will cause the creation of a 0 sized array, which
is undefined outside of structs.

Signed-off-by: Sasha Levin 
---
 crypto/algif_hash.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 68a5cea..a9f923f 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -184,7 +184,7 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
struct alg_sock *ask = alg_sk(sk);
struct hash_ctx *ctx = ask->private;
struct ahash_request *req = >req;
-   char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
+   char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))?:1];
struct sock *sk2;
struct alg_sock *ask2;
struct hash_ctx *ctx2;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

[Andrew Zaborowski]

Hi David,

On 23 February 2016 at 11:55, David Howells  wrote:
> Andrew Zaborowski  wrote:
>
>> AIUI Tadeusz is proposing adding the hashing as a new feature.  Note
>> though that the hash paremeter won't make sense for the encrypt,
>> decrypt or verify operations.
>
> The hash parameter is necessary for the verify operation.  From my
> perspective, I want a verify operation that takes the signature, the message
> hash and the hash name and gives me back an error code.

>From the certificates point of view yes, but the akcipher API only has
the four operations each of which has one input buffer and out output
buffer.

Without overhauling akcipher you could modify pkcs1pad so that sign
takes the hash as input, adds the DER struct in front of it to build
the signature, and the verify operation could at most check that the
DER string matches the hash type and return the hash.  But I think
RFC2437 suggests that you rather compare the signatures, not the
hashes.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

[David Howells]

Andrew Zaborowski  wrote:

> AIUI Tadeusz is proposing adding the hashing as a new feature.  Note
> though that the hash paremeter won't make sense for the encrypt,
> decrypt or verify operations.

The hash parameter is necessary for the verify operation.  From my
perspective, I want a verify operation that takes the signature, the message
hash and the hash name and gives me back an error code.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

[David Howells]

Tadeusz Struk  wrote:

> > Ummm...  Possibly.  Is that how it's used?
> > 
> > warthog>git grep pkcs1pad -- Documentation
> > warthog1>
> 
> Yes, no docs. Sorry.

Can I suggest you at least stick a quick usage summary in the banner comment
at the top of the file?

> > Anyway, the problem I have with this is that I want to get that knowledge
> > out of the asymmetric key in-software public key subtype.  It knows "rsa",
> > "dsa", "ecdsa", ... because that's all the OIDs tell it.
> 
> Rigth, for now the public_key would need to build the full algorithm string as
> follows:
> 
> vsprintf(name, "pkcs1pad(%s, %s)", pkey_algo_name[sig->pkey_algo],
>  hash_algo_name[sig->pkey_hash_algo]);

Does this apply to anything other than RSA?

> Do you plan to add more padding schemes later? 

No plans to, but one never knows.  I'm *assuming* that OID_rsaEncryption and
OID_sha256WithRSAEncryption, for example, must implicitly specify the padding
scheme (RFC4055 suggests I'm right in this assumption).

We might have to suppose RSASSA-SSP at some point.

> Yes, I can start woring on a subsequent patch based on your changes in
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa
> Is that ok with you?

Sure.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html