similar to: [PATCH] efi: off-by-one in gdt allocation

Displaying 20 results from an estimated 900 matches similar to: "[PATCH] efi: off-by-one in gdt allocation"

2020 Mar 24
2
[PATCH] efi/main.c: include <efisetjmp.h>
Building syslinux against gnu-efi 3.0.10 currently fails with: syslinux/efi/main.c:33:8: error: unknown type name ?jmp_buf? 33 | static jmp_buf load_error_buf; | ^~~~~~~ syslinux/efi/main.c: In function ?local_boot?: syslinux/efi/main.c:189:5: warning: implicit declaration of function ?longjmp? [-Wimplicit-function-declaration] 189 | longjmp(&load_error_buf, 1); |
2014 Feb 13
5
[PATCH] Potential bug in emalloc
From: Sylvain Gault <sylvain.gault at gmail.com> I found something suspicious while hunting another bug a while ago. The conditions for that bug to occur seems quite hard to meet, but it's still code quality improvement. See the commit message for details. Sylvain Gault (1): efi: Suspicious size reduction in emalloc efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3
2014 Feb 13
0
[PATCH] efi: Suspicious size reduction in emalloc
From: Sylvain Gault <sylvain.gault at gmail.com> It could happen on 32 bits architecture that the memory size really allocated could be less than required. On 64 bits, allocate_pages may be called more times than needed. This closes bug #39. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git
2014 Feb 13
2
[PATCH] Potential bug in emalloc
Op 2014-02-13 om 04:04 schreef Sylvain Gault: > 2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: > > From: Sylvain Gault <sylvain.gault at gmail.com> > > > > It looks like git-send-email messed the headers when changing the sender. And there was no actual patch ( no unified diff output ) in that e-mail. Please rerun providing
2014 Feb 13
1
[PATCH] Potential bug in emalloc
2014-02-13 4:04 UTC+01:00, Sylvain Gault <sylvain.gault at gmail.com>: > 2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> > > It looks like git-send-email messed the headers when changing the sender. > Actually this was correct. It's the git-send-email way to specify the
2014 Feb 13
0
[PATCH] Potential bug in emalloc
2014-02-13 7:38 UTC+01:00, Geert Stappers <stappers at stappers.nl>: > Op 2014-02-13 om 04:04 schreef Sylvain Gault: >> 2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: >> > From: Sylvain Gault <sylvain.gault at gmail.com> >> > >> >> It looks like git-send-email messed the headers when changing the sender. > >
2016 Jan 21
3
[PATCH 2/2] core: Fix stack overflow when reloading config
On 10/12/15 21:04, celelibi--- via Syslinux wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > The behavior when running a "CONFIG" command line is to reload > ldlinux.c32 with the new file as argument. This call never return. > > In order to avoid stacking up the calls to start_ldlinux, this patch > introduce a setjmp/longjmp to return to the
2014 Feb 22
0
[PATCH] efi: off-by-one in gdt allocation
On 02/21/2014 06:30 PM, celelibi at gmail.com wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > The assembly instruction lgdt take a segment limit that is one less than > the actual size, so that base+limit points to the last byte. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> This patch is of course correct (and will be applied); the bug
2015 Sep 11
2
[PATCH 1/1] efi/x86_64: fix trivial compilation warning
From: Sylvain Gault <sylvain.gault at gmail.com> Missing */ at the end of a comment. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/x86_64/linux.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/x86_64/linux.S b/efi/x86_64/linux.S index 972c0b2..29dde94 100644 --- a/efi/x86_64/linux.S +++ b/efi/x86_64/linux.S @@ -27,7 +27,7 @@ kernel_jump:
2015 Oct 13
2
[PATCH 1/1] ldlinux: Fix return pointer to local data
From: Sylvain Gault <sylvain.gault at gmail.com> The command-line parsing used to return a pointer to a local array. The code used to work by chance, but now, gcc 5 is able to detect it and return a NULL pointer instead. The buffer is now marked static. This shouldn't be a problem as only one command line can be read at a time. Signed-off-by: Sylvain Gault <sylvain.gault at
2015 Sep 14
1
[PATCH 1/4] efi: Don't unnecessarily rebuild syslinux.so
On Mon, Sep 14, 2015 at 05:50:56AM +0200, celelibi--- via Syslinux wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > OBJ directory creation changed from a .PHONY target to a real target > used through an order-only dependency. > > A target depending on another target marked .PHONY is always rebuilt, > thus forcing all the .o files to be rebuilt everytime.
2015 Aug 26
4
[PATCH 0/3] efi: A few warning fixes
From: Sylvain Gault <sylvain.gault at gmail.com> I don't know if I should merge those trivial warning fix into one commit. I can reformat it as requested. Those are a few warning fixes for the efi part. The code involved has mainly been introduced in recent commits. Sylvain Gault (3): efi: fix warnings about argument types efi: fix pointer-type mismatch assigment warning efi: fix
2015 Oct 13
5
[PATCH 0/2] Stack overflows when running commands
From: Sylvain Gault <sylvain.gault at gmail.com> Hello there, I propose 2 patches that fix two possible stack overflows either when running a COM32 module or when loading a new config file. I didn't find a better way to do this than to use the infamous setjmp/longjmp functions to restore the stack to a previous state. This makes the logic a bit more complex, but the behavior is not
2015 Sep 29
10
[PATCH 0/2] Fixes for gcc 5
From: Sylvain Gault <sylvain.gault at gmail.com> TL;DR: The section aligment in linker scripts messed-up the memory mapping needed for the compression / decompression to work. The bug with gcc 5 is not trivial, I'll do my best to explain it here. Basically, there are two memory mappings of the code. One in "virtual memory", and one in "load memory". The one in
2015 Sep 16
1
[PATCH 1/4] efi: Don't unnecessarily rebuild syslinux.so
On Mon, 14 Sep 2015 05:50:56 +0200 celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > OBJ directory creation changed from a .PHONY target to a real target > used through an order-only dependency. > > A target depending on another target marked .PHONY is always rebuilt, > thus forcing all the .o files to
2015 Sep 14
11
[PATCH 0/4] efi: Makefile improvement
From: Sylvain Gault <sylvain.gault at gmail.com> These few patches contain a few improvement about the Makefiles for EFI. Mainly, to rebuild the files when needed, and only when needed. The three shell scripts efi/{check,build,clean}-gnu-efi.sh disappeared and are now integrated as makefile recipes. You'll notice an argument ARFLAGS=rvU to the recursive make calls to gnu-efi. This is
2015 Sep 25
2
[PATCH 0/1] efi: DNS resolver
On Tue, Sep 15, 2015 at 05:22:40AM -0400, Gene Cumm via Syslinux wrote: > On Sep 10, 2015 1:32 AM, "celelibi--- via Syslinux" <syslinux at zytor.com> wrote: > > > > From: Sylvain Gault <sylvain.gault at gmail.com> > > > > Despite having native network capabilities, UEFI 2.4 (the most > > widely deployed at the moment) has no native DNS
2015 Oct 15
2
[PATCH 2/4] Remove unused linker scripts
On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Some linker scripts were splitted into i386 and x86_64 versions in > commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were > left there. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com>
2015 Aug 26
5
[PATCH] Call ExitBootServices twice
From: Sylvain Gault <sylvain.gault at gmail.com> On some architecture, including my hardware, the function ExitBootServices may need to be called twice in order to successfully exit the boot services. As stated by the UEFI spec, the first call to ExitBootServices may perform a partial shutdown of the services. It seems that during this partial shutdown, the memory map can be modified, thus
2015 Nov 27
8
[PATCH 0/2] Do not use the "red zone" on EFI
From: Sylvain Gault <sylvain.gault at gmail.com> The System V ABI for x86-64 specify that a "red zone" is an area of 128 bytes above the current stack frame. This area can be used by a called function in order to avoid the overhead of modifying the stack pointer. The direct effect is that interrupt/event/signal handlers must not write to this area. In the UEFI calling convention,