Messages in this thread | | | From | Andy Lutomirski <> | Subject | Re: [PATCH] x86/smap: Fix the smap_save() asm | Date | Tue, 15 Sep 2020 16:11:03 -0700 |
| |
> On Sep 15, 2020, at 2:24 PM, Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Tue, Sep 15, 2020 at 1:56 PM Andy Lutomirski <luto@kernel.org> wrote: >> >> The old smap_save() code was: >> >> pushf >> pop %0 >> >> with %0 defined by an "=rm" constraint. This is fine if the >> compiler picked the register option, but it was incorrect with an >> %rsp-relative memory operand. > > It is incorrect because ... (I think mentioning the point about the > red zone would be good, unless there were additional concerns?)
This isn’t a red zone issue — it’s a just-plain-wrong issue. The popf is storing the result in the wrong place in memory — it’s RSP-relative, but RSP is whatever the compiler thinks it should be minus 8, because the compiler doesn’t know that pushfq changed RSP.
> > This is something we should fix. Bill, James, and I are discussing > this internally. Thank you for filing a bug; I owe you a beer just > for that.
I’m looking forward to the day that beers can be exchanged in person again :)
> >> >> Fixes: e74deb11931f ("x86/uaccess: Introduce user_access_{save,restore}()") >> Cc: stable@vger.kernel.org >> Reported-by: Bill Wendling <morbo@google.com> # I think > > LOL, yes, the comment can be dropped...though I guess someone else may > have reported the problem to Bill?
The “I think” is because I’m not sure whether Bill reported this particular issue. But I’m fine with dropping it.
| |