From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier Date: Wed, 3 Jan 2018 21:49:33 -0800 Message-ID: References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> <1515035438.20588.4.camel@intel.com> <20180104044424.GC21978@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Dan Williams , Al Viro Cc: "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "tglx@linutronix.de" , "alan@linux.intel.com" , "Reshetova, Elena" , "mark.rutland@arm.com" , "gnomes@lxorguk.ukuu.org.uk" , "gregkh@linuxfoundation.org" , "jikos@kernel.org" , "linux-arch@vger.kernel.org" List-Id: linux-arch.vger.kernel.org On 01/03/2018 09:44 PM, Dan Williams wrote: > No, the concern is that an fd value >= fdt->max_fds may cause the cpu > to read arbitrary memory addresses relative to files->fdt and > userspace can observe that it got loaded. Yep, it potentially tells you someting about memory after fdt->fd[]. For instance, you might be able to observe if some random bit of memory after the actual fd[] array had 'mask' set because the CPU is running this code with a 'file' that actually fails the "fd < fdt->max_fds" check: file = __fcheck_files(files, fd); if (!file || unlikely(file->f_mode & mask)) return 0; return (unsigned long)file; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com ([192.55.52.115]:1978 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbeADFtf (ORCPT ); Thu, 4 Jan 2018 00:49:35 -0500 Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> <1515035438.20588.4.camel@intel.com> <20180104044424.GC21978@ZenIV.linux.org.uk> From: Dave Hansen Message-ID: Date: Wed, 3 Jan 2018 21:49:33 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dan Williams , Al Viro Cc: "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "tglx@linutronix.de" , "alan@linux.intel.com" , "Reshetova, Elena" , "mark.rutland@arm.com" , "gnomes@lxorguk.ukuu.org.uk" , "gregkh@linuxfoundation.org" , "jikos@kernel.org" , "linux-arch@vger.kernel.org" Message-ID: <20180104054933.jhbgRfHN0UBwzQ4wSLlA6v3RdaYCJNZSVdbXTHQ4EAQ@z> On 01/03/2018 09:44 PM, Dan Williams wrote: > No, the concern is that an fd value >= fdt->max_fds may cause the cpu > to read arbitrary memory addresses relative to files->fdt and > userspace can observe that it got loaded. Yep, it potentially tells you someting about memory after fdt->fd[]. For instance, you might be able to observe if some random bit of memory after the actual fd[] array had 'mask' set because the CPU is running this code with a 'file' that actually fails the "fd < fdt->max_fds" check: file = __fcheck_files(files, fd); if (!file || unlikely(file->f_mode & mask)) return 0; return (unsigned long)file;