From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3E42D81E69 for ; Wed, 18 Jan 2017 19:19:30 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 18 Jan 2017 19:19:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,251,1477983600"; d="scan'208";a="32493510" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 18 Jan 2017 19:19:29 -0800 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Jan 2017 19:19:29 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Jan 2017 19:19:28 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by shsmsx102.ccr.corp.intel.com ([169.254.2.88]) with mapi id 14.03.0248.002; Thu, 19 Jan 2017 11:19:25 +0800 From: "Wu, Jiaxin" To: Gary Lin , Laszlo Ersek CC: "Ni, Ruiyu" , "Ye, Ting" , "Justen, Jordan L" , "edk2-devel@ml01.01.org" , "Kinney, Michael D" , "Fu, Siyuan" Thread-Topic: [edk2] [PATCH v2 2/2] Nt32Pkg.dsc: Add flag to control HTTP connections Thread-Index: AQHScHJ5fflRVxVfYU+YjuTUCJopYKE76pCAgAGAUpD///h4AIAAD+EAgAGvmFA= Date: Thu, 19 Jan 2017 03:19:24 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B727416294F1F@SHSMSX103.ccr.corp.intel.com> References: <1484623992-52988-1-git-send-email-jiaxin.wu@intel.com> <1484623992-52988-3-git-send-email-jiaxin.wu@intel.com> <885aab27-f660-768b-59da-4d3e33f099ec@redhat.com> <895558F6EA4E3B41AC93A00D163B7274162948A8@SHSMSX103.ccr.corp.intel.com> <9cacd428-ac00-bab8-2329-6ea78c389dd2@redhat.com> <20170118092742.n3vp6moruovgtzkl@GaryWorkstation> In-Reply-To: <20170118092742.n3vp6moruovgtzkl@GaryWorkstation> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTI1NjQxYzktOTlmNS00OWQ5LTg0YzAtYzZjZGQ5YmZlYzAzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im5UTDFJdWIrQlJLbUJCdGlxdCs0cXNxWGZJcVdSSlJHZnNGQkNrOGRLUDg9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH v2 2/2] Nt32Pkg.dsc: Add flag to control HTTP connections X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:19:30 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > >> 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? > > >> > > > > > > Laszlo, > > > > > > As I talked above and according your requirement, we have the below > update choice: > > > > > > 1) The flag definition (ALLOW_HTTP_CONNECTIONS) with TRUE value to > allow the HTTP connections (the same to NT32). > > > > > > DEFINE ALLOW_HTTP_CONNECTIONS =3D TRUE > > > !if $(ALLOW_HTTP_CONNECTIONS) =3D=3D TRUE > > > gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE > > > !endif > > > > > > 2) Sets PcdAllowHttpConnections to TRUE whenever HTTP_BOOT_ENABLE is > TRUE > > > !if $( HTTP_BOOT_ENABLE) =3D=3D TRUE > > > gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE > > > !endif > > > > > > For 1), Flexible control! > > > For 2), we have no way to stop the HTTP connections while HTTPS is al= lowed. > That means no HTTP connections control switch. > > > > > > I still prefer 1), but that's depends on you since you are the OVMF p= latform > owner:). > > > > > > What's your opinion? > > > > I agree that for a security-oriented approach, for a production > > firmware, both the DEC default *and* the separate > ALLOW_HTTP_CONNECTIONS > > buid flag make sense. > > > > For the default -D HTTP_BOOT_ENABLE build of upstream OVMF however, I > > think ease of use is more important. In a home or company or team > > intranet setting, booting virtual machines from plain HTTP is > > acceptable, I think; forcing users to set up HTTPS on the server side, > > and mess with keys, would be an inconvenience, in my opionion. > > > > I guess we could introduce ALLOW_HTTP_CONNECTIONS with a TRUE default, > > but in general I try to minimize the number of different build flags > > (same way as MdeModulePkg seeks to minimize new PCDs); I think they > > quickly become confusing. > > > > Serious users (like distros shipping OVMF) can flip the PCD in the DSC > > files anyway. > > > > So, I prefer (2). Jordan, Gary, what do you guys think? > > > (2) sounds reasonable to me. Maybe we can also explain the PCD in the > comment or README to help the user to make the decision. >=20 Ok, I will append a third patch for OVMF with solution (2) but keep the ALL= OW_HTTP_CONNECTIONS only for Nt32Pkg. !if $( HTTP_BOOT_ENABLE) =3D=3D TRUE gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE !endif Thanks all of your comments. Jiaxin > Thanks, >=20 > Gary Lin >=20 > > Thanks! > > Laszlo > > > > > > > >> (Note that in "OvmfPkgIa32X64.dsc", the setting should likely go und= er > > >> [PcdsFixedAtBuild.X64].) > > >> > > >> Thanks! > > >> Laszlo > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel