4 ms·
Unlike a vulnerability, there is no particular reason for anyone to break the tricks used here. Platform detection almost always relies on quirks like this if i
by MobiusHorizons 4y ago
Unlike a vulnerability, there is no particular reason for anyone to break the tricks used here. Platform detection almost always relies on quirks like this if it hasn’t been designed in from the start.
- saagarjha 4y agoBreaking something like this would generally be for refactoring or performance reasons
- jart 4y agoDid you read the article? The only one I could foresee breaking is if OpenBSD decided to one day implement auxiliary values.
- saagarjha 4y agoI did. Putting aside syscall numbers, which I've talked you about before, there's a lot of things that you are depending on. One of them would be if OpenBSD implements auxv, but relying on the various registers being zeroed out or equal to each other at program startup is dicey on most platforms.
- jart 4y agoWell if you consider trolling talking https://news.ycombinator.com/item?id=32562674 https://news.ycombinator.com/item?id=32562674 whatever they break I'll just ask them to fix. I've had to make plenty of reasonable asks in the past to make APE possible. For example, I got a nasty bug fixed in the NetBSD /bin/sh. I got FreeBSD /bin/sh patched. We got POSIX to change their rules to allow it. Let's not forget zsh and fish.
- saagarjha 4y agoI think most OSes will be happy if you come to them with actual bugs, yes. But if you ask them to stop changing syscall numbers or various other "ABI" that is not actual ABI, I feel like they are not going to be as happy to accommodate you.
- guerrilla 4y agoI disagree. It's pretty easy to detect the OS using things that can't possibly change like ABI calling convention (the BSDs differ from Linux.) There's thousands of ways to differentiate Windows from Linux that can't be changed...