netdev - Re: [net-next][PATCH v2 2/2] rds: add sysctl for rds support of On-Demand-Paging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 5 May 2019 09:22:50 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     Santosh Shilimkar <santosh.shilimkar@...cle.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        Moni Shoua <monis@...lanox.com>
Subject: Re: [net-next][PATCH v2 2/2] rds: add sysctl for rds support of
 On-Demand-Paging

On Thu, May 02, 2019 at 10:59:58AM -0700, Santosh Shilimkar wrote:
>
>
> On 5/1/2019 11:18 PM, Leon Romanovsky wrote:
> > On Wed, May 01, 2019 at 10:54:50AM -0700, Santosh Shilimkar wrote:
> > > On 5/1/2019 12:45 AM, Leon Romanovsky wrote:
> > > > On Mon, Apr 29, 2019 at 04:37:20PM -0700, Santosh Shilimkar wrote:
> > > > > RDS doesn't support RDMA on memory apertures that require On Demand
> > > > > Paging (ODP), such as FS DAX memory. A sysctl is added to indicate
> > > > > whether RDMA requiring ODP is supported.
> > > > >
> > > > > Reviewed-by: H??kon Bugge <haakon.bugge@...cle.com>
> > > > > Reviewed-tested-by: Zhu Yanjun <yanjun.zhu@...cle.com>
> > > > > Signed-off-by: Hans Westgaard Ry <hans.westgaard.ry@...cle.com>
> > > > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@...cle.com>
> > > > > ---
> > > > >    net/rds/ib.h        | 1 +
> > > > >    net/rds/ib_sysctl.c | 8 ++++++++
> > > > >    2 files changed, 9 insertions(+)
> > > >
> > > > This sysctl is not needed at all
> > > >
> > > Its needed for application to check the support of the ODP support
> > > feature which in progress. Failing the RDS_GET_MR was just one path
> > > and we also support inline MR registration along with message request.
> > >
> > > Basically application runs on different kernel versions and to be
> > > portable, it will check if underneath RDS support ODP and then only
> > > use RDMA. If not it will fallback to buffer copy mode. Hope
> > > it clarifies.
> >
> > Using ODP sysctl to determine if to use RDMA or not, looks like very
> > problematic approach. How old applications will work in such case
> > without knowledge of such sysctl?
> > How new applications will distinguish between ODP is not supported, but
> > RDMA works?
> >
> Actually this is not ODP sysctl but really whether RDS supports
> RDMA on fs_dax memory or not. I had different name for sysctl but
> in internal review it got changed.
>
> Ignoring the name of the sysctl, here is the application logic.
> - If fs_dax sysctl path doesn't exist, no RDMA on FS DAX memory(this
> will cover all the older kernels, which doesn't have this patch)
> - If fs_dax sysctl path exist and its value is 0, no RDMA on FS
> DAX. This will cover kernels which this patch but don't have
> actual support for ODP based registration.
> - If fs_dax sysctl path exist and its value is 1, RDMA can be
> issued on FS DAX memory. This sysctl will be updated to value 1
> once the support gets added.
>
> Hope it clarifies better now.

Santosh,

Thanks for explanation, I have one more question,

If I'm author of hostile application and write code to disregard that
new sysctl, will any of combinations of kernel/application cause to
kernel panic? If not, we don't really need to expose this information,
if yes, this sysctl is not enough.

Thanks

>
> Regards,
> Santosh