On Tue, 2018-01-30 at 11:47 +0200, Nadav Har'El wrote:
> I have a vague feeling that fix_permissions() cannot just work on the
> whole object it needs to know which of the PT_LOAD segments (see
> file::load_segment()) the RELRO falls in, but I'm hazy on the
> details. Maybe even
On Mon, Jan 29, 2018 at 3:51 PM, Nadav Har'El wrote:
>
> On Mon, Jan 29, 2018 at 12:16 PM, Rick Payne wrote:
>
>>
>> Maybe I'm not following. The GNU_RELO sections look the same between
>> the 2 versions of erlexec. First one (-ubuntu17.10) fails, second
On Mon, 2018-01-29 at 11:43 +0200, Nadav Har'El wrote:
> 1. Your compiler defaults to "full relro" (-Wl,-z,now -Wl,-z,relro)
> but for some reason object::relocate_pltgot() doesn't recognize the
> bind_now.
FWIW, on both workign and non-working builds, I see '-pie -z now -z
relro' being passed to
On Mon, 2018-01-29 at 12:27 +0200, Nadav Har'El wrote:
> Both versions used "-pie", not "-shared"?
Should be, yes. Its exactly the same build setup and the Makefile shows
'-pie' for LDFLAGS.
I don't think gcc7.2 contains any of the -mindirect-branch changes, so
thats a red-herring. I'll continue
On Mon, 2018-01-29 at 11:43 +0200, Nadav Har'El wrote:
>
> Hmm, I don't know, I wasn't aware anything like that changed.
> We usually change parts of the object marked by PT_GNU_RELRO to read-
> only in object::fix_permissions(), I'm guessing (but didn't check)
> this what caused the read-only
On Mon, Jan 29, 2018 at 11:20 AM, Rick Payne wrote:
> On Mon, 2018-01-29 at 10:54 +0200, Nadav Har'El wrote:
>
> This all seems reasonable.
> Maybe we somehow got the PLT becoming read-only, so we are getting a
> pagefault trying to write to it?
> Can you please try in gdb
On Mon, 2018-01-29 at 10:54 +0200, Nadav Har'El wrote:
> This all seems reasonable.
> Maybe we somehow got the PLT becoming read-only, so we are getting a
> pagefault trying to write to it?
> Can you please try in gdb "osv mmap" and look at the mapping which
> includes the faulting address
On Wed, Jan 24, 2018 at 11:07 AM, Rick Payne wrote:
> Hi,
>
> On 23/01/18 20:16, Nadav Har'El wrote:
>
>> I don't have any bright ideas, but just a few small comments below,
>> hopefully (?) they will help something...
>>
>
> Appreciated...
>
> This writes in "addr", which
]: Set hostname to: osv
Running from /init/00-cmdline: /usr/mgmt/cloud-init.so;
Running from /init/30-auto-02: /libhttpserver-api.so &!
httpserver: loaded plugin from path:
/usr/mgmt/plugins/libhttpserver-api_fs.so
page fault outside application, addr: 0x1a20fe28
[registers]
RIP: 0x00
Hi,
On 23/01/18 20:16, Nadav Har'El wrote:
I don't have any bright ideas, but just a few small comments below,
hopefully (?) they will help something...
Appreciated...
This writes in "addr", which seems a reasonable address (doesn't seem
like junk).
In object::resolve_pltgot() you can see
(?) they will help something...
> eth0: 192.168.122.61
> page fault outside application, addr: 0x1a60fe28
> [registers]
> RIP: 0x00492dd1 <elf::object::arch_relocate_jump_slot(unsigned
> int, void*, long)+67>
> C
> (gdb) bt
> #0 process
t; A few moving parts, so not sure what is causing this - but trying to start
> an erlang application I'm seeing this:
>
> eth0: 192.168.122.61
> page fault outside application, addr: 0x1a60fe28
> [registers]
> RIP: 0x00492dd1 <elf::object::arch_relocate_jump_slot(
A few moving parts, so not sure what is causing this - but trying to
start an erlang application I'm seeing this:
eth0: 192.168.122.61
page fault outside application, addr: 0x1a60fe28
[registers]
RIP: 0x00492dd1 <elf::object::arch_relocate_jump_slot(unsigned
int, void*, l
13 matches
Mail list logo