From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx2.suse.de ([195.135.220.15]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1f8Y6z-0006ls-OY for speck@linutronix.de; Tue, 17 Apr 2018 23:26:04 +0200 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 81B64AC80 for ; Tue, 17 Apr 2018 21:25:56 +0000 (UTC) Date: Tue, 17 Apr 2018 23:25:49 +0200 (CEST) From: Jiri Kosina Subject: [MODERATED] Re: GPZv4 In-Reply-To: Message-ID: References: <20180417193105.GD3890@pd.tnic> <476c3e0b-dde6-6e6b-2054-6e71fa2c396b@redhat.com> <20180417203717.GF3890@pd.tnic> <47b619bf-8d07-c465-9017-583cf5ac80ee@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, 17 Apr 2018, speck for Thomas Gleixner wrote: > The prctl is an optimization which can be done afterwards and we first > need to agree whether we want it at all. I'm not too fond of yet another > conditional branch in the entry/exit code. The code patching there is > already bad enough. If we keep up adding this crap at that rate then we > have sooner than later more NOOPs and conditionals than actual code. Plus the prctl() aproach opens a potential hole for attacks that can first trick some vulnerable binary to call prctl() (ROP, return into libc ...) on itself. -- Jiri Kosina SUSE Labs