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

Re: [PATCH] x86/cet: Support cet=<bool> on the command line


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 28 Apr 2022 12:13:31 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SOylW/xOk1biFGmAmJblj3puGUp0ilc0fo9TwKsdZDk=; b=m9q1rSo1QdJ6/9QrUYZsaPF0SFSy2OCqnp/aQqFOjjTcZ7ChYjONfQaMVEVyM6+0NAlv4yfxwIjB4IIrD5+Nm6R/QCF7SoPsDnKQeuuE9dXCrx35/J8KRxT2nhHhVx/SIjTqS8S4DdrKAt+GTiJAbPWgVNseyB7wi4+hVDCuK0Xkz0TVaCLEHFAEZGHLW1VAop7dSpnsPfhjvD0emS9oB6ELHOoKR90GQDIQAiGooXk2zpF1SnVYtexzQpWgOQj5K20eoxPeudNAyOwEgdWCb2BSng/Qb4TrK3mmDGdkPRAWlb/goOXvCQnizJwCS9vDdRm7d2wVwpXWzITIB84lXw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gCWFQGUfP9PZQ0v8FXb8NqF3wlsPaumai7ngoYiauu6QPduUBjjmjHhI72TN4FK8O5GjqQLEUgZi05c0qgKwNijKCb4Bv0ISJxUVYbUNf2OvVhwc3tIGXnEz4cYS/dLw1yJUPBrN/DTh5D7u0Rxovgj92GBzBAiHVm4mx6Y4RBj16piyL90W7zBbl+e67k2FTvYgLsRuQaYyJ1AnR7nUqIK8G0JKB7k8JSptKsP4JePOXDK/FwZe5OOPXhpFbL2Ult2tmFsK4l1HFxqxYXKeFu10rfMLJ2MdVszNrl+VkvB4BSlY8Bwlc9jqADgpzoDfX6K7x/UfP8vRGBQm4bCFdQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 28 Apr 2022 10:13:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.04.2022 10:52, Andrew Cooper wrote:
> @@ -283,6 +283,8 @@ CET is incompatible with 32bit PV guests.  If any CET 
> sub-options are active,
>  they will override the `pv=32` boolean to `false`.  Backwards compatibility
>  can be maintained with the pv-shim mechanism.
>  
> +*   An unqualified boolean is shorthand for setting all suboptions at once.

You're the native speaker, but I wonder whether there an "a" missing
before "shorthand".

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -117,7 +117,20 @@ static int __init cf_check parse_cet(const char *s)
>          if ( !ss )
>              ss = strchr(s, '\0');
>  
> -        if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
> +        if ( (val = parse_bool(s, ss)) >= 0 )
> +        {
> +#ifdef CONFIG_XEN_SHSTK
> +            opt_xen_shstk = val;
> +#else
> +            no_config_param("XEN_SHSTK", "cet", s, ss);
> +#endif
> +#ifdef CONFIG_XEN_IBT
> +            opt_xen_ibt = val;
> +#else
> +            no_config_param("XEN_IBT", "cet", s, ss);
> +#endif

There shouldn't be two invocations of no_config_param() here; imo if
either CONFIG_* is defined, use of the option shouldn't produce any
warning at all.

> +        }
> +        else if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
>          {
>  #ifdef CONFIG_XEN_SHSTK
>              opt_xen_shstk = val;

Having seen Roger's reply, I'd like to make explicit that I don't
mind us allowing strange option combinations to be used, so long as
what we do matches the sequence in which they were provided.

Jan




 


Rackspace

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