From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by sourceware.org (Postfix) with ESMTPS id E2865386102B for ; Thu, 4 Mar 2021 16:11:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E2865386102B Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N0o7f-1letF31zKH-00wmBx for ; Thu, 04 Mar 2021 17:11:48 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id BA265A805CE; Thu, 4 Mar 2021 17:11:47 +0100 (CET) Date: Thu, 4 Mar 2021 17:11:47 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: segfault on 32bit cygwin snapshot Message-ID: Reply-To: cygwin@cygwin.com 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> <20210303185621.b048287526901af6a4c8200a@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:xTbYypoIgRFBSZeuHlhBYdW3O8ox+ffFJbBgWrYHLcGODUh7XU3 zXHmkYLeHCrWg/Gvuw7M7I3czhlChO2nqDXnyhUFEeTW79H1GjANecknqLZ9G2FGe/kBxwv 7ZwxYpfmVCELX6vvxRUoUphTJCTRRVRgiYWGfRVkbuv6O9GxuS4UTJT1LGLeDcZ6FjLnMTm 2iby81oJ/nBHzhaLnyYgQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:W6nfvdR3xh0=:Wi6OOKljcPX337zzmGhDre QSPjNquDEsdRAyl+niAnNMydcM2zHaXuojdEcMvZG3fQck5nNnqhJEyS5j8W0J7V0TPThnGLL eiYOuELWx6ADSa2GLeRQTd4POlwXkjlPb7mhB41qJONFC8hF1JstOYoiVnb/guPWyPM0aV47X PjN6p6xcL+C4SRtSmFX1P3Zg0JHLNxwOoSKgc4qFcYE2QqSU30ZGi0Q3M+16aBqx2Fzu51SNI 435MIB3yo2hkH3wdJUKcZVhWajKRSYknw6EOCjf83Xuwxgg392Unq0PfNXa7FHc/9jc8RRRlT C875Mdd+P/yiliSzT7WWI7OqqjxOuhEkTVqUqmth/uDzyYTWhN5G5oygpA7KuwKhVUnjaxa1S cnR/DlcDB1V8P3E8yJWwtcoFAwNRitE+qmvr02yvUIBttBXFXWMrHEHSLqpfdGpgM92sMlhQL NfZ3S8GGAQ== X-Spam-Status: No, score=-101.4 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 16:11:51 -0000 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