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

Use case planning #45

Open
Soft opened this issue Oct 16, 2017 · 3 comments
Open

Use case planning #45

Soft opened this issue Oct 16, 2017 · 3 comments

Comments

@Soft
Copy link
Contributor

Soft commented Oct 16, 2017

I created this ticket for brainstorming how Nitro could be used and what kind of APIs would be needed to support these use cases. The use cases could be low-level features or higher-level ideas. If there is need, I'll create more issues for individual items.

Off the top of my head, following things come to mind:

  • Collection of detailed information about individual applications. I guess this would include support for extracting system call arguments.
  • Altering of machine execution based on events that happened. So far our test have only included observing machine's activity.
  • Replacing, extending & altering OS system call handlers. I think this needs an API to control system call handler execution.

What do you think?

@Wenzel
Copy link
Member

Wenzel commented Oct 16, 2017

I think you have already the right use cases.

  • monitoring
  • altering the execution by rewriting syscall arguments values or just sysall return values.

Could you be more specific about the last one ? Extending or altering an OS system call handler ?

@Soft
Copy link
Contributor Author

Soft commented Oct 26, 2017

Regarding the second and third point, I've made a small proof-of-concept test case. It does not do everything correctly but it still seemed to work in the case of this very limited test case. Of course it probably still messes up machine state but for this test it didn't seem to matter

@Soft
Copy link
Contributor Author

Soft commented Oct 27, 2017

Hmm based on our latest discussion it seems that my approach for system call bypass cannot possibly work, I am wondering why that happened. Maybe I made a mistake in testing it or the test was flawed in some other way. In any case, I'll look into the kernel-side approach of bypassing system call handlers.

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