netdev - Re: Upstream Homa?

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>] [day] [month] [year] [list]

Date:   Fri, 11 Nov 2022 11:10:04 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     John Ousterhout <ouster@...stanford.edu>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: Upstream Homa?

On Fri, 11 Nov 2022 10:59:58 -0800
John Ousterhout <ouster@...stanford.edu> wrote:

> The netlink and 32-bit kernel issues are new for me; I've done some digging
> to learn more, but still have some questions.
> 
> * Is the intent that netlink replaces *all* uses of /proc and ioctl? Homa
> currently uses ioctls on sockets for I/O (its APIs aren't
> sockets-compatible). It looks like switching to netlink would double the
> number of system calls that have to be invoked, which would be unfortunate
> given Homa's goal of getting the lowest possible latency. It also looks
> like netlink might be awkward for dumping large volumes of kernel data to
> user space (potential for buffer overflow?).
> 
> * By "32 bit kernel problems" are you referring to the lack of atomic
> 64-bit operations and using the facilities of u64_stats_sync.h, or is there
> a more general issue with 64-bit operations?
> 
> -John-

I admit, haven't looked at Hama code. Are you using ioctl as a generic
way into kernel for operations?

Ioctl's on sockets are awkward API and have lots of issues.
The support of 32 bit app on 64 bit OS is one of them.
For that reason they are strongly discouraged.

Netlink allows multiple TLV options in single request and they should
be processed as transaction.  Netlink is intended for control operations.

If you need a new normal path operation, then either use an existing
system call (sendmsg/recvmsg) with new flags; or introduce a new system
call. Don't abuse ioctl as a way to avoid introducing new system call.
New system calls do add additional complexity to security modules, so
SELinux etc may need to know.

PS: please don't top post in replys to Linux mailing lists.