irst.
Although I *did* like having "it's easy now..." as the commit comment.
That exercise has highlighted one more potential improvement — the
upgrade from 1.0.2e to 1.0.2f did require changing about 18 instances
of the string "1.0.2e" to "1.0.2f". I'll see if I
More stuff got hidden. Some of this is tolerable. Other bits are
horrid, but given that we expose *requires* that we know the size
of the data structure, it's hard to see how we can avoid it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
Cryp
ontributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch | 323 -
CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt| 6 +-
CryptoPkg/Library/OpensslLib/opensslconf.h
ually.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 389 +---
CryptoPkg/Library/OpensslLib/process_files.sh | 82 +
2 files changed, 93 insertions(+), 378 deletions(-)
diff --git a/Cryp
en we update to 1.1, we can just kill Install.cmd completely (as well
as the patching step too, hopefully.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/CryptoPkg.dec | 1 +
CryptoPkg/Include/openssl/README
, and stand alone.
The last patch in the series stands alone for reasons which will be
obvious when you see it.
David Woodhouse (7):
CryptoPkg: Use OpenSSL include directory directly
CryptoPkg/OpensslLib: Include complete copy of opensslconf.h
CryptoPkg/OpensslLib: Update OpenSSL
On Thu, 2015-12-03 at 15:26 +0100, Ard Biesheuvel wrote:
> On 3 December 2015 at 12:26, Ard Biesheuvel wrote:
> > On 3 December 2015 at 12:17, David Woodhouse wrote:
> > > On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
> > > > The RVCT compiler chokes on
On Thu, 2015-12-03 at 13:13 +0100, Ard Biesheuvel wrote:
>
> OK, then I think we're good. I can still build my secure boot enabled
> platform with those files removed from OpensslLib, so they are not
> used. And in fact, the timestamp related functions are duplicated in
> BaseCryptLib anyway, whic
On Thu, 2015-12-03 at 12:32 +0100, Ard Biesheuvel wrote:
>
>
> ... or maybe not (I hit send too soon)
>
> It does not appear that there are any tests for those #defines
> anywhere, and the pqueue and ts_* source files are built
> unconditionally by the standard Makefiles.
That might be OK. I th
On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
> This comments out the pqueue and ts_* source files from the
> OpensslLib build, since they have no users.
These are going to be auto-generated from the OpenSSL build system (see
the process_files.sh script in the patches I've been submitti
On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
> The RVCT compiler chokes on a couple of issues in upstream OpenSSL
> that
> can be confirmed to be non-issues by inspection. So just ignore these
> warnings entirely.
I still maintain this needs a reference to bug reports — either
*compile
that the
upstream TS functions don't give us?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_
On Tue, 2015-11-24 at 14:19 +, Cohen, Eugene wrote:
>
> Here's a patch with this changes:
>
> ---
> edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf| 2
> +-
> edk2/CryptoPkg/Library/OpensslLib/openssl-1.0.2d/crypto/x509/x509_vfy.c | 1 +
> 2 files changed, 2 inserti
Testing list destination rewrites; apologies for the noise.
--
dwmw2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Testing list destination rewrites; apologies for the noise.
--
dwmw2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
trip unused functions/data.
>
> Yeah, that is still true, unfortunately.
Is it really still true?
https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14
If the patch that Nick committed to fix this *isn't* working, please
add a comment telling him that :)
--
David Woodhouse
See http://www.infradead.org/rpr.html
X-SRS-Rewrite: SMTP reverse-path rewritten from by
twosheds.infradead.org
See http://www.infradead.org/rpr.html
> On 2015-08-17 11:25:41, David Woodhouse wrote:
>> On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
>> > Can'
On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
> Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
Not for testing LLP64, no.
> I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
> based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
>
d rather see it updated to work with modern MinGW rather than
deprecated.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
On Fri, 2015-08-14 at 17:03 +0800, Gary Ching-Pang Lin wrote:
> I've tested the HttpBoot implementation with a simple test
> environment:
Is this tested with IPv6?
--
David WoodhouseOpen Source Technology Centre
david.woodho..
On Thu, 2015-08-13 at 23:54 -0500, Scott Duplichan wrote:
> David Woodhouse [mailto:dw...@infradead.org] wrote:
> ]On Thu, 2015-08-13 at 13:25 -0500, Scott Duplichan wrote:
> ]> A while back I experimented with mingw as a Windows hosted gcc tool
> ]> chain for EDK2. It
tps://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169
Although I only saw this in OpenSSL code, not elsewhere. Not sure why.
Perhaps nothing else uses enough stack to trigger it.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com I
s+MSVC.
(I wonder if we could get the MSVC build running under wine... now
*that* would be useful)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smim
yway. You might make it work with -fstack-check=specific:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME
From: David Woodhouse
This requires a version of OpenSSL HEAD with the following fixes:
RT3628: Allow filenames to be eliminated from compiled library
RT3955: Reduce stack usage in PKCS7_verify() and PKCS7_decrypt()
RT3964: Fix OPENSSL_NO_STDIO build
RT3965: Revert "OPENSSL_N
From: David Woodhouse
This updates to a version of the OpenSSL changes which is being submitted
upstream for inclusion in HEAD (which will be OpenSSL 1.1.x) and hopefully
also 1.0.2.
Generated from the OpenSSL_1_0_2-stable branch of git repository at
http://git.infradead.org/users/dwmw2
From: David Woodhouse
With the patches which are going into upstream OpenSSL, we are able to run
the standard Configure script and import the result into the EDK II source
repository for others to build natively. The opensslconf.h file and the
list of files in OpensslLib.inf don't need
From: David Woodhouse
In OpenSSL 1.1, all the public header files will reside directly in the
include/openssl/ directory of the source tree, rather than being symbolic
links. So we can just add that directory to our include path and not have
to worry about copying files around.
In fact, that
From: David Woodhouse
This can be an auto-generated file, and it *isn't* in the OpenSSL git tree;
it's only in the generated tarballs. So rather than including it in our
OpenSSL patch, just have the user copy it into place.
This makes it easier to manage changes, and is a step towa
From: David Woodhouse
Putting these on the command line as we do at the moment means that they
are *only* visible when actually building the OpenSSL code itself. When
building other things like BaseCryptLib, they were missing. Which could
lead to discrepancies in structures defined by the header
From: David Woodhouse
We were manually setting -DSIXTY_FOUR_BIT_LONG or -DTHIRTY_TWO_BIT on
the compiler command line when building OpensslLib itself, but not when
building BaseCryptLib.
But when building BaseCryptLib, we weren't setting OPENSSL_SYS_UEFI
*either*. This meant that *that*
From: David Woodhouse
OpenSSL ought to work this out for itself when OPENSSL_SYS_UEFI is set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2d.patch | 11 +++
CryptoPkg/Library/OpensslLib
From: David Woodhouse
OpenSSL HEAD is in the process of adding this flag to disable the validity
time checking. Backport it to 1.0.2 and use it too, for consistency.
https://rt.openssl.org/Ticket/Display.html?id=3951&user=guest&pass=guest
Contributed-under: TianoCore Contribution Agree
From: David Woodhouse
Instead of patching OpenSSL to add EFIAPI to the one varargs function we
actually *noticed* breakage in, let's fix the problem in a more coherent
way by undefining NO_BUILTIN_VA_FUNCS.
That way, the VA_START and similar macros will actually do the right
thing fo
From: David Woodhouse
Since OpenSSL 1.0.2 we can set this flag on the X509_STORE to instruct
OpenSSL to accept non-self-signed certificates as trusted. So we don't
need two entirely identical copies of a verify_cb() function which makes
it ignore the resulting errors.
We also *didn't
From: David Woodhouse
Use the new OBJ_get0_data() accessor to compare the data, and actually
check the length of the object too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
Tested-by: Laszlo Ersek
---
CryptoPkg/Library/BaseCryptLib/Pk
From: David Woodhouse
In OpenSSL 1.1, the X509_ATTRIBUTE becomes an opaque structure and we will
no longer get away with accessing its members directly. Use the accessor
functions X509_ATTRIBUTE_get0_object0() and X509_ATTRIBUTE_get0_type()
instead.
Also be slightly more defensive about
From: David Woodhouse
OpenSSL 1.1 has cleaned up its include files a little, and it will now
be necessary to directly include things like if we want
to use them, rather than assuming they are included indirectly from
other headers.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed
From: David Woodhouse
OpenSSL 1.1 introduces new OBJ_get0_data() and OBJ_length() accessor
functions and makes ASN1_OBJECT an opaque type.
Unlike the accessors in previous commits which *did* actually exist
already but just weren't mandatory, these don't exist in older versions
of O
From: David Woodhouse
In OpenSSL 1.1, the X509_NAME becomes an opaque structure and we will no
longer get away with accessing its members directly. Use i2d_X509_NAME()
instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
Tested-by: Laszlo Ersek
e
to calls to __chkstk_ms (see GCC PR#67169).
Git tree at http://git.infradead.org/users/dwmw2/edk2.git
David Woodhouse (16):
CryptoPkg/BaseCryptLib: Add missing OpenSSL includes
CryptoPkg/BaseCryptLib: Use i2d_X509_NAME() instead of abusing X509_NAME
CryptoPkg/BaseCryptLib: Use acc
ulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c:224:9:
note: ‘PageTables’ was declared here
UINTN PageTables;
^
cc1: all warnings being treated as errors
I think the warning is false, and you should probably file a GCC PR for
it as well as working around it in the s
On Wed, 2015-08-05 at 09:43 -0500, Scott Duplichan wrote:
> Here is how you can build Ovmf on Windows (tested with Win7 x64):
>
> 1) Get edk2, including BaseTools\Bin\Win32. You are right, git doesn't
> work for getting the external BaseTools\Bin\Win32.
>
> 2) Install Visual Studio 2008. EDK2 sup
On Wed, 2015-08-05 at 12:11 +0200, Laszlo Ersek wrote:
> On 08/05/15 10:21, David Woodhouse wrote:
> > On Wed, 2015-08-05 at 01:27 -0500, Scott Duplichan wrote:
> > >
> > > How can we make these files use consistent line endings?
> > > Would a patch wor
wrong with the 'build', too.
Would it be easier to avoid the pain of actually trying to use Windows,
and test my changes with MinGW instead? Should UNIXGCC work?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
hould use that facility when we finally make the switch?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptogra
On Tue, 2015-08-04 at 13:07 +0200, Laszlo Ersek wrote:
> On 08/04/15 12:42, David Woodhouse wrote:
> > Then (if the BDS gets it right) you should be able to boot legacy
> > targets as well as native UEFI targets.
>
> Okay, if you don't have your guests any longer, I gues
tp://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29
and then drop it into OvmfPkg/Csm/Csm16/Csm16.bin and build with -DCSM_ENABLE.
Then (if the BDS gets it right) you should be able to boot legacy
targets as well as native UEFI targets.
--
David Woodhouse
.h
--- crypto/x509v3/ext_dat.hThu Jun 11 21:50:12 2015
+++ crypto/x509v3/ext_dat.hFri Jun 12 11:11:03 2015
--
2.4.3
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com In
nction for X509VerifyCert(), but
probably should have done. So that can get X509_V_FLAG_PARTIAL_CHAIN for
consistency, too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
.../Library/BaseCryptLib/Pk/CryptPkcs7Verify.c | 93 ++
On Mon, 2015-07-27 at 17:25 +0100, David Woodhouse wrote:
> Instead of hacking OpenSSL to remove the validity time checks, which met
> with some resistance upstream (even when done in a cleaner fashion), just
> ensure that we have a verify_cb registered and explicitly i
On Mon, 2015-08-03 at 13:41 +0800, Ruiyu Ni wrote:
> A new BDS and UiApp was created in MdeModulePkg and are already
> used in Nt32Pkg.
> The patch changes the OvmfPkg to use the new BDS and UiApp as well.
Hi Ruiyu, were these changes tested with the SeaBIOS CSM?
--
David
cleanups. I'll include your Tested-By on those
too, unless you object.
Thanks!
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryp
Which keeps most of the spam out, *and* lets senders know what they did
wrong. Otherwise, they might assume their message got through... or
*will* get through after moderation.
> I know many projects are able to get away with wide-open posting, but
> I don't know how t
?
There were a bunch of patches which started to address some of that in
http://git.infradead.org/users/dwmw2/edk2.git/shortlog/refs/heads/csm16
(And I'm still mildly annoyed that the EFI_COMPATIBILITY16_TABLE update
for the new spec is *still* not merged...)
--
David Woodhouse
dds support for, and
*requires* OpenSSL HEAD.
To test with 1.0.2d you indeed want the penultimate commit in the tree
which is what you used. Thanks for testing!
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
the existing 1.0.2d support too.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel
e path *entirely*. We have all
those things like which include OpensslSupport.h for the
benefit of OpenSSL.
Now that we're properly using OPENSSL_SYS_UEFI instead of
OPENSSL_SYS_UWIN, we can go through the OpenSSL code and eliminate a
lot of those too. But let's get the first
ed, rather than having to undefine them on the
command line.
But again, that's something that can wait until the first pass is done.
I'd *also* like to see if we can eliminate some of those compiler
warnings. Isn't it rather scary that we have to build the crypto
package wi
the result
of time() into the mix. We're adding no *more* entropy with the
gettimeofday() result.
But I think there are a lot of our 'support' functions/macros — and
even whole header files — which can slowly be eliminated once we have
taught OpenSSL that it's
CTORY/$FILE\\r\\
+ fi
+ done
+ fi
+ ;;
+ esac
+done
+echo -e \\r
+}
+
+filelist < openssl/MINFO | sed -n -f - -i OpensslLib.inf
+
+# We can tell Windows users to put this back manually if they can't run
+# C
Should be: -mabi=ms
Thanks. Both fixed in my tree at
http://git.infradead.org/users/dwmw2/edk2.git/ and will be in the next
resend or pull request.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Cor
-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
.../Library/BaseCryptLib/Pk/CryptPkcs7Verify.c | 6 +++-
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c| 6 +++-
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c | 36 ++
.../Library
be easily built with something like gnu-efi.
That would make it an easier target for build testing, etc.
If we can avoid anything that's truly EDK2-specific, that might be
useful.
(Yes, that might involve reimplementing a lot of OpensslSupport.h in
OpenSSL in different ways.)
--
David
s a project for another day.
For now, just fix the OpenSSL build in a cleaner fashion.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
.../Library/OpensslLib/EDKII_openssl-1.0.2d.patch | 34 --
CryptoPkg/Library/OpensslLib
ull in the
version from opensslconf.h under and circumstances.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/Include/OpenSslSupport.h | 26 ++
CryptoPkg/Library/BaseCryptLib/InternalCryptL
IN
definition that wasn't actually *doing* anything.
Second, undefine NO_BUILTIN_VA_FUNCS in the gcc/x86_64 build so that
VA_START et al actually do the right thing for non-EFIAPI functions, as
discussed. Then we can drop the hack which adds EFIAPI to the
definition of ERR_add_erro
8..6327a64 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -76,6 +76,11 @@ extern "C" {
# define OPENSSL_SYS_NETWARE
# endif
+/* UEFI -- */
+# if defined(OPENSSL_SYS_UEFI)
+# undef OPENSSL_SYS_UNIX
+# endif
+
/*
Use the new OBJ_get0_data() accessor to compare the data, and actually
check the length of the object too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
But actually, I just threw up in my mouth a little bit. Because OpenSSL
doesn't grok the OID
OpenSSL 1.1 has cleaned up its include files a little, and it will now
be necessary to directly include things like if we want
to use them, rather than assuming they are included indirectly from
other headers.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
s which do the right thing, for
compatibility.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h | 7 +++
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 4 ++--
2 files changed, 9 insertions(+), 2
.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
b/CryptoPkg/Library/BaseCryptLib/Pk
In OpenSSL 1.1, the X509_NAME becomes an opaque structure and we will no
longer get away with accessing its members directly. Use i2d_X509_NAME()
instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
wn patches for it, and it's easy to update
to new versions.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptogr
g it working. I wonder if we
can put them in a separate section, and have a script post-process the
objects looking for discrepancies? I also thought about prepending
something to the function names, but I can't see how that could be made
to work. Any other ideas?
--
dwmw2
--
David Woodhouse
See http://www.infradead.org/rpr.html
X-SRS-Rewrite: SMTP reverse-path rewritten from by
twosheds.infradead.org
See http://www.infradead.org/rpr.html
> On 2015-07-23 12:54:24, David Woodhouse wrote:
>> (The 01.org list seems to be rejecting all my posts, so I'll repost to
>&g
See http://www.infradead.org/rpr.html
X-SRS-Rewrite: SMTP reverse-path rewritten from by
twosheds.infradead.org
See http://www.infradead.org/rpr.html
> On 2015-07-23 12:36:34, David Woodhouse wrote:
>> On Thu, 2015-07-23 at 11:50 -0700, Jordan Justen wrote:
>> > I think
101 - 177 of 177 matches
Mail list logo
