Skip to content

Changed README to README.md #4

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Changed README to README.md #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 16 additions & 16 deletions README → README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@

= A DFA-based x86 validator for Native Client =
# A DFA-based x86 validator for Native Client


This is a replacement x86-32 validator for Native Client. It uses a
Expand All @@ -11,16 +11,17 @@ instructions. This has a number of benefits:
* it's easier to verify the correctness of the validator


Faster:
## Faster

The DFA-based validator is roughly 8-10 times faster than the original
x86-32 validator.

Time to validate irt.nexe + libc.so.6 + ld.so:
original ncval: 0.446s
dfa_ncval: 0.047s

Smaller:
original ncval: 0.446s
dfa_ncval: 0.047s

## Smaller

The DFA-based validator is <3000 lines of non-generated code:
It has 250 lines of C code, and the rest is in Python.
Expand All @@ -34,7 +35,7 @@ therefore about 22k in size: 88 * 256 = 22528 (this DFA accepts bytes
as inputs so we multiply the number of states by 256). The total text
size of the validator executable is about 26k.

Easier to verify:
## Easier To Verify

Since the DFA is acyclic, it is possible to enumerate all the byte
sequences that it accepts. It is entirely feasible to feed all the
Expand All @@ -58,21 +59,20 @@ two specifications are equivalent, or list the instructions that one
specification accepts and the other rejects.


== How to try it out ==
# How to try it out

$ make
$ ./dfa_ncval .../hello_world.nexe
$ make
$ ./dfa_ncval .../hello_world.nexe


== How it works ==
# How it works

TODO: Explain how we generate the DFA.
# TODO: Explain how we generate the DFA.

TODO: Explain how we handle indirect jumps (superinstructions) and
# TODO: Explain how we handle indirect jumps (superinstructions) and
direct jumps.


== Still to do ==
# Still to do

* Implement instruction replacement checking. NaCl's
nacl_dyncode_modify() syscall allows immediate values and
Expand All @@ -94,12 +94,12 @@ validator allows. Check for any remaining SSE, MMX or 3DNow
instructions.


== Future work ==
# Future work

Implement an x86-64 validator.


== Differences from the original validator ==
# Differences from the original validator

The DFA-based validator does not require that CALL instructions are
aligned so that they end at an instruction bundle boundary.
Expand Down