On Wed, 2016-10-19 at 07:26 -0300, Arnaldo Carvalho de Melo wrote: > > But self profiling JITs would be useful for non-developers, on Android > (anywhere, really), and for that it would require being able to at > least, well, self profile, using sys_perf_event_open() by a normal > process, limited to profiling itself, no? > > This not being possible, self profiling will use some other means, its > like sys_perf_event_open() never existed for them. > > - Arnaldo It would defeat the purpose of the security feature if it was exposed to apps on Android. There are other ways for Chromium (including WebView) and the ART JIT to profile. AFAIK, they've never actually considered using perf for their JIT profiling. It wasn't something that anyone cared about when this was implemented. Chromium would *certainly* never use perf for this. They use a much tighter sandbox than the Android app sandbox. It doesn't have system calls like open(), let alone perf events. Their seccomp-bpf usage is to reduce kernel attack surface, since it has proven to be the easiest way out of a sandbox. They don't even allow futex() without filtering based on the parameters anymore. That proved to be a major issue. The only case where untrusted apps declaring the privileges they need actually works out is when the privileges are high-level controls over access to a user's personal information. That way, they can be exposed to the user with the ability to reject access when it's first needed or toggle it off later. The strength of the app sandbox isn't something that end users can be responsible for. Permissions also don't work if apps bypass them with local privilege escalation vulnerabilities. Even for the base system, no perf access is better than having it used anywhere. The difference is only that the base system can actually be trusted to declare what it needs, but those components can be exploited so it's still best if they are trusted as little as possible at runtime. I could see Android completely removing unprivileged access down the road too, not as a form of access control (apps already run as unique uid/gid pairs, etc.) but to remove a non-trivial form of kernel attack surface. The perf API isn't being singled out here. It just happened to be the first case where a kernel API was restricted to developer usage on Android. Should expect more of this. If you want perf exposed, make it secure. Stop writing kernel code in a memory unsafe language and start using isolation. Not going to happen in all likelihood, so kernel code will be increasingly walled off instead since it's the biggest liability on the system. Fixing bugs on a case by case basis doesn't work for systems that need even basic security.
Attachment:
signature.asc
Description: This is a digitally signed message part
