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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 6 May 2019 09:37:48 -0700 From: Santosh Shilimkar <santosh.shilimkar@...cle.com> To: Leon Romanovsky <leon@...nel.org> 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 5/4/2019 11:22 PM, Leon Romanovsky wrote: > 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. > It Won't panic. Thats why the other patch also makes the call fail when tried to register FS DAX memory with RDS.
Powered by blists - more mailing lists