DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E2865386102B
Date: Thu, 4 Mar 2021 17:11:47 +0100
To: cygwin@cygwin.com
Subject: Re: segfault on 32bit cygwin snapshot
Message-ID: <YEEGw4P+vtzejGOv@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <9d7b9dc2-cb92-498b-7655-e9c618114c87@gmail.com>
 <20210221072954.db2dcbd523ed366e4dfcb0d0@nifty.ne.jp>
 <7480c946-8e02-aba2-c06f-6b39f630699f@gmail.com>
 <20210301095546.dce31a474bd0cec2c3518f87@nifty.ne.jp>
 <20210301212542.8b1749f92af62c01b008f25a@nifty.ne.jp>
 <20210302200308.62db4fe01f78fb35a538784f@nifty.ne.jp>
 <YD5eXbxBWbUUSwcM@calimero.vinschen.de>
 <20210303185621.b048287526901af6a4c8200a@nifty.ne.jp>
 <YD9sSea32T7GqlJr@calimero.vinschen.de>
 <e15e6d1f-7680-8f80-871e-0d224a3ed682@maxrnd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e15e6d1f-7680-8f80-871e-0d224a3ed682@maxrnd.com>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces@cygwin.com
Sender: "Cygwin" <cygwin-bounces@cygwin.com>

On Mar  4 01:05, Mark Geisert wrote:
> Corinna Vinschen via Cygwin wrote:
> > Is there a way around that?  I'm not quite sure, so let's brain storm
> > a bit, ok?
> > 
> > - One thing we could try is to remove the above code, but add a python
> >    hack to dlsym instead.  This would let the "old" DLLs work again as
> >    before and for python we could add a hack to dlsym, along these lines:
> > 
> >      if (CYGWIN_VERSION_CHECK_FOR_UNAME_X
> >      	&& modulehandle == cygwin1.dll
> > 	&& strcmp (symname, "uname"))
> >        symname = "uname_x";
> > 
> > Thoughts?  Other ideas?
> 
> That's a sly fix, but it seems that it would do the job.  That's good!
> 
> On a different tack, I was thinking about how run time code could tell the
> difference between the versions of uname() being called.  It can't.  I
> looked at glibc and FreeBSD libc to see if they had to deal with this
> compatibility issue. It seems they don't, or I couldn't locate it if they
> do.
> 
> But FreeBSD has an approach that looked interesting in another way.  They
> have the standard uname() function taking the one usual arg.  But it's just
> a wrapper on a worker function that takes the original arg plus another arg
> specifying the size of the fields in struct utsname.  Paraphrasing, using
> Cygwin names:
>         int uname(struct utsname *uptr)
>         {
>             return uname_x((int) _UTSNAME_LENGTH, uptr);
>         }
> They allow the user to override what we call _UTSNAME_LENGTH.  That seems
> like an invitation to exploit so I don't care for that.  But what I was
> thinking is if we make that first arg to uname_x() be a uintptr_t, we could
> tell (with pretty good confidence) at run time inside uname_x() if we were
> passed a length (from new code passing two args) or a ptr-to-buf (from old
> code just passing one arg).

But uname_x just supports the new implementation, I'm not sure how this
helps us.  We may at least need two wrappers, one is the function called
from new apps, i.e.

  uname () { return uname_worker (sizeof old_utsname, &name); }
  uname_x () { return uname_worker (sizeof utsname, &name); }
  uname_worker { do your worst; }

However, it's not clear how this fixes the actual problem.  We just
don't have a way to know what size the caller expects.

Having version or size info in structs like the Win32 API does in a
couple of cases makes a lot more sense now...


Corinna
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple