Message ID | cover.1561588012.git.cedric.xing@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | security/x86/sgx: SGX specific LSM hooks | expand |
On Thu, Jun 27, 2019 at 11:56:18AM -0700, Cedric Xing wrote: I think it is fine to have these patch sets as a discussion starters but it does not make any sense to me to upstream LSM changes with the SGX foundations. This is exactly the same situation as with KVM changes. The patch set is already way too big to fit to the standards [1]. The eye should be on whether the uapi (e.g. device files, ioctl's) will work for LSM's in a legit way. Do we need more of these different flavors of experimental LSM changes or can we make some conclusions with the real issue we are trying to deal with? [1] "Do not send more than 15 patches at once to the vger mailing lists!!!" https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#select-the-recipients-for-your-patch /Jarkko
> The eye should be on whether the uapi (e.g. device files, ioctl's) will > work for LSM's in a legit way. Do we need more of these different > flavors of experimental LSM changes or can we make some conclusions with > the real issue we are trying to deal with? Anyway, sending v21 soonish. Finished it on Thu but have been waiting any internal QA feedback. If nothing pops up, I'll send it tmrw. /Jarkko
On Thu, Jul 04, 2019 at 02:22:21AM +0300, Jarkko Sakkinen wrote: > > The eye should be on whether the uapi (e.g. device files, ioctl's) will > > work for LSM's in a legit way. Do we need more of these different > > flavors of experimental LSM changes or can we make some conclusions with > > the real issue we are trying to deal with? > > Anyway, sending v21 soonish. Finished it on Thu but have been waiting > any internal QA feedback. If nothing pops up, I'll send it tmrw. Ugh, the point I forgot to add was that it contains update to SGX_IOC_ENCLAVE_ADD_PAGE that is relevant for the discussion (probably the same as Sean proposed cannot recall if I did tuning to it). /Jarkko
On 7/3/2019 4:16 PM, Jarkko Sakkinen wrote: > On Thu, Jun 27, 2019 at 11:56:18AM -0700, Cedric Xing wrote: > > I think it is fine to have these patch sets as a discussion starters but > it does not make any sense to me to upstream LSM changes with the SGX > foundations. Guess LSM is a gating factor, because otherwise SGX could be abused to make executable EPC from pages that are otherwise not allowed to be executable. Am I missing anything? > > This is exactly the same situation as with KVM changes. The patch set is > already way too big to fit to the standards [1]. > > The eye should be on whether the uapi (e.g. device files, ioctl's) will > work for LSM's in a legit way. Do we need more of these different > flavors of experimental LSM changes or can we make some conclusions with > the real issue we are trying to deal with? > > [1] "Do not send more than 15 patches at once to the vger mailing lists!!!" > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#select-the-recipients-for-your-patch > > /Jarkko >
On Fri, 2019-07-05 at 22:04 -0700, Xing, Cedric wrote: > On 7/3/2019 4:16 PM, Jarkko Sakkinen wrote: > > On Thu, Jun 27, 2019 at 11:56:18AM -0700, Cedric Xing wrote: > > > > I think it is fine to have these patch sets as a discussion starters but > > it does not make any sense to me to upstream LSM changes with the SGX > > foundations. > > Guess LSM is a gating factor, because otherwise SGX could be abused to > make executable EPC from pages that are otherwise not allowed to be > executable. Am I missing anything? No, but what was the point? LSM is always additional gating factor. Does not make a case for any of the proposed LSM changes. /Jarrko