public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Jiaxin Wu <jiaxin.wu@intel.com>, edk2-devel@ml01.01.org
Cc: Ruiyu Ni <ruiyu.ni@intel.com>, Ye Ting <ting.ye@intel.com>,
	Kinney Michael D <michael.d.kinney@intel.com>,
	Fu Siyuan <siyuan.fu@intel.com>,
	Gary Ching-Pang Lin <glin@suse.com>,
	"Jordan Justen (Intel address)" <jordan.l.justen@intel.com>
Subject: Re: [PATCH v2 2/2] Nt32Pkg.dsc: Add flag to control HTTP connections
Date: Tue, 17 Jan 2017 11:02:17 +0100	[thread overview]
Message-ID: <885aab27-f660-768b-59da-4d3e33f099ec@redhat.com> (raw)
In-Reply-To: <1484623992-52988-3-git-send-email-jiaxin.wu@intel.com>

CC Jordan and Gary

On 01/17/17 04:33, Jiaxin Wu wrote:
> v2:
> * Rename the flag.
> 
> This flag is used to overwrite the PcdAllowHttpConnections
> value, then the platform can make a decision whether to allow
> HTTP connections or not.
> 
> Cc: Ye Ting <ting.ye@intel.com>
> Cc: Fu Siyuan <siyuan.fu@intel.com>
> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Kinney Michael D <michael.d.kinney@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
> ---
>  Nt32Pkg/Nt32Pkg.dsc | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
> index 134afb8..88b1ea9 100644
> --- a/Nt32Pkg/Nt32Pkg.dsc
> +++ b/Nt32Pkg/Nt32Pkg.dsc
> @@ -2,11 +2,11 @@
>  # EFI/Framework Emulation Platform with UEFI HII interface supported.
>  #
>  # The Emulation Platform can be used to debug individual modules, prior to creating
>  #    a real platform. This also provides an example for how an DSC is created.
>  #
> -# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> +# Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
>  # Copyright (c) 2015, Hewlett-Packard Development Company, L.P.<BR>
>  # (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
>  #
>  #    This program and the accompanying materials
>  #    are licensed and made available under the terms and conditions of the BSD License
> @@ -57,11 +57,21 @@
>    #
>    # Note: TLS feature highly depends on the OpenSSL building. To enable this 
>    #       feature, please follow the instructions found in the file "Patch-HOWTO.txt" 
>    #       located in CryptoPkg\Library\OpensslLib to enable the OpenSSL building first.
>    #
> -  DEFINE TLS_ENABLE      = FALSE
> +  DEFINE TLS_ENABLE = FALSE
> +  
> +  #
> +  # Indicates whether HTTP connections (i.e., unsecured) are permitted or not.
> +  # -D FLAG=VALUE
> +  #
> +  # Note: If ALLOW_HTTP_CONNECTIONS is TRUE, HTTP connections is allowed. Both 
> +  #       the "https://" and "http://" URI schemes are permitted. Otherwise, HTTP 
> +  #       connections is denied. Only the "https://" URI scheme is permitted.
> +  #
> +  DEFINE ALLOW_HTTP_CONNECTIONS = TRUE
>  
>  ################################################################################
>  #
>  # SKU Identification section - list of all SKU IDs supported by this
>  #                              Platform.
> @@ -252,10 +262,14 @@
>    gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
>  !if $(SECURE_BOOT_ENABLE) == TRUE || $(TLS_ENABLE) == TRUE
>    gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
>  !endif
>  
> +!if $(ALLOW_HTTP_CONNECTIONS) == TRUE
> +  gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
> +!endif
> +
>  !ifndef $(USE_OLD_SHELL)
>    gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
>  !endif
>  
>  !if $(SECURE_BOOT_ENABLE) == TRUE
> 

Does the following combination make sense?

  TLS_ENABLE=FALSE and ALLOW_HTTP_CONNECTIONS=FALSE

In this case, only the https:// scheme would be accepted, however the
TLS facility that underlies HTTPS is missing. I think this would render
the HTTP stack useless. Is that correct?

I'm asking mainly for OVMF's sake. (I have nothing against this patch in
Nt32Pkg.) Namely, in OvmfPkg, I would dislike the additional complexity
of an ALLOW_HTTP_CONNECTIONS build flag. Instead, I think we should set
PcdAllowHttpConnections to TRUE, whenever HTTP_BOOT_ENABLE is defined
(and we shouldn't override the DEC default otherwise).

This would result in HTTP working with just -D HTTP_BOOT_ENABLE, and
both HTTP and HTTPS working with -D HTTP_BOOT_ENABLE -D TLS_ENABLE. I
don't see any downsides to always permitting HTTP in OVMF.

Thoughts?

If everyone agrees, then Jiaxin, can you please append a third patch for
OvmfPkg, which sets PcdAllowHttpConnections to TRUE whenever
HTTP_BOOT_ENABLE is TRUE?

(Note that in "OvmfPkgIa32X64.dsc", the setting should likely go under
[PcdsFixedAtBuild.X64].)

Thanks!
Laszlo


  reply	other threads:[~2017-01-17 10:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17  3:33 [PATCH v2 0/2] Enable the HTTP connections switch Jiaxin Wu
2017-01-17  3:33 ` [PATCH v2 1/2] NetworkPkg: Add PCD to enable " Jiaxin Wu
2017-01-17  8:53   ` Laszlo Ersek
2017-01-17  3:33 ` [PATCH v2 2/2] Nt32Pkg.dsc: Add flag to control HTTP connections Jiaxin Wu
2017-01-17 10:02   ` Laszlo Ersek [this message]
2017-01-17 10:29     ` Gary Lin
2017-01-18  2:16     ` Wu, Jiaxin
2017-01-18  8:30       ` Laszlo Ersek
2017-01-18  9:27         ` Gary Lin
2017-01-19  3:19           ` Wu, Jiaxin

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-list 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=885aab27-f660-768b-59da-4d3e33f099ec@redhat.com \
    --to=devel@edk2.groups.io \
    /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