On Wed, Aug 21, 2013 at 11:43:55AM -0400, Dave Jones wrote: > On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote: > > I've been running several iterations of it for a while (== up to 10 minutes > > run time - which is normally about how long it takes to find the > rather-too- > > exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any > > page table corruption. > > awesome. Guess it was a google specific issue then. > (Or something that got fixed post 3.4)
It's been running on this run for 38 minutes so far (having put a __GFP_NOWARN stopper in that kmalloc - which I think there needs to be a better solution.) What I have noticed is during the initialisation of the fd[] array, it sometimes hangs on a futex. Killing trinity, removing all the files and restarting it seems to sort the problem out. I'm not sure what's doing that - any ideas? I couldn't find any evidence of another trinity thread doing anything with futexes. > > Were there any nonstandard platform > > specific devices in /dev which that user could access - such as graphics > > or video decoder devices which could be exposing big holes? > > I'm not sure what google patched into that kernel altogether, so who knows.. Unfortunately, it seems to be rather common if there's hardware GPU or video codecs to expose physical addresses to userspace which get passed around in closed source libraries and ultimately to GPU/video hardware. I would not be surprised if trinity was finding that and finding some way to get something to poke randomly in kernel memory. It seems also that the normal approach is to expose the device nodes in /dev to the world, effectively handing any userspace program the ability to: (a) a way to allocate from a pool of memory, and get its physical address (b) to be able to pass a physical address to hardware for DMA type operations (c) to initiate DMA on that hardware This is why closed source GPU/video stuff is Bad News(tm) for security. I'd strongly suggest keeping such platforms well away from any data anyone cares about keeping private and keeping them well isolated. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/