From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga04.intel.com ([192.55.52.120]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fC7oY-0006Fl-TA for speck@linutronix.de; Fri, 27 Apr 2018 20:09:47 +0200 Date: Fri, 27 Apr 2018 11:09:44 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2] Linux Patch 1/1 Message-ID: <20180427180944.GD75137@tassilo.jf.intel.com> References: <92c45587-5eb3-2421-6fc1-42e74a715e30@linux.intel.com> <20180427164743.GA14180@pd.tnic> <6e2b14fc-3bf6-071d-6ce2-e518f2c4f069@redhat.com> <20180427173221.GB14180@pd.tnic> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Apr 27, 2018 at 07:48:03PM +0200, speck for Thomas Gleixner wrote: > On Fri, 27 Apr 2018, speck for Borislav Petkov wrote: > > > On Fri, Apr 27, 2018 at 01:13:03PM -0400, speck for Jon Masters wrote: > > > My opinion is this needs to be a prctl that a vulnerable application can > > > set. It can be a one-way thing that's set/inherited by children, etc. > > > > If the task does prctl, it *must* at least be a one-way thing because, > > as jikos said, if a malicious attacker can trick it into calling prctl() > > again to turn MD back on, the whole dance we're doing is useless. > > That's not the worst problem. The worst thing is that it's inherited on > fork and then the child can disable it again nilly-willy, which makes no > sense whatsoever. If it's set only then the child CANNOT do that. If the child can execute code it itself why shouldn't it be able to clear this bit? After all it can do everything else to itself too. It would be unsafe if it could disable it on someone else, but of course it can't do that. -Andi