All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.