Hi On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > On 09/10/2015 10:56 AM, Daniel Vetter wrote: >> That's not different from the compositor just freezing instead of >> crashing: Screen contents stays on and nothing happens. Imo this really is >> all just broken userspace, and the kernel can't make sure userspace >> doesn't randomly fall over. >> >> What we need to make sure is that assuming things work ok-ish there's no >> observed regression. And I still think that's the case here. > > > I would disagree on the no regressions when things work okay-ish principle, > there should be no regressions in the pessimistic scenario when security is > concerned. > > If we can agree the stuck frame on screen is not desirable from the security > point of view, then this change does enlarge the attack surface. > > Because, apart from freezing the compositor, it now also works to crash it > and prevent restart. Maybe it is far fetched, but as I said, attackers have > much better imagination with these things. I'd much more prefer a FB flag that forces a modeset on ID removal. Anyone who cares for it can set it, and the kernel will make sure to never keep such FBs around. However, for most use-cases, we want the FB to stay around after close() or FB removal. Btw., I also don't see the attack scenario at all. If an attacker makes your compositor crash at the same moment a security-relevant information is shown on screen, then the information is already visible. Who cares that it stays visible? Sure, I can make up an hypothetical use-case where that matters, but I cannot think of something real. Also, if the hypothetical scenario we go for is "if the compositor crashes", then I guess there's bigger problems than the FB content. Thanks David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
