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
