On Mon, Apr 3, 2017 at 9:27 PM, Alan Coopersmith <alan.coopersm...@oracle.com> wrote: > On 04/ 3/17 12:17 PM, Mark Kettenis wrote: >>> >>> From: Benjamin Tissoires <benjamin.tissoi...@gmail.com> >>> Date: Mon, 3 Apr 2017 17:52:32 +0200 >>> >>> On Mon, Apr 3, 2017 at 4:02 PM, Alan Coopersmith >>> <alan.coopersm...@oracle.com> wrote: >>>> >>>> On 04/ 3/17 05:52 AM, Benjamin Tissoires wrote: >>>>> >>>>> >>>>> This allows to fix CVE-2017-2625 on Linux platforms without pulling in >>>>> libbsd. >>>>> The syscall getrandom is available since kernel v3.17. The code first >>>>> tries to use the syscall on a supported kernel. If the syscall fails, >>>>> it falls back to the current (vulnerable) code. >>>>> We do not implement the glibc getrandom() call given that it's only >>>>> available in glibc 2.25, and the #if dance is already messy here. >>>>> >>>>> Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@gmail.com> >>>> >>>> >>>> >>>> This is dangerous - Solaris <sys/syscall.h> defines SYS_getrandom, but >>>> I don't know if our syscall arguments/semantics are the same, and we >>>> only support applications calling the libc getrandom() function, not the >>>> raw syscall. >> >> >> Doesn't Solaris have a proper arc4random_buf(3) in libc now though? > > > Yes - and if that was preferred over the raw syscall it would help, > but this patch looked like it always went to the syscall first, then > fell back to arc4random_buf. (The similar patch for libICE appears > to be the other way around, which is better, only making the syscall > if HAVE_ARC4RANDOM_BUF isn't defined.) > > Or did I misread it? >
Well, I guess the current #ifdef/#ifndef doesn't help, but if Solaris has arc4random_buf(3), it should only be used with this patch as well. I can also extract the same helpers than the libICE patch to clarify the situation, but the idea was indeed to first rely on arc4random_buf(3) if available. If it is not available at compile time, we would use the syscall and then fallback on the unsafe PRNG. I'll come up with a better patch. Cheers, Benjamin _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
