From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758254AbcCCRV7 (ORCPT ); Thu, 3 Mar 2016 12:21:59 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:50904 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756627AbcCCRV6 (ORCPT ); Thu, 3 Mar 2016 12:21:58 -0500 Date: Thu, 3 Mar 2016 17:21:01 +0000 From: One Thousand Gnomes To: Marty McFadden Cc: ak@linux.intel.com, andriy.shevchenko@linux.intel.com, bp@alien8.de, bp@suse.de, brgerst@gmail.com, dan.j.williams@intel.com, dyoung@redhat.com, hpa@zytor.com, linux@horizon.com, linux-kernel@vger.kernel.org, luto@kernel.org, mingo@redhat.com, pavel@ucw.cz, tglx@linutronix.de, viro@zeniv.linux.org.uk, x86@kernel.org, yu.c.chen@intel.com Subject: Re: [PATCH 4/4] MSR: msr Batch processing feature Message-ID: <20160303172101.7e288aef@lxorguk.ukuu.org.uk> In-Reply-To: <1456444979-224547-5-git-send-email-mcfadden8@llnl.gov> References: <1456444979-224547-1-git-send-email-mcfadden8@llnl.gov> <1456444979-224547-5-git-send-email-mcfadden8@llnl.gov> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > + myinfo->rawio_allowed = capable(CAP_SYS_RAWIO); > + file->private_data = myinfo; That strikes me as a very bad idea btw. If your opener was privileged and leaks the handle via exec or anything else to another process that process inherits the powers which means it can own the system trivially. (Texbook example was the early 4BSD socket bug where any root created socket could be used to reconfigure networking which meant rsh could be used to do wonderful things. Then faithfully duplicated in Solaris 2.x *after* BSD fixed it ;) ) > +static long msrbatch_ioctl(struct file *f, unsigned int ioc, unsigned long arg) > +{ > + int err = 0; > + struct msr_batch_array __user *uoa; > + struct msr_batch_op __user *uops; > + struct msr_batch_array koa; > + struct msrbatch_session_info *myinfo = f->private_data; > + > + if (ioc != X86_IOC_MSR_BATCH) { > + pr_err("Invalid ioctl op %u\n", ioc); So a user can fill your log because you have lots of pr_err() calls etc > + err = msrbatch_apply_whitelist(&koa, myinfo); Two threads doing this at once will break if they issue overlapping requests with and/or (plus whatever carnage if you clash with any other kernel used MSR) Alan