2018-06-13 09:59:34

by Jürgen Groß

[permalink] [raw]
Subject: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()

Using privcmd_call() for a singleton multicall seems to be wrong, as
privcmd_call() is using stac()/clac() to enable hypervisor access to
Linux user space.

Add a new xen_single_call() function to be use for that purpose.

Reported-by: Jan Beulich <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
---
arch/x86/include/asm/xen/hypercall.h | 25 +++++++++++++++++++------
arch/x86/xen/multicalls.c | 6 +++---
2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index bfd882617613..6b2f90a0b149 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -209,24 +209,37 @@ extern struct { char _entry[32]; } hypercall_page[];
})

static inline long
-privcmd_call(unsigned call,
- unsigned long a1, unsigned long a2,
- unsigned long a3, unsigned long a4,
- unsigned long a5)
+xen_single_call(unsigned int call,
+ unsigned long a1, unsigned long a2,
+ unsigned long a3, unsigned long a4,
+ unsigned long a5)
{
__HYPERCALL_DECLS;
__HYPERCALL_5ARG(a1, a2, a3, a4, a5);

- stac();
asm volatile(CALL_NOSPEC
: __HYPERCALL_5PARAM
: [thunk_target] "a" (&hypercall_page[call])
: __HYPERCALL_CLOBBER5);
- clac();

return (long)__res;
}

+static inline long
+privcmd_call(unsigned int call,
+ unsigned long a1, unsigned long a2,
+ unsigned long a3, unsigned long a4,
+ unsigned long a5)
+{
+ long res;
+
+ stac();
+ res = xen_single_call(call, a1, a2, a3, a4, a5);
+ clac();
+
+ return res;
+}
+
static inline int
HYPERVISOR_set_trap_table(struct trap_info *table)
{
diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
index dc502ca8263e..2bce7958ce8b 100644
--- a/arch/x86/xen/multicalls.c
+++ b/arch/x86/xen/multicalls.c
@@ -80,9 +80,9 @@ void xen_mc_flush(void)
and just do the call directly. */
mc = &b->entries[0];

- mc->result = privcmd_call(mc->op,
- mc->args[0], mc->args[1], mc->args[2],
- mc->args[3], mc->args[4]);
+ mc->result = xen_single_call(mc->op, mc->args[0], mc->args[1],
+ mc->args[2], mc->args[3],
+ mc->args[4]);
ret = mc->result < 0;
break;

--
2.13.7



2018-06-13 10:06:14

by Jan Beulich

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] xen: don't use privcmd_call() from xen_mc_flush()

>>> On 13.06.18 at 11:58, <[email protected]> wrote:
> Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
>
> Add a new xen_single_call() function to be use for that purpose.
>
> Reported-by: Jan Beulich <[email protected]>
> Signed-off-by: Juergen Gross <[email protected]>

Reviewed-by: Jan Beulich <[email protected]>



2018-06-13 10:21:02

by Jan Beulich

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] xen: don't use privcmd_call() from xen_mc_flush()

>>> On 13.06.18 at 12:05, <[email protected]> wrote:
>>>> On 13.06.18 at 11:58, <[email protected]> wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>>
>> Add a new xen_single_call() function to be use for that purpose.
>>
>> Reported-by: Jan Beulich <[email protected]>
>> Signed-off-by: Juergen Gross <[email protected]>
>
> Reviewed-by: Jan Beulich <[email protected]>

Actually I've only now realized that this isn't a real problem right now:
PV can't use SMAP (we don't provide a virtualized version of it), and
HVM/PVH can't use multicalls (which may have to change for PVH Dom0,
so having the change in place is helpful anyway), so the whole
in-kernel logic to collect and issue batches should be unreachable there.

But perhaps the commit message would benefit from a little bit of
re-wording.

Jan



2018-08-07 14:03:43

by Boris Ostrovsky

[permalink] [raw]
Subject: Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()

On 08/07/2018 09:11 AM, Juergen Gross wrote:
> On 13/06/18 11:58, Juergen Gross wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>>
>> Add a new xen_single_call() function to be use for that purpose.
>>
>> Reported-by: Jan Beulich <[email protected]>
>> Signed-off-by: Juergen Gross <[email protected]>
> Boris, any objections?


I think Jan wanted a change in commit message. I can commit with this:

"Using privcmd_call() for a singleton multicall seems to be wrong, as
privcmd_call() is using stac()/clac() to enable hypervisor access to
Linux user space.

Even if currently not a problem (pv domains can't use SMAP while HVM
and PVH domains can't use multicalls) things might change when
PVH dom0 support is added to the kernel."


-boris


2018-08-07 15:56:30

by Jürgen Groß

[permalink] [raw]
Subject: Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()

On 13/06/18 11:58, Juergen Gross wrote:
> Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
>
> Add a new xen_single_call() function to be use for that purpose.
>
> Reported-by: Jan Beulich <[email protected]>
> Signed-off-by: Juergen Gross <[email protected]>

Boris, any objections?


Juergen

2018-08-07 16:40:41

by Jürgen Groß

[permalink] [raw]
Subject: Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()

On 07/08/18 16:02, Boris Ostrovsky wrote:
> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>> On 13/06/18 11:58, Juergen Gross wrote:
>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>> Linux user space.
>>>
>>> Add a new xen_single_call() function to be use for that purpose.
>>>
>>> Reported-by: Jan Beulich <[email protected]>
>>> Signed-off-by: Juergen Gross <[email protected]>
>> Boris, any objections?
>
>
> I think Jan wanted a change in commit message. I can commit with this:
>
> "Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
>
> Even if currently not a problem (pv domains can't use SMAP while HVM
> and PVH domains can't use multicalls) things might change when
> PVH dom0 support is added to the kernel."

This would be fine, thanks.


Juergen

2018-08-07 16:55:03

by Boris Ostrovsky

[permalink] [raw]
Subject: Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()

On 08/07/2018 11:17 AM, Juergen Gross wrote:
> On 07/08/18 16:02, Boris Ostrovsky wrote:
>> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>>> On 13/06/18 11:58, Juergen Gross wrote:
>>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>>> Linux user space.
>>>>
>>>> Add a new xen_single_call() function to be use for that purpose.
>>>>
>>>> Reported-by: Jan Beulich <[email protected]>
>>>> Signed-off-by: Juergen Gross <[email protected]>
>>> Boris, any objections?
>>
>> I think Jan wanted a change in commit message. I can commit with this:
>>
>> "Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>>
>> Even if currently not a problem (pv domains can't use SMAP while HVM
>> and PVH domains can't use multicalls) things might change when
>> PVH dom0 support is added to the kernel."
> This would be fine, thanks.

Applied to for-linus-4.19