Re: [Xen-devel] [PATCH v2] mm: option to _always_ scrub freed domheap pages

["Elnikety, Eslam" <elnikety@xxxxxxxxxx>]

> On 7. May 2019, at 14:11, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 
>>>> On 07.05.19 at 13:34, <elnikety@xxxxxxxxxx> wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -214,6 +214,10 @@ custom_param("bootscrub", parse_bootscrub_param);
>> static unsigned long __initdata opt_bootscrub_chunk = MB(128);
>> size_param("bootscrub_chunk", opt_bootscrub_chunk);
>> 
>> + /* scrub-domheap -> Domheap pages are scrubbed when freed */
>> +static bool __read_mostly opt_scrub_domheap;
>> +boolean_param("scrub-domheap", opt_scrub_domheap);
> 
> Upon 2nd thought this, btw, would seem to be an excellent candidate
> for becoming a runtime parameter.

True.

> 
>> @@ -2378,9 +2382,10 @@ void free_domheap_pages(struct page_info *pg, 
>> unsigned int order)
>>             /*
>>              * Normally we expect a domain to clear pages before freeing 
>> them,
>>              * if it cares about the secrecy of their contents. However, 
>> after
>> -             * a domain has died we assume responsibility for erasure.
>> +             * a domain has died we assume responsibility for erasure. We do
>> +             * scrub regardless if option scrub_domheap is set.
>>              */
>> -            scrub = d->is_dying || scrub_debug;
>> +            scrub = d->is_dying || scrub_debug || opt_scrub_domheap;
> 
> Did you consider setting opt_scrub_domheap when scrub_debug is
> set? This would shorten the (runtime) calculation here by a tiny bit,
> at the price of doing one more thing once while booting.

Interesting. I have not particularly thought about that. Granted; this would 
shorten the “scrub” bool calculation. One would probably define a bool 
‘always_scrub’ that gets set at boot ‘always_scrub = scrub_debug || 
opt_scrub_domheap’, and use that new bool in the hunk at hand here. (Having 
opt_scrub_domheap as a runtime parameter and re-evaluating always_scrub should 
not be much of a complication either). 

In any case, given your response to George earlier, I would rather decouple 
these improvements from this patch. I would be happy to re-work these 
improvements at a later point if the community feels strongly about them.

> 
> Jan
> 
> 

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