From: George Spelvin <lkml@SDF.ORG>
To: Bernard Metzler <BMT@zurich.ibm.com>
Cc: linux-kernel@vger.kernel.org, Doug Ledford <dledford@redhat.com>,
Jason Gunthorpe <jgg@mellanox.com>,
linux-rdma@vger.kernel.org, Faisal Latif <faisal.latif@intel.com>,
Shiraz Saleem <shiraz.saleem@intel.com>,
Bart Van Assche <bvanassche@acm.org>,
lkml@sdf.org
Subject: Re: [RFC PATCH v1 42/50] drivers/ininiband: Use get_random_u32()
Date: Sun, 29 Mar 2020 16:52:04 +0000 [thread overview]
Message-ID: <20200329165204.GC4675@SDF.ORG> (raw)
In-Reply-To: <OF05D43316.2F69D46F-ON0025853A.00513FE8-0025853A.00528B66@notes.na.collabserv.com>
On Sun, Mar 29, 2020 at 03:01:36PM +0000, Bernard Metzler wrote:
> -----"George Spelvin" <lkml@sdf.org> wrote: -----
>> Subject: [EXTERNAL] [RFC PATCH v1 42/50] drivers/ininiband: Use
get_random_u32()
>>
>> There's no need to get_random_bytes() into a temporary buffer.
>>
>> This is not a no-brainer change; get_random_u32() has slightly weaker
>> security guarantees, but code like this is the classic example of when
>> it's appropriate: the random value is stored in the kernel for as long
>> as it's valuable.
>>
>> TODO: Could any of the call sites be further weakened to prandom_u32()?
>> If we're randomizing to avoid collisions with a *cooperating* (as opposed
>> to malicious) partner, we don't need cryptographic strength.
>>
>> Signed-off-by: George Spelvin <lkml@sdf.org>
>> Cc: Doug Ledford <dledford@redhat.com>
>> Cc: Jason Gunthorpe <jgg@mellanox.com>
>> Cc: linux-rdma@vger.kernel.org
>> Cc: Faisal Latif <faisal.latif@intel.com>
>> Cc: Shiraz Saleem <shiraz.saleem@intel.com>
>> Cc: Bart Van Assche <bvanassche@acm.org>
>> Cc: Bernard Metzler <bmt@zurich.ibm.com>
>> diff --git a/drivers/infiniband/sw/siw/siw_verbs.c
>> b/drivers/infiniband/sw/siw/siw_verbs.c
>> index 5fd6d6499b3d7..42f3ced4ca7c7 100644
>> --- a/drivers/infiniband/sw/siw/siw_verbs.c
>> +++ b/drivers/infiniband/sw/siw/siw_verbs.c
>> @@ -1139,7 +1139,7 @@ int siw_create_cq(struct ib_cq *base_cq, const
>> struct ib_cq_init_attr *attr,
>> rv = -ENOMEM;
>> goto err_out;
>> }
>> - get_random_bytes(&cq->id, 4);
>> + cq->id = get_random_u32();
>> siw_dbg(base_cq->device, "new CQ [%u]\n", cq->id);
>>
>> spin_lock_init(&cq->lock);
> Speaking for the siw driver only, these two changes are looking
> good to me. What is needed is a pseudo-random number, not
> to easy to guess for the application. get_random_u32() provides that.
>
> Thanks!
>
> Reviewed-by: Bernard Metzler <bmt@zurich.ibm.com>
Just so you know, get_random_u32() is still crypto-strength: it is
unguessable even to a resourceful attacker with access to large amounts
of other get_random_u32() output.
prandom_u32() is much cheaper, but although well seeded and distributed
(so equally resistant to accidental collisions), *is* guessable if someone
really wants to work at it.
Many intra-machine networks (like infiniband) are specifically not
designed to be robust in the face of malicious actors on the network.
A random transaction ID is sent in the clear, and a malicious actor
wanting to interfere could simply copy it.
In such cases, there's no need for crypto-grade numbers, because the
network already assumes that nobody's actively trying to create
collisions.
You seem to be saying that the siw driver could use prandom_u32().
next prev parent reply other threads:[~2020-03-29 16:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 0:21 [RFC PATCH v1 42/50] drivers/ininiband: Use get_random_u32() George Spelvin
2020-03-29 14:36 ` Jason Gunthorpe
2020-03-29 16:31 ` George Spelvin
2020-03-29 15:01 ` Bernard Metzler
2020-03-29 16:52 ` George Spelvin [this message]
2020-03-29 20:02 ` Jason Gunthorpe
2020-03-29 20:45 ` George Spelvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200329165204.GC4675@SDF.ORG \
--to=lkml@sdf.org \
--cc=BMT@zurich.ibm.com \
--cc=bvanassche@acm.org \
--cc=dledford@redhat.com \
--cc=faisal.latif@intel.com \
--cc=jgg@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=shiraz.saleem@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.