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

Proot problem on oreo 8.1 #49

Open
kazz2020 opened this issue Nov 6, 2018 · 17 comments
Open

Proot problem on oreo 8.1 #49

kazz2020 opened this issue Nov 6, 2018 · 17 comments

Comments

@kazz2020
Copy link

kazz2020 commented Nov 6, 2018

Hi
I dont know where to write this so sorry if that is wrong place :/
I have Honor 8x android 8.1 and after installing LXDE on Kali nethunter in Termux (in kali apt update && apt upgrade are ok) i have such error:

Setting up man-db (2.8.4-2+b1) ...
Building database of manual pages ... ./tracee/event.c:517: int handle_tracee_event(Tracee *, int): assertion "!IS_IN_SYSENTER(tracee)" failed proot warning: signal 6 received from process 7750
$
I can admit that everything was ok on my ze520kl android 8.0 version.
Does anybody has solution for my problem?

Originally posted by @kazz2020 in #13 (comment)

@michalbednarski
Copy link
Collaborator

I couldn't reproduce with mandb -cq command, but generally initial troubleshooting is to set export PROOT_NO_SECCOMP=1 before launching proot.

If it didn't help then please run proot with PROOT_VERBOSE=9 set and provide me output (script command can be used to capture terminal output, by default results are written to typescript file, exit shell to finish capture)

@corbinlc
Copy link
Contributor

A lot more is working now on Huawei devices, but there is a lot still not working. I wonder if this is another one of those issues. Getting the log would probably help as you mentioned.

@corbinlc
Copy link
Contributor

CypherpunkArmory/UserLAnd#398 talks about issues related to Huawei devices some.

@corbinlc
Copy link
Contributor

@michalbednarski I found a reproducible case for this. If on a Huawei device, I sudo apt install lxde-core and then exit that session in UserLAnd and try to reconnect with it via ssh or vnc I will get that assertion and things will die very early on. I have a log right now. I am digging through it and will share it.

@corbinlc
Copy link
Contributor

corbinlc commented Dec 26, 2018

The other Huawei issue I am having is that the pokedata work around cannot properly handle if any of the code changes the system number to PR_void. When the syscall is restarted, it gets trashed by seccomp filtering. You had mentioned previously what needed to be done about this, but I did not understand your suggestion.
This is what you said (in #15)...

There is already mechanism that automatically skips SIGSYS if that is the case.

The flag is set in case SIGTRAP | 0x80:,
but it seems that I missed case SIGTRAP | PTRACE_EVENT_SECCOMP << 8:
(which is what you've probably observed, you can check that by running with PROOT_NO_SECCOMP=1 and seeing if problem persists, but either way it seems that you've found valid bug)

I worked around this in some places previously by using a different benign system call, but it looks like it is popping up in some other use case. What is the proper fix for this bug?

@corbinlc
Copy link
Contributor

About this issue...not the other Huawei issue I just mentioned. It looks like the issue is related to readline so you probably don't need so many packages installed.

@corbinlc
Copy link
Contributor

So, when going through login on a newer Huawei device, that has readline installed, you will get the assertion described by @kazz2020

@corbinlc
Copy link
Contributor

Here is the log: https://www.dropbox.com/s/qj3qpv7wu0vcwrv/Huawei_PRoot_Debug_Log?dl=0
It dies right after looking for the inputrc file.

michalbednarski added a commit that referenced this issue Dec 30, 2018
When syscall was cancelled by poke data workaround,
don't relaunch it if it was cancelled by us
(otherwise we'll relaunch it as cancel wasn't intended,
but required to actually perform different operation (memory write))

#49
@michalbednarski
Copy link
Collaborator

@corbinlc Commited experimental fix, but this will need further testing

@corbinlc
Copy link
Contributor

corbinlc commented Jan 2, 2019

I will test it out on my Huawei device. Do you think this is the underlying issue for both of the issues I mentioned 1) !IS_IN_SYSENTER(tracee) and 2) the missed case here SIGTRAP | PTRACE_EVENT_SECCOMP << 8 that I reported back on #15 ?

@corbinlc
Copy link
Contributor

corbinlc commented Jan 3, 2019

The change makes it so installing readline-common no longer dies with the !IS_IN_SYSENTER(tracee) assertion, but breaks twm (tabbed window manager) from working in UserLAnd. I will get a log of that. Do you have a Huawei device? If not, maybe I could mail you one.

@corbinlc
Copy link
Contributor

corbinlc commented Jan 3, 2019

Oddly, for the twm case it created a !IS_IN_SYSENTER(tracee) issue where they hadn't been one before. So, it is like it fixed that issue in one case and caused it in another.
Here is it the log before your change: https://www.dropbox.com/s/xrvbl8l53irmwrn/Huawei_TWM_Working_PRoot_Log?dl=0
Here is the log after your change:
https://www.dropbox.com/s/ekdt99uhh07xm5n/Huawei_TWM_Failing_PRoot_Log?dl=0

@corbinlc
Copy link
Contributor

@michalbednarski, do you have any new thoughts on this?

@michalbednarski
Copy link
Collaborator

Not really new thoughts, but I can write down what I've found:

First, this issue with Huawei kernels can be emulated using LD_PRELOAD with following library, if you do this on non-Huawei phone.

#include <dlfcn.h>
#include <errno.h>
#include <sys/types.h>
#include <stdlib.h>

long ptrace(int request, pid_t pid, void *addr, void *data)
{
        if (request == 4 || request == 5)
        {
                errno = -EIO;
                return -1;
        }
        if (request == 0) {
                unsetenv("LD_PRELOAD");
        }
        return ((long(*)(int,pid_t,void*,void*))(dlsym(RTLD_NEXT, "ptrace")))(request, pid, addr, data);
}
(gdb) set startup-with-shell off
(gdb) set env LD_PRELOAD=/data/.../nopoke.so
(gdb) run

Original issue happened when on devices with broken PTRACE_POKEDATA syscall entry handler first written some memory and then decided to fail syscall. I think originally issue was that /etc/inputrc were present but user wasn't allowed to open it (UserLAnd version of proot keeps track of virtual uids and denies file access if access is denied according to these, In normal/Termux versions of proot this issue probably could be triggered with mv some_file non_existent_dir/some_file)


When I've checked updated version with twm from termux-ubuntu (and Xephyr on desktop GNU/Linux as X display) it hadn't problems. strace seems to not work in that version, however I haven't found nice fix for that.

@corbinlc
Copy link
Contributor

Can you describe the fix for this...
2) the missed case here SIGTRAP | PTRACE_EVENT_SECCOMP << 8 that I reported back on #15 ?

@corbinlc
Copy link
Contributor

Because it should be ok for an extension or otherwise to ultimately cause the sysnum to get changed to PR_void, either by returning a negative number or manually doing so.

@corbinlc
Copy link
Contributor

corbinlc commented Feb 4, 2019

Looks like if people are able to upgrade their devices to EMUI 9, the pokedata issue on Huawei devices goes away. Still interested in the item you said was a bug (two comments ago) for people stuck at android 8.

z80oolong pushed a commit to z80oolong/proot-z80oolong that referenced this issue Mar 17, 2019
When syscall was cancelled by poke data workaround,
don't relaunch it if it was cancelled by us
(otherwise we'll relaunch it as cancel wasn't intended,
but required to actually perform different operation (memory write))

termux#49
@termux termux deleted a comment from Asif16 Jun 7, 2019
Grimler91 pushed a commit that referenced this issue Jul 25, 2022
When syscall was cancelled by poke data workaround,
don't relaunch it if it was cancelled by us
(otherwise we'll relaunch it as cancel wasn't intended,
but required to actually perform different operation (memory write))

#49
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

3 participants