On 06/07/2021 13:48, Alyssa Rosenzweig wrote:
My concern is if we ever find a security bug which requires new information/behaviour in the submit ABI to properly fix. In this case it would be appropriate to backport a 'feature' (bug fix) which provides a new ABI but it would need to be a small change. A flags field where we can set a "PANFROST_ACTUALLY_BE_SECURE" bit would be useful then - but we wouldn't want to start bumping version numbers in the backport.
But at least for now we could just assume we'll expand the ioctl struct if we ever hit that situation, so no need for an explicit flags field.
I'm curious if kbase ever hit something like this? It wouldn't have occurred to me as a possibility.
kbase (at least historically) didn't care about backwards compatibility - so has tended to just break the ABI if necessary.
We have had workarounds such as BASE_HW_ISSUE_8987 (with the lovely named DEFAULT_SECURE_BUT_LOSS_OF_PERFORMANCE flag) where the isolation between address spaces was broken. It might have been reasonable in that situation to have exposed a new flag which allows security sensitive applications (e.g. the on-screen keyboard) to force the more secure mode of operation (taking the performance hit) while not penalising other applications.
But it's probably just my paranoia ;) All the serious security bugs I can think of were genuine software bugs and could just be fixed.
Steve