On Jun 11, 2012, at 8:21 AM, Tomas Mraz via RT wrote: > On Sun, 2012-06-10 at 18:04 +0200, Michael Tuexen wrote: >> 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. > > It fixes the first problem (although non-portably). But there are still ... the problem is specific to a platform... > the signed/unsigned int comparisons of the mtu values later in the code > in d1_both.c. Of course fixing the first problem will probably mask the Ahh, right. We'll look at it and update the patch.
Thanks a lot. Best regards Michael > second problem. > > -- > Tomas Mraz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > > > ______________________________________________________________________ > 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
