On 07/10/2018 11:59 AM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH] hvm/altp2m: Clarify the proper way to
> extend the altp2m interface"):
>> On 07/10/2018 11:32 AM, Ian Jackson wrote:
>>> We should have a way of remembering the design intent, even if it
>>> hasn't been audited.
>>>
>>> SUPPORT.md can deal with the possible problem of people thinking the
>>> non-blacklisted items are fully ready for use.
>>
>> I think SUPPORT.md should primarily be for end users to determine
>> whether they should use an interface or not. A technical discussion
>> about exactly to what degree an interface has (or hasn't) been vetted is
>> more towards a developer who may be looking to get things into a
>> supported state, and so should probably be in the code somewhere.
>
> I agree with that. But currently I think none of it has been
> audited. If there is any question of doubt we can leave a comment in
> one place referenceing the SUPPORT.md status and saying `one reason is
> that none of this stuff has been audited'.
I would assume that for the original interface, the authors at least did
some thinking about whether exposing each bit was safe or not (whether
this rises to the level of 'audit' is a different question). But in the
mean time, other extensions have been made, which have generally not
been thought about so much.
OTOH, someone picking up this use case will want to do their own
analysis of all the code anyway; so maybe making the distinction between
"was in the original design" and "was added later" isn't worth the effort.
Basically -- I suggested the idea of a blacklist for new subops as
something to make Jan less worried about security creep. If he wants
it, let's have it. Otherwise, let's not bother.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
