Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenBSD port #87

Open
vrza opened this issue Jun 9, 2022 · 4 comments
Open

OpenBSD port #87

vrza opened this issue Jun 9, 2022 · 4 comments

Comments

@vrza
Copy link
Contributor

vrza commented Jun 9, 2022

Project now builds using the feature branch from #86

It segfaults at runtime in init_terminal_settings in wrappers.c, when ioctl(2) (called by tcgetattr(3)) attempts to write to this memory location:

static struct termios original;

ioctl(2) fails with errno == 14 (EFAULT, "Bad address").

Is it possible that there is some unsafe programming practice at play here that OpenBSD catches?

@vrza
Copy link
Contributor Author

vrza commented Jun 9, 2022

Passing a pointer to heap memory to ioctl instead works around the problem:

void __attribute__((constructor)) init_terminal_settings()
{
    // Make a backup of the terminal state to restore to later.
    int attr;
    struct termios *t;
    t = malloc(sizeof(struct termios));
    if (isatty(STDIN_FILENO)) {
        attr = tcgetattr(STDIN_FILENO, t);
        memmove(t, &original, sizeof(struct termios));
        if (attr != 0) err(EXIT_FAILURE, "Failed to query terminal attributes.");
    }

}

but I still don't understand why it can't write directly to the data segment.

@taviso
Copy link
Owner

taviso commented Jun 9, 2022

wow, cool that it works!

I'm not really sure why it's failing, the code seems okay to me... I think there's no guarantee about what order constructors are run in, so maybe they're being run too early, and OpenBSD expects some other constructor to run first?

These might not really be necessary anymore though... I might be able to refactor them out. I think now terminal settings are better handled, so less cleanup is necessary.

(Sorry for the slow response to PRs, I'll get to them!)

@vrza
Copy link
Contributor Author

vrza commented Jun 9, 2022

Although it passes the workaround, it proceeds to segfault here:

Program received signal SIGSEGV, Segmentation fault.
0x0804adb8 in ?? ()
(gdb) bt
#0  0x0804adb8 in ?? ()
#1  0x0804a53b in __init ()
#2  0x0804ad67 in _start ()
(gdb) disas __init
Dump of assembler code for function __init:
   0x0804a530 <+0>:	push   %ebp
   0x0804a531 <+1>:	mov    %esp,%ebp
   0x0804a533 <+3>:	and    $0xfffffff0,%esp
   0x0804a536 <+6>:	call   0x804ad90
   0x0804a53b <+11>:	nop
   0x0804a53c <+12>:	leave  
   0x0804a53d <+13>:	ret    
End of assembler dump.

@vrza
Copy link
Contributor Author

vrza commented Jun 10, 2022

After rebuilding the symbol undefine list for OpenBSD (using the Linux list as the starting point), the "Bad address" ioctl issue is gone. I reverted the workaround.

Program still segfaults in __init, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants