From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga06.intel.com ([134.134.136.31]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fC91C-0007Vd-Tb for speck@linutronix.de; Fri, 27 Apr 2018 21:26:55 +0200 Subject: [MODERATED] Re: [PATCH v2] Linux Patch 1/1 References: <92c45587-5eb3-2421-6fc1-42e74a715e30@linux.intel.com> <20180427164743.GA14180@pd.tnic> <6e2b14fc-3bf6-071d-6ce2-e518f2c4f069@redhat.com> <20180427173221.GB14180@pd.tnic> <20180427180944.GD75137@tassilo.jf.intel.com> From: Tim Chen Message-ID: <85e5e716-bd80-30f5-d4fe-a9bf0601e6d8@linux.intel.com> Date: Fri, 27 Apr 2018 12:26:51 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="2Kogy9eGEY01Mjn73gbL8EYhX6PHur44b"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --2Kogy9eGEY01Mjn73gbL8EYhX6PHur44b Content-Type: multipart/mixed; boundary="9Es6K78nyN6NNthyoZkCKgVm1mKOMoBfp" --9Es6K78nyN6NNthyoZkCKgVm1mKOMoBfp Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/27/2018 11:30 AM, speck for Linus Torvalds wrote: >=20 >=20 > On Fri, 27 Apr 2018, speck for Thomas Gleixner wrote: >> On Fri, 27 Apr 2018, speck for Thomas Gleixner wrote: >>> >>> Sure. You set it on that sandbox thing and then the thread which is s= pawned >>> of from there can disable it. Brilliant idea. >> >> And in fact you want it even inherit on exec because then you can star= t the >> JVM or whatever you want to protect with it disabled and never have to= >> worry about it again. >=20 > I don't think that's the attack people are worried about. >=20 > Basically, for the store buffer bypass, the *only* worry is JIT'ed code= =2E=20 > I don't think people expect it to leak from supervisor to user mode, fo= r=20 > example, so it's not primarily a protection domain issue. >=20 > It's almost purely a "I generated code assuming the architecture would = > actualy execute the code I wrote" issue. >=20 > That means that it's not like you're really executing "untrusted" code = in=20 > general. Your jitted code isn't going to just run random sysctl's witho= ut=20 > any checking or anything like that. You trust your JVM to take care of = > *those* kinds of security issues. >=20 > So "user can turn it on and off as they please" is not really an issue.= In=20 > fact, it could easily be seen as a feature. Making it expensive or hard= to=20 > turn off the mitigation means that you can't necessarily just turn it o= n=20 > temporarily for the code you really care about. I'll keep the option in prctl to turn the mitigation off then till we find a strong reason to do otherwise. Tim --9Es6K78nyN6NNthyoZkCKgVm1mKOMoBfp-- --2Kogy9eGEY01Mjn73gbL8EYhX6PHur44b--