On Wed, Mar 02, 2022 at 03:11:06AM +0100, Jarkko Sakkinen wrote: > On Wed, Mar 02, 2022 at 03:05:25AM +0100, Jarkko Sakkinen wrote: > > > The work that follows this series aimed to do the integration with user > > > space policy. > > > > What do you mean by "user space policy" anyway exactly? I'm sorry but I > > just don't fully understand this. > > > > It's too big of a risk to accept this series without X taken care of. Patch > > series should neither have TODO nor TBD comments IMHO. I don't want to ack > > a series based on speculation what might happen in the future. > > If I accept this, then I'm kind of pre-acking code that I have no idea what > it looks like, can it be acked, or am I doing the right thing for the > kernel by acking this. > > It's unfortunately force majeure situation for me. I simply could not ack > this, whether I want it or not. I'd actually to leave out permission change madness completely out of this patch set, as we all know it is a grazy beast of microarchitecture. For user space having that is less critical than having executable pages. Simply with EAUG/EACCEPTCOPY you can already populate enclave with any permissions you had in mind. Augmenting alone would be logically consistent patch set that is actually usable for many workloads. Now there is half-broken augmenting (this is even writtend down to the TBD comment) and complex code for EMODPR and EMODT that is usable only for kselftests and not much else before there is fully working augmenting. This way we get actually sound patch set that is easy to review and apply to the mainline. It is also factors easier for you to iterate a smaller set of patches. After this it is so much easier to start to look at remaining functionality, and at the same time augmenting part can be stress tested with real-world code and it will mature quickly. This whole thing *really* needs a serious U-turn on how it is delivered to the upstream. Sometimes it is better just to admit that this didn't start with the right foot. BR, Jarkko
