[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201107152758.GB29530@wind.enjellic.com>
Date: Sat, 7 Nov 2020 09:27:58 -0600
From: "Dr. Greg" <greg@...ellic.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>, x86@...nel.org,
linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
Sean Christopherson <sean.j.christopherson@...el.com>,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Jethro Beekman <jethro@...tanix.com>,
Darren Kenny <darren.kenny@...cle.com>,
andriy.shevchenko@...ux.intel.com, asapek@...gle.com, bp@...en8.de,
cedric.xing@...el.com, chenalexchen@...gle.com,
conradparker@...gle.com, cyhanish@...gle.com,
dave.hansen@...el.com, haitao.huang@...el.com, kai.huang@...el.com,
kai.svahn@...el.com, kmoy@...gle.com, ludloff@...gle.com,
luto@...nel.org, nhorman@...hat.com, npmccallum@...hat.com,
puiterwijk@...hat.com, rientjes@...gle.com, tglx@...utronix.de,
yaozhangx@...gle.com, mikko.ylinen@...el.com
Subject: Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct
On Fri, Nov 06, 2020 at 09:13:11PM +0000, Matthew Wilcox wrote:
> On Fri, Nov 06, 2020 at 11:43:59AM -0600, Dr. Greg wrote:
> > The 900 pound primate in the room, that no one is acknowledging, is
> > that this technology was designed to not allow the operating system to
> > have any control over what it is doing. In the mindset of kernel
> > developers, the operating system is the absolute authority on
> > security, so we find ourselves in a situation where the kernel needs
> > to try and work around this fact so any solutions will be imperfect at
> > best.
> >
> > As I've noted before, this is actually a primary objective of enclave
> > authors, since one of the desires for 'Confidential Computing' is to
> > hide things like proprietary algorithms from the platform owners. I
> > think the driver needs to acknowledge this fact and equip platform
> > owners with the simplest and most effective security solutions that
> > are available.
> Or we need to not merge "technology" that subverts the owner of the
> hardware. Remember: root kit authors are inventive buggers.
That will be an interesting philosophical argument for Linux moving
forward. I've often stated that there is going to be a natural
political tension between the objectives of open-source and advances
in platform security. By definition, advancing the latter will result
in technology that contrains what can be done with a platform.
It may have made more sense for the SGX driver to be mainline when the
technology was going to be ubiquitous. Given the decision by Intel to
monetize the platform, by limiting its implementation to high end
server platforms, the case could be made that it is a driver best
supported by the distributions or cloud providers.
I'm neither for or against inclusion, I'm simply advocating that we
make informed decisions on the driver implementation that benefits the
user community. FWIW, based on knowledge that has come from building
application stacks on top of the technology for a half decade now.
Have a good weekend.
Dr. Greg
As always,
Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive
Enjellic Systems Development, LLC IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND 58102
PH: 701-281-1686 EMAIL: greg@...ellic.com
------------------------------------------------------------------------------
"Atilla The Hun's Maxim: If you're going to rape, pillage and burn, be sure
to do things in that order."
-- P.J. Plauger
Programming On Purpose
Powered by blists - more mailing lists