Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2023-12-27 Thread Michael Brown
On 26/12/2023 11:28, Chang, Abner via groups.io wrote: For the HTTPS connetion that doesn't require TLS peer verification, EDKII_HTTPS_TLS_PLATFORM_POLICY_PROTOCOL is introduced to platform developer to provide the TLS configure data that is different than the default TLS configuration. The use c

Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2023-12-28 Thread Michael Brown
On 28/12/2023 02:47, Chang, Abner via groups.io wrote: On 26/12/2023 11:28, Chang, Abner via groups.io wrote: Platform developer can provide this protoocl to EFI HTTP driver to configure TLS using TLS conifg data provided by EDKII_HTTPS_TLS_PLATFORM_POLICY_PROTOCOL for the specific HTTP protocol

Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2023-12-28 Thread Michael Brown
On 28/12/2023 15:04, Chang, Abner via groups.io wrote: With the TLS protocol installed onto the same handle, I don't think you then even need to use RegisterProtocolNotify(). On return from EFI_HTTP_PROTOCOL.Request() you can open the TLS protocol on the handle and immediately call SetSessionDat

Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2023-12-28 Thread Michael Brown
On 28/12/2023 23:37, Chang, Abner via groups.io wrote: As far as I am aware, EfiHttpRequest sets up all of the relevant data structures but functions as a non-blocking open. If you reconfigure the TLS session immediately after return from EfiHttpRequest() then this reconfiguration should take ef

Re: [edk2-devel] [PATCH 1/5] NetworkPkg/HttpDxe: Refactor TlsCreateChild function

2024-01-01 Thread Michael Brown
estion, I'm happy to add Reviewed-by: Michael Brown for this patch. Thanks, Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113014): https://edk2.groups.io/g/devel/message/113014 Mute This Topic: https://groups.io/mt/1034

Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2024-01-01 Thread Michael Brown
On 29/12/2023 15:07, Chang, Abner via groups.io wrote: To locate TLS protocol from the HTTP handle and configure TLS configuration data at the return from EfiHttpRequest during that short window of non-blocking request is not reliable. It also doesn't make sense to ask upper layer application

Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2024-01-02 Thread Michael Brown
On 02/01/2024 06:06, Chang, Abner via groups.io wrote: What do you think about: - installing TLS on HTTP handle (as you have already implemented) - using EDKII_HTTP_CALLBACK_PROTOCOL to catch the HttpEventInitSession and perform whatever calls are needed to SetData() to modify the TLS configura

Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2024-01-02 Thread Michael Brown
On 02/01/2024 16:31, Chang, Abner via groups.io wrote: From: Michael Brown - Allow the call to Request() to perform its normal TLS configuration via TlsConfigureSession(), as though the connection were going to perform host verification etc as per the platform default policy. This

Re: [edk2-devel] [PATCH 1/5] NetwokrPkg/HttpDxe: Refactor TlsCreateChild

2024-01-05 Thread Michael Brown
nstance->TlsChildHandle + with opened EFI_TLS_PROTOCOL and EFI_TLS_CONFIGURATION_PROTOCOL. As above. Reviewed-by: Michael Brown Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113309): https://edk2.groups.io/g

Re: [edk2-devel] [PATCH 2/5] NetwokrPkg/HttpDxe: Consider TLS certificate not found as a success case

2024-01-05 Thread Michael Brown
turns EFI_SUCCESS to the caller. The failure is pushed back to TLS DXE driver if the HTTP communication actually requires certificate. Reviewed-by: Michael Brown Thanks, Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113310): https:/

Re: [edk2-devel] [PATCH 3/5] NetwokrPkg/HttpDxe: Add HttpEventTlsConfigured HTTP callback event

2024-01-05 Thread Michael Brown
Since this changes the ABI, you may want to also update the protocol GUID to prevent strange errors if old and new binaries are used on the same system. Reviewed-by: Michael Brown Thanks, Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Re

Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy

2024-01-05 Thread Michael Brown
On 05/01/2024 08:41, Chang, Abner wrote: We are not aware there is a TlsConnectSession() for TLS handshake using the default TLS configuration data and it returns a failure as expected because the default TLS configuration is TLS_VERIFY_HOST without certificate installed on system. This happen

Re: [edk2-devel] Updates to .mailmap needed for Jeff Brasen, Jake Garver, Joey Vagades and Michael Roth?

2024-01-09 Thread Michael Brown
On 09/01/2024 12:13, Laszlo Ersek wrote: On 1/9/24 11:45, Ard Biesheuvel wrote: Note that git am does support a 'From: ' header as the first line of the commit log, and will use it correctly to supersede the From: header in the SMTP envelope. OTOH, that doesn't help in this case, IIUC. When th

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

2024-01-16 Thread Michael Brown
On 16/01/2024 08:47, Gerd Hoffmann wrote: I think the reason is that the next timer interrupt arriving while the handler is running still is *much* more likely in virtual machines because the vCPU does not get 100% of the of the physical CPU time slice. The interrupt handler can run for an arbi

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

2024-01-16 Thread Michael Brown
On 16/01/2024 14:34, Laszlo Ersek wrote: On 1/16/24 10:48, Michael Brown wrote: IOW, my impression is that NestedInterruptTplLib can certainly handle all scenarios thrown at it, but where it really matters is in the face of an interrupt storm (not just "normal nesting"), and a storm i

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

2024-01-17 Thread Michael Brown
On 17/01/2024 07:11, Ni, Ray wrote: The above flow shows endless re-entrance of timer interrupt handler. But, my question is: above flow only can happen in real platform when the below 4 steps occupies more time than the timer period (usually 10ms). [Timer Interrupt #2]1. RaiseTPL

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

2024-01-19 Thread Michael Brown
On 19/01/2024 13:14, Ni, Ray wrote: So, the interrupt re-entrance we want to avoid is “env:NOTIFY”  -> “env:NOTIFY”, or “env:CALLBACK” -> “env:CALLBACK”, or “env:APPLICATION” -> “env:APPLICATION”. Because it’s endless. NestedTplInterruptLib was written to avoid it. Yes, precisely this. 2.

[edk2-devel] [PATCH 1/1] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg

2024-01-19 Thread Michael Brown
Signed-off-by: Michael Brown --- MdeModulePkg/MdeModulePkg.dec | 4 OvmfPkg/OvmfPkg.dec | 4 OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +- OvmfPkg/CloudHv/CloudHvX64.dsc

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

2024-01-19 Thread Michael Brown
On 19/01/2024 23:44, Ni, Ray wrote: I still want to see if the RestoreTpl2 that does not enable interrupt is added as a protocol, and how simple the lib could be. RestoreTpl() always has to enable interrupts during its execution, since interrupts must be allowed to occur while callbacks are ru

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg

2024-01-20 Thread Michael Brown
On 20/01/2024 07:03, Ni, Ray wrote: Can you submit another patch to add Iret.h to the INF file [Sources] section? Without that, incremental build might not work if changes are made in Iret.h. Good catch, thank you. I will send a v2. It doesn't support non-x86 CPU. Will ARM have similar prob

[edk2-devel] [PATCH v2 1/2] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg

2024-01-20 Thread Michael Brown
Signed-off-by: Michael Brown --- MdeModulePkg/MdeModulePkg.dec | 4 OvmfPkg/OvmfPkg.dec | 4 OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +- OvmfPkg/CloudHv/CloudHvX64.dsc

[edk2-devel] [PATCH v2 2/2] MdeModulePkg: Add missing Iret.h to NestedInterruptTplLib sources list

2024-01-20 Thread Michael Brown
Suggested-by: Ray Ni Signed-off-by: Michael Brown --- .../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf | 1 + 1 file changed, 1 insertion(+) diff --git a/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf b/MdeModulePkg/Library/NestedInterruptTplLib

[edk2-devel] [PATCH v2 0/2] Move NestedInterruptTplLib to MdeModulePkg

2024-01-20 Thread Michael Brown
sources list Cc: Ray Ni Cc: Laszlo Ersek Cc: Gerd Hoffmann Cc: Michael D Kinney Michael Brown (2): MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg MdeModulePkg: Add missing Iret.h to NestedInterruptTplLib sources list MdeModulePkg/MdeModulePkg.dec | 4

Re: [edk2-devel] [PATCH v2 1/2] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg

2024-01-23 Thread Michael Brown
On 22/01/2024 10:36, Laszlo Ersek wrote: (1) Does LocalApicTimerDxe have any other dependencies on OvmfPkg than the library class header? In other words, can't we remove "OvmfPkg/OvmfPkg.dec" from this [Packages] section, too? I can't see anything else, so I'd suggest to remove "OvmfPkg/OvmfPkg

[edk2-devel] [PATCH v3 1/5] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg

2024-01-23 Thread Michael Brown
IA32 and X64 only, since those are the only two architectures for which DisableInterruptsOnIret() is currently supported. Cc: Ray Ni Cc: Laszlo Ersek Cc: Gerd Hoffmann Cc: Michael D Kinney Reviewed-by: Laszlo Ersek Signed-off-by: Michael Brown --- MdeModulePkg/MdeModulePkg.dec

[edk2-devel] [PATCH v3 0/5] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg

2024-01-23 Thread Michael Brown
: - Add missing Iret.h to NestedInterruptTplLib sources list Changes since v2: - Remove obsolete dependency of LocalApicTimerDxe on OvmfPkg - Add to MdeModulePkg.dsc for build coverage - Add self-tests - Add support for Arm CPUs Michael Brown (5): MdeModulePkg: Move

[edk2-devel] [PATCH v3 2/5] MdeModulePkg: Add missing Iret.h to NestedInterruptTplLib sources list

2024-01-23 Thread Michael Brown
Allow build system to detect changes to Iret.h. Suggested-by: Ray Ni Reviewed-by: Laszlo Ersek Signed-off-by: Michael Brown --- .../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf | 1 + 1 file changed, 1 insertion(+) diff --git a/MdeModulePkg/Library/NestedInterruptTplLib

[edk2-devel] [PATCH v3 3/5] MdeModulePkg: Do nothing on NestedInterruptRestoreTPL(TPL_HIGH_LEVEL)

2024-01-23 Thread Michael Brown
that we do not need to consider the effect of this possible invariant violation on the remainder of the logic. Signed-off-by: Michael Brown --- MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c | 13 + 1 file changed, 13 insertions(+) diff --git a/MdeModulePkg/Library

[edk2-devel] [PATCH v3 4/5] MdeModulePkg: Add self-tests for NestedInterruptTplLib

2024-01-23 Thread Michael Brown
time. Only one test is performed by default (to avoid unnecessary system startup delay). The number of tests performed can be controlled via PcdNestedInterruptNumberOfSelfTests at build time. Signed-off-by: Michael Brown --- MdeModulePkg/MdeModulePkg.dec | 4

[edk2-devel] [PATCH v3 5/5] MdeModulePkg: Extend NestedInterruptTplLib to support Arm CPUs

2024-01-23 Thread Michael Brown
o use NestedInterruptTplLib and verifying that ArmVirtQemu passes the NestedInterruptTplLib self-tests for both ARM and AARCH64. Cc: Ard Biesheuvel Signed-off-by: Michael Brown --- MdeModulePkg/MdeModulePkg.dsc | 2 +- .../NestedInterruptTplLib.inf | 3 +++ .../Li

Re: [edk2-devel] [PATCH v3 5/5] MdeModulePkg: Extend NestedInterruptTplLib to support Arm CPUs

2024-01-23 Thread Michael Brown
On 23/01/2024 15:51, Ard Biesheuvel wrote: On Tue, 23 Jan 2024 at 16:31, Michael Brown wrote: Add implementations of DisableInterruptsOnIret() for MDE_CPU_ARM and MDE_CPU_AARCH64. In both cases, the saved IRQs-disabled and FIQs-disabled flags are set in the stored processor status register

Re: [edk2-devel] [PATCH v3 3/5] MdeModulePkg: Do nothing on NestedInterruptRestoreTPL(TPL_HIGH_LEVEL)

2024-01-23 Thread Michael Brown
On 23/01/2024 16:32, Laszlo Ersek wrote: On 1/23/24 16:31, Michael Brown wrote: At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI specification) and so we should never encounter a situation in which an interrupt occurs at TPL_HIGH_LEVEL. Restoring TPL to TPL_HIGH_LEVEL is always

Re: [edk2-devel] [PATCH v3 5/5] MdeModulePkg: Extend NestedInterruptTplLib to support Arm CPUs

2024-01-23 Thread Michael Brown
On 23/01/2024 17:10, Laszlo Ersek wrote: Other than that, the patch looks great to me; I'd only propose one (superficial) improvement: rather than include , scavenge #ifdef MDE_CPU_ARM #include #elif defined (MDE_CPU_AARCH64) #include #endif from it. Reasons: (a) Those are the headers that

Re: [edk2-devel] [PATCH v3 4/5] MdeModulePkg: Add self-tests for NestedInterruptTplLib

2024-01-23 Thread Michael Brown
On 23/01/2024 16:55, Laszlo Ersek wrote: + /// + /// Number of self-tests performed. + /// + UINTN SelfTestCount; } NESTED_INTERRUPT_STATE; /** I suggest that the new field be UINT32. The (exclusive) limit is a 32-bit PCD. Making the counter (potentially) wider than the limit is

Re: [edk2-devel] RFC: Another solution to the nested interrupt issue

2024-01-25 Thread Michael Brown
On 25/01/2024 07:57, Ni, Ray wrote: This mail is to bring another approach to solve the stack-overflow due to nested interrupts. Michael solved this problem in OVMF through NestedInterruptTplLib. I made a draft patch as attached “DxeCore.diff”. The patch simply to avoid the interrupt in enabl

Re: [edk2-devel] RFC: Another solution to the nested interrupt issue

2024-01-25 Thread Michael Brown
On 25/01/2024 13:54, Ni, Ray wrote: I don't disagree with the approach, but it does break the API as per the UEFI PI specification (version 1.8 section II-12.10), and so this is not something that can just be dropped in as an EDK2 code change. You think that the TimerInterruptHandler() doesn't

Re: [edk2-devel] RFC: Another solution to the nested interrupt issue

2024-01-25 Thread Michael Brown
On 25/01/2024 15:06, Ni, Ray wrote: I agree with you about the above PI spec clarifications. Would you like to write a PI spec ECR? I am not a UEFI Forum member, so I don't think I have standing to do this. (I also don't have the spare time to do this for free, sorry.) But I do not think t

Re: [edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations

2023-11-01 Thread Michael Brown
On 01/11/2023 09:56, Ard Biesheuvel wrote: On Wed, 1 Nov 2023 at 03:09, Pedro Falcato wrote: On Wed, Nov 1, 2023 at 12:40 AM Joe L wrote: Our CMN TRM showcases an example where ECAM and MMIO are two different regions in the HN-I SAM. The implication is that we would expect a DSB between the

Re: [edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations

2023-11-01 Thread Michael Brown
On 01/11/2023 12:51, Ard Biesheuvel wrote: On Wed, 1 Nov 2023 at 13:25, Michael Brown wrote: By my reading, the PCIe specification seems to therefore require something stronger than an ordering guarantee: it requires the ability for software to make a standalone determination that the write

Re: [edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations

2023-11-01 Thread Michael Brown
On 01/11/2023 20:17, Joe L wrote: Thanks for the discussion, Are we saying that DataSynchronizationBarrier () before the return from RootBridgeIoPciAccess() is not strong enough to determine that the final ECAM write would have completed? According to Learn the architecture - ARMv8-A memory s

Re: [edk2-devel] [PATCH] MdeModulePkg/PciHostBridgeDxe: Add readback after final Cfg-Write

2023-11-03 Thread Michael Brown
On 03/11/2023 16:03, Kinney, Michael D wrote: PCI Configuration read/write operations are non-posted, so the PCI Configuration write operation should complete without the need for an additional transaction. If you are seeing an issue, then it may be in the implementation of the PciLib/PciSegment

Re: [edk2-devel] Problem Booting Starlingx On PXE

2024-02-19 Thread Michael Brown
On 19/02/2024 06:44, Hamit Can Karaca wrote: I am having problem while booting Starlingx on iPXE on UEFI. It says malformed binary and does not allow me to boot afterwards. What should I do in BIOS to solve this problem? I can boot Starlingx on other platforms using OEM BIOS. Our platform is

Re: [edk2-devel] [PATCH] UefiCpuPkg/CpuPageTableLib: qualify page table accesses as volatile

2024-02-23 Thread Michael Brown
On 22/02/2024 08:41, Zhou Jianfeng wrote: --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c @@ -20,13 +20,13 @@ **/ VOID PageTableLibSetPte4K ( - IN OUT IA32_PTE_4K *Pte4K, - IN UINT64 Offset, -

Re: [edk2-devel] [PATCH] UefiCpuPkg/CpuPageTableLib: qualify page table accesses as volatile

2024-02-23 Thread Michael Brown
On 23/02/2024 15:12, Zhou, Jianfeng wrote: While it may well cause the compiler to generate less optimised code, there is absolutely no way that this volatile declaration on a local stack variable can possibly change the outcome of the code. There can never be any meaningful side-effects from r

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

2024-02-29 Thread Michael Brown
On 29/02/2024 13:02, Ni, Ray wrote: A ideal solution is to not keep the interrupt disabled when RestoreTPL(TPL_HIGH -> not TPL_HIGH) is executed in the timer interrupt context because the interrupt handler will re-enable the interrupt with arch specific instructions (e.g.: IRET for x86). The pat

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

2024-02-29 Thread Michael Brown
On 29/02/2024 16:43, Kinney, Michael D wrote: Hi Michael, Can you provide a pointer to the UEFI Spec statement this breaks? II-9.7.1.3 RestoreTPL(): "When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has been installed, then the full version of the Boot Service RestoreTPL()

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

2024-02-29 Thread Michael Brown
On 29/02/2024 19:04, Paolo Bonzini wrote: On 2/29/24 14:02, Ray Ni wrote: In the end, it will lower the TPL to TPL_APPLICATION with interrupt enabled. However, it's possible that another timer interrupt happens just in the end of RestoreTPL() function when TPL is TPL_APPLICATION. How do no

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

2024-02-29 Thread Michael Brown
On 29/02/2024 19:09, Michael D Kinney wrote: "When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has been installed, then the full version of the Boot Service RestoreTPL() can be made available. When an attempt is made to restore the TPL level to level below EFI_TPL_HIGH_LEVEL, t

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

2024-02-29 Thread Michael Brown
On 29/02/2024 19:26, Michael D Kinney wrote: I think one advantage of this new proposal is to prevent an extra level of nesting and use of stack resources in that extra level. I think that's a negligible benefit. In the scenario as I outlined for NestedInterruptTplLib, there is potentially on

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

2024-03-01 Thread Michael Brown
On 01/03/2024 08:37, Paolo Bonzini wrote: So I am starting to see more and more similarities between the two approaches. I went a step further with fresh mind, removing the while loop... and basically reinvented your and Michael's patch. :) The only difference in the logic is a slightly differen

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

2024-03-01 Thread Michael Brown
On 01/03/2024 09:33, Paolo Bonzini wrote: On Fri, Mar 1, 2024 at 10:27 AM Michael Brown wrote: It's possible that it doesn't matter. The new logic will effectively mean that RestoreTPL() will restore not only the TPL but also the interrupts-enabled state to whatever existed at the t

Re: [edk2-devel] [PATCH] UefiCpuPkg/CpuPageTableLib: qualify page table accesses as volatile

2024-03-01 Thread Michael Brown
Reviewed-by: Michael Brown Thanks, Michael On 01/03/2024 02:54, Zhou Jianfeng wrote: Add volatile qualifier to page table related variable to prevent compiler from optimizing away the variables which may lead to unexpected result. Signed-off-by: Zhou Jianfeng Cc: Ray Ni Cc: Laszlo Ersek

Re: [edk2-devel] [PATCH] NetworkPkg/HttpBootDxe: Correctly uninstall HttpBootCallbackProtocol

2024-04-06 Thread Michael Brown
On 06/04/2024 16:53, Mike Beaton wrote: The existing uninstall call was passing the wrong handle (parent object, not the correct child object) and additionally passing the address of a pointer to the interface to be removed rather than the pointer itself, so always failed with EFI_NOT_FOUND. Afte

Re: [edk2-devel] [PATCH] NetworkPkg/HttpBootDxe: Correctly uninstall HttpBootCallbackProtocol

2024-04-20 Thread Michael Brown
On 19/04/2024 11:02, Mike Beaton wrote: Dear Michael, I don't know if you had time to answer one follow-up question. Obviously one thing that someone might want to do is to notify on protocol installs and trap installs of this protocol - e.g. so that something other than UefiBootManagerLib ca

Re: [edk2-devel] [PATCH v1 07/14] NetworkPkg:: SECURITY PATCH CVE-2023-45237

2024-05-08 Thread Michael Brown
On 08/05/2024 22:19, Ard Biesheuvel wrote: I've always found that logic rather bizarre - there is no way the implementation of the raw protocol can ensure that the caller uses it correctly, and so enforcing a minimum read size is pointless and arbitrary. And as you note, it has no basis in the UE

Re: 回复: [edk2-devel] [PATCH v3 00/20] NetworkPkg: CVE-2023-45236 and CVE-2023-45237

2024-05-30 Thread Michael Brown
On 30/05/2024 10:31, Gerd Hoffmann wrote: On Thu, May 30, 2024 at 01:07:45PM GMT, gaoliming via groups.io wrote: If ASSERT trigs the exception, could call stack show each caller? Turned out to be ipxe, apparently it has a exit-boot-services handler which triggers all this. iPXE shouldn't be

Re: 回复: [edk2-devel] [PATCH v3 00/20] NetworkPkg: CVE-2023-45236 and CVE-2023-45237

2024-05-30 Thread Michael Brown
On 30/05/2024 11:33, Gerd Hoffmann wrote: Most likely it is exactly this ... As of commit https://github.com/ipxe/ipxe/commit/6769a7c3c, we now deliberately leak resources once ExitBootServices has been triggered by skipping the cleanup calls to UninstallMultipleProtocolInterfaces etc. ... as

Re: [edk2-devel] [edk2-platforms][PATCH 1/8] Platform/RPi: Add model family detection

2019-11-14 Thread Michael Brown
On 14/11/2019 16:07, Pete Batard wrote: +typedef +EFI_STATUS +(EFIAPI *GET_MODEL_FAMILY) ( + UINT32 *ModelFamily + ); + typedef EFI_STATUS (EFIAPI *GET_FIRMWARE_REVISION) ( @@ -143,6 +150,7 @@ typedef struct { GET_MODEL GetModel; GET_MODEL_REVISIONGetModelRevision;

Re: [edk2-devel] [edk2-platforms: PATCH 0/3] Platform/RPi3: Improve timeout handling in DwUsbHostDxe

2019-07-19 Thread Michael Brown
On 19/07/2019 12:53, Leif Lindholm wrote: The patches look good, and I don't mind you upstreaming Michael's code, *but* I don't want patches submitted with anyone other than the contributor's Signed-off-by:. (It's the equivalent of saying "Yeah, Michael says he's OK with https://developercertific

[edk2-devel] [edk2-platforms: PATCH 0/1] Handle RPi device trees using "ethernet0"

2019-07-19 Thread Michael Brown
This standalone patch fixes FdtDxe.c to handle newer Raspberry Pi device trees using the "ethernet0" alias (while retaining compatibility with older device trees). Michael Brown (1): Platform/RPi3: Accept "ethernet" or "ethernet0" aliases in device tree Pla

[edk2-devel] [edk2-platforms: PATCH 1/1] Platform/RPi3: Accept "ethernet" or "ethernet0" aliases in device tree

2019-07-19 Thread Michael Brown
hernet alias") and U-Boot commit f8e57c6 ("fdt_support: Fixup 'ethernet' aliases not ending in digits"). Accept either "ethernet" or "ethernet0" as being the alias to the node for which the MAC address should be updated. Signed-off-by: Michael Brown ---

Re: [edk2-devel] [edk2-platforms: PATCH 1/1] Platform/RPi3: Accept "ethernet" or "ethernet0" aliases in device tree

2019-07-23 Thread Michael Brown
On 23/07/2019 11:34, Leif Lindholm wrote: On Fri, Jul 19, 2019 at 06:29:07PM +0100, Michael Brown wrote: Older device trees tend to use the alias "ethernet". Newer device trees tend to use "ethernet0" since older versions of U-Boot would skip aliases that do not include a

[edk2-devel] [edk2-platforms: PATCHv2 1/1] Platform/RPi3: Provide "ethernet[0]" aliases in device tree

2019-07-24 Thread Michael Brown
her alias, and with device trees that contain either (or both) aliases. Signed-off-by: Michael Brown --- .../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 64 +++ 1 file changed, 64 insertions(+) diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c b/Platform/Raspbe

[edk2-devel] [edk2-platforms: PATCHv2 0/1] Platform/RPi3: Provide "ethernet[0]" aliases in device tree

2019-07-24 Thread Michael Brown
ot; aliases exist within the device tree. The code is unfortunately much more verbose than v1, since there is no convenient libfdt helper function for creating an alias. I have attempted to match the existing coding style, but I apologise in advance for any errors in so doing. Michael Brown (1):

Re: [edk2-devel] [edk2-platforms: PATCHv2 1/1] Platform/RPi3: Provide "ethernet[0]" aliases in device tree

2019-07-24 Thread Michael Brown
On 24/07/2019 19:53, Leif Lindholm wrote: SanitizePSCI (); CleanMemoryNodes (); CleanSimpleFramebuffer (); + FixEthernetAliases (); ...would it be worth having a return value here and Print()ing a message visible regardless of build profile if this function fails? Yes, I think th

[edk2-devel] [edk2-platforms: PATCH 1/1] Platform/RPi3: Report device tree modification errors using Print()

2019-07-25 Thread Michael Brown
Most functions in FdtDxe currently return VOID and report errors using only DEBUG. Update functions to return EFI_STATUS and report errors using Print() so that errors are at least visible in non-debug builds. Signed-off-by: Michael Brown --- .../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102

[edk2-devel] [edk2-platforms: PATCH 0/1] Report device tree modification errors using Print()

2019-07-25 Thread Michael Brown
n >> then follow up with a second patch to improve the error visibility in >> non-debug builds? > > Yeah, that works for me. As promised, here is the subsequent patch to improve error visibility throughout FdtDxe. Michael Brown (1): Platform/RPi3: Report device tree modificat

[edk2-devel] [edk2-platforms: PATCH v2 1/1] Platform/RPi3: Report device tree modification errors using Print()

2019-08-08 Thread Michael Brown
Most functions in FdtDxe currently return VOID and report errors using only DEBUG. Update functions to return EFI_STATUS and report errors using Print() so that errors are at least visible in non-debug builds. Signed-off-by: Michael Brown --- .../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102

[edk2-devel] [edk2-platforms: PATCH v2 0/1] Platform/RPi3: Report device tree

2019-08-08 Thread Michael Brown
(EFI_INVALID_PARAMETER seemed misleading to me, since there is nothing wrong with the parameters provided by the caller.) Michael Brown (1): Platform/RPi3: Report device tree modification errors using Print() .../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102 -- 1 fil

Re: [edk2-devel] iSCSI and iBFT

2019-05-22 Thread Michael Brown
On 22/05/2019 11:40, Tomas Pilar (tpilar) wrote: Yeah, I just AllocateCopyPool the static struct on heap for each device. I can honestly see how one would assume that a protocol instance would never be installed on more than one handle, same as I assumed that using a statically allocated struc

Re: [edk2-devel] iSCSI and iBFT

2019-05-23 Thread Michael Brown
On 23/05/2019 10:46, Tomas Pilar (tpilar) wrote: I was mostly puzzled by the double step. First find a parent device to LoadedImage that support NII. Rather than using that device we will scan all devices to see if any of them has the same NII protocol and if so we use that one. I am not sure

Re: [edk2-devel] [PATCH] NetworkPkg: Add WiFi profile sync protocol support

2022-09-26 Thread Michael Brown
On 26/09/2022 16:39, Clark-williams, Zachary wrote: + if (Profile->Password[StrLen (Profile->Password)] != '\0') { +Profile->Password[StrLen (Profile->Password)] = L'\0'; } + I don't understand this change, StrLen returns the length of a Null-terminated Unicode string, it means "Profile->

Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

2020-08-19 Thread Michael Brown
On 19/08/2020 19:13, Laszlo Ersek wrote: I'm still undecided whether option#43 / tag#6 / bit#3 being clear means we should *ignore* PXE_BOOT_SERVERS (tag#8), but I'm willing to defer to you on that. So, I can give a cautious Reviewed-by: Laszlo Ersek for this patch. FWIW, iPXE's equivalent l

Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

2020-08-20 Thread Michael Brown
On 20/08/2020 11:44, Maciej Rabeda wrote: @Michael I am now wondering whether bit 3 is actually relevant to server choice. Bit 3: == 0 -> prompt user to choose a boot file. Which means to me: show minimal menu with prompt (tag 10 - PXE_MENU_PROMPT) and options (tag 9 - PXE_BOOT_MENU). == 1 ->

Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

2020-08-23 Thread Michael Brown
On 21/08/2020 12:19, Laszlo Ersek wrote: On 08/19/20 20:46, Michael Brown wrote: FWIW, iPXE's equivalent logic (based on a combination of what the PXE spec says and what the Intel reference PXE implementation actually does, which is not necessarily the same thing) is to *i

Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

2021-11-09 Thread Michael Brown
On 09/11/2021 08:40, Gerd Hoffmann wrote: 3. Require use of uncrustify tool before submitting patch review emails or PRs. * The required version would be a formally released version from the fork maintained by Michael Kubacki until the changes can be upstreamed. * https://d

Re: [edk2-devel] [PATCH] MdePkg: DebugLib: Compilation fix for clang-13.

2021-11-22 Thread Michael Brown
On 22/11/2021 16:42, Michael D Kinney wrote: You are also modifying the DebugLib in the paths where ASSERT() macros are disabled. When they are disabled, we want all code/data associated with ASSERT() to be removed by the optimizing compiler/linker. The source code change appears to force a ref

Re: [edk2-devel] [PATCH] MdePkg: DebugLib: Compilation fix for clang-13.

2021-11-23 Thread Michael Brown
On 23/11/2021 06:41, Marvin Häuser wrote: 23.11.2021 00:17:30 Michael Brown : I would very strongly recommend having the non-debug version of the macro use something like: #define ASSERT(Expression) do {   \ if (FALSE) {  \    (VOID) (Expression

Re: [edk2-devel] reg: iPxe Boot in NetworkPkg

2021-02-05 Thread Michael Brown
On 05/02/2021 08:28, Sivaraman Nainar wrote: Hello Maciej: I met an issue when tried to do the PXE boot with keeping the ipxe.efi as boot file. When iPXE.efi is set as boot file once it downloaded it again starts, it does the download and start of iPXE continuously and at some point it asse

Re: [edk2-devel] EfiRom vs. iPXE usability note

2021-02-19 Thread Michael Brown
On 19/02/2021 17:33, Laszlo Ersek wrote: The PCI Firmware Spec does not seem to specify a particular "checksum byte" in the option ROM format, it only seems to state that the bytes in the option ROM must sum to zero. This (apparently) allows option ROM providers to implement different schemes fo

Re: [edk2-devel] Read SPI BAR offset 0x10 throwing processor exception

2022-01-28 Thread Michael Brown
On 28/01/2022 12:47, Rao G wrote: Attempting to Read SPIBAR 0x10 from BUS 0 Dev 1F Func 5 >> ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase + PCI_BASE_ADDRESSREG_OFFSET) & 0xF000; >> The above code is throwing exception PchSpiBase at 0xC00FD000 X64 Exception Type - 0E(#PF - Page-

Re: [edk2-devel] [PATCH] MdeModulePkg/Frontpage: Get SMBIOS Data from table directly

2022-02-01 Thread Michael Brown
On 01/02/2022 09:34, Sean Rhodes wrote: Gather information from SMBIOS table rather than getting it from the EFI SMBIOS protocol for coreboot builds. Could you not avoid code duplication by exposing the SMBIOS table via EFI_SMBIOS_PROTOCOL? This would provide a much more general solution tha

Re: [edk2-devel] [PATCH] MdeModulePkg/Frontpage: Get SMBIOS Data from table directly

2022-02-02 Thread Michael Brown
On 02/02/2022 09:02, Sean Rhodes wrote: Not quite sure how to implement that, are there any existing use cases that I can look at? From the way that your patch uses SMBIOS data, I'm assuming that your use case involves a pre-existing SMBIOS table structure that is constructed by something (e.

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

2021-04-07 Thread Michael Brown
On 05/04/2021 00:01, Marvin Häuser wrote: 3. During my initial exploration, I discovered defective PPIs and protocols (e.g. returning data with no corresponding size) originating from the UEFI PI and UEFI specifications. Changes need to be discussed, settled on, and submitted to the UEFI Forum.

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

2021-04-07 Thread Michael Brown
On 07/04/2021 22:31, Marvin Häuser wrote: Sorry, but I do not see why this would be the case. In fact the solution is (temporary) co-existence, as already is the case with InstallProtocolInterface() and InstallMultipleProtocolInterfaces() InstallMultipleProtocolInterfaces() is not a breaking c

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

2021-04-08 Thread Michael Brown
On 08/04/2021 09:53, Marvin Häuser wrote: On 07.04.21 23:50, Michael Brown wrote: InstallMultipleProtocolInterfaces() is not a breaking change: the existence of InstallMultipleProtocolInterfaces() does not require any change to the way that InstallProtocolInterface() is implemented or

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

2021-04-08 Thread Michael Brown
On 08/04/2021 10:04, Marvin Häuser wrote: Thank you a lot. One thing I noticed is that part of the quote I did not see on the list before, so I marked it below. On 08.04.21 00:10, Andrew Fish wrote: The general UEFI (and UEFI PI) is we mostly add new things, and don’t depreciated things to mai

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

2021-04-08 Thread Michael Brown
On 08/04/2021 10:41, Marvin Häuser wrote: No, backwards-compatibility will not be broken in the sense that the old API is absent or malfunctioning. Perfect. :) As I *have* said, I imagine there to be an option (default true) to expose both variants. Very much less perfect. The mere existe

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

2021-04-08 Thread Michael Brown
On 08/04/2021 11:13, Marvin Häuser wrote: Very much less perfect.  The mere existence of such an option immediately reimposes the burden on external code to support both, because it opens up the possibility of running on systems where the option is set to false. One more time, I do not know w

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

2021-04-08 Thread Michael Brown
On 08/04/2021 22:07, Marvin Häuser wrote: PE is not a moving target, but EDK II is. The fact that even old and proven code sometimes needs maintanance is evidental from the proposal and its so far positive feedback. I'm not ready to duplicate code, I'd rather take the utilities out of the curr

Re: [edk2-devel] [EDK2 / UEFI]: Support for flashing ubi-volume using fastboot

2021-04-14 Thread Michael Brown
On 14/04/2021 20:34, Andrew Fish via groups.io wrote: EFI does not have a concept of Volume names, EFI has a concept of EFI_HANDLEs that contain device paths that indentify the volume. The UEFI Shell has volume names, but that is a construct produced by the UEFI Shell. The filesystem label (

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

2021-04-15 Thread Michael Brown
On 15/04/2021 06:28, Ethin Probst wrote: - I hoped to add recording in case we in future want to add accessibility aids like speech recognition (that was one of the todo tasks on the EDK2 tasks list) Is there any necessity for audio input and output to be implemented within the same protocol?

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

2021-04-15 Thread Michael Brown
On 16/04/2021 00:42, Ethin Probst wrote: Forcing a particular channel mapping, sample rate and sample format on everyone would complicate application code. From an application point of view, one would, with that type of protocol, need to do the following: 1) Load an audio file in any audio file f

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

2021-04-15 Thread Michael Brown
On 16/04/2021 01:59, Ethin Probst wrote: Also, I'm a bit confused. I've looked at several VirtIO devices now and have seen things like this: #define VIRTIO_PCI_DEVICE_SIGNATURE SIGNATURE_32 ('V', 'P', 'C', 'I') // ... UINT32 Signature; I'm quite confused because I can't seem

Re: [edk2-devel] [PATCH V5 1/1] EmbeddedPkg: DwMmcHcDxe: Add support for Designware SDMMC driver

2021-04-27 Thread Michael Brown
On 27/04/2021 18:31, Andrew Fish via groups.io wrote: One trick people have pulled in the past is to write a driver that produces a “fake” PCI IO Protocol. The “fake” PCI IO driver abstracts how the MMIO device shows up on the platform. This works well if the MMIO device is really the same IP b

Re: [edk2-devel] [PATCH] UefiCpuPkg/PiSmmCpu: Remove hardcode 48 address size limitation

2021-05-20 Thread Michael Brown
On 18/05/2021 19:42, Laszlo Ersek wrote: On 05/18/21 09:51, Ni, Ray wrote: Thanks for explaining why you don't think it's a good patch. I thought anytime changing a code, I should try to make it better, functional better, looks better. My only point was that separate concerns should be implem

Re: [edk2-devel] GSOC 2021 EXT4 driver Project

2021-05-24 Thread Michael Brown
On 24/05/2021 20:26, Pedro Falcato wrote: Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity to collaborate with you and improve Tianocore! If anyone has any questions, please fire away :) How do I get started? I'd like to find

Re: [edk2-devel] GSOC 2021 EXT4 driver Project

2021-06-01 Thread Michael Brown
On 28/05/2021 18:16, Pedro Falcato wrote: 2) Although I'd love to avoid journaling, which is a matter I'm not too familiar with, I'm not entirely sure what simplifications may be done because for one, what happens if the power cuts during a write? It's unclear to me how a FW filesystem driver m

Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

2021-06-04 Thread Michael Brown
On 04/06/2021 11:11, Laszlo Ersek wrote: And, to reiterate, just because Confidential Computing is the new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64 do not disappear. Regressing them, or making them unmaintainable due to skyrocketing complexity, is not acceptable. Tot

Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

2021-06-04 Thread Michael Brown
On 04/06/2021 11:43, Michael Brown wrote: On 04/06/2021 11:11, Laszlo Ersek wrote: And, to reiterate, just because Confidential Computing is the new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64 do not disappear. Regressing them, or making them unmaintainable due to

  1   2   >