On Mon, Feb 19, 2024 at 03:17:24PM +0000, Srinivas Kandagatla wrote: > On 17/02/2024 19:58, Bjorn Andersson wrote: > > On Mon, Feb 05, 2024 at 07:27:58PM +0100, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > > > We've established the need for using separate secured memory pools for > > > SCM and QSEECOM > > > > Where has this need been established, what is the actual problem you're > > solving with this series? > > SHMbridge will restrict the amount of memory that TZ can see, making system > more secure. > Then tell me this in the cover letter and commit messages. > Need for having different pools makes this more scalable overall, so that > different usecases can run seamlessly. ex: loading a TA and SCM calls. > How is it more scalable to give each "client" a chunk of 256KB instead of them sharing a pool of ~4GB memory? > > > > Does SCM and QSEECOM, as it's implemented in the kernel today, not work > > satisfactory? > > > > > as well as the upcoming scminvoke driver. > > > > > > > Is smcinvoke driver upstreaming blocked by not transitioning the scm > > driver to a "secure memory pool"? > > > > Is this happening now, or do we need to merge this series when that day > > comes? > > SMCInvoke development is happening now, I see no reason for this patchset to > wait for it. > As presented, I see no reason to merge this series. > This series can go as it is for two reasons. > 1> improves system security in general > 2> Hardware Wrapped key support patches also use this which are also in good > shape and tested, ready to be merged. > Then tell me this in the cover letter and commit messages! It's not sufficient that I happen to know the answer to these questions, neither community nor maintainer should not have to guess these things. Regards, Bjorn
