qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [RFC PATCH v6 3/5] softmmu/vl: Allow -fw_cfg 'blob_id' option to set any file pathname
Date: Thu, 28 May 2020 19:03:18 +0200	[thread overview]
Message-ID: <70be0748-0cb7-e493-53b9-f3c1d13077fd@redhat.com> (raw)
In-Reply-To: <3225db1c-1dcb-8bec-18a5-0ea7fe890508@redhat.com>

On 5/20/20 12:45 AM, Laszlo Ersek wrote:
> On 05/19/20 20:20, Philippe Mathieu-Daudé wrote:
>> This is to silent:
>>
>>   $ qemu-system-x86_64 \
>>     -object tls-cipher-suites,id=ciphersuite0,priority=@SYSTEM \
>>     -fw_cfg name=etc/edk2/https/ciphers,blob_id=ciphersuite0
>>   qemu-system-x86_64: -fw_cfg name=etc/edk2/https/ciphers,blob_id=ciphersuite0: warning: externally provided fw_cfg item names should be prefixed with "opt/"
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>  softmmu/vl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/softmmu/vl.c b/softmmu/vl.c
>> index f76c53ad2e..3b77dcc00d 100644
>> --- a/softmmu/vl.c
>> +++ b/softmmu/vl.c
>> @@ -2052,7 +2052,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
>>                     FW_CFG_MAX_FILE_PATH - 1);
>>          return -1;
>>      }
>> -    if (strncmp(name, "opt/", 4) != 0) {
>> +    if (!nonempty_str(blob_id) && strncmp(name, "opt/", 4) != 0) {
>>          warn_report("externally provided fw_cfg item names "
>>                      "should be prefixed with \"opt/\"");
>>      }
>>
> 
> Hmmm, difficult question! Is "ciphersuite0" now externally provided or not?
> 
> Because, ciphersuite0 is populated internally to QEMU alright (and so we
> can think it's internal), but its *association with the name* is external.
> 
> What if we keep the same "-object" switch, but use a different (bogus)
> "name" with "-fw_cfg"? IMO that kind of invalidates "-object" too.
> 
> Should the fw_cfg generator interface dictate the fw_cfg filename too?
> Because that would eliminate this problem. Put differently, we now have
> a possibility to label the "ciphersuite0" object in the fw_cfg file
> directory any way we want -- but is that freedom *useful* for anything?

Good point. Not now.

> 
> I guess we might want multiple "tls-cipher-suites" objects one day, so
> hard-coding the fw_cfg names on that level could cause conflicts.

I haven't thought of that. If we set a limit today, we can relax it
tomorrow. That won't break anything.

> On the
> other hand, I wouldn't like "blob_id" to generally circumvent the "etc/"
> namespace protection.

Eh, that was too easy.

> 
> I'm leaning towards agreeing with this patch, but I'd appreciate some
> convincing arguments.

OK. I'll think about it. Maybe keep this as single-RFC patch & repost
the rest so review can go on until we settle on this.

> 
> Thanks
> Laszlo
> 



  reply	other threads:[~2020-05-28 17:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 18:20 [PATCH v6 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-05-19 18:20 ` [PATCH v6 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
2020-05-19 22:01   ` Laszlo Ersek
2020-05-28 14:54     ` Philippe Mathieu-Daudé
2020-05-19 18:20 ` [PATCH v6 2/5] softmmu/vl: Let -fw_cfg option take a 'blob_id' argument Philippe Mathieu-Daudé
2020-05-19 22:34   ` Laszlo Ersek
2020-05-28 12:07     ` Philippe Mathieu-Daudé
2020-05-27 11:38   ` Daniel P. Berrangé
2020-05-19 18:20 ` [RFC PATCH v6 3/5] softmmu/vl: Allow -fw_cfg 'blob_id' option to set any file pathname Philippe Mathieu-Daudé
2020-05-19 18:22   ` Philippe Mathieu-Daudé
2020-05-19 22:45   ` Laszlo Ersek
2020-05-28 17:03     ` Philippe Mathieu-Daudé [this message]
2020-05-19 18:20 ` [PATCH v6 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
2020-05-19 23:24   ` Laszlo Ersek
2020-05-27 11:36   ` Daniel P. Berrangé
2020-05-28 10:17     ` Philippe Mathieu-Daudé
2020-05-19 18:20 ` [PATCH v6 5/5] crypto/tls-cipher-suites: Product fw_cfg consumable blob Philippe Mathieu-Daudé
2020-05-19 22:49   ` Laszlo Ersek
2020-05-27 11:29 ` [PATCH v6 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-05-27 11:33   ` Daniel P. Berrangé
2020-05-27 11:34     ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70be0748-0cb7-e493-53b9-f3c1d13077fd@redhat.com \
    --to=philmd@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).