Pinging per Laurent.
On 2/13/21 3:48 PM, Laurent Vivier wrote:
Le 31/01/2021 à 07:19, Vincent Fazio a écrit :
From: Vincent Fazio
Previously, guest_loaddr was not taken into account when returning an
address from pgb_find_hole when /proc/self/maps was unavailable which
caused an improper
Pinging per Laurent.
On 2/14/21 5:32 AM, Alex Bennée wrote:
Vincent Fazio writes:
From: Vincent Fazio
Previously, if the build host's libc did not define MAP_FIXED_NOREPLACE
or if the running kernel didn't support that flag, it was possible for
pgd_find_hole_fallback to
On 2/15/21 3:52 AM, Alex Bennée wrote:
Vincent Fazio writes:
Ahh right so I think this is a case of binaries being built on a
different platform than kernel they are running on. In which case the
flag would be defined but the underlying kernel fails to identify it. Is
this a container
On Sun, Feb 14, 2021 at 6:50 AM Laurent Vivier wrote:
>
> Le 14/02/2021 à 12:24, Alex Bennée a écrit :
> >
> > Vincent Fazio writes:
> >
> >> From: Vincent Fazio
> >>
> >> Previously, pgd_find_hole_fallback assumed that if the build host&#
From: Vincent Fazio
Previously, guest_loaddr was not taken into account when returning an
address from pgb_find_hole when /proc/self/maps was unavailable which
caused an improper guest_base address to be calculated.
This could cause a SIGSEGV later in load_elf_image -> target_mmap for
ET_E
From: Vincent Fazio
Previously, if the build host's libc did not define MAP_FIXED_NOREPLACE
or if the running kernel didn't support that flag, it was possible for
pgd_find_hole_fallback to munmap an incorrect address which could lead to
SIGSEGV if the range happened to overlap with
From: Vincent Fazio
Previously, pgd_find_hole_fallback assumed that if the build host's libc
had MAP_FIXED_NOREPLACE defined that the address returned by mmap would
match the requested address. This is not a safe assumption for Linux
kernels prior to 4.17
Now, we always compare mmap's
From: Vincent Fazio
Previously, the signal handler would be byte swapped if the target and
host CPU used different endianness. This would cause a SIGSEGV when
attempting to translate the opcode pointed to by the swapped address.
Thread 1 "qemu-ppc64" received signal SIGSEGV, Segmenta
From: Vincent Fazio
Previously, the signal handler would be byte swapped if the target and
host CPU used different endianness. This would cause a SIGSEGV when
attempting to translate the opcode pointed to by the swapped address.
Thread 1 "qemu-ppc64" received signal SIGSEGV, Segmenta
David, Laurent,
On 3/15/20 9:21 PM, David Gibson wrote:
On Sun, Mar 15, 2020 at 07:29:04PM -0500, Vincent Fazio wrote:
Laurent,
On Sun, Mar 15, 2020 at 1:10 PM Laurent Vivier wrote:
Le 15/03/2020 à 16:52, Vincent Fazio a écrit :
From: Vincent Fazio
In ELFv2, function pointers are entry
Laurent,
On Sun, Mar 15, 2020 at 1:10 PM Laurent Vivier wrote:
>
> Le 15/03/2020 à 16:52, Vincent Fazio a écrit :
> > From: Vincent Fazio
> >
> > In ELFv2, function pointers are entry points and are in host endianness.
>
> "host endianness" is misleading
From: Vincent Fazio
In ELFv2, function pointers are entry points and are in host endianness.
Previously, the signal handler would be swapped if the target CPU was a
different endianness than the host. This would cause a SIGSEGV when
attempting to translate the opcode pointed to by the swapped
12 matches
Mail list logo
