This is already the current implementation in CM10.1 - exynos-mem is 660 system.graphicsjust my $0.02.
Isn't this a matter of using specific usergroup for the device?
Besides the driver implementation side, instead of chmoding to 0400/0600?
I - creating a group like exynos-mem
II - chgrp exynos-mem /dev/exynos-mem
||| - chmod 0440, 0660 or 0640 to /dev/exynos-mem
|V - adding camera app user (and anyother that needs it) to exynos-mem
So you need to be running in the graphics group to use the exploit. 660 system.graphics will block the easiest routes to abuse, but it may be possible for an app with camera permissions to do the privilege escalation. Not sure.
That is why I'll be working on getting Andrei's patches integrated into the smdk4210 kernel tree tonight. I think I just need to port his mach-midas changes over to mach-u1. Also on CM, I need to port his mach-midas changes to mach-p4notepq
Andrei, can you clarify your comment about CONFIG_CMA_DMA? Are you saying the fix is neutered if that config isn't used? The way I read your post, it sounds like you're saying the fix won't work on Note2 or Note10.1 (Exynos devices with 2GB RAM)?
That's odd. 0600 should block shell users from exploiting - 660 won't as the shell user has graphics privileges.hmmm as far as I had a look on both apps from chainfire and supercurio, both set the permission for /dev/exynos-mem to c---------
edit: only supercurios app does that, chainfires app sets the permission to cr--------
anyway, both apps don't hinder executing successfully the original exploit from within an adb shell (exploit was stored on /data)