| 29 Dec 2025 |
 Randy Eckenrode | The only issue I can see with forcing a larger size for all packages is what happens when packages request their own size (e.g., a smaller one). | 00:42:00 |
 emily |
This will not resolve the issue of fds limited to 1024 per se but only
disable the fault trap in libSystem. To increase the number of fds
supported by select, one also has to increase FD_SETSIZE macro value
during compilation, making sure it's defined before select header is
included.
I believe the idea is actually that you pass a heap-allocated fd buffer instead
| 00:42:21 |
| emily | and then it checks whether it's on the stack or not | 00:42:34 |
 Ihar Hrachyshka | ...which is what I'm doing in that glib patch (and in the counterpart local to glib package here: https://github.com/NixOS/nixpkgs/pull/474904) but we had a discussion with Randy the other day that maybe there's no practical reason to limit it (BSDs don't) | 00:42:43 |
| Randy Eckenrode | The implementation in xnu just disables the check. It doesn’t check location AFAIK. | 00:43:11 |
| emily | POSIX doesn't say FD_SETSIZE has to be 1024, so Apple could raise the default if they wanted to (so perhaps there is a reason they haven't) | 00:43:41 |
| Ihar Hrachyshka |
I believe the idea is actually that you pass a heap-allocated fd buffer instead
interesting. and it rhymes with something we read elsewhere. where do you get this from?
| 00:43:54 |
| emily | one obvious way it can go badly is if people cast their own 1024-size stack buffers to fd_set and then you have a heap overflow vulnerability | 00:44:10 |
| Randy Eckenrode | Wouldn’t that be a breaking change? | 00:44:12 |
| emily | well, no more or less a breaking change than if we do it | 00:44:39 |
| Randy Eckenrode | https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/libsyscall/wrappers/select-base.c#L10 | 00:44:40 |
| Randy Eckenrode | * | 00:44:46 |
| emily | nominally it should just increase people's stack sizes, but ^ could potentially cause disaster, but then that's a reason it could be bad for us too | 00:44:59 |
| Randy Eckenrode | But we’re building everything from source. Apple has to support older binaries. | 00:45:17 |
| Randy Eckenrode | https://devblogs.microsoft.com/oldnewthing/20221102-00/?p=107343 | 00:45:40 |
| Randy Eckenrode | Apple is kind of stuck with a crappy ABI it inherited from BSD. | 00:46:00 |
