From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29887 invoked from network); 28 Aug 2020 19:40:42 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 28 Aug 2020 19:40:42 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 3e02b102 for ; Fri, 28 Aug 2020 14:40:36 -0500 (EST) Received: from sender4-of-o58.zoho.com (sender4-of-o58.zoho.com [136.143.188.58]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id c260e739 for ; Fri, 28 Aug 2020 14:40:35 -0500 (EST) ARC-Seal: i=1; a=rsa-sha256; t=1598643633; cv=none; d=zohomail.com; s=zohoarc; b=iptuwlXXH9V0REYN7lGOHGlfSqus0zw8v51I20Se8H3SgLktSEa19dJ254w8e+WyEA3wKt7sFlad5G/m5kVeYZdfwydOEnhZSPteJlJkmniHaZaXZlnFLamx+Y+gjItyJ7OYHBmgHY/Y6xM06Fm9/6BluSQDZkxrV8YGh43w1/A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1598643633; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=jpSM/2AEIS0N/jhDgJakDVYF3u1uF1xpGeUn1EIUemY=; b=HczrxnK2tQp9Y7iYJwo/4gIvmzVAb21j2IN0/YJzL4sGRWC1k9PvnKlF+3YLi+vyRTzOYszqaWx7/eAA6cE+NnM1skuITRZXld5GUphstFDrPaRCYuGb9ENHxsh4a1V2u6m9Kvm5igyrrGygzrRMgshxLEGKlVcWFpH0Q43dCl0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=irixnet.org; spf=pass smtp.mailfrom=kazuo@irixnet.org; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598643633; s=default; d=irixnet.org; i=kazuo@irixnet.org; h=Subject:To:References:From:Cc:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=jpSM/2AEIS0N/jhDgJakDVYF3u1uF1xpGeUn1EIUemY=; b=NCJABoH9foneApakJ87pRNZE1iOYd2xChJvyPwGZ0G7Ax2LQjPcG2nlp3/mTi7DE aP+RuX1+89oKPWisI9Ax7srWnjVlgpxT3Q9dYAoJX+HZ+0fPQNyUoeI0ggEqIQ9tvkj 4zIY2pXicSzpStXIQDz0CwZA84wYXzyE9GYkuF/I= Received: from [10.8.253.173] (172.93.226.174 [172.93.226.174]) by mx.zohomail.com with SMTPS id 1598643629352125.92254530119692; Fri, 28 Aug 2020 12:40:29 -0700 (PDT) Subject: Re: Patching Mandoc for IRIX To: Ingo Schwarze References: <20200622214406.GD93760@athene.usta.de> <20200827180924.GG28751@athene.usta.de> From: Kazuo Kuroi Cc: discuss@mandoc.bsd.lv Message-ID: <2c74d173-4bbb-7837-9f6f-29441c74b8da@irixnet.org> Date: Fri, 28 Aug 2020 15:40:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 In-Reply-To: <20200827180924.GG28751@athene.usta.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ZohoMailClient: External Hi Ingo, This has gotten piled up and I've not had a chance to apply any of your fixes. 1. Libc on IRIX: We're not looking to replace libc with say GNUlibc (oh gods no) and I understand the viewpoint that you don't want to pollute the code with workarounds. What I am suggesting possibly would be to have your configure script detect IRIX either by the preprocessor macro __sgi or by uname -a output and automatically advise them to check your ports page for a proper patch or something like that. Give me some time to see what I can do. . There's literally no chance of fixing the libc unless someone comes along and writes a 100% FOSS reimplementation, which I'm sure we both know is wishful thinking. Similar to say HP-UX 11iv1 or Tru64, IRIX is 100% unsupported by its current IP holder (HP Enterprise) and hasn't received any patches since 2006, it's also not FOSS and there's thus no real option but to create a wrapper or something around it. Sure, it's an issue, and this is not the last BSD-related project I've had these issues with, I have been researching byacc, bsd awk, openrsync (From OpenBSD), openm4 (also from BSD) etc. to figure out good FOSS replacements for IRIX tools. Ironically, I don't have issues with %zu with GNU ports for the most part, and I've been developing a little code scanner to figure out how to go in and catch these issues before I try compiling so I can be on the lookout. It's not a bug; more like a lack of functionality. The trailing n, apparently, doesn't cause issues when I remove the z format specifier. I'm going to confirm that all of your %zun are for size_t, and I'll go in and double check that we've not introduced any nasty bugs in our downstream patches. The postscript functionality I've not tested, primarily because the main goal here is to avoid having to use GNU groff. 2. __sgi vs __sgi__ __sgi is different. IRIX doesn't define __sgi__ as to my knowledge. But IRIX is pretty much static at this point, so uname output and platform IDs aren't going to change. AFAIK, OpenBSD no longer supports SGI hardware, so why their other MIPS ports would define that is probably a bug unless it's using a straight port of IRIX n32/n64 ABIs as Linux MIPS does (There's so many ABI similarities other than syscalls/libc differences it's kinda uncanny). Fair point either way, but in that case what alternatives do you suggest? I think it's fair to just point us downstream if that's all you can do it. 3. Conclusions To end my message for now I want to explain that the reason people still use IRIX is because of its uniqueness and historical value. I certainly am understanding that I can't expect you to make all kinds of special accomodations for us, all the same I do appreciate your help. For me, and most of the community, Linux and BSD on SGI hardware misses the point. Without the original environment, it's just below-average underpowered hardware. if I wanted a high performance RISC system without that baggage, I'd use POWER64el. So we're kinda stuck with IRIX since it's a system of interest. For now, I'll check the latest CVS revisions, see if that solves some of the issues mentioned, and I'll do some more extensive testing just to verify if I have any more issues. Will take me a bit of time before you hear from me again! Best Regards, Kazuo On 8/27/2020 2:09 PM, Ingo Schwarze wrote: > Hi Kazuo, > > oh no, this thread got buried under other matters *again*. > This is getting really embarassing... :-( > > Kazuo Kuroi wrote on Mon, Jun 22, 2020 at 06:09:09PM -0400: > >> IRIX is not free/open source, and we do not have access >> to the IRIX libc to change the printf() implementation. > Now i'm somewhat confused - how do you diagnose and fix security > vulnerabilities in libc in that case? The system is no longer > maintained by the original vendor, right? > >> I've considered adding an external override printf() replacement >> to my library I use to improve portability (libxg) > Yes. My general philosophy is to write code according to current > standards, and if an older system lacks some function, provide > a replacement function if that can be done without undue effort. > I do not want to pollute the portable code with wrapper functions > or #ifdefs or even macro expansion. > > Unfortunately, writing a portability wrapper for printf(3) that > modifies the format string to change %zu into whatever is appropriate > for the current platform is tricky and potentially dangerous, so > maybe it is better that you manually maintain patches for that, > unless or until we have a better idea. > >> but let me quote a dev on my forums on the topic: >> >> "The "%zun" format specifier to the printf family of functions is >> problematic for us. Newer libc implementations (GNU, BSD, ...) use the >> "z" character as a length modifier to indicate the following "u" >> argument is of type size_t. IRIX libc doesn't support the "z" length >> modifier at all. So that's got to go, for starters. I'm assuming >> you're compiling as N32 code, so an unmodified "%u" should suffice since >> size_t is defined as an unsigned int in /usr/include/sys/types.h. (Use >> %lu for 64-bit code where size_t is an unsigned long instead. Which >> clearly shows why the z modifier is needed for portable code!) > So far, i see what the problem is here. > > Apart from the fact that fixing this in compat_* code would be tricky > and would be needed for few platforms (IRIX the only one known so far), > the detection is also tricky. Besically, the test_* code would have > to compare sizeof(size_t) to native types like sizeof(unsigned) > and sizeof(unsigned long) and sizeof(unsigned long long) to make > the decision. That's all somewhat ugly... > >> Also, the trailing "n" is potentially problematic. I'm not 100% sure, >> but I think the code is intended to print a size_t followed by a literal >> "n". > Correct. > >> But IRIX libc seems to be interpreting it as the "n" "conversion >> character" which requests the printf family of functions to put the >> length of the printed string into a variable. > That sounds like a very dangerous security vulnerability in IRIX > libc. The "%n" conversion specifier is supposed to cause writing > into a variable, and even that is rather risky even when implemented > and used correctly, but the literal letter "n" is absolutely not > supposed to do any such thing. Also, each conversion specification > ends with the conversion specifier letter, in this case the 'u', > so whatever follows the 'u' is no longer part of the conversion > specification but just literal text. > > You really need to get that bug fixed. I sounds extremely dangerous > and and i can think of no way to work around it. It is likely to > have dire consequences in any software you compile. > >> In this case, the trailing n didn't cause any issues. I understand for >> portability reasons you wouldn't want to change it, and that's totally >> understandable. > Indeed, printing the literal 'n' right after the number is required, > roff(7) syntax dictates that it must be there. Doing it in some > different way would cause substantial complication of the code, > and i don't think working around such a serious libc bug would be > reasonable. > >> One way you could accommodate IRIX would be to use the >> __sgi definition in configure, > I strongly dislike testing for platform IDs or version numbers in > autoconfiguration; it's fragile, never complete, and easily gets > outdated when platforms improve, which most platforms do all the > time. Besides, the OpenBSD mips64 port also defines __sgi__, so > it idenfifies the CPU architecture rather than the operating system. > I guess NetBSD is likely to do even more of that kind because NetBSD > is famous for its wide range of hardware support. > >> and then you could use perl or sed to >> change the code, or you could throw a warning out in configure regarding >> %zu in the code and we could work out a more conservative patch that >> fixes just the %zu for those who stumble upon this. This mostly affects >> the makewhatis commands, the actual mandoc binary appears to work fine. > I doubt that all else works fine without %zu. That sequence is used > for > > * reporting of configuration errors in manpath.c > * ctags(1) support for terminal output in term_tag.c > * abstract syntax tree dumping in tree.c > * PostScript and PDF generation in term_ps.c > * mdoc(7) syntax validation in mdoc_validate.c > > All that is potentially broken unless correctly patched. > >> I would think that some other platforms like older AIX, Solaris, HP-UX >> etc. may have this issue too, but I've not worked on those extensively. > F > Solaris 11 and Solaris 10 are definitely fine. Solaris 9 is now > so old that i'm not very diligent about supporting it any longer. > There was a mandoc port for AIX many years ago, and people have > occasionally done light testing on AIX in recent years, but no > such issue came up. I'm not aware that anyone ever tested on HP-UX, > that system doesn't appear to be used a lot. > >> On your question of whether or not we have ports or anything, not >> currently. > No problem, so i'll just link to these build instructions: > >> I usually, for now, keep patches and references in "Xenopatches" here: >> http://gitea.irixce.org/Raion/Xenopatches/src/branch/master/mandoc >> >> So pragmatically, once I figure out how to get it all together, you can >> link here and I'll include a build instructions file. Once Nekoware II >> is packaging tardists again, you can link back to nekoware II's homepage. > Thanks for your information about Nekoware II. > > For now, i have added links to ports.html and porthistory.html > as shown below. Speak up if you think there is a better way. > > Yours, > Ingo > > > Index: porthistory.html > =================================================================== > RCS file: /home/cvs/mandoc/www/porthistory.html,v > retrieving revision 1.52 > diff -u -r1.52 porthistory.html > --- porthistory.html 4 Mar 2020 03:19:07 -0000 1.52 > +++ porthistory.html 27 Aug 2020 17:58:28 -0000 > @@ -36,6 +36,7 @@ > illumos (2019 May 30, Michal Nowak) > Alpine Linux (2019 Aug 25) > Fedora (2019 Oct 16, David Cantrell) > + IRIX Nekoware II (2020 June 2, Kazuo Kuroi) > >
  • 1.14.4 (2018 Aug 8): > Void Linux (2018 Aug 8, Leah Neukirchen) > Index: ports.html > =================================================================== > RCS file: /home/cvs/mandoc/www/ports.html,v > retrieving revision 1.78 > diff -u -r1.78 ports.html > --- ports.html 4 Mar 2020 03:20:27 -0000 1.78 > +++ ports.html 27 Aug 2020 17:54:42 -0000 > @@ -245,6 +245,17 @@ > — > > > + IRIX > + 1.14.5 > + — > + — > + 2020 June 2 > + — > + — > + — > + — > + > + > Crux Linux > 1.14.3 > — > @@ -559,6 +569,15 @@ > >macports/mandoc > dito > — > + > + > + IRIX > + + href="http://gitea.irixce.org/Raion/Xenopatches/commits/branch/master/mandoc" > + >Xenopatches/mandoc > + work in progress > + + >Kazuo Kuroi, Nekoware II > > > Crux Linux -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv