Bug 915

Summary: IRIX 6.5.22 - sudo fails to compile due to MAP_ANON being undefined
Product: Sudo Reporter: Kazuo Kuroi <kazuok>
Component: SudoAssignee: Todd C. Miller <Todd.Miller>
Status: RESOLVED FIXED    
Severity: normal CC: daniel.hams, max.z.gewalt
Priority: low    
Version: 1.8.30   
Hardware: SGI   
OS: IRIX   
Attachments: IRIX-specific patch for sudo
MAP_ANON test success
MAP_SGI_ANYADDR test fail

Description Kazuo Kuroi 2020-01-27 15:49:22 MST
Created attachment 540 [details]
IRIX-specific patch for sudo

Running IRIX 6.5.22, sudo fails to compile because the IRIX mmap.h has no definitions for MAP_ANON/MAP_ANONYMOUS. 

The errors are in arc4random.h and getentropy.c, and both errors are:

cc-1020 c99: ERROR File = ./arc4random.h, Line = 90
  The identifier "MAP_ANON" is undefined.

            MAP_ANON|MAP_PRIVATE, -1, 0)) == MAP_FAILED)
            ^

I have included a patch below that uses the __sgi macro to define the flag to MAP_SGI_ANYADDR for users using IRIX, this will not work on GCC likely as __sgi is a MIPSPro-specific macro. This is not a direct MAP_ANON equivalent, but it works fine. You can read a definition here:

http://nixdoc.net/man-pages/irix/man2/man1/sgi_use_anyaddr.1.html

There's other ways of getting around this, including open an fd to /dev/zero. 

This does not break the testsuite:

parse_gids_test: 6 tests run, 0 errors, 100% success rate
strsplit_test: 29 tests run, 0 errors, 100% success rate
fnmatch: 6 tests run, 0 errors, 100% success rate
getdelim_test: 16 tests run, 0 errors, 100% success rate
/bin/ksh[27]: 41525 Abort(coredump)
strtobool_test: 14 tests run, 0 errors, 100% success rate
strtoid_test: 9 tests run, 0 errors, 100% success rate
strtomode_test: 4 tests run, 0 errors, 100% success rate
strtonum_test: 25 tests run, 0 errors, 100% success rate
hltq_test: 19 tests run, 0 errors, 100% success rate
sudo_conf/test1: OK
sudo_conf/test2: OK
sudo_conf/test3: OK
sudo_conf/test4: OK
sudo_conf/test4 (stderr): OK
sudo_conf/test5: OK
sudo_conf/test5 (stderr): OK
sudo_conf/test6: OK
sudo_conf/test7: OK
sudo_conf: 9/9 tests passed; 0/9 tests failed
sudo_parseln/test1: OK
sudo_parseln/test2: OK
sudo_parseln/test3: OK
sudo_parseln/test4: OK
sudo_parseln/test5: OK
sudo_parseln/test6: OK
sudo_parseln: 6/6 tests passed; 0/6 tests failed

ignoring the ksh coredump, that appears to be a system-level issue.
Comment 1 Todd C. Miller 2020-01-27 16:17:58 MST
Thanks, I committed a slightly different patch that just checks for MAP_SGI_ANYADDR instead of using __sgi.

https://www.sudo.ws/repos/sudo/rev/9dce3ebb2c37
Comment 2 Kazuo Kuroi 2020-01-27 16:41:01 MST
Cool, thank you for your prompt attention Todd. If there's any further IRIX-specific issues that I find or else someone else does, I'll be happy to maintain the SGI compatibility. 

:)
Comment 3 Max Gewalt 2020-01-27 18:38:30 MST
Created attachment 541 [details]
MAP_ANON test success

MAP_ANON example success
Comment 4 Max Gewalt 2020-01-27 18:38:51 MST
Created attachment 542 [details]
MAP_SGI_ANYADDR test fail

Example mmap MAP_SGI_ANYADDR fail
Comment 5 Max Gewalt 2020-01-27 18:39:07 MST
This is wrong, linked documentation in original post even shows it.

MAP_SGI_ANYADDR = Enable mmap to "locked out regions" of memory
MAP_ANON = Create zero filled memory allocation

Completely different... MAP_SGI_ANYADDR with fd of -1 also even fails in IRIX! Maybe no sudo test case coverage?

Fail MAP_SGI_ANYADDR case, success MAP_ANON case attached.

Where does MAP_SGI_ANYADDR idea even come from?
Comment 6 Kazuo Kuroi 2020-01-27 22:32:52 MST
Hi Max,

I know it's not "Correct" as it doesn't create an anonymous mapping. I mentioned that in my initial post. If you have a better way of correcting the issue, by all means be my guest. The IRIX mman.h has MAP_SGI_ANYADDR set to flag 0x1000, same as MAP_ANONYMOUS on NetBSD:

% uname -rsm
NetBSD 9.99.13 evbarm
% grep MAP_ANONYMOUS /usr/include/sys/mman.h
#define MAP_ANONYMOUS   0x1000  /* allocated from memory, swap space */

% grep 0x1000 /usr/include/sys/mman.h
#define MAP_SGI_ANYADDR 0x1000 

So pardon my transgression in trying to help. I'm not a particularly smart developer, just one whose enough of an idiot to try something.
Comment 7 Daniel Hams 2020-01-28 02:45:59 MST
Hello,

Would like to nip this in the bud before it becomes part of the sudo tree. This change

(a) Doesnt work (you can't just use MAP_SGI_ANYADDR because it matches something on FreeBSD)

(b) Can't have been tested

We've had confirmation of working approach and behaviour (and passing tests) here (patched against 1.8.29).

https://github.com/sgidevnet/sgug-rse/commit/e25f822f4cbbc677635c85279808ceac9a00b3e2

And as a side note - GCC _does_ indeed define "__sgi" on Irix too.
Comment 8 Daniel Hams 2020-01-28 05:41:32 MST
Probably important to mention too - the code I linked to isn't correct either (it's missing a mmap call) - but I'm not advocating for merging that. I think it's an unfair burden on project maintainers to look after a long gone OS.

What I _am_ advocating is that the proposed change using MAP_SGI_ANYADDR isn't merged.
Comment 9 Todd C. Miller 2020-01-28 10:09:03 MST
I've committed changes to avoid MAP_ANON where is it not supported.  There was already some code to handle this in other parts of the sudo code base.  The changes will be in the next sudo 1.8.x release.
Comment 10 Kazuo Kuroi 2020-01-28 11:55:59 MST
Much respect to both Max and Daniel here for chiming in on this.

I simply was trying to fix __something__ because not having an up to date sudo is kind of a bummer. 

The fact that this is being fixed one way or the other is a good thing. 

With regards to gcc on IRIX using __sgi, that's good to know. I mostly focus on native compiling for my own ventures, so i have little experience using GNU cc. 

Thanks to everyone involved.
Comment 11 Daniel Hams 2020-01-28 14:27:07 MST
Thanks Todd, that seems a most reasonable compromise.

@Kazuo - if it's of interest - the set of patches we use with gcc (and should work with Mipspro too) - can be found here:

https://github.com/sgidevnet/sgug-rse/tree/master/packages/sudo/SOURCES

They are against 1.8.29 but possibly can be pulled forward for your version of interest too.

Current status is good for me -> OK to close. Thanks for your time.
Comment 12 Kazuo Kuroi 2020-02-12 00:24:18 MST
Never saw this close, since I opened it, I'm marking it fixed.

Tyvm Todd, Max and Daniel