Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1608151058250.25028@sstabellini-ThinkPad-X260>
Date: Mon, 15 Aug 2016 11:00:16 -0700 (PDT)
From: Stefano Stabellini <sstabellini@...nel.org>
To: Julien Grall <julien.grall@....com>
cc: Catalin Marinas <catalin.marinas@....com>, 
    linux-arm-kernel@...ts.infradead.org, James Morse <james.morse@....com>, 
    Will Deacon <will.deacon@....com>, Kees Cook <keescook@...omium.org>, 
    kernel-hardening@...ts.openwall.com, 
    Stefano Stabellini <sstabellini@...nel.org>, 
    "xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>
Subject: Re: [PATCH 6/7] arm64: xen: Enable user access before a privcmd hvc
 call

On Mon, 15 Aug 2016, Julien Grall wrote:
> Hi Catalin,
> 
> I have CCed Stefano who is maintaining the Xen ARM code in Linux.
> 
> On 12/08/2016 17:27, Catalin Marinas wrote:
> > Privcmd calls are issued by the userspace. The kernel needs to enable
> > access to TTBR0_EL1 as the hypervisor would issue stage 1 translations
> > to user memory via AT instructions. Since AT instructions are not
> > affected by the PAN bit (ARMv8.1), we only need the explicit
> > uaccess_enable/disable if the TTBR0 PAN option is enabled.
> > 
> > Cc: Julien Grall <julien.grall@....com>
> > Cc: Will Deacon <will.deacon@....com>
> > Cc: James Morse <james.morse@....com>
> > Cc: Kees Cook <keescook@...omium.org>
> > Signed-off-by: Catalin Marinas <catalin.marinas@....com>
> 
> Reviewed-by: Julien Grall <julien.grall@....com>
> 
> Regards,
> 
> > ---
> >  arch/arm64/xen/hypercall.S | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> > 
> > diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> > index 329c8027b0a9..4c509f4f4dcc 100644
> > --- a/arch/arm64/xen/hypercall.S
> > +++ b/arch/arm64/xen/hypercall.S
> > @@ -91,6 +91,24 @@ ENTRY(privcmd_call)
> >  	mov x2, x3
> >  	mov x3, x4
> >  	mov x4, x5
> > +#ifdef CONFIG_ARM64_TTBR0_PAN
> > +	/*
> > +	 * Privcmd calls are issued by the userspace. The kernel needs to
> > +	 * enable access to TTBR0_EL1 as the hypervisor would issue stage 1
> > +	 * translations to user memory via AT instructions. Since AT
> > +	 * instructions are not affected by the PAN bit (ARMv8.1), we only
> > +	 * need the explicit uaccess_enable/disable if the TTBR0 PAN option is
> > +	 * enabled.

That's a pity but it is how it is.

Acked-by: Stefano Stabellini <sstabellini@...nel.org>

Given that the patch is part of your PAN series, I expect that it is
going to go via your tree.


> > +	uaccess_enable x6, x7, x8
> > +#endif
> >  	hvc XEN_IMM
> > +
> > +#ifdef CONFIG_ARM64_TTBR0_PAN
> > +	/*
> > +	 * Disable userspace access from kernel once the hyp call completed.
> > +	 */
> > +	uaccess_disable x6
> > +#endif
> >  	ret
> >  ENDPROC(privcmd_call);
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@...ts.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 
> -- 
> Julien Grall
> 

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.