Rudimentary IRIX support added
Hello Libressl team,
This is an attempt by my employer, Kaz Kuroi, to add IRIX support upstream to libressl. This doesn't solve all IRIX related breakage, but it greatly eases porting for others.
Let me explain my modifications:
arc4random_irix.h - IRIX doesn't support anonymous maps. We get around this using an fd to /dev/zero. Works perfectly fine. mman.h - Issue a warning instead of a #error. IRIX is closed source. It won't support anonymous mapping, likely ever. A warning to the builder is sufficient, IMHO.
getentropy_irix.c - IRIX uses yarrow for /dev/random and urandom, and the fallback hack is just there if there's not sufficient bits in urandom.
I did not try to patch automake. Please also note, I'm submitting this code on behalf of Kaz, who doesn't use GitHub for personal reasons. If there's questions, it may take me some time to respond.
Thanks!
Patrick Maxis
@botovq
These were quick and dirty modifications, so we can fix up some commits to repair these complaints.
For one:
Is there a way to check this in CI to reduce the risk of accidental breakage?
IRIX is sgi MIPS only. No CI. But again, maintenance of patches is something that me/my employer can handle. They can't break other OSes because __sgi is only defined on IRIX -- that's the only area that preprocessing may intersect.
@botovq When you have time to review, I've resolved licensing +arc4random. If you prefer for us to not modify mman.h at all... the alternative is that we find every preprocessor inclusion in the code and ifdef IRIX away from it... which for obvious reasons will probably end up messier.
I will discuss and figure out a better fallback per your request for getentropy.
@botovq Closer hopefully? We will use memset in our downstream port regardless if your standards prefer bzero() -- the bsd bzero in IRIX has problems and loves to break weirdly.
This doesn't fix all build issues with IRIX (we are forced to change all %zu to %u...) but this would suffice for us to track and test against your releases.
We will use memset in our downstream port regardless if your standards prefer bzero() -- the bsd bzero in IRIX has problems and loves to break weirdly.
This isn't about the old bzero() vs memset() dispute, but rather about explicit_bzero(), which is provided in the compat code from our libc. The point of this is that the memset() will likely be optimized away by the compiler since it is at the end of the function, but we want to make sure that the secret randomness is cleared.
change all %zu to %u
That's unfortunate, but I don't think there is a way we can help with that.
I will endeavor to review the new fallback in the next couple of days.
This isn't about the old
bzero()vsmemset()dispute, but rather aboutexplicit_bzero(), which is provided in the compat code from our libc. The point of this is that thememset()will likely be optimized away by the compiler since it is at the end of the function, but we want to make sure that the secret randomness is cleared.
With that in mind I will fix the function to use explicit_bzero() then.
Any updates?