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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as 
required"):
> Ian Jackson <ian.jackson@xxxxxxxxxx> 03/07/19 3:44 PM >>>
> >Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as 
> >required"):
> >> 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.
> >
> >I think if you do this
> >extern const struct blah blah_start[];
> >it is not safe to cast the const away later.
...
> It looks to me as if we were in agreement then.

Perhaps so.

> I was talking about freeing an object that was const-qualified, not
> modifying it.

I'm not sure what you mean, precisely.  Do you mean this:

   extern const struct blah blah_start[];
   ...
   free(blah_start);

?  But I'm sure the hypervisor doesn't have a function free().

> The scrubbing of the memory could be considered part
> of the freeing, it just ought to occur up front because of otherwise
> possible races, and because we have no means to tell the freeing
> function to do the scrubbing (in fact I should say "we used to have
> no means, as I think right now the memory would be scrubbed
> implicitly, so the explicit scrubbing could probably be dropped).

Maybe you mean this:

   extern const struct blah blah_start[];
   ...
   memset(blah_start, 0, size of blah array);

?  That is clearly forbidden, regardless of whether the cost
is cast away.  But I think this:

   extern struct blah blah_start[];
   ...
   memset(blah_start, 0, size of blah array);

is fine.

Ian.

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