On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote: > I'll take it, but there's unanswered review feedback (your response to the > first question), and Alan raised some doubts about the patches which I'm > not sure have been resolved. The remaining opens seem to be CAP_SYS_RAWIO and firmware signing? Ironically, disabling CAP_SYS_RAWIO disables firmware loading… The problem with CAP_SYS_RAWIO is that its semantics were never sufficiently well documented, and as a result it's a mixture of "This is incredibly dangerous" and "We replaced a check for uid 0 with whichever capability seemed to have the most appropriate name". I've gone through all the uses of CAP_SYS_RAWIO and added additional checks to the generic ones that seem appropriate. There's a couple of old drivers that use it to gate access to features that potentially allow arbitrary DMA and it might be worth cleaning those up, but the only general case I haven't modified is the ability to send arbitrary SCSI commands from userspace. My understanding is that endpoints aren't going to be able to DMA to arbitrary addresses, so that doesn't seem like a problem. On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected functionality - firmware loading and the fibmap ioctl are probably the most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks userspace expectations, so we're kind of stuck there. As for signed firmware, I'm looking forward to Kees' work on that. -- Matthew Garrett <matthew.garrett@xxxxxxxxxx> ��.n��������+%������w��{.n�����{����*jg��������ݢj����G�������j:+v���w�m������w�������h�����٥