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 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
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
