Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Bob Pearson <rpearsonhpe@gmail.com>
To: Leon Romanovsky <leon@kernel.org>, linux-rdma@vger.kernel.org
Subject: Re another alternative to resolve hardened user copy warnings
Date: Tue, 25 Aug 2020 11:37:52 -0500	[thread overview]
Message-ID: <42b0da37-898f-2ca1-ffcb-444b65c9c48d@gmail.com> (raw)

Currently only the rxe driver is exhibiting the issue of kernel warnings during qp create caused by recent kernel changes looking for potential information leaks to user space. The test which triggers this warning is very specific. It occurs when a portion of a kernel object stored in a slab cache is copied to user space and the copied area has not been 'whitelisted' by setting useroffset and usersize parameters for the kmem cache. As already discussed there are two ways to mitigate this

	- copy the data, in this case an int, out of the kmem cache object then copy that to user space
	- play by the rules and set useroffset and usersize using kmem_cache_create_usercopy()

Additionally, as you have mentioned, we could move the allocation to the core (like AH, CQ, PD, etc.). But this only works for a different reason. If you use kmalloc or kzalloc then the warning is not triggered either and core uses these to allocate objects.

Allocating memory from kmalloc or kzalloc is effectively the same as kmem cache except that the pre-allocated sizes are typically powers of 2 so there is some wastage of memory and you have the potential to pre initialize all the objects in the kmem cache (e.g. locks, constants, etc) saving some time. Currently rxe does not take advantage of this second feature because resource allocation is not on the performance path for RDMA. Given this we have a third alternative which is

	- get rid of the kmem caches and use kzalloc to allocate storage for objects in the pools.

This is a simple change to rxe_pool.c, easy to understand, little or no change to the rest of the driver. This does not prevent moving other object allocations into the core but will resolve the warning issue.

Bob

             reply	other threads:[~2020-08-25 16:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25 16:37 Bob Pearson [this message]
2020-08-25 16:53 ` Re another alternative to resolve hardened user copy warnings Jason Gunthorpe
2020-08-25 17:12   ` Bob Pearson
2020-08-25 17:26     ` Jason Gunthorpe

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=42b0da37-898f-2ca1-ffcb-444b65c9c48d@gmail.com \
    --to=rpearsonhpe@gmail.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox