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

[BUG] ioctl TCGETS return and glibc throws "**** stack smashing detected ***" #149

Closed
jessehui opened this issue Dec 20, 2021 · 0 comments · Fixed by #157
Closed

[BUG] ioctl TCGETS return and glibc throws "**** stack smashing detected ***" #149

jessehui opened this issue Dec 20, 2021 · 0 comments · Fixed by #157
Assignees

Comments

@jessehui
Copy link
Contributor

Describe the bug

In the make test, when running ioctl test with glibc, the test will fail with error message: **** stack smashing detected ***.

To reproduce

Steps to reproduce the behavior:

  1. make
  2. comment the SGX related tests in "ioctl" test case
  3. TESTS=ioctl make test-glibc

Expected behavior

make test-glibc should succeed.

Environment

  • HW: [e.g. SGX1, SGX2] SGX2
  • OS: [e.g. Ubuntu18.04, CentOS8.1] ubuntu
  • Occlum version: [e.g. 0.17.0] NGO master

Additional context

After some digging, I found that it is related with isatty function which will call INTERNAL_SYSCALL macro in glibc and finally call ioctl syscall with TCGETS. However, I have inspected the implementation of TCGETS and didn't find anything abnormal.

There are actually two ways to workaround that I have tried:
(1) Directly use syscall to replace INTERNAL_SYSCALL macro
(2) Shrink the size of TCGETS related struct (from 32 to 30)

However, in CI environment, this error will not show. The reason is unclear.

Possible solution/Implementation

In my opinion, this could be related to syscall entry or the memory manipulation in ioctl implementation but I am not sure.

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

Successfully merging a pull request may close this issue.

2 participants