I want to implement Control-Flow Integrity in Clang/llvm. (I know there is Forward-Edge CFI already implemented)
My problem is, that I have never implemented anything for a compiler (I am new to compiler based approaches) and therefore don't know where to start.
For my implementation I need first to get a list of all calls (internal => no library calls) and than change how functions are ended (for example: pop + jmp instead of ret).
Does anyone know where to start or even if this is possible using the plugin system (LibClang, Clang Plugins, LibTooling)?
Thanks in advance
here is a advanced one CCFI :
https://bitbucket.org/CCFI/
it based on this :
http://iot.stanford.edu/pubs/mashtizadeh-ccfi-ccs15.pdf
you can learn that how to add your code to each jmp,call,jmp,ret and so on...
Related
Is there the possibility to emit ASM when compiling something using Cranelift? By "ASM" I mean the assembler text-representation, in e.g. Intel-Syntax or similar
Now I was planing on implementing this myself using a dissasembler-library like Capstone or Iced, but then I found Context::set_disasm(bool) which apparently does exactly what I need. The problem is I'm unable to find where to extract this assembler-code from. There's no function like get_disasm as far as I looked.
If it's relevant, I'm building both a JIT and an AOT compiler and I want the dissasembler to work when using either.
Can one help me out?
Retrieve the disasm field of CompiledCode. It is in CompiledCodeBase, so it is not documented, unfortunately.
I would like to use the helm-semantic-or-imenu command to navigate components of type annotated Python code, but whatever code analyzer is used to dentify the components doesn't seem to recognize the type annotated python code. Functions with the return type annotation doesn't get recognized at all and functions with annotated arguments show the type instead of the arguments names in the signatures
The main problem I have is that I do not properly understand the components that is involved in making this work (when it does work). Obviously it might help to somehow update the code analyzer, but in which project do I find that? helm? semantic? imenu? or as someone mentioned somewhere else with regards to code analysis python.el? I could really use some help getting started to solve this. If the code analyzer is found in python.el, can I then try to modify and make emacs use a local version preferentially over the installed one?
EDIT:
After making the initial post I finally made a break through in trying to figure out where the components come from. I searched for python*.el in all of the file systemsystem and discovered these:
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python.elc
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python-wy.elc
I found the source for emacs 26.2 and discovered that indeed it seems python-el is responsible for parsing python files for semantic. It also internally uses the python-wy for recognizing a large portion of the language components. But unfortunately that is where I hit a brick wall. I was hoping to be able to monkey patch the function that recognizes a function definition via an re or something, but semantic actually solves the problem the right way. So python-wy seems to be auto-generated from a formal grammar definition file (in emacs git admin/grammars/python.wy) and figuring out how to modify that it is unfortunately much beyond my abilities.
The semantic python backend doesn't appear to parse type annotations correctly (and there hasn't been much recent development on those libraries as far as I can tell). Since helm-semantic-or-imenu favors semantic when it is active, you can disable semantic altogether for python buffers unless you use its other features (personally I only use it for C/C++).
When the semantic mode-specific libraries are loaded they set imenu-create-default-create-index and imenu-default-goto-function, causing imenu to use semantic instead of python.el's imenu function.
To disable semantic support for your python files you can customize the semantic-new-buffer-setup-functions, only adding entries for modes you want semantic support for, eg. in your semantic hook (or alternatively with the customize UI),
(setq semantic-new-buffer-setup-functions
'((c-mode . semantic-default-c-setup)
(c++-mode . semantic-default-c-setup)
(srecode-template-mode . srecode-template-setup-parser)
(texinfo-mode . semantic-default-texi-setup)
;; etc.
;; (makefile-automake-mode . semantic-default-make-setup)
;; (makefile-mode . semantic-default-make-setup)
;; (makefile-gmake-mode . semantic-default-make-setup)
))
I've been tasked with creating conformance tests of user input, the task if fairly tricky and we need very high levels of reliability. The server runs on PHP, the client runs on JS, and I thought Haxe might reduce duplicative work.
However, I'm having trouble with deadcode removal. Since I am just creating helper functions (utilObject.isMeaningOfLife(42)) I don't have a main program that calls each one. I tried adding #:keep: to a utility class, but it was cut out anyway.
I tried to specify that utility class through the -main switch, but I had to add a dummy main() method and this doesn't scale beyond that single class.
You can force the inclusion of all the files defined in a given package and its sub packages to be included in the build using a compiler argument.
haxe --macro include('my.package') ..etc
This is a shortcut to the macro.Compiler.include function.
As you can see the signature of this function allows you to do it recursive and also exclude packages.
static include (pack:String, rec:Bool = true, ?ignore:Array<String>, ?classPaths:Array<String>):Void
I think you don't have to use #:keep in that case for each library class.
I'm not sure if this is what you are looking for, I hope it helps.
Otherwise this could be helpful checks:
Is it bad that the code is cut away if you don't use it?
It could also be the case some code is inlined in the final output?
Compile your code using the compiler flag -dce std as mentioned in comments.
If you use the static analyzer, don't use it.
Add #:keep and reference the class+function somewhere.
Otherwise provide minimal setup if you can reproduce.
When converting a thrift object for nodejs:
thrift -r --gen js:node state_service.thrift
The following error is thrown:
[ERROR: /state_service.thrift:33] (last token was 'not') Cannot use
reserved language keyword: "not"
The lines in the code around 33 are:
typedef bool Not
struct Exp {
1: string left
2: Not not
3: BinaryOp op
4: AnyValue right
}
I am using the most recent Thrift version 0.9.2
Try to change the not to something else, i think the problem is that 'not' may have another meaning in the language that you choose to generate.
2: Not not
The solution is to not use the reserved language keyword, as advised by the Thrift compiler. These keywords are reserved for a reason. Thrift is a cross-language tool, and not is indeed a keyword in some of them.
I don't want to change the processing code only because of a faulty js converter.
I beg to differ. Faulty is something that does not work, altough it should. Thrift clearly tells you that what you are about to try is illegal (as of today) and what the problem is.
To put it another way: With Linux, you can put uppercase and lowercase letters in a file name (actually you can put a whole bunch of strange things in, but I'll make it easy). So creating a FILE and a file in the same folder will work perfectly. If you now take your program and run it on Windows, relying on that behaviour, you will sooner or later run into trouble and may start to complain you "dont want to change your processing code only because of that faulty OS".
Note that complaining will not help you out of the pothole, altough the endorphines emitted during that process will make sure you have a fun time. The solution is of course to wait until Microsoft fixed their faulty OS, because you make the rules. Correct?
Of course not. So if you feel the implementation is wrong - fine! This is Open Source, and nobody claimed perfection. You are free to provide a patch, and we will happily review it. But please make sure you tested it with all 20+ languages currently supported by Thrift.
I've been using CGSPrivate.h for cocoa development under MacOSX for a while. I'm now using it under Lion (10.7.x), and it turns out that the CGSCStringValue() function described in that file no longer exists under that OS version.
I want to make use of the functionality of CGSCStringValue() -- i.e., converting a CGSValue to its associated char* when appropriate -- and I'm wondering if anyone knows how that function is actually implemented.
I've tried various forms of casting of the CGSValue, but to no avail. So could anyone point me to some documentation or actual cocoa code that runs in 10.7 which will take a CGSValue that's associated with a string as input and return its char* equivalent?
Thanks in advance.
It's implemented by checking the type (to make sure it's really a CFString) and calling CFStringGetCString(). You can do that yourself, there is no real need for CGSCStringValue.