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

Re: [PATCH v3 2/3] xsm: consolidate loading the policy buffer


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 31 May 2022 13:02:06 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1654016617; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=tcGpwATKnB8tjbSMB7ke1FkWwTgORrNPTiS1SBigrjo=; b=T1u+IDvK6IDvzrkb05shI7LY9OqUMQBr2Hd0H8bd+YA+DTlssrshO4rTndE/hpKDNUU3mEh8FzAfq2DCLnvRqKgeSo+2L9FZXDvF7P54kkWd+9Mkuv70eUGbz0iCRJp4E9ml9xdGX1zFDGPBtqWfoTKtDI/P+xkUDv8L5rozMC8=
  • Arc-seal: i=1; a=rsa-sha256; t=1654016617; cv=none; d=zohomail.com; s=zohoarc; b=aYv0es7mKYVjwZB2c485H9L/8xXYP5xBh8Q9P1pEtHHhx0gDHGpwckKA2B8OpjdzMHSRmlV6d9W1KOd+fB2bBLspxrw20Sw7mOIveO579dTQUBWOwtfynqIQ05DvNov9MX/jv3sdIjsbH3cftlms0/R1jTADhnjvYrpVQGZ+OBU=
  • Cc: scott.davis@xxxxxxxxxx, christopher.clark@xxxxxxxxxx, jandryuk@xxxxxxxxx, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 31 May 2022 17:03:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 5/31/22 12:05, Jan Beulich wrote:
> On 31.05.2022 17:08, Daniel P. Smith wrote:
>> Previously, initializing the policy buffer was split between two functions,
>> xsm_{multiboot,dt}_policy_init() and xsm_core_init(). The latter for loading
>> the policy from boot modules and the former for falling back to built-in 
>> policy.
>>
>> This patch moves all policy buffer initialization logic under the
>> xsm_{multiboot,dt}_policy_init() functions. It then ensures that an error
>> message is printed for every error condition that may occur in the functions.
>> With all policy buffer init contained and only called when the policy buffer
>> must be populated, the respective xsm_{mb,dt}_init() functions will panic if 
>> an
>> error occurs attempting to populate the policy buffer.
> 
> "flask=late" is also a mode where, afaict, no policy is required. I can't,
> however, see how you're taking care of that (but maybe I'm overlooking
> something); inspecting flask_bootparam in generic XSM code would actually
> be a layering violation.

Good point, flask=late is meant to be enforcing with a late loading of a
policy file. I will address it.

>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -775,7 +775,7 @@ int xsm_multiboot_init(
>>      unsigned long *module_map, const multiboot_info_t *mbi);
>>  int xsm_multiboot_policy_init(
>>      unsigned long *module_map, const multiboot_info_t *mbi,
>> -    void **policy_buffer, size_t *policy_size);
>> +    const unsigned char *policy_buffer[], size_t *policy_size);
> 
> I don't think we're dealing with an array here, so const unsigned char **
> would seem the more correct representation to me.
> 
> Also - what about the DT counterpart function?

Ack.

v/r
dps



 


Rackspace

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