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

Get rid of stack-pivot and ROP (schedule springboard) #176

Open
ampresent opened this issue Dec 15, 2022 · 0 comments
Open

Get rid of stack-pivot and ROP (schedule springboard) #176

ampresent opened this issue Dec 15, 2022 · 0 comments
Labels
Feature New feature or request

Comments

@ampresent
Copy link
Collaborator

These two fundamental features are written in binary hacker's fashion, and are frequently broken on different Linux major version, and different architectures. So it's significantly important to find an alternative way to replace __schedule function.

There are two major pitfalls we may encounter when replacing __schedule, and they are why stack-pivot and ROP comes for.

  • After unloading, the module's .text section is gone. If a task wakes up after unloading, it steps on the module's .text section and panics.
  • The top and bottom halves of __schedule may assume __schedule to have different stack layout and size.

Apart from stack-pivot + ROP, another potential solution to these problems might be,
When unloading the module,

  • stop_machine, and restore __schedule's prologue to nop, and add sleeping tasks to sleep_list
  • traverse sleep_list, and set their need_resched bit, and wakes them up
  • wait until all tasks in sleep_list to finish one round of __schedule, and enters vmlinux's __schedule

In this way, springboard_search, stack guard, stack-pivot can all be eliminated.

@ampresent ampresent added the Feature New feature or request label Dec 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant