All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
@ 2018-12-31 17:35 Andrew Cooper
  2019-01-02 10:13 ` Roger Pau Monné
  2019-01-04 15:32 ` Jan Beulich
  0 siblings, 2 replies; 9+ messages in thread
From: Andrew Cooper @ 2018-12-31 17:35 UTC (permalink / raw)
  To: Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, Julien Grall,
	Jan Beulich, Roger Pau Monné

When the command line parsing was updated to use const strings and no longer
tokenise with NUL characters, string matches could no longer be made with
strcmp().

Unfortunately, the replacement was buggy.  strncmp(s, "opt", ss - s) matches
"o", "op" and "opt" on the command line, as ss - s may be shorter than the
passed literal.  Furthermore, parse_bool() is affected by this, so substrings
such as "d", "e" and "o" are considered valid, with the latter being ambiguous
between "on" and "off".

Introduce a new strcmp-like function for the task, which looks for exact
string matches, but declares success when the NUL of the literal matches a
comma or colon in the command line fragment.

No change to the intended parsing functionality, but fixes cases where a
partial string on the command line will inadvertently trigger options.

A few areas were more than just a trivial change:

 * fdt_add_uefi_nodes(), while not command line parsing, had the same broken
   strncmp() pattern.  As a fix, perform an explicit length check first.
 * parse_irq_vector_map_param() gained some style corrections.
 * parse_vpmu_params() was rewritten to use the normal list-of-options form,
   rather than just fixing up parse_vpmu_param() and leaving the parsing being
   hard to follow.
 * Instead of making the trivial fix of adding an explicit length check in
   parse_bool(), use the length to select which token to we search for, which
   is more efficient than the previous linear search over all possible tokens.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>

Split out of the dom0 fix series.  This needs backporting to 4.9 and later,
and to the security trees, as this bug has been backported in security fixes.

This patch is more easily reviewed with `git diff --color-words` which
highlights that it is a straight function transformation in most cases.

The psr= option is a complete pain, and unlike all similar options in Xen.
I've half a mind to rewrite it from scratch, seeing as the option isn't
enabled by default.
---
 xen/arch/arm/cpuerrata.c              |  6 +--
 xen/arch/arm/efi/efi-boot.h           |  2 +-
 xen/arch/x86/cpu/vpmu.c               | 49 ++++++++--------------
 xen/arch/x86/irq.c                    | 12 +++---
 xen/arch/x86/psr.c                    |  4 +-
 xen/arch/x86/spec_ctrl.c              |  6 +--
 xen/arch/x86/x86_64/mmconfig-shared.c |  4 +-
 xen/common/efi/boot.c                 |  4 +-
 xen/common/kernel.c                   | 77 +++++++++++++++++++++++++++++------
 xen/drivers/cpufreq/cpufreq.c         |  6 +--
 xen/drivers/passthrough/iommu.c       | 28 ++++++-------
 xen/drivers/passthrough/pci.c         |  4 +-
 xen/include/xen/lib.h                 |  7 ++++
 13 files changed, 127 insertions(+), 82 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index adf88e7..f4815ca 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -257,11 +257,11 @@ static int __init parse_spec_ctrl(const char *s)
         {
             s += 5;
 
-            if ( !strncmp(s, "force-disable", ss - s) )
+            if ( !cmdline_strcmp(s, "force-disable") )
                 ssbd_state = ARM_SSBD_FORCE_DISABLE;
-            else if ( !strncmp(s, "runtime", ss - s) )
+            else if ( !cmdline_strcmp(s, "runtime") )
                 ssbd_state = ARM_SSBD_RUNTIME;
-            else if ( !strncmp(s, "force-enable", ss - s) )
+            else if ( !cmdline_strcmp(s, "force-enable") )
                 ssbd_state = ARM_SSBD_FORCE_ENABLE;
             else
                 rc = -EINVAL;
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index ca655ff..22a86ec 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -212,7 +212,7 @@ EFI_STATUS __init fdt_add_uefi_nodes(EFI_SYSTEM_TABLE *sys_table,
             break;
 
         type = fdt_getprop(fdt, node, "device_type", &len);
-        if ( type && strncmp(type, "memory", len) == 0 )
+        if ( type && len == 6 && strncmp(type, "memory", 6) == 0 )
         {
             fdt_del_node(fdt, node);
             continue;
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 8a4f753..13da7d0 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -61,42 +61,31 @@ static unsigned vpmu_count;
 
 static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
 
-static int parse_vpmu_param(const char *s, unsigned int len)
-{
-    if ( !*s || !len )
-        return 0;
-    if ( !strncmp(s, "bts", len) )
-        vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-    else if ( !strncmp(s, "ipc", len) )
-        vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
-    else if ( !strncmp(s, "arch", len) )
-        vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
-    else
-        return 1;
-    return 0;
-}
-
 static int __init parse_vpmu_params(const char *s)
 {
-    const char *sep, *p = s;
+    const char *ss;
 
     switch ( parse_bool(s, NULL) )
     {
     case 0:
         break;
     default:
-        for ( ; ; )
-        {
-            sep = strchr(p, ',');
-            if ( sep == NULL )
-                sep = strchr(p, 0);
-            if ( parse_vpmu_param(p, sep - p) )
-                goto error;
-            if ( !*sep )
-                /* reached end of flags */
-                break;
-            p = sep + 1;
-        }
+        do {
+            ss = strchr(s, ',');
+            if ( !ss )
+                ss = strchr(s, '\0');
+
+            if ( !cmdline_strcmp(s, "bts") )
+                vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+            else if ( !cmdline_strcmp(s, "ipc") )
+                vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
+            else if ( !cmdline_strcmp(s, "arch") )
+                vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
+            else
+                return -EINVAL;
+
+            s = ss + 1;
+        } while ( *ss );
         /* fall through */
     case 1:
         /* Default VPMU mode */
@@ -105,10 +94,6 @@ static int __init parse_vpmu_params(const char *s)
         break;
     }
     return 0;
-
- error:
-    printk("VPMU: unknown flags: %s - vpmu disabled!\n", s);
-    return -EINVAL;
 }
 
 void vpmu_lvtpc_update(uint32_t val)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 8b44d6c..23b4f42 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -70,12 +70,12 @@ static int __init parse_irq_vector_map_param(const char *s)
         if ( !ss )
             ss = strchr(s, '\0');
 
-        if ( !strncmp(s, "none", ss - s))
-            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_NONE;
-        else if ( !strncmp(s, "global", ss - s))
-            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_GLOBAL;
-        else if ( !strncmp(s, "per-device", ss - s))
-            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_PERDEV;
+        if ( !cmdline_strcmp(s, "none") )
+            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_NONE;
+        else if ( !cmdline_strcmp(s, "global") )
+            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_GLOBAL;
+        else if ( !cmdline_strcmp(s, "per-device") )
+            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_PERDEV;
         else
             rc = -EINVAL;
 
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 0ba8ef8..5866a26 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -591,13 +591,13 @@ static int __init parse_psr_param(const char *s)
         if ( val_delim > ss )
             val_delim = ss;
 
-        if ( *val_delim && !strncmp(s, "rmid_max", val_delim - s) )
+        if ( *val_delim && !cmdline_strcmp(s, "rmid_max") )
         {
             opt_rmid_max = simple_strtoul(val_delim + 1, &q, 0);
             if ( *q && *q != ',' )
                 rc = -EINVAL;
         }
-        else if ( *val_delim && !strncmp(s, "cos_max", val_delim - s) )
+        else if ( *val_delim && !cmdline_strcmp(s, "cos_max") )
         {
             opt_cos_max = simple_strtoul(val_delim + 1, &q, 0);
             if ( *q && *q != ',' )
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index a36bcef..ad72ecd 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -138,11 +138,11 @@ static int __init parse_spec_ctrl(const char *s)
         {
             s += 10;
 
-            if ( !strncmp(s, "retpoline", ss - s) )
+            if ( !cmdline_strcmp(s, "retpoline") )
                 opt_thunk = THUNK_RETPOLINE;
-            else if ( !strncmp(s, "lfence", ss - s) )
+            else if ( !cmdline_strcmp(s, "lfence") )
                 opt_thunk = THUNK_LFENCE;
-            else if ( !strncmp(s, "jmp", ss - s) )
+            else if ( !cmdline_strcmp(s, "jmp") )
                 opt_thunk = THUNK_JMP;
             else
                 rc = -EINVAL;
diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c b/xen/arch/x86/x86_64/mmconfig-shared.c
index 8675dbd..9e1c81d 100644
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -46,8 +46,8 @@ static int __init parse_mmcfg(const char *s)
         case 1:
             break;
         default:
-            if ( !strncmp(s, "amd_fam10", ss - s) ||
-                 !strncmp(s, "amd-fam10", ss - s) )
+            if ( !cmdline_strcmp(s, "amd_fam10") ||
+                 !cmdline_strcmp(s, "amd-fam10") )
                 pci_probe |= PCI_CHECK_ENABLE_AMD_MMCONF;
             else
                 rc = -EINVAL;
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 2ed5403..1e1a551 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1401,14 +1401,14 @@ static int __init parse_efi_param(const char *s)
         if ( !ss )
             ss = strchr(s, '\0');
 
-        if ( !strncmp(s, "rs", ss - s) )
+        if ( !cmdline_strcmp(s, "rs") )
         {
             if ( val )
                 __set_bit(EFI_RS, &efi_flags);
             else
                 __clear_bit(EFI_RS, &efi_flags);
         }
-        else if ( !strncmp(s, "attr=uc", ss - s) )
+        else if ( !cmdline_strcmp(s, "attr=uc") )
             efi_map_uc = val;
         else
             rc = -EINVAL;
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 5766a0f..b313af1 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -227,19 +227,49 @@ int parse_bool(const char *s, const char *e)
     if ( !len )
         return -1;
 
-    if ( !strncmp("no", s, len) ||
-         !strncmp("off", s, len) ||
-         !strncmp("false", s, len) ||
-         !strncmp("disable", s, len) ||
-         !strncmp("0", s, len) )
-        return 0;
+    switch ( len )
+    {
+    case 1:
+        if ( *s == '1' )
+            return 1;
+        else if ( *s == '0' )
+            return 0;
+        break;
 
-    if ( !strncmp("yes", s, len) ||
-         !strncmp("on", s, len) ||
-         !strncmp("true", s, len) ||
-         !strncmp("enable", s, len) ||
-         !strncmp("1", s, len) )
-        return 1;
+    case 2:
+        if ( !strncmp("on", s, 2) )
+            return 1;
+        else if ( strncmp("no", s, 2) )
+            return 0;
+        break;
+
+    case 3:
+        if ( !strncmp("yes", s, 3) )
+            return 1;
+        else if ( !strncmp("off", s, 3) )
+            return 0;
+        break;
+
+    case 4:
+        if ( !strncmp("true", s, 4) )
+            return 1;
+        break;
+
+    case 5:
+        if ( !strncmp("false", s, 5) )
+            return 0;
+        break;
+
+    case 6:
+        if ( !strncmp("enable", s, 6) )
+            return 1;
+        break;
+
+    case 7:
+        if ( !strncmp("disable", s, 7) )
+            return 0;
+        break;
+    }
 
     return -1;
 }
@@ -271,6 +301,29 @@ int parse_boolean(const char *name, const char *s, const char *e)
     return -1;
 }
 
+int cmdline_strcmp(const char *frag, const char *name)
+{
+    while ( 1 )
+    {
+        int res = (*frag - *name);
+
+        if ( res || *name == '\0' )
+        {
+            /*
+             * NUL in 'name' matching a comma or colon in 'frag' implies
+             * success.
+             */
+            if ( *name == '\0' && (*frag == ',' || *frag == ':') )
+                res = 0;
+
+            return res;
+        }
+
+        frag++;
+        name++;
+    }
+}
+
 unsigned int tainted;
 
 /**
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 4d6badc..ba9897a 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -73,7 +73,7 @@ static int __init setup_cpufreq_option(const char *str)
         arg = strchr(str, '\0');
     choice = parse_bool(str, arg);
 
-    if ( choice < 0 && !strncmp(str, "dom0-kernel", arg - str) )
+    if ( choice < 0 && !cmdline_strcmp(str, "dom0-kernel") )
     {
         xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
         cpufreq_controller = FREQCTL_dom0_kernel;
@@ -81,14 +81,14 @@ static int __init setup_cpufreq_option(const char *str)
         return 0;
     }
 
-    if ( choice == 0 || !strncmp(str, "none", arg - str) )
+    if ( choice == 0 || !cmdline_strcmp(str, "none") )
     {
         xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
         cpufreq_controller = FREQCTL_none;
         return 0;
     }
 
-    if ( choice > 0 || !strncmp(str, "xen", arg - str) )
+    if ( choice > 0 || !cmdline_strcmp(str, "xen") )
     {
         xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
         cpufreq_controller = FREQCTL_xen;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index ac62d7f..c27eee2 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -98,36 +98,36 @@ static int __init parse_iommu_param(const char *s)
         b = parse_bool(s, ss);
         if ( b >= 0 )
             iommu_enable = b;
-        else if ( !strncmp(s, "force", ss - s) ||
-                  !strncmp(s, "required", ss - s) )
+        else if ( !cmdline_strcmp(s, "force") ||
+                  !cmdline_strcmp(s, "required") )
             force_iommu = val;
-        else if ( !strncmp(s, "workaround_bios_bug", ss - s) )
+        else if ( !cmdline_strcmp(s, "workaround_bios_bug") )
             iommu_workaround_bios_bug = val;
-        else if ( !strncmp(s, "igfx", ss - s) )
+        else if ( !cmdline_strcmp(s, "igfx") )
             iommu_igfx = val;
-        else if ( !strncmp(s, "verbose", ss - s) )
+        else if ( !cmdline_strcmp(s, "verbose") )
             iommu_verbose = val;
-        else if ( !strncmp(s, "snoop", ss - s) )
+        else if ( !cmdline_strcmp(s, "snoop") )
             iommu_snoop = val;
-        else if ( !strncmp(s, "qinval", ss - s) )
+        else if ( !cmdline_strcmp(s, "qinval") )
             iommu_qinval = val;
-        else if ( !strncmp(s, "intremap", ss - s) )
+        else if ( !cmdline_strcmp(s, "intremap") )
             iommu_intremap = val;
-        else if ( !strncmp(s, "intpost", ss - s) )
+        else if ( !cmdline_strcmp(s, "intpost") )
             iommu_intpost = val;
-        else if ( !strncmp(s, "debug", ss - s) )
+        else if ( !cmdline_strcmp(s, "debug") )
         {
             iommu_debug = val;
             if ( val )
                 iommu_verbose = 1;
         }
-        else if ( !strncmp(s, "amd-iommu-perdev-intremap", ss - s) )
+        else if ( !cmdline_strcmp(s, "amd-iommu-perdev-intremap") )
             amd_iommu_perdev_intremap = val;
-        else if ( !strncmp(s, "dom0-passthrough", ss - s) )
+        else if ( !cmdline_strcmp(s, "dom0-passthrough") )
             iommu_hwdom_passthrough = val;
-        else if ( !strncmp(s, "dom0-strict", ss - s) )
+        else if ( !cmdline_strcmp(s, "dom0-strict") )
             iommu_hwdom_strict = val;
-        else if ( !strncmp(s, "sharept", ss - s) )
+        else if ( !cmdline_strcmp(s, "sharept") )
             iommu_hap_pt_share = val;
         else
             rc = -EINVAL;
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1277ce2..93c20b9 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -213,12 +213,12 @@ static int __init parse_pci_param(const char *s)
         if ( !ss )
             ss = strchr(s, '\0');
 
-        if ( !strncmp(s, "serr", ss - s) )
+        if ( !cmdline_strcmp(s, "serr") )
         {
             cmd_mask = PCI_COMMAND_SERR;
             brctl_mask = PCI_BRIDGE_CTL_SERR | PCI_BRIDGE_CTL_DTMR_SERR;
         }
-        else if ( !strncmp(s, "perr", ss - s) )
+        else if ( !cmdline_strcmp(s, "perr") )
         {
             cmd_mask = PCI_COMMAND_PARITY;
             brctl_mask = PCI_BRIDGE_CTL_PARITY;
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 972fc84..e0a4745 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -79,6 +79,13 @@ int parse_bool(const char *s, const char *e);
  */
 int parse_boolean(const char *name, const char *s, const char *e);
 
+/**
+ * Very similar to strcmp(), but will declare a match if the NUL in 'name'
+ * lines up with comma or colon in 'frag'.  Designed for picking exact string
+ * matches out of a delimited command line list.
+ */
+int cmdline_strcmp(const char *frag, const char *name);
+
 /*#define DEBUG_TRACE_DUMP*/
 #ifdef DEBUG_TRACE_DUMP
 extern void debugtrace_dump(void);
-- 
2.1.4


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

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2018-12-31 17:35 [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct Andrew Cooper
@ 2019-01-02 10:13 ` Roger Pau Monné
  2019-01-02 12:18   ` Andrew Cooper
  2019-01-04 15:32 ` Jan Beulich
  1 sibling, 1 reply; 9+ messages in thread
From: Roger Pau Monné @ 2019-01-02 10:13 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Jan Beulich, Xen-devel

On Mon, Dec 31, 2018 at 05:35:21PM +0000, Andrew Cooper wrote:
> When the command line parsing was updated to use const strings and no longer
> tokenise with NUL characters, string matches could no longer be made with
> strcmp().
> 
> Unfortunately, the replacement was buggy.  strncmp(s, "opt", ss - s) matches
> "o", "op" and "opt" on the command line, as ss - s may be shorter than the
> passed literal.  Furthermore, parse_bool() is affected by this, so substrings
> such as "d", "e" and "o" are considered valid, with the latter being ambiguous
> between "on" and "off".
> 
> Introduce a new strcmp-like function for the task, which looks for exact
> string matches, but declares success when the NUL of the literal matches a
> comma or colon in the command line fragment.
> 
> No change to the intended parsing functionality, but fixes cases where a
> partial string on the command line will inadvertently trigger options.
> 
> A few areas were more than just a trivial change:
> 
>  * fdt_add_uefi_nodes(), while not command line parsing, had the same broken
>    strncmp() pattern.  As a fix, perform an explicit length check first.
>  * parse_irq_vector_map_param() gained some style corrections.
>  * parse_vpmu_params() was rewritten to use the normal list-of-options form,
>    rather than just fixing up parse_vpmu_param() and leaving the parsing being
>    hard to follow.
>  * Instead of making the trivial fix of adding an explicit length check in
>    parse_bool(), use the length to select which token to we search for, which
>    is more efficient than the previous linear search over all possible tokens.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien.grall@arm.com>
> 
> Split out of the dom0 fix series.  This needs backporting to 4.9 and later,
> and to the security trees, as this bug has been backported in security fixes.
> 
> This patch is more easily reviewed with `git diff --color-words` which
> highlights that it is a straight function transformation in most cases.
> 
> The psr= option is a complete pain, and unlike all similar options in Xen.
> I've half a mind to rewrite it from scratch, seeing as the option isn't
> enabled by default.
> ---
> +int cmdline_strcmp(const char *frag, const char *name)
> +{
> +    while ( 1 )
> +    {
> +        int res = (*frag - *name);
> +
> +        if ( res || *name == '\0' )
> +        {
> +            /*
> +             * NUL in 'name' matching a comma or colon in 'frag' implies
> +             * success.
> +             */
> +            if ( *name == '\0' && (*frag == ',' || *frag == ':') )
> +                res = 0;
> +
> +            return res;
> +        }
> +
> +        frag++;
> +        name++;
> +    }
> +}

The previous function would get the max length of the frag argument,
which I think was useful. If the length of name > frag you could end
up accessing an unmapped address AFAICT. Or at least *frag == '\0'
should also be taken into account if it's guaranteed that frag must
always have an ending NUL.

I would also consider adding __attribute__ ((format_arg (2))); to the
prototype, so that the name argument is always checked to be a
literal, as is the current usage.

Thanks, Roger.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2019-01-02 10:13 ` Roger Pau Monné
@ 2019-01-02 12:18   ` Andrew Cooper
  2019-01-02 12:25     ` Roger Pau Monné
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2019-01-02 12:18 UTC (permalink / raw)
  To: Roger Pau Monné
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Jan Beulich, Xen-devel

On 02/01/2019 10:13, Roger Pau Monné wrote:
> On Mon, Dec 31, 2018 at 05:35:21PM +0000, Andrew Cooper wrote:
>> When the command line parsing was updated to use const strings and no longer
>> tokenise with NUL characters, string matches could no longer be made with
>> strcmp().
>>
>> Unfortunately, the replacement was buggy.  strncmp(s, "opt", ss - s) matches
>> "o", "op" and "opt" on the command line, as ss - s may be shorter than the
>> passed literal.  Furthermore, parse_bool() is affected by this, so substrings
>> such as "d", "e" and "o" are considered valid, with the latter being ambiguous
>> between "on" and "off".
>>
>> Introduce a new strcmp-like function for the task, which looks for exact
>> string matches, but declares success when the NUL of the literal matches a
>> comma or colon in the command line fragment.
>>
>> No change to the intended parsing functionality, but fixes cases where a
>> partial string on the command line will inadvertently trigger options.
>>
>> A few areas were more than just a trivial change:
>>
>>  * fdt_add_uefi_nodes(), while not command line parsing, had the same broken
>>    strncmp() pattern.  As a fix, perform an explicit length check first.
>>  * parse_irq_vector_map_param() gained some style corrections.
>>  * parse_vpmu_params() was rewritten to use the normal list-of-options form,
>>    rather than just fixing up parse_vpmu_param() and leaving the parsing being
>>    hard to follow.
>>  * Instead of making the trivial fix of adding an explicit length check in
>>    parse_bool(), use the length to select which token to we search for, which
>>    is more efficient than the previous linear search over all possible tokens.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Julien Grall <julien.grall@arm.com>
>>
>> Split out of the dom0 fix series.  This needs backporting to 4.9 and later,
>> and to the security trees, as this bug has been backported in security fixes.
>>
>> This patch is more easily reviewed with `git diff --color-words` which
>> highlights that it is a straight function transformation in most cases.
>>
>> The psr= option is a complete pain, and unlike all similar options in Xen.
>> I've half a mind to rewrite it from scratch, seeing as the option isn't
>> enabled by default.
>> ---
>> +int cmdline_strcmp(const char *frag, const char *name)
>> +{
>> +    while ( 1 )
>> +    {
>> +        int res = (*frag - *name);
>> +
>> +        if ( res || *name == '\0' )
>> +        {
>> +            /*
>> +             * NUL in 'name' matching a comma or colon in 'frag' implies
>> +             * success.
>> +             */
>> +            if ( *name == '\0' && (*frag == ',' || *frag == ':') )
>> +                res = 0;
>> +
>> +            return res;
>> +        }
>> +
>> +        frag++;
>> +        name++;
>> +    }
>> +}
> The previous function would get the max length of the frag argument,
> which I think was useful. If the length of name > frag you could end
> up accessing an unmapped address AFAICT. Or at least *frag == '\0'
> should also be taken into account if it's guaranteed that frag must
> always have an ending NUL.

It is completely unreasonable to pass a non-terminated string into
string parsing functions, and a lot of the parsing code will explode if
this expectation is violated.

Remember that before the const parsing was introduced (4.9 iirc), all
parsing went without a max length, and resolving that is part of the bugfix.

> I would also consider adding __attribute__ ((format_arg (2))); to the
> prototype, so that the name argument is always checked to be a
> literal, as is the current usage.

That would falsely prohibit looking for a string with a literal % in it.

Furthermore, see "[PATCH 3/9] x86/cpuid: Extend the cpuid= command line
option to support all named features" which was the origin of this
function, and a usecase where it definitely won't have a string literal.

~Andrew

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2019-01-02 12:18   ` Andrew Cooper
@ 2019-01-02 12:25     ` Roger Pau Monné
  2019-01-02 12:28       ` Andrew Cooper
  0 siblings, 1 reply; 9+ messages in thread
From: Roger Pau Monné @ 2019-01-02 12:25 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Jan Beulich, Xen-devel

On Wed, Jan 02, 2019 at 12:18:27PM +0000, Andrew Cooper wrote:
> On 02/01/2019 10:13, Roger Pau Monné wrote:
> > On Mon, Dec 31, 2018 at 05:35:21PM +0000, Andrew Cooper wrote:
> >> When the command line parsing was updated to use const strings and no longer
> >> tokenise with NUL characters, string matches could no longer be made with
> >> strcmp().
> >>
> >> Unfortunately, the replacement was buggy.  strncmp(s, "opt", ss - s) matches
> >> "o", "op" and "opt" on the command line, as ss - s may be shorter than the
> >> passed literal.  Furthermore, parse_bool() is affected by this, so substrings
> >> such as "d", "e" and "o" are considered valid, with the latter being ambiguous
> >> between "on" and "off".
> >>
> >> Introduce a new strcmp-like function for the task, which looks for exact
> >> string matches, but declares success when the NUL of the literal matches a
> >> comma or colon in the command line fragment.
> >>
> >> No change to the intended parsing functionality, but fixes cases where a
> >> partial string on the command line will inadvertently trigger options.
> >>
> >> A few areas were more than just a trivial change:
> >>
> >>  * fdt_add_uefi_nodes(), while not command line parsing, had the same broken
> >>    strncmp() pattern.  As a fix, perform an explicit length check first.
> >>  * parse_irq_vector_map_param() gained some style corrections.
> >>  * parse_vpmu_params() was rewritten to use the normal list-of-options form,
> >>    rather than just fixing up parse_vpmu_param() and leaving the parsing being
> >>    hard to follow.
> >>  * Instead of making the trivial fix of adding an explicit length check in
> >>    parse_bool(), use the length to select which token to we search for, which
> >>    is more efficient than the previous linear search over all possible tokens.
> >>
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> ---
> >> CC: Jan Beulich <JBeulich@suse.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Roger Pau Monné <roger.pau@citrix.com>
> >> CC: Stefano Stabellini <sstabellini@kernel.org>
> >> CC: Julien Grall <julien.grall@arm.com>
> >>
> >> Split out of the dom0 fix series.  This needs backporting to 4.9 and later,
> >> and to the security trees, as this bug has been backported in security fixes.
> >>
> >> This patch is more easily reviewed with `git diff --color-words` which
> >> highlights that it is a straight function transformation in most cases.
> >>
> >> The psr= option is a complete pain, and unlike all similar options in Xen.
> >> I've half a mind to rewrite it from scratch, seeing as the option isn't
> >> enabled by default.
> >> ---
> >> +int cmdline_strcmp(const char *frag, const char *name)
> >> +{
> >> +    while ( 1 )
> >> +    {
> >> +        int res = (*frag - *name);
> >> +
> >> +        if ( res || *name == '\0' )
> >> +        {
> >> +            /*
> >> +             * NUL in 'name' matching a comma or colon in 'frag' implies
> >> +             * success.
> >> +             */
> >> +            if ( *name == '\0' && (*frag == ',' || *frag == ':') )
> >> +                res = 0;
> >> +
> >> +            return res;
> >> +        }
> >> +
> >> +        frag++;
> >> +        name++;
> >> +    }
> >> +}
> > The previous function would get the max length of the frag argument,
> > which I think was useful. If the length of name > frag you could end
> > up accessing an unmapped address AFAICT. Or at least *frag == '\0'
> > should also be taken into account if it's guaranteed that frag must
> > always have an ending NUL.
> 
> It is completely unreasonable to pass a non-terminated string into
> string parsing functions, and a lot of the parsing code will explode if
> this expectation is violated.
> 
> Remember that before the const parsing was introduced (4.9 iirc), all
> parsing went without a max length, and resolving that is part of the bugfix.

But shouldn't you check for *frag == NUL in order to avoid overruns?

> > I would also consider adding __attribute__ ((format_arg (2))); to the
> > prototype, so that the name argument is always checked to be a
> > literal, as is the current usage.
> 
> That would falsely prohibit looking for a string with a literal % in it.
> 
> Furthermore, see "[PATCH 3/9] x86/cpuid: Extend the cpuid= command line
> option to support all named features" which was the origin of this
> function, and a usecase where it definitely won't have a string literal.

Oh, didn't know about this case. If the plan is to use it without
literals then the comment is moot.

Thanks, Roger.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2019-01-02 12:25     ` Roger Pau Monné
@ 2019-01-02 12:28       ` Andrew Cooper
  0 siblings, 0 replies; 9+ messages in thread
From: Andrew Cooper @ 2019-01-02 12:28 UTC (permalink / raw)
  To: Roger Pau Monné
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Jan Beulich, Xen-devel

On 02/01/2019 12:25, Roger Pau Monné wrote:
> On Wed, Jan 02, 2019 at 12:18:27PM +0000, Andrew Cooper wrote:
>> On 02/01/2019 10:13, Roger Pau Monné wrote:
>>> On Mon, Dec 31, 2018 at 05:35:21PM +0000, Andrew Cooper wrote:
>>>> When the command line parsing was updated to use const strings and no longer
>>>> tokenise with NUL characters, string matches could no longer be made with
>>>> strcmp().
>>>>
>>>> Unfortunately, the replacement was buggy.  strncmp(s, "opt", ss - s) matches
>>>> "o", "op" and "opt" on the command line, as ss - s may be shorter than the
>>>> passed literal.  Furthermore, parse_bool() is affected by this, so substrings
>>>> such as "d", "e" and "o" are considered valid, with the latter being ambiguous
>>>> between "on" and "off".
>>>>
>>>> Introduce a new strcmp-like function for the task, which looks for exact
>>>> string matches, but declares success when the NUL of the literal matches a
>>>> comma or colon in the command line fragment.
>>>>
>>>> No change to the intended parsing functionality, but fixes cases where a
>>>> partial string on the command line will inadvertently trigger options.
>>>>
>>>> A few areas were more than just a trivial change:
>>>>
>>>>  * fdt_add_uefi_nodes(), while not command line parsing, had the same broken
>>>>    strncmp() pattern.  As a fix, perform an explicit length check first.
>>>>  * parse_irq_vector_map_param() gained some style corrections.
>>>>  * parse_vpmu_params() was rewritten to use the normal list-of-options form,
>>>>    rather than just fixing up parse_vpmu_param() and leaving the parsing being
>>>>    hard to follow.
>>>>  * Instead of making the trivial fix of adding an explicit length check in
>>>>    parse_bool(), use the length to select which token to we search for, which
>>>>    is more efficient than the previous linear search over all possible tokens.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> ---
>>>> CC: Jan Beulich <JBeulich@suse.com>
>>>> CC: Wei Liu <wei.liu2@citrix.com>
>>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>> CC: Julien Grall <julien.grall@arm.com>
>>>>
>>>> Split out of the dom0 fix series.  This needs backporting to 4.9 and later,
>>>> and to the security trees, as this bug has been backported in security fixes.
>>>>
>>>> This patch is more easily reviewed with `git diff --color-words` which
>>>> highlights that it is a straight function transformation in most cases.
>>>>
>>>> The psr= option is a complete pain, and unlike all similar options in Xen.
>>>> I've half a mind to rewrite it from scratch, seeing as the option isn't
>>>> enabled by default.
>>>> ---
>>>> +int cmdline_strcmp(const char *frag, const char *name)
>>>> +{
>>>> +    while ( 1 )
>>>> +    {
>>>> +        int res = (*frag - *name);
>>>> +
>>>> +        if ( res || *name == '\0' )
>>>> +        {
>>>> +            /*
>>>> +             * NUL in 'name' matching a comma or colon in 'frag' implies
>>>> +             * success.
>>>> +             */
>>>> +            if ( *name == '\0' && (*frag == ',' || *frag == ':') )
>>>> +                res = 0;
>>>> +
>>>> +            return res;
>>>> +        }
>>>> +
>>>> +        frag++;
>>>> +        name++;
>>>> +    }
>>>> +}
>>> The previous function would get the max length of the frag argument,
>>> which I think was useful. If the length of name > frag you could end
>>> up accessing an unmapped address AFAICT. Or at least *frag == '\0'
>>> should also be taken into account if it's guaranteed that frag must
>>> always have an ending NUL.
>> It is completely unreasonable to pass a non-terminated string into
>> string parsing functions, and a lot of the parsing code will explode if
>> this expectation is violated.
>>
>> Remember that before the const parsing was introduced (4.9 iirc), all
>> parsing went without a max length, and resolving that is part of the bugfix.
> But shouldn't you check for *frag == NUL in order to avoid overruns?

That check is present, but I'll admit that it is a subtlety of how
strcmp() works.  A NUL in frag matching anything other than a NUL in
name will cause res to be nonzero and exit via that path.  This
particular arrangement of the function deliberately doesn't increment
the frag pointer until later in the loop.

~Andrew

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2018-12-31 17:35 [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct Andrew Cooper
  2019-01-02 10:13 ` Roger Pau Monné
@ 2019-01-04 15:32 ` Jan Beulich
  2019-01-04 15:55   ` Andrew Cooper
  1 sibling, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2019-01-04 15:32 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Xen-devel, Roger Pau Monne

>>> On 31.12.18 at 18:35, <andrew.cooper3@citrix.com> wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -61,42 +61,31 @@ static unsigned vpmu_count;
>  
>  static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>  
> -static int parse_vpmu_param(const char *s, unsigned int len)
> -{
> -    if ( !*s || !len )
> -        return 0;
> -    if ( !strncmp(s, "bts", len) )
> -        vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> -    else if ( !strncmp(s, "ipc", len) )
> -        vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
> -    else if ( !strncmp(s, "arch", len) )
> -        vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
> -    else
> -        return 1;
> -    return 0;
> -}
> -
>  static int __init parse_vpmu_params(const char *s)
>  {
> -    const char *sep, *p = s;
> +    const char *ss;
>  
>      switch ( parse_bool(s, NULL) )
>      {
>      case 0:
>          break;
>      default:
> -        for ( ; ; )
> -        {
> -            sep = strchr(p, ',');
> -            if ( sep == NULL )
> -                sep = strchr(p, 0);
> -            if ( parse_vpmu_param(p, sep - p) )
> -                goto error;
> -            if ( !*sep )
> -                /* reached end of flags */
> -                break;
> -            p = sep + 1;
> -        }
> +        do {
> +            ss = strchr(s, ',');
> +            if ( !ss )
> +                ss = strchr(s, '\0');
> +
> +            if ( !cmdline_strcmp(s, "bts") )
> +                vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> +            else if ( !cmdline_strcmp(s, "ipc") )
> +                vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
> +            else if ( !cmdline_strcmp(s, "arch") )
> +                vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
> +            else
> +                return -EINVAL;
> +
> +            s = ss + 1;
> +        } while ( *ss );

While presumably also applicable elsewhere, the issue is more
noticeable here because you introduce "ss" anew: It is now
unhelpful (in terms of generated code) to calculate ss before
the various cmdline_strcmp() calls, as the compiler can't know
(despite the const) that what s points to won't change across
those calls, and hence has to calculate ss early (and put it into
a callee saved register or on the stack), as written. If the
calculation was pulled down, only scratch registers would
suffice for the compiler to carry out the calculation.

That said - all of this is boot time only code, so not really
performance critical. It's just that this general structure will
then further proliferate, and the overall binary size is likely
going to be (slightly) larger this way.

> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -227,19 +227,49 @@ int parse_bool(const char *s, const char *e)
>      if ( !len )
>          return -1;
>  
> -    if ( !strncmp("no", s, len) ||
> -         !strncmp("off", s, len) ||
> -         !strncmp("false", s, len) ||
> -         !strncmp("disable", s, len) ||
> -         !strncmp("0", s, len) )
> -        return 0;
> +    switch ( len )
> +    {
> +    case 1:
> +        if ( *s == '1' )
> +            return 1;
> +        else if ( *s == '0' )

The "else" here is pointless (also further down).

> @@ -271,6 +301,29 @@ int parse_boolean(const char *name, const char *s, const char *e)
>      return -1;
>  }
>  
> +int cmdline_strcmp(const char *frag, const char *name)
> +{
> +    while ( 1 )

Could I talk you into using "for ( ; ; )" instead (and then perhaps
moving the two increments up here)? I know gcc doesn't do this,
but in the general case a compiler warning about such constant
conditionals is not an entirely bad or wrong thing, so I prefer to
see such constructs avoided where we reasonably can.

> +    {
> +        int res = (*frag - *name);

With the result of this being implementation defined (due to plain
char's implementation defined - often command line controlled
with an implementation defined default - signedness) I wonder if
this function can really usefully return "int" rather than "bool".

> +        if ( res || *name == '\0' )
> +        {
> +            /*
> +             * NUL in 'name' matching a comma or colon in 'frag' implies
> +             * success.
> +             */
> +            if ( *name == '\0' && (*frag == ',' || *frag == ':') )

There's only a single (unrelated) use of ; as a separator right
now (afaics), but adding it here would seem quite desirable to
me.

Also, speaking of (the lack of) tokenization of the command line
in the caller, wouldn't it make sense to accept white space as
separators here too?

Jan


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2019-01-04 15:32 ` Jan Beulich
@ 2019-01-04 15:55   ` Andrew Cooper
  2019-01-04 16:25     ` Andrew Cooper
  2019-01-04 16:47     ` Jan Beulich
  0 siblings, 2 replies; 9+ messages in thread
From: Andrew Cooper @ 2019-01-04 15:55 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Xen-devel, Roger Pau Monne

On 04/01/2019 15:32, Jan Beulich wrote:
>>>> On 31.12.18 at 18:35, <andrew.cooper3@citrix.com> wrote:
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -61,42 +61,31 @@ static unsigned vpmu_count;
>>  
>>  static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>>  
>> -static int parse_vpmu_param(const char *s, unsigned int len)
>> -{
>> -    if ( !*s || !len )
>> -        return 0;
>> -    if ( !strncmp(s, "bts", len) )
>> -        vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> -    else if ( !strncmp(s, "ipc", len) )
>> -        vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>> -    else if ( !strncmp(s, "arch", len) )
>> -        vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>> -    else
>> -        return 1;
>> -    return 0;
>> -}
>> -
>>  static int __init parse_vpmu_params(const char *s)
>>  {
>> -    const char *sep, *p = s;
>> +    const char *ss;
>>  
>>      switch ( parse_bool(s, NULL) )
>>      {
>>      case 0:
>>          break;
>>      default:
>> -        for ( ; ; )
>> -        {
>> -            sep = strchr(p, ',');
>> -            if ( sep == NULL )
>> -                sep = strchr(p, 0);
>> -            if ( parse_vpmu_param(p, sep - p) )
>> -                goto error;
>> -            if ( !*sep )
>> -                /* reached end of flags */
>> -                break;
>> -            p = sep + 1;
>> -        }
>> +        do {
>> +            ss = strchr(s, ',');
>> +            if ( !ss )
>> +                ss = strchr(s, '\0');
>> +
>> +            if ( !cmdline_strcmp(s, "bts") )
>> +                vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> +            else if ( !cmdline_strcmp(s, "ipc") )
>> +                vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>> +            else if ( !cmdline_strcmp(s, "arch") )
>> +                vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>> +            else
>> +                return -EINVAL;
>> +
>> +            s = ss + 1;
>> +        } while ( *ss );
> While presumably also applicable elsewhere, the issue is more
> noticeable here because you introduce "ss" anew:

I don't introduce it.  It was previously named "sep", which I renamed
for consistency.  It is also subtly disguised with a 0 instead of '\0'
and a redundant local variable named p.

> It is now
> unhelpful (in terms of generated code) to calculate ss before
> the various cmdline_strcmp() calls, as the compiler can't know
> (despite the const) that what s points to won't change across
> those calls, and hence has to calculate ss early (and put it into
> a callee saved register or on the stack), as written. If the
> calculation was pulled down, only scratch registers would
> suffice for the compiler to carry out the calculation.
>
> That said - all of this is boot time only code, so not really
> performance critical. It's just that this general structure will
> then further proliferate, and the overall binary size is likely
> going to be (slightly) larger this way.

TBH, I'm not concerned far more with code consistency than efficiency,
given how often we manage to subtly break the command line parsing.

If we do want to come up with a more efficient way of doing this, we can
do a blanket change to our prevailing style.

>
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -227,19 +227,49 @@ int parse_bool(const char *s, const char *e)
>>      if ( !len )
>>          return -1;
>>  
>> -    if ( !strncmp("no", s, len) ||
>> -         !strncmp("off", s, len) ||
>> -         !strncmp("false", s, len) ||
>> -         !strncmp("disable", s, len) ||
>> -         !strncmp("0", s, len) )
>> -        return 0;
>> +    switch ( len )
>> +    {
>> +    case 1:
>> +        if ( *s == '1' )
>> +            return 1;
>> +        else if ( *s == '0' )
> The "else" here is pointless (also further down).

So they are.  I'll drop.

>
>> @@ -271,6 +301,29 @@ int parse_boolean(const char *name, const char *s, const char *e)
>>      return -1;
>>  }
>>  
>> +int cmdline_strcmp(const char *frag, const char *name)
>> +{
>> +    while ( 1 )
> Could I talk you into using "for ( ; ; )" instead (and then perhaps
> moving the two increments up here)? I know gcc doesn't do this,
> but in the general case a compiler warning about such constant
> conditionals is not an entirely bad or wrong thing, so I prefer to
> see such constructs avoided where we reasonably can.

Ok.

>
>> +    {
>> +        int res = (*frag - *name);
> With the result of this being implementation defined (due to plain
> char's implementation defined - often command line controlled
> with an implementation defined default - signedness) I wonder if
> this function can really usefully return "int" rather than "bool".

My CPUID command line parsing needs this to work properly as int, for
bisecting across a sorted list.

I'll add an explicit cast to signed char.  I'll also fix out local libc
functions, which are similarly buggy.

>
>> +        if ( res || *name == '\0' )
>> +        {
>> +            /*
>> +             * NUL in 'name' matching a comma or colon in 'frag' implies
>> +             * success.
>> +             */
>> +            if ( *name == '\0' && (*frag == ',' || *frag == ':') )
> There's only a single (unrelated) use of ; as a separator right
> now (afaics), but adding it here would seem quite desirable to
> me.

Where is ; used, out of interest?  I'm happy to add it, but I didn't
spot it on my audit.

> Also, speaking of (the lack of) tokenization of the command line
> in the caller, wouldn't it make sense to accept white space as
> separators here too?

I'm not sure if that is wise or not.  I can't think of a situation where
you would want that behaviour, rather than finding yourself with a
parsing bug and having to fix a bug elsewhere.

~Andrew

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2019-01-04 15:55   ` Andrew Cooper
@ 2019-01-04 16:25     ` Andrew Cooper
  2019-01-04 16:47     ` Jan Beulich
  1 sibling, 0 replies; 9+ messages in thread
From: Andrew Cooper @ 2019-01-04 16:25 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Roger Pau Monne, Xen-devel

On 04/01/2019 15:55, Andrew Cooper wrote:
> On 04/01/2019 15:32, Jan Beulich wrote:
>>> +    {
>>> +        int res = (*frag - *name);
>> With the result of this being implementation defined (due to plain
>> char's implementation defined - often command line controlled
>> with an implementation defined default - signedness) I wonder if
>> this function can really usefully return "int" rather than "bool".
> My CPUID command line parsing needs this to work properly as int, for
> bisecting across a sorted list.
>
> I'll add an explicit cast to signed char.  I'll also fix out local libc
> functions, which are similarly buggy.

And by this, I actually mean an explicit unsigned cast, having just
cross-checked with the C spec.

~Andrew

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
  2019-01-04 15:55   ` Andrew Cooper
  2019-01-04 16:25     ` Andrew Cooper
@ 2019-01-04 16:47     ` Jan Beulich
  1 sibling, 0 replies; 9+ messages in thread
From: Jan Beulich @ 2019-01-04 16:47 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Julien Grall, Stefano Stabellini, Wei Liu, Xen-devel, Roger Pau Monne

>>> On 04.01.19 at 16:55, <andrew.cooper3@citrix.com> wrote:
> On 04/01/2019 15:32, Jan Beulich wrote:
>>>>> On 31.12.18 at 18:35, <andrew.cooper3@citrix.com> wrote:
>>> +    {
>>> +        int res = (*frag - *name);
>> With the result of this being implementation defined (due to plain
>> char's implementation defined - often command line controlled
>> with an implementation defined default - signedness) I wonder if
>> this function can really usefully return "int" rather than "bool".
> 
> My CPUID command line parsing needs this to work properly as int, for
> bisecting across a sorted list.
> 
> I'll add an explicit cast to signed char.  I'll also fix out local libc
> functions, which are similarly buggy.

Why "signed char" when the standard specifically mandates "unsigned
char"?

>>> +        if ( res || *name == '\0' )
>>> +        {
>>> +            /*
>>> +             * NUL in 'name' matching a comma or colon in 'frag' implies
>>> +             * success.
>>> +             */
>>> +            if ( *name == '\0' && (*frag == ',' || *frag == ':') )
>> There's only a single (unrelated) use of ; as a separator right
>> now (afaics), but adding it here would seem quite desirable to
>> me.
> 
> Where is ; used, out of interest?  I'm happy to add it, but I didn't
> spot it on my audit.

As said, it's in unrelated (but still command line parsing) code.
See xen/drivers/passthrough/vtd/dmar.c:parse_rmrr_param().

>> Also, speaking of (the lack of) tokenization of the command line
>> in the caller, wouldn't it make sense to accept white space as
>> separators here too?
> 
> I'm not sure if that is wise or not.  I can't think of a situation where
> you would want that behaviour, rather than finding yourself with a
> parsing bug and having to fix a bug elsewhere.

Well, I wasn't sure either (hence me having phrased it as a
question), so let's leave it out (at least for now)

Jan



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-01-04 16:47 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-31 17:35 [PATCH] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct Andrew Cooper
2019-01-02 10:13 ` Roger Pau Monné
2019-01-02 12:18   ` Andrew Cooper
2019-01-02 12:25     ` Roger Pau Monné
2019-01-02 12:28       ` Andrew Cooper
2019-01-04 15:32 ` Jan Beulich
2019-01-04 15:55   ` Andrew Cooper
2019-01-04 16:25     ` Andrew Cooper
2019-01-04 16:47     ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.