From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas Lengyel Subject: Re: [PATCH 0/2] Xen/mem_event: Do not rely on the toolstack being bug-free Date: Fri, 18 Jul 2014 00:17:22 +0200 Message-ID: References: <1405602637-8321-1-git-send-email-andrew.cooper3@citrix.com> <97A500D504438F4ABC02EBA81613CC6331885B2C@xmb-aln-x02.cisco.com> <53C8317C.6020807@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0768144378763095395==" Return-path: In-Reply-To: <53C8317C.6020807@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Razvan Cojocaru Cc: Andrew Cooper , Xen-devel , "Aravindh Puthiyaparambil (aravindp)" List-Id: xen-devel@lists.xenproject.org --===============0768144378763095395== Content-Type: multipart/alternative; boundary=047d7bb04f0438afbb04fe6b013f --047d7bb04f0438afbb04fe6b013f Content-Type: text/plain; charset=ISO-8859-1 I've also tested the patch with LibVMI and everything works fine. The pause/unpause reference count now does take effect, so the previous issue I reported (a paused domain getting unpaused by mem_event_enable) is fixed by this patch. One question I have, what if the toolstack wants to unconditionally (force) unpause a domain? Right now with this patch if someone runs 'xl pause domain' a couple times he has no other recourse then to issue 'xl unpause domain' at least the same number of times, or to restart the entire domain. Might be user-friendlier if there was an override provided in case a domain got paused a million times by accident. Cheers, Tamas On Thu, Jul 17, 2014 at 10:26 PM, Razvan Cojocaru wrote: > On 07/17/2014 10:01 PM, Aravindh Puthiyaparambil (aravindp) wrote: > >> Xen performs insufficient validation of the contents of mem_event > responses > >>from the toolstack. As a result, a buggy toolstack could cause Xen to > walk off > >> the end of a domain's vcpu list, and get out of sync with vcpu pause > reference > >> counts. > >> > >> These two fixes are compile tested only, as I have no way to plausibly > test the > >> mem-event functionality itself. > > > > One easy way of testing is to use the tools/tests/xen-access test > program which exercises mem_access and thereby mem_event. It is fairly easy > to run. Bring up a domain and execute " xen-access write|exec". > But I understand if you are under time constraints and cannot do it. If you > Cc me on these patches, I will gladly test them for you. > > Indeed, our application is very xen-access-like (except quite a bit more > involved), and I've tested the original patches with 5 different domains > 3 times over - but it's a well-behaved citizen of the Xen ecosystem and > there were no gimmicks involved. No mem_events piled up, and there was > always just one mem_event handler per domain. > > Everything went without a hitch, but I did not try to pause the domain > while it was running or try to trick the hypervisor in any way. > > > Thanks, > Razvan Cojocaru > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > --047d7bb04f0438afbb04fe6b013f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've also tested the patch with LibVMI and e= verything works fine. The pause/unpause reference count now does take effec= t, so the previous issue I reported (a paused domain getting unpaused by me= m_event_enable) is fixed by this patch.

One question I have, what if the toolstack wants to unconditional= ly (force) unpause a domain? Right now with this patch if someone runs '= ;xl pause domain' a couple times he has no other recourse then to issue= 'xl unpause domain' at least the same number of times, or to resta= rt the entire domain. Might be user-friendlier if there was an override pro= vided in case a domain got paused a million times by accident.

Cheers,
Tamas


On Thu, Jul 17, 2014 at 10:26 PM, Razvan Cojocaru <rcojocaru@bitdefender.com> wrote:
On 07/17/2014 10:01 PM, Arav= indh Puthiyaparambil (aravindp) wrote:
>> Xen performs insufficient validation of the contents of mem_event = responses
>>from the toolstack. =A0As a result, a buggy toolstack could cause X= en to walk off
>> the end of a domain's vcpu list, and get out of sync with vcpu= pause reference
>> counts.
>>
>> These two fixes are compile tested only, as I have no way to plaus= ibly test the
>> mem-event functionality itself.
>
> One easy way of testing is to use the tools/tests/xen-access test prog= ram which exercises mem_access and thereby mem_event. It is fairly easy to = run. Bring up a domain and execute " xen-access <domain_id> writ= e|exec". But I understand if you are under time constraints and cannot= do it. If you Cc me on these patches, I will gladly test them for you.

Indeed, our application is very xen-access-like (except quite a bit m= ore
involved), and I've tested the original patches with 5 different domain= s
3 times over - but it's a well-behaved citizen of the Xen ecosystem and=
there were no gimmicks involved. No mem_events piled up, and there was
always just one mem_event handler per domain.

Everything went without a hitch, but I did not try to pause the domain
while it was running or try to trick the hypervisor in any way.


Thanks,
Razvan Cojocaru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.x= en.org/xen-devel

--047d7bb04f0438afbb04fe6b013f-- --===============0768144378763095395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0768144378763095395==--