Android sandbox: workaround for restricted errno values.

Android sandbox: workaround for restricted errno values.

On Android, errno are only supported up to 255 and are not processed
otherwise. Fix a test to work around this issue.

BUG=181647, 169416
NOTRY=true
TBR=markus

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=187410

[commit-bot: I haz the power, 2013-03-11 23:21:07]

No comments yet.

[commit-bot: I haz the power, 2013-03-11 23:24:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jln@chromium.org/12638015/16001

[commit-bot: I haz the power, 2013-03-11 23:39:22]

Change committed as 187410

[Markus (顧孟勤), 2013-03-12 00:23:05]

We should check whether we can make a direct SandboxSyscall() instead of going
through the bionic libc wrapper.

That might be a cleaner fix.

Do we have any indication that Android patched the kernel to reduce the maximum
errno value? If not, then it probably is still 4096; it's just the runtime
library that doesn't know this.

And if in doubt, I rather do what is correct for the kernel than what is correct
for a user-space layer on top of that. Following the kernel's conventions is
less likely to introduce security relevant bugs.

[jln (very slow on Chromium), 2013-03-12 00:30:57]

On 2013/03/12 00:23:05, Markus (顧孟勤) wrote:
> We should check whether we can make a direct SandboxSyscall() instead of going
> through the bionic libc wrapper.
> 
> That might be a cleaner fix.

It really depends on the intention of the test. To me the intention was: "Any
errno between the min and max value that is returned by the kernel to userland
will appear automatically in errno to userland". Indeed, we're also testing the
libc in that case, which is important and useful.

In other words: we caught an interesting bug that needs to be fixed (most likely
on Android itself, or perhaps in ErrorCode, as a workaround).

> Do we have any indication that Android patched the kernel to reduce the
maximum
> errno value? If not, then it probably is still 4096; it's just the runtime
> library that doesn't know this.

Let's discuss this on the bug (crbug.com/181647). I already asked David if we
could get this fixed in Android at some point.

> And if in doubt, I rather do what is correct for the kernel than what is
correct
> for a user-space layer on top of that. Following the kernel's conventions is
> less likely to introduce security relevant bugs.

In general yes. In this case, I don't think that further restricting it would be
bad for security.