linux-kernel - Re: [PATCH] drivers/xen/evtchn.c: Check failure for evtchn_make

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5400817E.6060500@gmail.com>
Date:	Fri, 29 Aug 2014 21:34:54 +0800
From:	Chen Gang <gang.chen.5i5j@...il.com>
To:	David Vrabel <david.vrabel@...rix.com>, konrad.wilk@...cle.com,
	boris.ostrovsky@...cle.com
CC:	xen-devel@...ts.xenproject.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers/xen/evtchn.c: Check failure for evtchn_make_refcounted()



On 8/28/14 23:49, David Vrabel wrote:
> On 28/08/14 16:13, Chen Gang wrote:
>> evtchn_make_refcounted() may return failure, so need process the failure
>> case. In failure case, it need call unbind_from_irqhandler() just like
>> evtchn_unbind_from_user() has done.
>>
>> irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed,
>> so need not check it again.
>>
>> Also still need remain the closing port code, because when the failure
>> occurs, unbind_from_irqhandler() will not close port internally.
> 
> None of the evtchn_make_refcounted() failures can occur since we know we
> have a valid irq and info at the single call site.
> 

OK, thanks. I guess what you said is correct.

But only according to the code, for me, I am not quite sure about 'info'
must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not
find any related code to prove 'info' must be valid.

 - for a new irq, it will allocate 'info' for it.

 - but for an existing irq, the code assumes it may has no 'info'.
   (so several areas check 'info' whether valid, although irq is OK).

So could you give some additional related proofs for it? And if 'info'
must be always OK, can we remove all the related check about 'info'?


> I would like to see this fixed by refactoring the code to remove
> evtchn_make_refcounted() by making all irqs for event channels reference
> counted.  These no need for this refcounting to be optional.
> 

If 'info' really must always be valid, what you said sounds reasonable
to me.


Thanks
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/