netdev - Re: [PATCH] net/smc: mark as BROKEN due to remote memory exposure

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]

Message-ID: <3f1bdc23-2777-0d2b-5cf0-303fa1435a98@grimberg.me>
Date:   Mon, 15 May 2017 09:41:09 +0300
From:   Sagi Grimberg <sagi@...mberg.me>
To:     David Miller <davem@...emloft.net>, hch@....de
Cc:     Bart.VanAssche@...disk.com, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, stable@...r.kernel.org,
        ubraun@...ux.vnet.ibm.com
Subject: Re: [PATCH] net/smc: mark as BROKEN due to remote memory exposure

Hi Dave,

>> this patch has not been superceeded by anything, can you explain why
>> it has been marked as such in patchworks?
>
> I think you're being overbearing by requiring this to be marked BROKEN
> and I would like you to explore other ways with the authors to fix
> whatever perceived problems you think SMC has.

Well, its not one's opinion, its a real problem. To be fair, this
security breach existed in other RDMA based storage protocols for
years in the past, but we cleaned it up completely.

Our assumption is that *if* the user is willingly choosing to expose its
entire physical address space to remote access to get some performance
boost that's fine, but to have the kernel expose it by default, without
even letting the user to control it is plain irresponsible. IMHO we
should *not* repeat the mistakes of the past and set a higher bar for
RDMA protocol implementations.

> You claim that this is somehow "urgent" is false.  You can ask
> distributions to disable SMC or whatever in the short term if it
> reallly, truly, bothers you.

I doubt that is sufficient given that not all implementations
out there rely on distros. I'm afraid one time is too much in
this case.