Re: [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 20/01/16 15:05, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Andrew Cooper wrote:
>> On 20/01/16 14:29, Stefano Stabellini wrote:
>>> On Wed, 20 Jan 2016, Andrew Cooper wrote:
>>>>
>>> I wouldn't encourage the introduction of anything else that requires
>>> root privileges in QEMU. With QEMU running as non-root by default in
>>> 4.7, the feature will not be available unless users explicitly ask to
>>> run QEMU as root (which they shouldn't really).
>> This isn't how design works.
>>
>> First, design a feature in an architecturally correct way, and then
>> design an security policy to fit.
>>
>> We should not stunt design based on an existing implementation.  In
>> particular, if design shows that being a root only feature is the only
>> sane way of doing this, it should be a root only feature.  (I hope this
>> is not the case, but it shouldn't cloud the judgement of a design).
> I would argue that security is an integral part of the architecture and
> should not be retrofitted into it.

There is no retrofitting - it is all part of the same overall design
before coding starts happen.

>
> Is it really a good design if the only sane way to implement it is
> making it a root-only feature? I think not.

Then you have missed the point.

If you fail at architecting the feature in the first place, someone else
is going to have to come along and reimplement it properly, then provide
some form of compatibility with the old one.

Security is an important consideration in the design; I do not wish to
understate that.  However, if the only way for a feature to be
architected properly is for the feature to be a root-only feature, then
it should be a root-only feature.

>  Designing security policies
> for pieces of software that don't have the infrastructure for them is
> costly and that cost should be accounted as part of the overall cost of
> the solution rather than added to it in a second stage.

That cost is far better spent designing it properly in the first place,
rather than having to come along and reimplement a v2 because v1 was broken.

>
>
>> (note, both before implement happens).
> That is ideal but realistically in many cases nobody is able to produce
> a design before the implementation happens.

It is perfectly easy.  This is the difference between software
engineering and software hacking.

There has been a lot of positive feedback from on-list design
documents.  It is a trend which needs to continue.

~Andrew