On 13 August 2015 at 08:27, Ard Biesheuvel wrote:
> On 12 August 2015 at 23:48, David Woodhouse wrote:
>> On Wed, 2015-08-12 at 09:08 +0200, Ard Biesheuvel wrote:
>>> Is there any reason these are kept out of sync? Are UNIXGCC and CYGGCC
>>> known to be widely used in some particular environment?
On 12 August 2015 at 23:48, David Woodhouse wrote:
> On Wed, 2015-08-12 at 09:08 +0200, Ard Biesheuvel wrote:
>> Is there any reason these are kept out of sync? Are UNIXGCC and CYGGCC
>> known to be widely used in some particular environment? If not, I
>> think it makes sense to merge them, i.e.,
On 8/12/15 11:47 PM, Gao, Liming wrote:
Add -std=gnu89 to the CC flags.
This is the default for gcc 4.x, so it doesn't change anything for those tool
chains (other than making the command line slightly longer). GCC5 however,
defaults to -std=gnu11. By adding -std=gnu89, gcc5 will behave
On 13 August 2015 at 07:44, Gao, Liming wrote:
> Reviewed-by: Liming Gao
>
Thanks
Committed as SVN r18217
--
Ard.
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, August 13, 2015 1:19 PM
> To: edk2-devel@lists.01.org; ler...@redhat.com;
I agree to unify GCC option and add -std=gun89 flag.
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Scott
Duplichan
Sent: Thursday, August 13, 2015 9:25 AM
To: 'Ard Biesheuvel'; edk2-de...@ml01.01.org; Justen, Jordan L; Liu, Yingke
Reviewed-by: Liming Gao
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, August 13, 2015 1:19 PM
To: edk2-devel@lists.01.org; ler...@redhat.com; Liu, Yingke D
Cc: Gao, Liming; Ard Biesheuvel
Subject: [PATCH v2] BaseTools IA32/X64: prevent .eh_fra
After the recent GNU linker script changes, the following warning is
emitted many times during the OVMF build:
BFD: <...>: warning: Empty loadable segment detected, is this intentional ?
This is caused by the fact that, now that the section layout has changed
somewhat, the .eh_frame section is as
On 08/13/2015 11:10 AM, Heyi Guo wrote:
Interrupt must be disabled before we storing ELR and other system
registers, or else ELR will be overridden by interrupt reentrance.
This bug is critical as we may get occasional exception or dead loop
when interrupt reentrance occurs:
After increasi
Interrupt must be disabled before we storing ELR and other system
registers, or else ELR will be overridden by interrupt reentrance.
This bug is critical as we may get occasional exception or dead loop
when interrupt reentrance occurs:
After increasing SP ... Before popping out registers
Or
A
Right. Thanks a lot to catch it.
I will fix it before check in.
Thank you
Yao Jiewen
-Original Message-
From: Zhang, Chao B
Sent: Thursday, August 13, 2015 9:32 AM
To: Yao, Jiewen; edk2-devel@lists.01.org
Subject: RE: [patch 1/2] Add TPM2 definition in trusted computing group.
Hi Jiewen
Hi Samer,
This changing caused ifconfig in shell failed to get the address from dhcp with
the command "ifconfig -s eth0 dhcp" since the default policy is dhcp already.
Yes, it does. We have been aware of this ifconfig issue and will fix it by
following the rule to starting the Ip4 auto configurat
Hi Jiewen:
Comments for ManufacturerID in tdEFI_TCG2_BOOT_SERVICE_CAPABILITY from
Tcg2Protocol.h have unreadable character.
Others are good to me.
Reviewed-by: Chao Zhang
Thanks & Best regards
Chao Zhang
-Original Message-
From: Yao, Jiewen
Sent: Tuesday, August 11, 2015
Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote:
]Sent: Friday, August 07, 2015 10:05 AM
]To: edk2-de...@ml01.01.org; jordan.l.jus...@intel.com; yingke.d@intel.com
]Cc: Ard Biesheuvel
]Subject: [edk2] [RFC PATCH 0/4] unify GCC command line options
]
]This unifies all command line opti
There is an issue in this implementation
1. This patch addresses the problem of DHCP being triggered during boot up.
2. But the below piece of code will not let the DHCP DORA get triggered when,
for instance, running "ifconfig -s eth0 dhcp" in the UEFI Shell:
if (NewPolicy == Instance->Policy
On Wed, 2015-08-12 at 09:08 +0200, Ard Biesheuvel wrote:
> Is there any reason these are kept out of sync? Are UNIXGCC and CYGGCC
> known to be widely used in some particular environment? If not, I
> think it makes sense to merge them, i.e., retain the UNIXGCC and
> CYGGCC toolchain names, but make
I just did an 'interview' with LegbaCore today:
http://firmwaresecurity.com/2015/08/12/interview-with-legbacore-and-their-oprom-checker-ships/
In addition to previous UEFI Forum plugfest advice from Phoenix (RUN
CHIPSEC!!), also note below comment from LegbaCore.
They were professional enough to
On 08/12/15 20:57, Ard Biesheuvel wrote:
> After the recent GNU linker script changes, the following warning is
> emitted many times during the OVMF/X86 build:
>
> BFD: <...>: warning: Empty loadable segment detected, is this intentional ?
>
> This is caused by the fact that, now that the section
After the recent GNU linker script changes, the following warning is
emitted many times during the OVMF/X86 build:
BFD: <...>: warning: Empty loadable segment detected, is this intentional ?
This is caused by the fact that, now that the section layout has changed
somewhat, the .eh_frame section i
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_NO_xxx cle
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/openssl.
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 to be mana
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 *al
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 towards better
int
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* build wa
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/Openss
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 Agreement 1.0
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 for non-EFIAPI
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* use that v
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/CryptAuthentico
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 unlikely
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 OpenSSL. So in
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
---
C
Not sure which version this is; let's call it v3 despite the fact that
I think it's actually the first time all this lot has been posted
together in a single coherent series.
All the OpenSSL fixes are filed in upstream RT and in my git tree at
http://git.infradead.org/users/dwmw2/openssl.git/ — a
Continuing:
On 08/12/15 00:53, Laszlo Ersek wrote:
> On 08/03/15 07:41, Ruiyu Ni wrote:
>> Compare to the old BDS, the new BDS separates the UI part to a standalone
>> application UiApp.
>> QemuBootOrderLib was changed to depend on the UefiBootManagerLib.
> I've covered the following files thus f
On 10 August 2015 at 10:00, Gao, Liming wrote:
> Ard:
> This patch introduces GCC4X_ for common GCC option. It may be common for
> GCC5, GCC6... So, how about use GCC_ prefix for all GCC common option?
>
OK, I have been looking into this. It is mostly possible to fold all
GCC 4.x options into
37 matches
Mail list logo
