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? > >> 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 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. I think http://rt.openssl.org/Ticket/Display.html?id=2830&user=guest&pass=guest already fixes the bug, since it changes sockopt_val from long to int.
Do you want that patch to be split up in a bug fixing patch and a feature patch? Best regards Michael > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
