On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote: >>>>> The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a >>>>> value of length 4. On little endian systems this is not so critical >>>>> problem however on big endian 64 bit systems it means the interpretation >>>>> of the returned value by the code in dgram_ctrl() is completely wrong - > >> >>> Actually similar argument applies even to sockopt_len. Modulo fact >>> that you get into trouble in cases when *expected* >>> sizeof(sockopt_len) is 8, while the value is declared int. The >>> situation is intensified by fact that in some cases expected >>> sizeof(sockopt_len) depends on compiler flags. And I'm not talking >>> about -m32 vs. -m64 compiler flags, I'm talking about flags in >>> 64-bit case [Tru64 for one if you have to know]. One way to attack >>> the problem is depicted in crypto/bio/b_sock.c:975. I mean union >>> between unsigned int and size_t, explicit zeroing of size_t member >>> and heuristic that detects big-endian trouble. Then one can declare >>> even sockopt_val as similar union and pick int or long depending on >>> calculated sockopt_len being 4 or 8. >> General comment: >> Can't you use socklen_t as the type of the last argument? > > As it says in crypto/bio/b_sock.c:975, there *are* platforms that don't have > socklen_t. Of course one can question if these platforms are modern > enough/worth to care about, but why not, if it's feasible and enriching? Or > course one can go for #ifdef, but does one have to? OK, I see... Personally, I would define socklen_t on platforms which don't have them to the right type (int of size_t according to you comment), but that is just personal preference... > >> At least >> this is what I normally use. The type of *option_value might be >> platform dependent, but then we need some #ifdefs for platforms. > > But the choice is still between 32- and 64-bit integers. And if so, you can > distinguish among them at run time as accurately. Or should one say even I'm not sure I understand what you are requesting. The implementation of the IP_MTU defines the opt_value as an int. It doesn't matter what sizeof(int) is. Only if I compile on one platform and run it on a different platform and both don't agree on sizeof(int). > more accurately, because it's actual value, not assumed one from compile > time. Of course, absolute majority of compiled code heavily relies on assumed > values being equal to actual, but it's not prohibited to assume that there > are not, is it? #ifdefs have to be maintained in sense that you have to > follow their changes on multiple platforms, while #ifdef-free alternative > simply adapts to whichever situation with *no* maintenance. > >> Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man >> page says, that the type of the option_value is int. So I guess the >> bug is simply, that the code uses long sockopt_val instead of int >> sockopt_val. All this is specific to Linux. > > Can you guarantee that the code in question won't ever become interesting to > reuse even in non-Linux context? I mean do you really have to assume Linux > that categorically? In other words in context of multi-platform code such as > OpenSSL there is value in *not* assuming things. That code is platform specific. It is surrounded by #ifdef OPENSSL_SYS_LINUX #endif We are looking in several platform specific issues, like setting the TOS (for ECN) byte, setting the DF bit, querying the interface MTU, receiving the ECN bits for DTLS. We will provide one API, but the implementation is platform specific. So I guess, we can fix this bug easily. However, according to initial comment, all getsockopt() call are broken, right?
Best regards Michael > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
