linux-kernel - Re: [PATCH v19 011/130] KVM: Add new members to struct kvm_gfn

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: <52bc2c174c06f94a44e3b8b455c0830be9965cdf.camel@intel.com>
Date: Tue, 19 Mar 2024 02:50:48 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "isaku.yamahata@...ux.intel.com"
	<isaku.yamahata@...ux.intel.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"Huang, Kai" <kai.huang@...el.com>, "sagis@...gle.com" <sagis@...gle.com>,
	"Chen, Bo2" <chen.bo@...el.com>, "isaku.yamahata@...il.com"
	<isaku.yamahata@...il.com>, "Aktas, Erdem" <erdemaktas@...gle.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Yuan, Hang" <hang.yuan@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v19 011/130] KVM: Add new members to struct kvm_gfn_range
 to operate on

On Wed, 2024-03-13 at 10:14 -0700, Isaku Yamahata wrote:
> > IMO, an enum will be clearer than the two flags.
> > 
> >     enum {
> >         PROCESS_PRIVATE_AND_SHARED,
> >         PROCESS_ONLY_PRIVATE,
> >         PROCESS_ONLY_SHARED,
> >     };
> 
> The code will be ugly like
> "if (== PRIVATE || == PRIVATE_AND_SHARED)" or
> "if (== SHARED || == PRIVATE_AND_SHARED)"
> 
> two boolean (or two flags) is less error-prone.

Yes the enum would be awkward to handle. But I also thought the way
this is specified in struct kvm_gfn_range is a little strange.

It is ambiguous what it should mean if you set:
 .only_private=true;
 .only_shared=true;
...as happens later in the series (although it may be a mistake).

Reading the original conversation, it seems Sean suggested this
specifically. But it wasn't clear to me from the discussion what the
intention of the "only" semantics was. Like why not?
 bool private;
 bool shared;