[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/vm_event: fix rc check for uninitialized ring


  • To: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Fri, 24 May 2019 16:54:20 +0200
  • Autocrypt: addr=jgross@xxxxxxxx; prefer-encrypt=mutual; keydata= mQENBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAG0H0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT6JATkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPuQENBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAGJAR8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHf4kBrQQY AQgAIBYhBIUSZ3Lo9gSUpdCX97DendYovxMvBQJa3fDQAhsCAIEJELDendYovxMvdiAEGRYI AB0WIQRTLbB6QfY48x44uB6AXGG7T9hjvgUCWt3w0AAKCRCAXGG7T9hjvk2LAP99B/9FenK/ 1lfifxQmsoOrjbZtzCS6OKxPqOLHaY47BgEAqKKn36YAPpbk09d2GTVetoQJwiylx/Z9/mQI CUbQMg1pNQf9EjA1bNcMbnzJCgt0P9Q9wWCLwZa01SnQWFz8Z4HEaKldie+5bHBL5CzVBrLv 81tqX+/j95llpazzCXZW2sdNL3r8gXqrajSox7LR2rYDGdltAhQuISd2BHrbkQVEWD4hs7iV 1KQHe2uwXbKlguKPhk5ubZxqwsg/uIHw0qZDk+d0vxjTtO2JD5Jv/CeDgaBX4Emgp0NYs8IC UIyKXBtnzwiNv4cX9qKlz2Gyq9b+GdcLYZqMlIBjdCz0yJvgeb3WPNsCOanvbjelDhskx9gd 6YUUFFqgsLtrKpCNyy203a58g2WosU9k9H+LcheS37Ph2vMVTISMszW9W8gyORSgmw==
  • Cc: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 24 May 2019 14:54:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 24/05/2019 16:05, Razvan Cojocaru wrote:
> On 5/24/19 4:15 PM, Juergen Gross wrote:
>> vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
>> since commit 15e4dd5e866b43bbc ("common/vm_event: Initialize vm_event
>> lists on domain creation"), but the callers test for -ENOSYS.
>>
>> Correct the callers.
>>
>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>> ---
>>   xen/arch/x86/mm/p2m.c | 2 +-
>>   xen/common/monitor.c  | 2 +-
>>   xen/common/vm_event.c | 2 +-
>>   3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 57c5eeda91..8a9a1153a8 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1705,7 +1705,7 @@ void p2m_mem_paging_populate(struct domain *d,
>> unsigned long gfn_l)
>>         /* We're paging. There should be a ring */
>>       int rc = vm_event_claim_slot(d, d->vm_event_paging);
>> -    if ( rc == -ENOSYS )
>> +    if ( rc == -EOPNOTSUPP )
>>       {
>>           gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
>>                                "in place\n", d->domain_id, gfn_l);
>> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
>> index cb5f37fdb2..d5c9ff1cbf 100644
>> --- a/xen/common/monitor.c
>> +++ b/xen/common/monitor.c
>> @@ -98,7 +98,7 @@ int monitor_traps(struct vcpu *v, bool sync,
>> vm_event_request_t *req)
>>       {
>>       case 0:
>>           break;
>> -    case -ENOSYS:
>> +    case -EOPNOTSUPP:
>>           /*
>>            * If there was no ring to handle the event, then
>>            * simply continue executing normally.
>> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>> index 6e68be47bc..7b4ebced16 100644
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/vm_event.c
>> @@ -513,7 +513,7 @@ bool vm_event_check_ring(struct vm_event_domain *ved)
>>    * this function will always return 0 for a guest.  For a non-guest,
>> we check
>>    * for space and return -EBUSY if the ring is not available.
>>    *
>> - * Return codes: -ENOSYS: the ring is not yet configured
>> + * Return codes: -EOPNOTSUPP: the ring is not yet configured
>>    *               -EBUSY: the ring is busy
>>    *               0: a spot has been reserved
>>    *
>>
> 
> But vm_event_grab_slot() (which ends up being what vm_event_wait_slot()
> returns), still returns -ENOSYS:
> 
> 463 static int vm_event_grab_slot(struct vm_event_domain *ved, int foreign)
> 464 {
> 465     unsigned int avail_req;
> 466
> 467     if ( !ved->ring_page )
> 468         return -ENOSYS;
> 
> Although we can't get to that part if vm_event_check_ring() returns
> false, we should probably return -EOPNOTSUPP from there as well. In

Hmm, in case the page is removed while a vcpu is waiting for a slot
to become free ENOSYS should still be possible. There is, however, a
race in vm_event_grab_slot(): ved->ring_page is tested outside the
lock, so it could be zeroed just after the test occurred leading to
a "use after free" when calling vm_event_ring_available().

> fact, I wonder if any of the -ENOSYS returns in vm_event.c should not be
> replaced with return -EOPNOTSUPPs.

I believe the ones for the ring page not existing should be replaced,
while the ones for wrong hypercall sub-commands should either remain
or be replaced by EINVAL.

> Anyway, the change does clearly improve the code even without settling
> the above questions, so:
> 
> Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.