[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a558bbf3-cdc5-e95d-3954-b6f5d769c64e@intel.com>
Date: Wed, 3 Jan 2018 21:49:33 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Dan Williams <dan.j.williams@...el.com>,
Al Viro <viro@...iv.linux.org.uk>
Cc: "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"alan@...ux.intel.com" <alan@...ux.intel.com>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
"mark.rutland@....com" <mark.rutland@....com>,
"gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"jikos@...nel.org" <jikos@...nel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier
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;
Powered by blists - more mailing lists