From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12283 Path: news.gmane.org!.POSTED!not-for-mail From: bluemoon Newsgroups: gmane.linux.lib.musl.general Subject: Re: Problems that emerged when trying to port dosemu2 Date: Sat, 23 Dec 2017 15:35:24 +0100 Message-ID: <9905cee8-ef80-51d7-8382-d9003c58fe8c@mailbox.org> References: <4b3b4442-af00-6134-b284-8699dddb35ea@mailbox.org> <20171203144920.GZ15263@port70.net> <20171203220145.GQ1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1514039636 32321 195.159.176.226 (23 Dec 2017 14:33:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 14:33:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12299-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 23 15:33:52 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eSks3-00089m-Kn for gllmg-musl@m.gmane.org; Sat, 23 Dec 2017 15:33:51 +0100 Original-Received: (qmail 19479 invoked by uid 550); 23 Dec 2017 14:35:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19461 invoked from network); 23 Dec 2017 14:35:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:received; s=mail20150812; t= 1514039734; bh=9OCkX0zcrVDTdeQM8BH4uCWhvUrwdTExnQEjjZFiLeI=; b=C nRDBNk3wKKiN38lrybFKp8oKWiQ4H6dSRiFcQzOAdGkMiUZ5o2iuW6j9WmpMuVMk IdD/NEzvxvzXSLbLdW4PfiHn/FSLOf+CKhohzpHjAAwXlIi6HYyVp0yjNpLd3rZI Wbi5yjR4sgCOXGLY3tejmtxPJkAxSZsdzV3Knf+NF7QW+yDYPocyDXCLzQzsPrRG 3Pq6aC2tTm0pPUc1o+Zv8veVZ3jpJdSV4ShNlDEO8n3RhuJ23Ys6rocp/gq3p+Li Bt33jkrBG2N8lTDePHdZgZ8heIQ42o8JZLEBVEn5s4EUMRgVYYc5yvpn+LzhWtOf iEn4JTJ+kWChInz18MVgQ== X-Virus-Scanned: amavisd-new at heinlein-support.de In-Reply-To: <20171203220145.GQ1627@brightrain.aerifal.cx> Content-Language: de-DE Xref: news.gmane.org gmane.linux.lib.musl.general:12283 Archived-At: Am 03.12.2017 um 23:01 schrieb Rich Felker: > On Sun, Dec 03, 2017 at 03:49:20PM +0100, Szabolcs Nagy wrote: >> * bluemoon [2017-12-03 11:50:34 +0100]: >>> My knowledge of the matter is too limited to explain it in my own words, but >>> he summarized what’s going on here (patches are below): >>> https://github.com/stsp/dosemu2/issues/537#issuecomment-346177776 >>> >>>> The checks that you remove, are nonsense: >>>> they check for "ss_size" and return ENOMEM >>>> even for SS_DISABLE. They check for ~SS_DISABLE >>>> and return error for SS_AUTODISARM, even >>>> though it is defined in their headers. Overall >>>> they try to check the syscall parameters - >>>> something they should never do simply because >>>> libc does not understand the syscall parameters. >>>> It should just call the syscall - not more, not less. >>>> syscall understands its parameters, so it will >>>> check them correctly and return error as appropriate. >>>> Check from musl should be removed, and I think >>>> it would be good to try to submit that change. >>>> >>>> Stack-protector problem is a kernel mis-feature, >>>> and a very unfortunate one. We should pester >>>> Andy Lutomirski (@amluto) to finally fix it. :) >>>> I don't know if musl can accept this patch, maybe >>>> it can if the attribute is put under #ifdef __GNUC__ >>>> check. >>> >>> To make it work the following two patches were applied: >>> >>> --- src/misc/syscall.c.orig 2017-10-31 20:13:58.000000000 +0100 >>> +++ src/misc/syscall.c 2017-11-21 18:36:38.912082672 +0100 >>> @@ -3,7 +3,7 @@ >>> >>> #undef syscall >>> >>> -long syscall(long n, ...) >>> +__attribute__((optimize("no-stack-protector"))) long syscall(long n, ...) >>> { >> >> changing fs/gs behind the back of the c runtime is not >> guaranteed to work, but it makes sense to me to compile >> syscall.c without ssp instrumentation to allow certain hacks. >> (but i think this should be done in the makefile) > > I'm not clear why this would even work on glibc, since %gs is used to > access the vdso syscall pointer. I don't think it makes sense to treat > syscall() specially here. If the thread pointer register is not valid, > then the ABI is not being satisfied and that's all there is to say. > Programs that have changed the thread pointer in a thread must refrain > from doing anything that could cause a call into libc. If they need to > make syscalls, they can do it via [inline] asm; they're already using > target-specific asm anyway if they're changing %fs/%gs. > >>> va_list ap; >>> syscall_arg_t a,b,c,d,e,f; >>> >>> --- src/signal/sigaltstack.c.orig 2017-10-31 20:13:58.000000000 +0100 >>> +++ src/signal/sigaltstack.c 2017-11-21 20:56:59.740814704 +0100 >>> @@ -4,15 +4,5 @@ >>> >>> int sigaltstack(const stack_t *restrict ss, stack_t *restrict old) >>> { >>> - if (ss) { >>> - if (ss->ss_size < MINSIGSTKSZ) { >>> - errno = ENOMEM; >>> - return -1; >>> - } >> >> i think this part has to be kept for conformance reasons: >> the kernel does not check MINSIGSTKSZ (it does not even >> know how it is defined in musl, so it is musl abi, not >> kernel abi), but posix requires the check. > > Indeed, but POSIX says: > > "If it is set to SS_DISABLE, the stack is disabled and ss_sp and > ss_size are ignored." > > so it's a bug to be checking ss_size when ss_flags == SS_DISABLE. We > should only check ss_size if !(ss_flags & SS_DISABLE) or similar. > >>> - if (ss->ss_flags & ~SS_DISABLE) { >>> - errno = EINVAL; >>> - return -1; >>> - } >> >> this is another conformance check, but one can argue >> that linux extensions should be allowed here. >> (it's unfortunate that some useful linux extensions >> are in conflict with posix requirements..) > > Yes, this one is a requirement and I don't see any way around it... Thank you for your replies! The developer of dosemu2 was able to implement some work-arounds so that now it’s possible to run protected mode programs. However, a remaining question is that if linux extensions aren’t allowed why is #define SS_AUTODISARM (1U << 31) #define SS_FLAG_BITS SS_AUTODISARM defined in signal.h? This confuses the detections.