Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jordan Justen > Sent: Thursday, September 10, 2015 11:03 AM > On 2015-09-09 20:26:54, Andrew Fish wrote: > > > On Sep 9, 2015, at 5:41 PM, Jordan Justen > wrote: > > > On 2015-09-09 16:05:20, Andrew Fish wrote: > > >> So yo

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 11:19 PM, Alexander Graf wrote: > > > >> Am 10.09.2015 um 07:32 schrieb Jordan Justen : >> >> On 2015-09-09 20:26:54, Andrew Fish wrote: On Sep 9, 2015, at 5:41 PM, Jordan Justen wrote: > On 2015-09-09 16:05:20, Andrew Fish wrote: > So you have a legal

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 20:26:54, Andrew Fish wrote: > > On Sep 9, 2015, at 5:41 PM, Jordan Justen wrote: > > On 2015-09-09 16:05:20, Andrew Fish wrote: > >> So you have a legal degree and are speaking on behalf of your > >> employer on this subject? > > > > No and no. How about you? :) > > No but I have

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

Hi, afaik Android doesn't have sepc's, just advices and maybe "rules to allow the OEM to install Google services", but there actually are some reasons not to use GUID's. First off, the names aren't always the same, heck not even the number of partitions is the same. some vendors use boot and reco

Re: [edk2] [PATCH v2 5/5] ArmPkg/Mmu: Fix potential page table memory leak

On 09/09/2015 09:38 PM, Ard Biesheuvel wrote: On 9 September 2015 at 12:35, Ard Biesheuvel wrote: On 9 September 2015 at 11:53, Heyi Guo wrote: During page entry attribute update, if there are table entries between starting BlockEntry and LastBlockEntry, table entries will be set as block e

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 5:41 PM, Jordan Justen wrote: > > On 2015-09-09 16:05:20, Andrew Fish wrote: >> >>> On Sep 9, 2015, at 3:24 PM, Jordan Justen wrote: >>> >>> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: The recent expansions beyond BSD where all permissive licenses (BSD

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 2015/9/9 19:30, Laszlo Ersek wrote: On 09/09/15 13:07, Ian Campbell wrote: On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote: Thanks for all the info, I think I get it (although its not clear to me whether how an app can claim to be UEFI 2.5 capable and what the transition plan for legac

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 2015/9/9 18:48, Laszlo Ersek wrote: me neither :) but if this (executable code on stack) is happening in grub is there something which is explicitly forbidden to UEFI apps by the UEFI spec? Yes, there is. This small OvmfPkg patch only enables the edk2 feature added by Star Zeng in

Re: [edk2] [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath

Reviewed-by: Ye Ting -Original Message- From: Zhang, Lubo Sent: Wednesday, September 09, 2015 5:10 PM To: edk2-devel@lists.01.org Cc: Fu, Siyuan; Ye, Ting Subject: [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath PXE driver's LoadFile protocol should check the

Re: [edk2] [patch] MdeModulePkg: PXE Driver's LoadFile protocol should check FilePath

Reviewed-by: Ye Ting -Original Message- From: Zhang, Lubo Sent: Wednesday, September 09, 2015 5:09 PM To: edk2-devel@lists.01.org Cc: Fu, Siyuan; Ye, Ting Subject: [patch] MdeModulePkg: PXE Driver's LoadFile protocol should check FilePath PXE driver's LoadFile protocol should check th

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 16:05:20, Andrew Fish wrote: > > > On Sep 9, 2015, at 3:24 PM, Jordan Justen wrote: > > > > On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: > >> The recent expansions beyond BSD where all permissive licenses (BSD > >> like) as far as I can tell. > >> > >> I agree with Andrew,

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

Michael Is there a spec about the GPT partition naming rule in Android world? Could you share the link? If these GPT partitions have special naming rules (boot, recovery…), why they don’t define specific partition type guid just like EFI SYSTEM PARTITION to distinguish them? For example, EFI

Re: [edk2] [PATCH v2 0/2] MdeModulePkg: ScsiDiskDxe: handle EFI_BAD_BUFFER_SIZE from SCSI host adapter

Series Reviewed-by: Feng Tian Thanks Feng -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, September 09, 2015 17:39 To: edk2-de...@ml01.01.org Cc: Tian, Feng Subject: [PATCH v2 0/2] MdeModulePkg: ScsiDiskDxe: handle EFI_BAD_BUFFER_SIZE from SCSI host ad

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> I don’t understand the issue BSD licensed code? > It should be compatible with the GPL? > The GPL code could merge bug fixes from the BSD > source base as needed. It is just the BDS source > base that can not take back GPL code. I'm not sure I understand, I presume you understand all BSD/GPL lic

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 3:24 PM, Jordan Justen wrote: > > On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: >> The recent expansions beyond BSD where all permissive licenses (BSD >> like) as far as I can tell. >> >> I agree with Andrew, opening the door for GPL licensed code in EDK2 >> will hav

Re: [edk2] [Xen-devel] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:34, Ian Campbell wrote: > On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list > > Thanks for including xen-devel in this. Was anyone f

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 10:57 AM, Jordan Justen wrote: > > On 2015-09-09 10:04:50, Andrew Fish wrote: >> >>> On Sep 9, 2015, at 9:17 AM, Jordan Justen wrote: >>> >>> So, related to this, I wonder how the community would feel about a >>> GplDriverPkg. Would the community allow it as a new package

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: > The recent expansions beyond BSD where all permissive licenses (BSD > like) as far as I can tell. > > I agree with Andrew, opening the door for GPL licensed code in EDK2 > will have severe consequences for products that are built using > EDK2.

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 1:37 PM, Blibbet wrote: > > Short term an OVMF-centric solution is good. > > But long term, I think Linux needs a Linux-friendly IBV to build native > UEFI -- as well as OVMF-flavored UEFI -- with non-BSD licensed community > code. I don’t understand the issue BSD licensed

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

Short term an OVMF-centric solution is good. But long term, I think Linux needs a Linux-friendly IBV to build native UEFI -- as well as OVMF-flavored UEFI -- with non-BSD licensed community code. If you restrict this to just OVMF, any GPL innovations will only happen at virtual level. Right now, b

Re: [edk2] UEFI and NIST SP-147 compliance

On 09/09/2015 11:49 AM, Bill Paul wrote: [...] > Oh sure, no pressure. > > As you say, the closed source nature of most BIOSes makes complying with these > requirements nearly impossible for most organizations. The only exceptions I > can think of are big companies with connections to the IBVs (e.g

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

Well, FatPkg is only superficially permissive and not even open source, so there is a precedent. (A precedent that, I might add, happens to violate SourceForge's the off service). When we import edk2 into Fedora we just remove FatBinPkg. We would think twice before contributing to it, but do no

[edk2] [PATCH] ArmPlatformPkg/ARMJunoPkg: Correct Interrupt Numbers for PCIe Root port

Support for PCI IO range with ACPI on JUNO. Interrupt Number Reference: http://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_trm.pdf table 3-3 page 3-7 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Supreeth Venkatesh --- .../ArmJunoPkg/AcpiTables/

Re: [edk2] UEFI and NIST SP-147 compliance

Of all the gin joints in all the towns in all the world, Blibbet had to walk into mine at 11:14:29 on Wednesday 09 September 2015 and say: > I have some questions about UEFI and the below excerpts from NIST > SP-147, from sections 3.1.1 and 3.2. > > Is this "gold master image" possible with UEFI

[edk2] UEFI and NIST SP-147 compliance

I have some questions about UEFI and the below excerpts from NIST SP-147, from sections 3.1.1 and 3.2. Is this "gold master image" possible with UEFI? Are any enterprises practicing this? What tools are they using? I can't any information on any enterprise who does this today. I currently doubt i

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

yes, I tested it and it works. I use Linaro's linux-gnueabi 4.9 toolchain from here: http://releases.linaro.org/15.05/components/toolchain/binaries/arm-linux-gnueabi/ I've copied the manifest info so you don't have to download the toolchain: http://pastebin.com/jvyPcMkz On Wed, Sep 9, 2015 at 7:4

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 10:04:50, Andrew Fish wrote: > > > On Sep 9, 2015, at 9:17 AM, Jordan Justen wrote: > > > > So, related to this, I wonder how the community would feel about a > > GplDriverPkg. Would the community allow it as a new package in EDK II > > directly, or would a separate repo be require

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 9 September 2015 at 18:49, Michael Zimmermann wrote: > thx, the patches work just fine.(they apply and the runtime warnings are > gone). OK, great. May I take that as a tested-by? Which GCC version are you using btw? > if edk2 patches aren't that usable, how the maintainers test it? because >

Re: [edk2] [PATCH 3/3] ArmVirtPkg: set max physical address width to 40 bits

> On Sep 9, 2015, at 10:02 AM, Ard Biesheuvel wrote: > >> >> >> The 1:1 mapping only goes to 4 GB, so anything beyond that is never >> mapped anyway. >> >> >> This is the state when you hand off to the OS, but it is possible as part of >> the boot process to have a driver do some alternate m

Re: [edk2] [PATCH 3/3] ArmVirtPkg: set max physical address width to 40 bits

On 09/09/15 19:02, Ard Biesheuvel wrote: > On 9 September 2015 at 17:42, Andrew Fish wrote: >> >> On Sep 9, 2015, at 7:03 AM, Ard Biesheuvel >> wrote: >> >> On 9 September 2015 at 15:59, Laszlo Ersek wrote: >> >> On 09/08/15 19:35, Ard Biesheuvel wrote: >> >> When executing on a LPAE capable 32-

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 9:17 AM, Jordan Justen wrote: > > On 2015-09-09 01:57:51, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list, after some off-list discussion (I tried >> to in

Re: [edk2] [PATCH 3/3] ArmVirtPkg: set max physical address width to 40 bits

On 9 September 2015 at 17:42, Andrew Fish wrote: > > On Sep 9, 2015, at 7:03 AM, Ard Biesheuvel > wrote: > > On 9 September 2015 at 15:59, Laszlo Ersek wrote: > > On 09/08/15 19:35, Ard Biesheuvel wrote: > > When executing on a LPAE capable 32-bit ARM platform, we support > up to 40 bits of phys

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 09/09/15 18:49, Michael Zimmermann wrote: > thx, the patches work just fine.(they apply and the runtime warnings are > gone). > if edk2 patches aren't that usable, how the maintainers test it? because > usually people don't post git links. For shorter series, they are willing to mangle some (no

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

thx, the patches work just fine.(they apply and the runtime warnings are gone). if edk2 patches aren't that usable, how the maintainers test it? because usually people don't post git links. On Wed, Sep 9, 2015 at 6:31 PM, Ard Biesheuvel wrote: > On 9 September 2015 at 18:21, Michael Zimmermann >

Re: [edk2] [Xen-devel] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:34, Ian Campbell wrote: > On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list > > Thanks for including xen-devel in this. Was anyone f

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 09/09/15 18:21, Michael Zimmermann wrote: > what I meant is that git am fails: > Applying: BaseTools/GenFw: remove ARM and RVCT references from ELF64 code > error: patch failed: BaseTools/Source/C/GenFw/Elf64Convert.c:360 > error: BaseTools/Source/C/GenFw/Elf64Convert.c: patch does not apply > P

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 9 September 2015 at 18:21, Michael Zimmermann wrote: > what I meant is that git am fails: > Applying: BaseTools/GenFw: remove ARM and RVCT references from ELF64 code > error: patch failed: BaseTools/Source/C/GenFw/Elf64Convert.c:360 > error: BaseTools/Source/C/GenFw/Elf64Convert.c: patch does n

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 09/09/15 18:17, Jordan Justen wrote: > On 2015-09-09 01:57:51, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list, after some off-list discussion (I tried >> to incorporate comments

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

what I meant is that git am fails: Applying: BaseTools/GenFw: remove ARM and RVCT references from ELF64 code error: patch failed: BaseTools/Source/C/GenFw/Elf64Convert.c:360 error: BaseTools/Source/C/GenFw/Elf64Convert.c: patch does not apply Patch failed at 0001 BaseTools/GenFw: remove ARM and RVC

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

> On 9 sep. 2015, at 18:10, Michael Zimmermann wrote: > > Yes I'm using 32bit ARM :) > thx for the patches - unfortunatelythe patches fail for me. > Did you regenerate Conf/tools_def.txt and rebuild the BaseTools/ ? >> On Wed, Sep 9, 2015 at 5:33 PM, Ard Biesheuvel >> wrote: >> On 9 Septe

[edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 01:57:51, Laszlo Ersek wrote: > On 08/10/15 18:24, Laszlo Ersek wrote: > > Hi. > > > > Let's do an OVMF BoF at this year's KVM Forum too. > > Here's a preliminary task list, after some off-list discussion (I tried > to incorporate comments): > > - create GPL'd fork called "ovmf" fo

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Yes I'm using 32bit ARM :) thx for the patches - unfortunatelythe patches fail for me. On Wed, Sep 9, 2015 at 5:33 PM, Ard Biesheuvel wrote: > On 9 September 2015 at 17:26, Gao, Liming wrote: > > Michael: > > Do you use the linker script BaseTools/Scripts/GccBase.lds and -z > common-page-size

Re: [edk2] [PATCH 2/2] ShellPkg: Fix Shell fail with redundant space following delay number.

Reviewed-by: Jaben Carsey > -Original Message- > From: Qiu, Shumin > Sent: Sunday, September 06, 2015 8:06 PM > To: edk2-devel@lists.01.org > Cc: Qiu, Shumin ; Carsey, Jaben > > Subject: [PATCH 2/2] ShellPkg: Fix Shell fail with redundant space following > delay number. > Importance: Hig

Re: [edk2] Why I get assert in PCD\Dxe\Service.c

> On Sep 9, 2015, at 12:28 AM, 王晓峰 wrote: > > Dear PCD module owner, > I have meet an assert in PCDDXE UDK2014 revision. The Assert happens when > PCDdxe initlize. > ASSERT e:\code\MdeModulePkg\Universal\PCD\Dxe\Service.c(1137): TokenNumber + > 1 < mPcdTotalTokenCount + 1 > it seems that bu

Re: [edk2] [PATCH 3/3] ArmVirtPkg: set max physical address width to 40 bits

> On Sep 9, 2015, at 7:03 AM, Ard Biesheuvel wrote: > > On 9 September 2015 at 15:59, Laszlo Ersek > wrote: >> On 09/08/15 19:35, Ard Biesheuvel wrote: >>> When executing on a LPAE capable 32-bit ARM platform, we support >>> up to 40 bits of physical address space so s

Re: [edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

> On Sep 9, 2015, at 7:38 AM, Ard Biesheuvel wrote: > > On 9 September 2015 at 16:31, Leif Lindholm > wrote: >> On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: >>> Make sure that the PEI memory region is carved out of memory that is >>> 32-bit ad

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 9 September 2015 at 17:33, Ard Biesheuvel wrote: > On 9 September 2015 at 17:26, Gao, Liming wrote: >> Michael: >> Do you use the linker script BaseTools/Scripts/GccBase.lds and -z >> common-page-size=4096? >> > > Are you building for 32-bit ARM by any chance? That does not have this > feat

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 9 September 2015 at 17:26, Gao, Liming wrote: > Michael: > Do you use the linker script BaseTools/Scripts/GccBase.lds and -z > common-page-size=4096? > Are you building for 32-bit ARM by any chance? That does not have this feature wired up yet. I posted a v2 of my series that addresses this

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Michael: Do you use the linker script BaseTools/Scripts/GccBase.lds and -z common-page-size=4096? Thanks Liming From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] Sent: Wednesday, September 9, 2015 3:22 PM To: Yao, Jiewen Cc: Gao, Liming; edk2-devel@lists.01.org Subject: Re: [edk2] Sect

Re: [edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

On Wed, Sep 09, 2015 at 05:11:33PM +0200, Ard Biesheuvel wrote: > On 9 September 2015 at 16:53, Leif Lindholm wrote: > > On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote: > >> On 9 September 2015 at 16:31, Leif Lindholm > >> wrote: > >> > On Tue, Sep 08, 2015 at 07:35:40PM +0200, A

Re: [edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

On 9 September 2015 at 16:53, Leif Lindholm wrote: > On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote: >> On 9 September 2015 at 16:31, Leif Lindholm wrote: >> > On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: >> >> Make sure that the PEI memory region is carved out

Re: [edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote: > On 9 September 2015 at 16:31, Leif Lindholm wrote: > > On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: > >> Make sure that the PEI memory region is carved out of memory that is > >> 32-bit addressable, by taking MAX_

Re: [edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

On 9 September 2015 at 16:31, Leif Lindholm wrote: > On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: >> Make sure that the PEI memory region is carved out of memory that is >> 32-bit addressable, by taking MAX_ADDRESS into account (which is >> defined as '4 GB - 1' on ARM) >> >> Co

Re: [edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: > Make sure that the PEI memory region is carved out of memory that is > 32-bit addressable, by taking MAX_ADDRESS into account (which is > defined as '4 GB - 1' on ARM) > > Contributed-under: TianoCore Contribution Agreement 1.0 > Si

Re: [edk2] [PATCH 3/3] ArmVirtPkg: set max physical address width to 40 bits

On 9 September 2015 at 15:59, Laszlo Ersek wrote: > On 09/08/15 19:35, Ard Biesheuvel wrote: >> When executing on a LPAE capable 32-bit ARM platform, we support >> up to 40 bits of physical address space so set PcdPrePiCpuMemorySize >> accordingly. >> >> Contributed-under: TianoCore Contribution A

Re: [edk2] [PATCH 3/3] ArmVirtPkg: set max physical address width to 40 bits

On 09/08/15 19:35, Ard Biesheuvel wrote: > When executing on a LPAE capable 32-bit ARM platform, we support > up to 40 bits of physical address space so set PcdPrePiCpuMemorySize > accordingly. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel > --- > Ar

Re: [edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtMemoryInitPeiLib: handle memory above 4 GB on 32-bit ARM

On 09/08/15 19:35, Ard Biesheuvel wrote: > On 32-bit ARM, split system memory into a region below (and up to) 4 GB > and a region above 4 GB. This is necessary to get the DXE core to consider > the former as the resource descriptor that describes the primary memory > region that also covers the PHI

Re: [edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

On 09/08/15 19:35, Ard Biesheuvel wrote: > Make sure that the PEI memory region is carved out of memory that is > 32-bit addressable, by taking MAX_ADDRESS into account (which is > defined as '4 GB - 1' on ARM) > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Bieshe

Re: [edk2] [PATCH v2 5/5] ArmPkg/Mmu: Fix potential page table memory leak

On 9 September 2015 at 12:35, Ard Biesheuvel wrote: > On 9 September 2015 at 11:53, Heyi Guo wrote: >> During page entry attribute update, if there are table entries >> between starting BlockEntry and LastBlockEntry, table entries will be >> set as block entries and the allocated memory of the ta

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 14:08, Jan Beulich wrote: On 09.09.15 at 12:48, wrote: >> Personally I think that this dynamic approach is overkill (mainly >> because I'm fine with being unable to install Debian Wheezy guests, both >> wearing and not wearing my red fedora; and because the properties table >> fea

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 13:30, Paolo Bonzini wrote: > > > On 09/09/2015 13:07, Ian Campbell wrote: >> I have a question: What attack vector is setting the stack as Nx in OVMF >> (or even UEFI generally) trying to protect against? Or is this being done >> for a reason other than security? >> >> I understand w

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 13:07, Ian Campbell wrote: > On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote: > > Thanks for all the info, I think I get it (although its not clear to me > whether how an app can claim to be UEFI 2.5 capable and what the transition > plan for legacy applications was going to be).

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/2015 13:07, Ian Campbell wrote: > I have a question: What attack vector is setting the stack as Nx in OVMF > (or even UEFI generally) trying to protect against? Or is this being done > for a reason other than security? > > I understand why it is done for kernels and apps, but where does

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 11:37, Ian Campbell wrote: > On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: > On 09.09.15 at 00:23, wrote: >>> On 09/08/15 19:26, Anthony PERARD wrote: And I get this on the console: Welcome to GRUB! X64 Exception Type - 0E(#PF - Page-Fault) CPU Api

Re: [edk2] [PATCH v2 5/5] ArmPkg/Mmu: Fix potential page table memory leak

On 9 September 2015 at 11:53, Heyi Guo wrote: > During page entry attribute update, if there are table entries > between starting BlockEntry and LastBlockEntry, table entries will be > set as block entries and the allocated memory of the tables will be > leaked. > > so we break the inner loop when

Re: [edk2] [PATCH v2 3/5] ArmPkg/Mmu: Fix literal number left shift bug

On 9 September 2015 at 11:53, Heyi Guo wrote: > There is a hidden bug for below code: > > (1 << BaseAddressAlignment) & *BlockEntrySize > > From disassembly code, we can the literal number 1 will be treated as > INT32 by compiler by default, and we'll get 0x8000 when > BaseAddressAlign

Re: [edk2] [PATCH v2 1/5] ArmPkg/Mmu: Fix bug of aligning new allocated page table

On 9 September 2015 at 11:53, Heyi Guo wrote: > The code has a simple bug on calculating aligned page table address. > We can just use AllocateAlignedPages in MemoryAllocationLib instead. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Heyi Guo > Cc: Leif Lindholm >

Re: [edk2] [PATCH] BaseTools/GenFw: align RVA of debug

On 9 September 2015 at 11:54, Gao, Liming wrote: > Ard: > He reports that the 'common-page-size' flag doesn't work. When he > configures its value to 4096, the alignment in the converted EFI image is > still default 32. Could you help check it? > > The detail report is attached below. > The

[edk2] [PATCH v2 3/5] ArmPkg/Mmu: Fix literal number left shift bug

There is a hidden bug for below code: (1 << BaseAddressAlignment) & *BlockEntrySize >From disassembly code, we can the literal number 1 will be treated as INT32 by compiler by default, and we'll get 0x8000 when BaseAddressAlignment is equal to 31. So we will always get 31 when alignme

[edk2] [PATCH v2 5/5] ArmPkg/Mmu: Fix potential page table memory leak

During page entry attribute update, if there are table entries between starting BlockEntry and LastBlockEntry, table entries will be set as block entries and the allocated memory of the tables will be leaked. so we break the inner loop when we find a table entry and run outer loop again to step in

Re: [edk2] [PATCH] BaseTools/GenFw: align RVA of debug

Ard: He reports that the 'common-page-size' flag doesn't work. When he configures its value to 4096, the alignment in the converted EFI image is still default 32. Could you help check it? The detail report is attached below. The 'common-page-size' flag doesn't change the value of this fiel

[edk2] [PATCH v2 2/5] ArmPkg/Mmu: Fix page level calculation bug

The bug can be triggered when alignment of Base is larger than Length by 2 level of page granularity, e.g. Base is 0x4000_, Length is 0x1000 The original code will change 2MB page level and we will get a negative remaining length. Contributed-under: TianoCore Contribution Agreement 1.0 Signe

[edk2] [PATCH v2 4/5] ArmPkg/Mmu: Increase PageLevel when table found at the targeted level

Below code has bug since *BlockEntrySize and *TableLevel are not updated accordingly: if (IndexLevel == PageLevel) { // And get the appropriate BlockEntry at the next level BlockEntry = (UINT64*)TT_GET_ENTRY_FOR_ADDRESS (TranslationTable, \ IndexLevel + 1, RegionStart); // Set the las

[edk2] [PATCH v2 1/5] ArmPkg/Mmu: Fix bug of aligning new allocated page table

The code has a simple bug on calculating aligned page table address. We can just use AllocateAlignedPages in MemoryAllocationLib instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Cc: Leif Lindholm Cc: Ard Biesheuvel --- ArmPkg/Library/ArmLib/AArch64/AArch

Re: [edk2] [PATCH] BaseTools/GenFw: align RVA of debug

On 9 September 2015 at 11:46, Gao, Liming wrote: > Ard: > Dose this patch fix Section Alignment of elf binaries compiled with > GCC(Linux) reported by Michael Zimmermann ? > No. This fixes a problem on 32-bit ARM where the debug entry is resolved before the MMU is up, which results in an align

Re: [edk2] [PATCH] BaseTools/GenFw: align RVA of debug

Ard: Dose this patch fix Section Alignment of elf binaries compiled with GCC(Linux) reported by Michael Zimmermann ? Thanks Liming -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Wednesday, September 09, 2015 5:44 PM To: edk2-devel@lists.01.org; Gao, Li

[edk2] [PATCH] BaseTools/GenFw: align RVA of debug

SVN commit r18077 ("BaseTools/GenFw: move .debug contents to .data to save space") removed the separate .debug section after moving its contents into .text or .data. However, this change does not take into account that some of these contents need to appear at a 32-bit aligned offset. So align the d

[edk2] [PATCH v2 2/2] MdeModulePkg: ScsiDiskDxe: adapt SectorCount when shortening transfers

The specification of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru() function documents the EFI_BAD_BUFFER_SIZE return status, and the EFI_EXT_SCSI_STATUS_HOST_ADAPTER_DATA_OVERRUN_UNDERRUN host adapter status. These allow an EFI_EXT_SCSI_PASS_THRU_PROTOCOL implementation to request higher layers i

[edk2] [PATCH v2 0/2] MdeModulePkg: ScsiDiskDxe: handle EFI_BAD_BUFFER_SIZE from SCSI host adapter

No changes in either patch, relative to what has been discussed / proposed in the v1 thread. I *think* Feng's Reviewed-by in already covers both patches, but I'm not 100% sure, therefore I'm reposting in order for Feng to confirm

[edk2] [PATCH v2 1/2] MdeModulePkg: ScsiDiskDxe: recognize EFI_BAD_BUFFER_SIZE

Acting specifically upon this error condition from UefiScsiLib (and ultimately from EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru()) in the - ScsiDiskRead10(), - ScsiDiskWrite10(), - ScsiDiskRead16(), - ScsiDiskWrite16() functions allows us to retry these operations from ScsiDiskReadSectors() and Scsi

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

The name is reliable because it's used by all OEM's :) I'm the founder of EFIDroid, a port of UEFI to Qualcomm based Android devices. https://github.com/efidroid https://plus.google.com/u/0/communities/114053643671219382368 Android boot images(a container for kernel,ramdisk, devicetree and bootarg

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 09:06, Jan Beulich wrote: On 09.09.15 at 00:23, wrote: >> On 09/08/15 19:26, Anthony PERARD wrote: >>> And I get this on the console: >>> Welcome to GRUB! >>> >>> X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - >>> RIP - 0F5F8918, CS - 000

Re: [edk2] [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath

Reviewed-by: Fu Siyuan -Original Message- From: Zhang, Lubo Sent: Wednesday, September 9, 2015 5:10 PM To: edk2-devel@lists.01.org Cc: Fu, Siyuan ; Ye, Ting Subject: [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath PXE driver's LoadFile protocol should chec

Re: [edk2] [patch] MdeModulePkg: PXE Driver's LoadFile protocol should check FilePath

Reviewed-by: Fu Siyuan -Original Message- From: Zhang, Lubo Sent: Wednesday, September 9, 2015 5:09 PM To: edk2-devel@lists.01.org Cc: Fu, Siyuan ; Ye, Ting Subject: [patch] MdeModulePkg: PXE Driver's LoadFile protocol should check FilePath PXE driver's LoadFile protocol should ch

[edk2] [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath

PXE driver's LoadFile protocol should check the input parameter FilePath to see whether it's a supported device path.If not, it should return invalid parameter, do not continue PXE boot. Cc: Fu Siyuan Cc: Ye Ting Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo --

[edk2] [patch] MdeModulePkg: PXE Driver's LoadFile protocol should check FilePath

PXE driver's LoadFile protocol should check the input parameter FilePath to see whether it's a supported device path.If not, it should return invalid parameter, do not continue PXE boot. Cc: Fu Siyuan Cc: Ye Ting Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo --

Re: [edk2] [PATCH] MdeModulePkg: ScsiDiskDxe: adapt SectorCount when shortening transfers

On 09/09/15 09:11, Tian, Feng wrote: > I agreed ScsiDisk misses the handling for EFI_BAD_BUFFER_SIZE. That's why I > proposed a patch although it's not good:-) > > The uncertain part from my side at previous discussion is about the value of > In/OutTransferLength when EFI_BAD_BUFFER_SIZE is retu

Re: [edk2] OVMF BoF @ KVM Forum 2015

On 08/10/15 18:24, Laszlo Ersek wrote: > Hi. > > Let's do an OVMF BoF at this year's KVM Forum too. Here's a preliminary task list, after some off-list discussion (I tried to incorporate comments): - create GPL'd fork called "ovmf" for expediting virt development (OvmfPkg, ArmVirtPkg) - mayb

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

My concern is the name string is also not reliable. Different partition tools may have different naming rules. Yes, "private protocol" I meant is using it as your local implementation. Last, still has a little curious on your usage model, could you explain it more? Maybe there is a better way

Re: [edk2] [PATCH] MdePkg: Refine UefiFileHandleLib to avoid write non-ASCII char into ASCII file.

Reviewed-by: Liming Gao -Original Message- From: Qiu, Shumin Sent: Tuesday, September 08, 2015 3:05 PM To: edk2-devel@lists.01.org Cc: Qiu, Shumin; Carsey, Jaben; Gao, Liming Subject: [PATCH] MdePkg: Refine UefiFileHandleLib to avoid write non-ASCII char into ASCII file. Cc: Jaben Cars

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

UniquePartitionGUID isn't suitable because the device vendor's don't set proper values(they're auto generated each time the partition table changes). Instead names like "boot" are used so you can find the correct partition. by "Implement it as a private protocol" do u just mean "use your own fork"

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

Michael, IMHO, I don't think it's valuable to introducing this new protocol to get a name string. It's too burden. If only you have this use case, I would suggest you implement it as a private protocol rather than the public one. PS: Why UniquePartitionGUID doesn't work for your case? Thanks F

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

Hi, I need the partition name because I need to boot from partitions by their GPT label(filesystem label and GUID aren't set/reliable). Usually I would've just added a name field to the existing DiskIo Protocol, but since it's a UEFI standard we can't/shouldn't do this. I chose option 3 over 1/2

[edk2] Why I get assert in PCD\Dxe\Service.c

Dear PCD module owner, I have meet an assert in PCDDXE UDK2014 revision. The Assert happens when PCDdxe initlize. ASSERT e:\code\MdeModulePkg\Universal\PCD\Dxe\Service.c(1137): TokenNumber + 1 < mPcdTotalTokenCount + 1 it seems that build tool automatically generate PEI and DXE token number

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Unfortunately I missed the replies but I debugged this problem further and the Problem is that GenFw set's the alignment based on "sh_addralign" in the Elf header. The 'common-page-size' flag doesn't change the value of this field though. what it does change is the Alignment value of the Program H

Re: [edk2] [PATCH] MdeModulePkg: ScsiDiskDxe: adapt SectorCount when shortening transfers

I agreed ScsiDisk misses the handling for EFI_BAD_BUFFER_SIZE. That's why I proposed a patch although it's not good:-) The uncertain part from my side at previous discussion is about the value of In/OutTransferLength when EFI_BAD_BUFFER_SIZE is returned. In UEFI spec, there are two sentences to