Refuse a call of xenevtchn_open() with unsupported bits in flags being
set.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V11:
- new patch (Andrew Cooper)
---
 tools/libs/evtchn/core.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/libs/evtchn/core.c b/tools/libs/evtchn/core.c
index 50bae8ec0d..581a14e3df 100644
--- a/tools/libs/evtchn/core.c
+++ b/tools/libs/evtchn/core.c
@@ -13,6 +13,7 @@
  * License along with this library; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <errno.h>
 #include <unistd.h>
 #include <stdlib.h>
 
@@ -31,9 +32,16 @@ static int all_restrict_cb(Xentoolcore__Active_Handle *ah, domid_t domid)
 
 xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned int flags)
 {
-    xenevtchn_handle *xce = malloc(sizeof(*xce));
+    xenevtchn_handle *xce;
     int rc;
 
+    if ( flags )
+    {
+        errno = EINVAL;
+        return NULL;
+    }
+
+    xce = malloc(sizeof(*xce));
     if ( !xce )
         return NULL;
 
-- 
2.26.2

On 14/01/2021 15:37, Juergen Gross wrote:
> Refuse a call of xenevtchn_open() with unsupported bits in flags being
> set.
>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Possibly worth stating that this potentially going to cause problems for
callers who were already passing junk into the flags field, but this is
far cleaner than the fallout of slowly changing the meaning of said junk
slowly as we add new parameters.

~Andrew

On 14.01.21 20:24, Andrew Cooper wrote:
> On 14/01/2021 15:37, Juergen Gross wrote:
>> Refuse a call of xenevtchn_open() with unsupported bits in flags being
>> set.
>>
>> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Possibly worth stating that this potentially going to cause problems for
> callers who were already passing junk into the flags field, but this is
> far cleaner than the fallout of slowly changing the meaning of said junk
> slowly as we add new parameters.

Added the following:

This will change behavior for callers passing junk in flags today,
but those would otherwise get probably unwanted side effects when the
flags they specify today get any meaning. So checking flags is the
right thing to do.


Juergen