7 ms·

Comments here are cute. NFS has been in the kernel for ages and works roughly the same way, kernel driver with a userland component. NFS has the advantage of

by mangix 4y ago

Comments here are cute. NFS has been in the kernel for ages and works roughly the same way, kernel driver with a userland component. NFS has the advantage of having been in the kernel longer with most low hanging fruit security bugs fixed. ksmbd is brand new. Quite the expectation to have it be completely bug free. edit: wait a minute, this was fixed with kernel 5.15.61 That's at least 20 releases ago.

jacquesm 4y ago
That's a valid observation. All of the old stuff has been battle tested and reviewed many times. Newer stuff is bound to have bugs that still have not been found. And even old stuff turns up surprises every now and then. For instance https://nvd.nist.gov/vuln/detail/CVE-2021-27363 https://nvd.nist.gov/vuln/detail/CVE-2021-27363 4300 affected kernel versions has to be a record of sorts.
- ryao 4y ago
  I found a buffer overflow in the OpenSolaris code a few hours ago that originated in a commit made in 2007. It predates that Linux bug by at least a year. It is amazing how many old bugs have survived to the present day. :/
  - nix23 4y ago
    >I found a buffer overflow in the OpenSolaris code a few hours ago that originated in a commit made in 2007. That's because there is no OpenSolaris anymore....
Sirened 4y ago
The criticism isn't that anyone expects bug free code, rather that introducing new remotely accessible attack surface to the kernel in 2022 when we know it's likely unsafe is silly. Building an SMB server in the kernel because "well, NFS was secure eventually" overlooks the fact that NFS shouldn't be in the kernel either.
- rosnd 4y ago
  > rather that introducing new remotely accessible attack surface to the kernel in 2022 when we know it's likely unsafe is silly. This is the worst possible take on this. > Building an SMB server in the kernel because "well, NFS was secure eventually" overlooks the fact that NFS shouldn't be in the kernel either. The way Linux works, NFS unfortunately has to be in the kernel to achieve reasonable performance.
  - lillecarl 4y ago
    How do people running Ceph and other exotic filesystems deal with performance? What performance is considered reasonable performance in your opinion? It might not align with others, most people don't push that crazy amounts of data. I know IBM went from in-kernel NFS to Ganesha for their Spectrum Scale product recently.
    - rosnd 4y ago
      "Crazy amounts of data" isn't the main concern, it's latency. It's the people storing giant amounts of data who generally don't worry about that so much.
      - lillecarl 4y ago
        We usually run those services with local nvme disks, they're not as portable but we get great performance.
    - paulmd 4y ago
      Ceph isn't a filesystem, it's a service layer (self-described "storage platform") that runs on top of some other unspecified filesystem. Think git-annex or hadoop, not ext4. Anyway the way Ceph does that is replication, just like those other solutions. There may be 4 nodes with filesystems that contain that data, and Ceph is the veneer that lets you not have to worry about the implementation-detail of where it lives.
      - 4y ago

by mangix 4y ago

jacquesm 4y ago

That's a valid observation. All of the old stuff has been battle tested and reviewed many times. Newer stuff is bound to have bugs that still have not been found. And even old stuff turns up surprises every now and then. For instance https://nvd.nist.gov/vuln/detail/CVE-2021-27363 https://nvd.nist.gov/vuln/detail/CVE-2021-27363 4300 affected kernel versions has to be a record of sorts.

ryao 4y ago
I found a buffer overflow in the OpenSolaris code a few hours ago that originated in a commit made in 2007. It predates that Linux bug by at least a year. It is amazing how many old bugs have survived to the present day. :/
- nix23 4y ago
  >I found a buffer overflow in the OpenSolaris code a few hours ago that originated in a commit made in 2007. That's because there is no OpenSolaris anymore....

Sirened 4y ago

The criticism isn't that anyone expects bug free code, rather that introducing new remotely accessible attack surface to the kernel in 2022 when we know it's likely unsafe is silly. Building an SMB server in the kernel because "well, NFS was secure eventually" overlooks the fact that NFS shouldn't be in the kernel either.

rosnd 4y ago
> rather that introducing new remotely accessible attack surface to the kernel in 2022 when we know it's likely unsafe is silly. This is the worst possible take on this. > Building an SMB server in the kernel because "well, NFS was secure eventually" overlooks the fact that NFS shouldn't be in the kernel either. The way Linux works, NFS unfortunately has to be in the kernel to achieve reasonable performance.
- lillecarl 4y ago
  How do people running Ceph and other exotic filesystems deal with performance? What performance is considered reasonable performance in your opinion? It might not align with others, most people don't push that crazy amounts of data. I know IBM went from in-kernel NFS to Ganesha for their Spectrum Scale product recently.
  - rosnd 4y ago
    "Crazy amounts of data" isn't the main concern, it's latency. It's the people storing giant amounts of data who generally don't worry about that so much.
    - lillecarl 4y ago
      We usually run those services with local nvme disks, they're not as portable but we get great performance.
  - paulmd 4y ago
    Ceph isn't a filesystem, it's a service layer (self-described "storage platform") that runs on top of some other unspecified filesystem. Think git-annex or hadoop, not ext4. Anyway the way Ceph does that is replication, just like those other solutions. There may be 4 nodes with filesystems that contain that data, and Ceph is the veneer that lets you not have to worry about the implementation-detail of where it lives.
    - 4y ago