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

Dependency Graph #44

Open
RafaelRMachado opened this Issue Mar 29, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@RafaelRMachado
Copy link

RafaelRMachado commented Mar 29, 2016

First of all this project is amazing!

Would it be possible to add a dependency graph option ?
I think on something to let easier to understand what modules are dependent to each other.

@NikolajSchlej

This comment has been minimized.

Copy link
Collaborator

NikolajSchlej commented Mar 29, 2016

Thanks.

There is a problem with dependency graph, and it's a big one: modules are very rarely dependent on modules (the only cases are BEFORE and AFTER opcodes). Most of modules are dependent on PPIs/protocols, but there is no easy way to determine what module publish/unpublish/republish a given protocol. There are some easy heuristics like "if the module has protocol GUID inside, but it's not in it's DEPEX section, it's probably publishing it", there are some more complex heuristics, there are disassembler/decompiler engines that can be used to locate calls of RegisterProtocol/NotifyProtocol and similar functions - possibilities are many, but all of them are very hard to automate well enough.
One of the best options is symbolic execution, or something like @jethrogb did here, but it also very hard to do without human assistance. And then there are events and notifications, and callbacks, and interrupts, and SMI handlers, and...

I don't say the feature isn't worth it, but there are many easier things to do right now, like NVRAM parsing/validation and new builder code, so I don't think I can get into DepGraph problem any time soon.

@jethrogb

This comment has been minimized.

Copy link

jethrogb commented Mar 29, 2016

"if the module has protocol GUID inside, but it's not in it's DEPEX section, it's probably publishing it"

In my experience, even this is not always the case in practice. For example the ThinkPad modules I've worked with often contain many GUIDs inside which are never referenced by the code.

@NikolajSchlej

This comment has been minimized.

Copy link
Collaborator

NikolajSchlej commented Mar 29, 2016

Yep, seen such cases too.
DepGraph based on firmware image only will be a tough nut with symbolic exec/virtualization, and even tougher without it, that's why the only thing done in this general direction was DEPEX parsing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment