On 8/9/19 2:16 PM, Stefan Hajnoczi wrote:
> On Thu, Aug 08, 2019 at 11:53:07AM +0100, Daniel P. Berrangé wrote:
>> On Thu, Aug 08, 2019 at 11:10:13AM +0100, Stefan Hajnoczi wrote:
>>> On Wed, Aug 07, 2019 at 12:20:47PM +0200, Philippe Mathieu-Daudé wrote:
>>>>> +void python_args_clean(char *args[], int nargs)
>>>>> +{
>>>>> + for (int i = 0; i < nargs; i++) {
>>>>> + g_free(args[i]);
>>>>> + }
>>>>> +}
>>>>>
>>>> Wondering about security, is this feature safe to enable in production
>>>> environment? It seems to bypass all the hard effort to harden QEMU
>>>> security.
>>> This seems like a feature that distros would not enable. Only users
>>> building QEMU from source could enable it.
>> Well that's true when this scripting is only used from one obscure ppc
>> device. Once merged though, its inevitable that people will want to
>> extend scripting to more & more parts of QEMU code. This is a big can
>> of worms...
> When it gets used in new contexts it will be necessary to address
> problems or accept that it is unsuitable for those use cases. Starting
> simple and dealing with challenges as and when necessary seems okay to
> me.
>
> I think we should give features a chance in QEMU if there is a
> maintainer to support them. I don't want to use this feature myself and
> I see lots of issues with it for my use cases, but if it is compiled out
> and doesn't place many requirements on code that does not use it, let's
> give it a chance.
>
> My main concern is licensing. I think the QEMU Python API should be GPL
> licensed because these scripts are executing as part of the QEMU
> process.
>
> Beyond that, let's see if people find this feature useful. Maybe it
> will die and be removed, maybe it will become popular and we'll have to
> change our perspective :).
Thank you all for review and sharing the thoughts :)
>
> Stefan