Re: debugging "invalid argument" errors when loading elf files
On Tue, Oct 10, 2023 at 11:44 PM Lorenz (xha) wrote: > On Mon, Oct 09, 2023 at 01:29:52PM -0700, Philip Guenther wrote: > > On Mon, Oct 9, 2023 at 11:21 AM Lorenz (xha) wrote: > > > > > hi misc@, > > > > > > i'm currently porting the hare programming language to openbsd and i am > > > having quite a few problems trying to use a linker script. i am always > > > getting a "/bin/ksh: .bin/hare: Invalid argument" error. > > > > > > so far i tried a lot of stuff like comparing a working version without > a > > > linker script, looking if any of the programm headers are missing, etc. > ... > > Read /usr/src/sys/kern/*exec* and review the logic around the 10 > > occurrences of EINVAL in that code. Presumably the differences you > > identified will point to one or more of them > > found it: PT_PHDRS is missing. i didn't identify that difference at > first tho. it's needeed for PIE if i understand correctly. > Yeah. > why is ld not adding a PT_PHDR programm header? as far as i undestand, > PT_PHDR are the programm headers themselfs? PT_PHDR is the tag for an entry in the program headers that points to the program headers themselves. Some ELF files (for example, core files) have a program header but don't include a PT_PHDR entry in it. It's presumably not added by ld because you supplied a linker script and ld is trying to give you as much control as possible. Some of the other arguments you supplied may have required it to fill in other details, but including a DT_PHDR entry in the program header is apparently not one of them. As Theo says, this sort of thing makes linker scripts very subtle, with arch dependencies**, interactions with RELRO and W^X processing, and plain ABI weirdness. Even those of us who have written several of them often have to start from what 'readelf -lS' shows the default is to put together a starting point and massage it from there to achieve whatever our goal for going through this effort is. ** e.g., permissions on and immutability of .plt, .got, etc sections vary. Some archs have required some sections to be before or after others due to the CPU treating a limited range offset in some instructions as unsigned, so 'before' cannot be reached this is my linker script ... > i am moving the init functions in a > different section so that the hare runtime can execute them and not > libc. Well, the first issue with this is that libc doesn't invoke init functions, so there's some sort of misunderstanding going on. The .init section of the executable itself is invoked by the entry point code in crt0 before main is called, not libc. At a low level, that's done not via DT_INIT's value or the section name but via a symbol placed in the section which would presumably be carried along if you renamed the section, so you can't affect that. The .init_array section is handled by ld.so in dynamic programs where it's located via DT_INIT_ARRAY, and by crt0 in static programs where it's located via *_start and *_end symbols which I _guess_ would be from whatever ended up with the .init_array section name, so maybe renaming the section would prevent them from being invoked in that case, but I'm not sure and that an implementation detail that might change. (Moving a chunk of the crt0 code into libc would be possible (glibc did it, for example) and might make some evolution easier, but it hasn't happened.) ...but, backing up...what problem exists with the ordering that currently happens that makes you believe you need to interpose and have the "hare runtime" (sorry, I'm not familiar with that) execute them? How will you measure success of the change? Philip Guenther
Re: debugging "invalid argument" errors when loading elf files
I think the problem here is you are using a linker script.
You are creating a new class of binary, with different layouts and issues,
and since you are doing it on your own, you'll never know what you are
missing until later.
The linker script stuff is fragile, poorly undocumented stuff which changes
constantly between releases, has big variance between clang and gnu toolchains,
and if you don't have to do it you shouldn't.
We only use it for kernels, bootblocks, and ld.so. And in all those cases,
we need a linker script *PER ARCHITECTURE*.
I think you'll never get it perfect for 1 architecture, and certainly not
for 4 architectures.
Lorenz (xha) wrote:
> On Mon, Oct 09, 2023 at 01:29:52PM -0700, Philip Guenther wrote:
> > On Mon, Oct 9, 2023 at 11:21 AM Lorenz (xha) wrote:
> >
> > > hi misc@,
> > >
> > > i'm currently porting the hare programming language to openbsd and i am
> > > having quite a few problems trying to use a linker script. i am always
> > > getting a "/bin/ksh: .bin/hare: Invalid argument" error.
> > >
> > > so far i tried a lot of stuff like comparing a working version without a
> > > linker script, looking if any of the programm headers are missing, etc.
> > >
> >
> > So you have a working binary (w/o linker script) and a not-working binary
> > (w/linker script) and you've even done the comparison of the program
> > headers of the two...and you're not going to show those but rather ask
> > what, in general, could be wrong? Okay.
>
> i am pretty sure that it woudln't have been helpful since i don't know
> what i am doing (yet). nothing's working
>
> > Read /usr/src/sys/kern/*exec* and review the logic around the 10
> > occurrences of EINVAL in that code. Presumably the differences you
> > identified will point to one or more of them
>
> found it: PT_PHDRS is missing. i didn't identify that difference at
> first tho. it's needeed for PIE if i understand correctly.
>
> why is ld not adding a PT_PHDR programm header? as far as i undestand,
> PT_PHDR are the programm headers themselfs?
>
> this is my linker script (kind of mess right now because of debugging).
> it is supposed to link with libc. i am moving the init functions in a
> different section so that the hare runtime can execute them and not
> libc. that should have nothing to do with the problems i am having,
> however. am i missing something?
>
> ```
> ENTRY(__start)
> SECTIONS {
> .text : {
> KEEP (*(.text))
> *(.text.*)
> }
>
> .data : {
> KEEP (*(.data))
> *(.data.*)
> }
>
> .init_array : {
> PROVIDE_HIDDEN (__init_array_start = .);
> KEEP (*(.init_array))
> PROVIDE_HIDDEN (__init_array_end = .);
> }
>
> .fini_array : {
> PROVIDE_HIDDEN (__fini_array_start = .);
> KEEP (*(.fini_array))
> PROVIDE_HIDDEN (__fini_array_end = .);
> } :data
>
> .test_array : {
> PROVIDE_HIDDEN (__test_array_start = .);
> KEEP (*(.test_array))
> PROVIDE_HIDDEN (__test_array_end = .);
> } :data
>
> .note.openbsd.ident : {
> KEEP (*(.note.openbsd.ident))
> *(.note.openbsd.*)
> }
>
> .bss : {
> KEEP (*(.bss))
> *(.bss.*)
> }
> }
> ```
>
> this is the readelf --headers of the programm produced with the linker
> script:
>
> ```
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSizMemSiz Flags Align
> INTERP 0x1000 0x 0x
> 0x0013 0x0013 R 1
> [Requesting program interpreter: /usr/libexec/ld.so]
> LOAD 0x1000 0x 0x
> 0xb47c 0xb47c R 1000
> LOAD 0xc480 0xb480 0xb480
> 0x001356d0 0x001356d0E1000
> LOAD 0x00141b50 0x00140b50 0x00140b50
> 0x000211e8 0x000211e8 RW 1000
> LOAD 0x00162d38 0x00161d38 0x00161d38
> 0x0018 0x0018 R 1000
> LOAD 0x00162d50 0x00161d50 0x00161d50
> 0x 0x09b0 RW 1000
> DYNAMIC0x00162ab0 0x00161ab0 0x00161ab0
> 0x0160 0x0160 RW 8
> GNU_RELRO 0x00162a40 0x00161a40 0x00161a40
> 0x02f8 0x05c0 R 1
> GNU_EH_FRAME 0xc390 0xb390 0xb390
> 0x002c 0x002c
Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets
Nan ZoE wrote: > In *OpenBSD 7.3,* out of 264 programs, we only > managed to generate ROP for 134 programs, with a success rate of *50.75%*. Please provide a list of all programs where you *ESCALATED PRIVILEGE* via ROP methods. I ask, because: 1. If you are playing with a setuid static program, you cannot see where in memory the binary is mapped, so you do not know the precise syscall stub that is permitted for execve(2). 2. If you are playing with a setuid dynamic program, you cannot see where in memory libc.so is mapped, so you do not know the precise syscall stub that is permitted for execve(2). 3. If you are attacking a daemon, you cannot see where in memory it's execve stub (dynamic or static) is mapped, so you do not know the precise syscall stub to address which will perform execve(2). Please explain how you perform the step of determining the execve system call entrypoint for a memory image which is not readable. >From innovations.html: ld.so and crt0 register the location of the execve(2) stub with the kernel using pinsyscall(2), after which the kernel only accepts an execve call from that specific location. Theo de Raadt, Feb 2023. What info leak are you exercising to extract libc.so's location, and per-boot layout, and then precisely target the specific "syscall" instruction? My theory is that you are performing tests which are highly synthetic (like -- reading a binary, checking it's in-memory layout once it starts executing), and then you conclude that all the steps to your ROP methodology are sufficient to plausibly gain *ESCALATED PRIVILEGE*. So either you have new methodology that allows you to bypass these other mitigations, or you have jumped to conclusion that the existance of polymorphic ROP learned from (impossible) runtime inspection gaurantees exploit.
Re: Compulab's Fitlet3: Intel's Elkhart Atom X6425E with MARVELL PHY 88E1512 Ethernet
On Mon, Sep 18, 2023 at 09:15:48AM +0200, Wolfgang Oelerich wrote: > ok; thank you for the quick reply. The next amd64 -current snapshot should have dwqe(4) attach to at least one of the Elkhart Lake interfaces of your system, provided it has PCI product Id 4ba0 in pcidump -vv output. > > Am 15.09.2023 um 21:54 schrieb Stefan Sperling : > > On Fri, Sep 15, 2023 at 04:55:42PM +0200, Wolfgang Oelerich wrote: > >> Hello, > >> > >> recently, I „inherited“ one of Compulab‘s Fitlet3. I received it with > >> Linux Mint installed and found all 4 available Ethernet ports working: > >> 2 of its extensional FACET card and 2 of Intel‘s Elkhart Lake Atom X6425E > >> with MARVELL-type PHY „88E1512" at Atom's PCIe bus (see link below). > >> > >> Now, I tried a clean install of OpenBSD 7.3/AMD64 which smoothly worked > >> out but only the FACET card Ethernet ports have been recognized properly. > >> While assuming BIOS is ok since Linux Mint worked I am wondering how far > >> the hardware combination of X6425E/MARVELL PHY 88E1512 is already set to > >> be working or if there is some driver or other Kernel level code not > >> available yet. > > > > Elkhart Lake Ethernet will require PCI attachment code to be written > > for dwqe(4). There is interest in getting this working but it will take > > time. Definitely won't be ready for OpenBSD 7.4. Maybe 7.5. > >
Re: openFPGAloader successfully built, but can't flash with ftdi error
Gregory Edigarov wrote: > On Fri, 6 Oct 2023 10:06:15 - (UTC) > Stuart Henderson wrote: > > > On 2023-10-06, S V wrote: > > >> The software that you're using may need the USB device to be > > >> attached to ugen rather than uftdi. The simplest way to do this is > > >> probably to type "boot -c" at the boot loader, "disable uftdi", > > >> "quit". > > > > > > > > > Thanks!!! It works!!! > > > > good, thanks for confirming. > > > > > Last "barrier" in front of openhardware > > > > > > more or less falls! :D :D :D > > > > btw, see bsd.re-config(5) if you want this regularly (but then, you > > won't be able to connect to a uftdi device as a normal serial port > > with cu). > > > > Just a small bit of side note, perhaps somebody with knowledge of usb > stack will find it interesting enough to implement. > I think we need a way to detach a specific usb driver from device on the > fly, leaving it attached as ugen. > That "disable [whatever]" way is a problem itself because it is > possible that there also is a real device that needs to be attached. That seems like what you want, but please consider. Now that you've done that, who is opening that 'raw usb device'? Or is the regular user? Who fully audited the USB stack for this use case, to make sure there are no bugs which can result in escalation or misbehaviour? What happens if a usb device is played with directly, while there is a kernel driver which assumes it has control over it? What kinds of racy bugs lurk in that area? We really have no interlock design allowing such sharing. I can give you the anwers to these questions. Noone did that audit. That is why we have been avoiding going down your chosen roadmanp. When you say "I think we need", you can easily read it as "I think I want" and it means someone must do the not-small job.
Re: openFPGAloader successfully built, but can't flash with ftdi error
On Fri, 6 Oct 2023 10:06:15 - (UTC) Stuart Henderson wrote: > On 2023-10-06, S V wrote: > >> The software that you're using may need the USB device to be > >> attached to ugen rather than uftdi. The simplest way to do this is > >> probably to type "boot -c" at the boot loader, "disable uftdi", > >> "quit". > > > > > > Thanks!!! It works!!! > > good, thanks for confirming. > > > Last "barrier" in front of openhardware > > > > more or less falls! :D :D :D > > btw, see bsd.re-config(5) if you want this regularly (but then, you > won't be able to connect to a uftdi device as a normal serial port > with cu). > Just a small bit of side note, perhaps somebody with knowledge of usb stack will find it interesting enough to implement. I think we need a way to detach a specific usb driver from device on the fly, leaving it attached as ugen. That "disable [whatever]" way is a problem itself because it is possible that there also is a real device that needs to be attached. -- With best regards, Gregory Edigarov
Re: debugging "invalid argument" errors when loading elf files
On Mon, Oct 09, 2023 at 01:29:52PM -0700, Philip Guenther wrote:
> On Mon, Oct 9, 2023 at 11:21 AM Lorenz (xha) wrote:
>
> > hi misc@,
> >
> > i'm currently porting the hare programming language to openbsd and i am
> > having quite a few problems trying to use a linker script. i am always
> > getting a "/bin/ksh: .bin/hare: Invalid argument" error.
> >
> > so far i tried a lot of stuff like comparing a working version without a
> > linker script, looking if any of the programm headers are missing, etc.
> >
>
> So you have a working binary (w/o linker script) and a not-working binary
> (w/linker script) and you've even done the comparison of the program
> headers of the two...and you're not going to show those but rather ask
> what, in general, could be wrong? Okay.
i am pretty sure that it woudln't have been helpful since i don't know
what i am doing (yet). nothing's working
> Read /usr/src/sys/kern/*exec* and review the logic around the 10
> occurrences of EINVAL in that code. Presumably the differences you
> identified will point to one or more of them
found it: PT_PHDRS is missing. i didn't identify that difference at
first tho. it's needeed for PIE if i understand correctly.
why is ld not adding a PT_PHDR programm header? as far as i undestand,
PT_PHDR are the programm headers themselfs?
this is my linker script (kind of mess right now because of debugging).
it is supposed to link with libc. i am moving the init functions in a
different section so that the hare runtime can execute them and not
libc. that should have nothing to do with the problems i am having,
however. am i missing something?
```
ENTRY(__start)
SECTIONS {
.text : {
KEEP (*(.text))
*(.text.*)
}
.data : {
KEEP (*(.data))
*(.data.*)
}
.init_array : {
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array : {
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array))
PROVIDE_HIDDEN (__fini_array_end = .);
} :data
.test_array : {
PROVIDE_HIDDEN (__test_array_start = .);
KEEP (*(.test_array))
PROVIDE_HIDDEN (__test_array_end = .);
} :data
.note.openbsd.ident : {
KEEP (*(.note.openbsd.ident))
*(.note.openbsd.*)
}
.bss : {
KEEP (*(.bss))
*(.bss.*)
}
}
```
this is the readelf --headers of the programm produced with the linker
script:
```
Program Headers:
Type Offset VirtAddr PhysAddr
FileSizMemSiz Flags Align
INTERP 0x1000 0x 0x
0x0013 0x0013 R 1
[Requesting program interpreter: /usr/libexec/ld.so]
LOAD 0x1000 0x 0x
0xb47c 0xb47c R 1000
LOAD 0xc480 0xb480 0xb480
0x001356d0 0x001356d0E1000
LOAD 0x00141b50 0x00140b50 0x00140b50
0x000211e8 0x000211e8 RW 1000
LOAD 0x00162d38 0x00161d38 0x00161d38
0x0018 0x0018 R 1000
LOAD 0x00162d50 0x00161d50 0x00161d50
0x 0x09b0 RW 1000
DYNAMIC0x00162ab0 0x00161ab0 0x00161ab0
0x0160 0x0160 RW 8
GNU_RELRO 0x00162a40 0x00161a40 0x00161a40
0x02f8 0x05c0 R 1
GNU_EH_FRAME 0xc390 0xb390 0xb390
0x002c 0x002c R 4
OPENBSD_RANDOM 0x00162aa8 0x00161aa8 0x00161aa8
0x0008 0x0008 RW 8
GNU_STACK 0x 0x 0x
0x 0x RW 0
OPENBSD_NOBTCF 0x 0x 0x
0x 0xE0
NOTE 0x00162d38 0x00161d38 0x00161d38
0x0018 0x0018 R 4
Section to Segment mapping:
Segment Sections...
00 .interp
01 .interp .dynsym .gnu.hash .hash .dynstr .rela.dyn .rela.plt .rodata
.eh_frame_hdr .eh_frame
02 .text .init .fini .plt
03 .data .openbsd.randomdata.retguard.1205
