[RFC PATCH] arm64: fault: Don't leak data in ESR context for user fault on kernel VA

Dave Martin Dave.Martin at arm.com
Wed Apr 18 03:33:13 PDT 2018


On Tue, Apr 17, 2018 at 06:34:11PM +0100, Peter Maydell wrote:
> On 13 April 2018 at 15:21, Dave Martin <Dave.Martin at arm.com> wrote:
> > There are certain fault types that should never be exposed to
> > userspace, such as TLB conflict aborts, access flag faults, etc.
> > See the changes upstream between v4.16 and torvalds/master (which I had
> > temporarily forgotten about...)
> >
> > Now, __do_user_fault() is called for these cases but the signal has
> > already been mapped to SIGKILL by this point via the fault_info[]
> > table.  It doesn't matter too much what we do in such cases because
> > the user task will be killed on signal delivery and so doesn't get a
> > chance to inspect the ESR contents anyway.  It might be worth expanding
> > the WARN() to catch mismaintenance of the fault_info[] table -- but that
> > may be overkill.  Maybe adding some comments explaining the dependency
> > is sufficient.
> 
> I had a look at the code in current master, and from my reading
> of it it does not call __do_user_fault() for faults like TLB
> conflict aborts, etc. Those all have fault_info[] table entries
> that specify do_bad() as the function pointer, which just returns 1.
> It's only do_page_fault(), do_translation_fault() and do_alignment()
> fault that can get into __do_user_fault().
> 
> So I don't think there's any change that needs to be made for this
> point. Am I misunderstanding what you have in mind? If so it would
> probably be simplest if you explained the change you'd like to see.

Don't worry about this; I think you're right.  I was confusing do_bad()
with do_bad_area() in my head somewhere along the line...

> 
> (The changes in master since v4.16 do require a rebase anyway, mostly
> for textual reasons, so I'll base v2 on master unless you have a
> different branch you'd rather I based it on.)

-rc1 or master is probably fine.  Most of the dust from the merge window
ought to have settled now.

> I've made the various other changes you suggest.

Cheers
---Dave



More information about the linux-arm-kernel mailing list