From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web09.6064.1572310042516413052 for ; Mon, 28 Oct 2019 17:47:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WtxHhHbI; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572310041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3CdGqGFWXfXrhJEoQAVExV7kkPyIduRpy25v3M/iEN4=; b=WtxHhHbIh8ty9EiP8nKhvZEZaPwYrsPcqrVge5M191N1gEO8BwoycZqLNpKg7I0OlYF+pe 1AdOxK2FuQUXV2tDUdmXC0jgAeIdSIJS2MfjJw9OKZq3fRHz4J7fMbc6E4tdIioCrS6kaK GOLPjA+6C+sobz8oK2nd+1uyOteKBho= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-275-uSZS7aT5ODuQkSksaa5TxQ-1; Mon, 28 Oct 2019 20:47:18 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E541C476; Tue, 29 Oct 2019 00:47:16 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-28.ams2.redhat.com [10.36.116.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F893600F0; Tue, 29 Oct 2019 00:47:14 +0000 (UTC) Subject: Re: [PATCH v2 4/8] CryptoPkg/Crt: satisfy "inet_pton.c" dependencies (CVE-2019-14553) To: David Woodhouse , edk2-devel-groups-io Cc: Jian J Wang , Jiaxin Wu , Sivaraman Nainar , Xiaoyu Lu References: <20191026053719.10453-1-lersek@redhat.com> <20191026053719.10453-5-lersek@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 29 Oct 2019 01:47:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: uSZS7aT5ODuQkSksaa5TxQ-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/28/19 14:06, David Woodhouse wrote: > On Sat, 2019-10-26 at 07:37 +0200, Laszlo Ersek wrote: >> In a later patch in this series, we're going to resurrect "inet_pton.c" >> (originally from the StdLib package). That source file has a number of >> standard C and BSD socket dependencies. Provide those dependencies here: >> >> - The header files below will simply #include : >> >> - arpa/inet.h >> - arpa/nameser.h >> - netinet/in.h >> - sys/param.h >> - sys/socket.h >> >> - EAFNOSUPPORT comes from "StdLib/Include/errno.h", at commit >> e2d3a25f1a31; which is the commit immediately preceding the removal of >> StdLib from edk2 (964f432b9b0a). >> >> Note that the other error macro, which we alread #define, namely EINVA= L, >> has a value (22) that also matches "StdLib/Include/errno.h". >> >> - The AF_INET and AF_INET6 address family macros come from >> "StdLib/Include/sys/socket.h". >> >> - The NS_INT16SZ, NS_INADDRSZ and NS_IN6ADDRSZ macros come from >> "StdLib/Include/arpa/nameser.h". >> >> - The "u_int" and "u_char" types come from "StdLib/Include/sys/types.h". >=20 > Hm. >=20 > If you're porting a whole standard C library to EDK2 then I suppose it > makes sense to build up all this infrastructure for it. >=20 > But in this case when it's only the single inet_pton() function that > you need, perhaps it makes more sense to 'port' that one function to > UEFI (or just reimplement it looking like EDK2 code), instead of > bringing all this stuff along with it? I didn't want to take responsibility for touching any of that code -- I wanted it to be a piece of the puzzle that we'd just drop in. Its coding style is very foreign to edk2 norms, so once we started, we wouldn't stop before rewriting it more or less completely. (For example it quite frequently consumes the values that assignment expressions evaluate to, which is a huge no-no in edk2, as far as I understand.) I have no capacity for such a rework (or additional ownership / responsibility), sorry. I worked from Friday evening to Saturday ~6-7AM as my "second sprint" on this code and its testing, until I was satisfied with the test coverage. I apologize but I simply cannot repeat that. This is all I can contribute code-wise (and testing-wise) to fixing this issue. Thanks Laszlo