Re: [Xen-devel] [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as required

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.03.19 at 22:38, <sstabellini@xxxxxxxxxx> wrote:
> On Wed, 6 Mar 2019, Jan Beulich wrote:
>> >>> On 05.03.19 at 23:38, <sstabellini@xxxxxxxxxx> wrote:
>> > @@ -600,7 +602,9 @@ static void noinline init_done(void)
>> >      unregister_init_virtual_region();
>> >  
>> >      /* Zero the .init code and data. */
>> > -    for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
>> > +    for ( va = (char *)__init_begin;
>> > +          init_lt(va, __init_end);
>> > +          va += PAGE_SIZE )
>> >          clear_page(va);
>> 
>> At the example of this - is casting away of const-ness not also a
>> potential certification hindrance?
> 
> Darn, well spotted! No, it is not permitted (Rule 11.8).
> In this case const is not correct because we actually modify the object
> few lines below:
> 
>   base->priv = 1;
> 
> 
> This is problematic. We have also the following instances in this series
> to deal with:
> 
> xen/arch/arm/percpu.c:_free_percpu_area
>   char *p = (char *)__per_cpu_start + __per_cpu_offset[cpu];
> 
> xen/arch/x86/percpu.c:_free_percpu_area
>   char *p = (char *)__per_cpu_start + __per_cpu_offset[cpu];
> 
> xen/arch/x86/setup.c:init_done
>   for ( va = (char *)__init_begin; init_lt(va, __init_end); va += PAGE_SIZE 
> )
> 
> xen/arch/x86/alternative.c:apply_alternatives
>   for ( a = base = (struct alt_instr *)start; alt_instr_lt(a, end); a++ )
> 
> 
> In all these cases we actually end up modifying the object. I suggest
> we remove the const from either __DECLARE_BOUNDS (so from everywhere),
> or just for per_cpu, init, and alt_instr by introducing another MACRO.

The core macro should just have another parameter, "modifier", which
is allowed to be empty. The "end" pointers should, if at all possible, be
const regardless, but the start pointer declarations should honor the
specified macro.

I'd like to note though that in the first two cases we don't alter the
declared object anyway, but instead a derived one; the declaration
should not use const for other reasons though. And the 3rd case is
fiddling with something that has lost its meaning as an object. In fact
we're about to free the underlying memory. In this case I'd prefer to
retain the const, but I won't insist as the symbol is non-const right
now as well.

Jan



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