I have noticed there are some profiling source code under arch/arm/kernel:
perf_event.c
perf_event_cpu.c
perf_event_v6.c
perf_event_v7.c
perf_event_xscale.c
I can't understand the hierarchy of those files and how can I use them? can I assume they are always exists and use them in a kernel module? my kernel module runs on Cortex-A7 or Cortex-A15 cores.
There seems to be a lot of very useful things under /arch/arm/kernel/ directory but no documentation about the capabilities ? how comes ?
Perf_event does provide an API that can be used programmatically, but the documentation is sparse at best. Vince Weaver made the best resource for using the perf_event API here: http://web.eece.maine.edu/~vweaver/projects/perf_events/
He also provides some example code for recording counters.
However your best bet is to use an API that wraps perf_event and makes it more accessible, like PAPI (http://icl.cs.utk.edu/papi/)
EDIT: Since you want to do this from a kernel module, PAPI will not be available. The perf_event API still is, however.
The functionality in the perf_* files is used by/provided for tools like oprofile and perf tools.
And no, they are not ALWAYS available, as there is a config option (CONFIG_PERF_EVENTS) to enable/disable performance measurements.
The functionality is not really meant to be used from another driver. I'm pretty sure that will "upset" any user of oprofile or perf.
Related
I'm working on a project, implementing everything in C language. As a part of the project, we need to be able to control and configure firewalld, firewall of the current system.
firewalld is implemented in Python and an interface is available. However, we don't want to make Python calls from C or vice versa.
There are command line tools to configure firewalld (e.g. firewall-cmd) but we don't want to make such calls from C either.
I recently started working on firewalld, I don't know much about its internals. I've read that it uses D-Bus, I also don't know much about D-Bus.
There is a C library developed by Thomas Woerner: libfirewall.
However, it's been more than a year and a half since the last commit so it's not maintained. Other than libfirewall, I don't know any firewalld interface in C.
I gave libfirewall a shot. It got me some problems when both compiling and running the examples and I still have problems to resolve. Is it worth to continue with libfirewall? Should I use it?
Is there any other interface that I'm not aware of?
Possibly naive question due to lack of understanding of D-Bus: I thought, maybe, with a D-Bus interface, I can issue commands to firewalld. Can it be done? (i.e. Does D-Bus work like that?) Can we write a program that mimics, say firewall-cmd, and interacts with D-Bus in the same way and at the end allows us to control firewalld?
If this is possible, how to do it and what to use? libdbus and GDBus have relatively good documentation although libdbus requires good deal of effort. They even said "If you use this low-level API directly, you're signing up for some pain." in the documentation. In any case I'll be in need of examples or any kind of text demonstrating their usage.
How should I approach this problem?
Yes, you can issue commands to firewalld via D-Bus. I haven't checked but expect that firewall-cmd is itself implemented as a D-Bus client.
The D-Bus API is extensively documented: https://firewalld.org/documentation/man-pages/firewalld.dbus.html. The documentation should give you a rough idea what can be accomplished through the API. You could try the D-Bus debugger d-feet to interact with firewalld without any code.
GDBus is definitely the easiest way use D-Bus from C but it's still not trivial and firewalld is a fairly complex API: Using it may require some expertise (completely depending on what you need to do).
I'm looking for an embedded RTOS that supports the dynamic upgrade/replacement of a thread. This should be used to allow the user to perform a network based upgrade of the running application. This should basically work like a bootloader, but without replacing the entire application.
My target architecture is an ARM Cortex-M4 processor, so I am looking for a deeply embedded RTOS such as FreeRTOS.
I'am not sure that I get your question right, but for me it seems that dynamic modules support is what you need. Using this feature you could implement partial-firmware OTA update. If so, you could look at NuttX, RIOT OS or Contiki. It looks like that they all support the requested feature. If you are asking about live update, than you probably should consider Minix 3, but I'am not sure that it fits your target device.
I am embarking on a programming project that will need to confirm device identity of removable media (e.g. usb thumb drives) before it will go on to do a bunch of other cool stuff.
Some friends of mine pointed me towards using the Serial Number, and preliminary testing using the udevadm command indicates that this should work. I did some additional checking and it appears that if I can get the software working with libudev then it should (minimally) compile on ubuntu, slackware and gentoo, which would be a really nice benefit.
So I used bing to find a tutorial and got the Signal 11 site (http://www.signal11.us/oss/udev/) it's a very well-written tutorial. It actually seems to have everything I need. I download the code. Fix a couple of platform-specific bugs and then compile. BOOM! Gcc compiles without errors. So far so good.
But when I try to run it, it kicks up a couple of bugs, and I realize that I need to read some more tutorials so that I can understand libudev well enough to fix the bugs, and to turn out working software. Problem is that there really ISN'T any other tutorials (that I can find) and the kernel.org site that is the (only known?) site of the library documentation is down after a recent server compromise.
I considered just issuing udevadm directives to system() and then parsing results, but that's a really hackish way to put software together, and I am planning on releasing this to the community when I'm finished writing.
So how best for me to learn libudev??
libudev is quite simple library. After reading library you've mentioned and using API documentation (site should be soon up) I was able to get what I wanted. udevadm is great help, after issuing # udevadm info --query=all --name=/path/to/dev you'll get all information that udev has about this device and what's more important, these are parameters used in property functions (e.g. udev_device_get_property_value(device, "ID_VENDOR")). So best way to learn libudev is to start using it with help of signal11 tutorial, API documentation and udevadm informations.
EDIT: libudev is currently part of systemd - documentation is available as manual pages - https://www.freedesktop.org/software/systemd/man/libudev.html#
For those looking in 2023...
As Maciej pointed out, libudev is now a part of systemd.
According to:
https://www.freedesktop.org/software/systemd/man/libudev.html#
...this library is supported, but should not be used in new projects.
Please see sd-device(3) for an equivalent replacement with a more
modern API.
Documentation for sd-device:
https://www.freedesktop.org/software/systemd/man/sd-device.html#
Introduction:
I am currently developing a document classifier software in C/C++ and I will be using Naive-Bayesian model for classification. But I wanted the users to use any algorithm that they want(or I want in the future), hence I went to separate the algorithm part in the architecture as a plugin that will be attached to the main app # app start-up. Hence any user can write his own algorithm as a plugin and use it with my app.
Problem Statement:
The way I am intending to develop this is to have each of the algorithms that user wants to use to be made into a DLL file and put into a specific directory. And at the start, my app will search for all the DLLs in that directory and load them.
My Questions:
(1) What if a malicious code is made as a DLL (and that will have same functions mandated by plugin framework) and put into my plugins directory? In that case, my app will think that its a plugin and picks it and calls its functions, so the malicious code can easily bring down my entire app down (In the worst case could make my app as a malicious code launcher!!!).
(2) Is using DLLs the only way available to implement plugin design pattern? (Not only for the fear of malicious plugin, but its a generic question out of curiosity :) )
(3) I think a lot of softwares are written with plugin model for extendability, if so, how do they defend against such attacks?
(4) In general what do you think about my decision to use plugin model for extendability (do you think I should look at any other alternatives?)
Thank you
-MicroKernel :)
Do not worry about malicious plugins. If somebody managed to sneak a malicious DLL into that folder, they probably also have the power to execute stuff directly.
As an alternative to DLLs, you could hook up a scripting language like Python or Lua, and allow scripted plugins. But maybe in this case you need the speed of compiled code?
For embedding Python, see here. The process is not very difficult. You can link statically to the interpreter, so users won't need to install Python on their system. However, any non-builtin modules will need to be shipped with your application.
However, if the language does not matter much to you, embedding Lua is probably easier because it was specifically designed for that task. See this section of its manual.
See 1. They don't.
Using a plugin model sounds like a fine solution, provided that a lack of extensibility really is a problem at this point. It might be easier to hard-code your current model, and add the plugin interface later, if it turns out that there is actually a demand for it. It is easy to add, but hard to remove once people started using it.
Malicious code is not the only problem with DLLs. Even a well-meaning DLL might contain a bug that could crash your whole application or gradually leak memory.
Loading a module in a high-level language somewhat reduces the risk. If you want to learn about embedding Python for example, the documentation is here.
Another approach would be to launch the plugin in a separate process. It does require a bit more effort on your part to implement, but it's much safer. The seperate process approach is used by Google's Chrome web browser, and they have a document describing the architecture.
The basic idea is to provide a library for plugin writers that includes all the logic for communicating with the main app. That way, the plugin author has an API that they use, just as if they were writing a DLL. Wikipedia has a good list of ways for inter-process communication (IPC).
1) If there is a malicious dll in your plugin folder, you are probably already compromised.
2) No, you can load assembly code dynamically from a file, but this would just be reinventing the wheel, just use a DLL.
3) Firefox extensions don't, not even with its javascript plugins. Everything else I know uses native code from dynamic libraries, and is therefore impossible to guarantee safety. Then again Chrome has NaCL which does extensive analysis on the binary code and rejects it if it can't be 100% sure it doesn't violate bounds and what not, although I'm sure they will have more and more vulnerabilities as time passes.
4) Plugins are fine, just restrict them to trusted people. Alternatively, you could use a safe language like LUA, Python, Java, etc, and load a file into that language but restrict it only to a subset of API that wont harm your program or environment.
(1) Can you use OS security facilities to prevent unauthorized access to the folder where the DLL's are searched or loaded from? That should be your first approach.
Otherwise: run a threat analysis - what's the risk, what are known attack vectors, etc.
(2) Not necessarily. It is the most straigtforward if you want compiled plugins - which is mostly a question of performance, access to OS funcitons, etc. As mentioned already, consider scripting languages.
(3) Usually by writing "to prevent malicous code execution, restrict access to the plugin folder".
(4) There's quite some additional cost - even when using a plugin framework you are not yet familiar with. it increases cost of:
the core application (plugin functionality)
the plugins (much higher isolation)
installation
debugging + diagnostics (bugs that occur only with a certain combinaiton of plugins)
administration (users must know of, and manage plugins)
That pays only if
installing/updating the main software is much more complex than updating the plugins
individual components need to be updated individually (e.g. a user may combine different versions of plugins)
other people develop plugins for your main application
(There are other benefits of moving code into DLL's, but they don't pertain to plugins as such)
What if a malicious code is made as a DLL
Generally, if you do not trust dll, you can't load it one way or another.
This would be correct for almost any other language even if it is interpreted.
Java and some languages do very hard job to limit what user can do and this works only because they run in virtual machine.
So no. Dll loaded plug-ins can come from trusted source only.
Is using DLLs the only way available to implement plugin design pattern?
You may also embed some interpreter in your code, for example GIMP allows writing plugins
in python.
But be aware of fact that this would be much slower because if nature of any interpreted language.
We have a product very similar in that it uses modules to extend functionality.
We do two things:
We use BPL files which are DLLs under the covers. This is a specific technology from Borland/Codegear/Embarcadero within C++ Builder. We take advantage of some RTTI type features to publish a simple API similar to the main (argv[]) so any number of paramters can be pushed onto the stack and popped off by the DLL.
We also embed PERL into our application for things that are more business logic in nature.
Our software is an accounting/ERP suite.
Have a look at existing plugin architectures and see if there is anything that you can reuse. http://git.dronelabs.com/ethos/about/ is one link I came across while googling glib + plugin. glib itself might may it easier to develop a plugin architecture. Gstreamer uses glib and has a very nice plugin architecture that may give you some ideas.
Is there any kind of way to monitor the low level keyboard hooks in a Windows enviroment. Say if I am making a program trying to find keyloggers.
> There is no official API to query the installed keyboard hooks.
Yes, there are. (you're too young to know this...)
You must read the PEB.
See on Win32 api Group
where all the Windows source code (each api, undocumented or not ) had been disassembled
Discussion about reading hooks
A problem you might run into is that there are malware that do not exist as "processes" that you can enumerate easily.
There is no official API to query the installed keyboard hooks. Since MicroSoft doesn't share the source for Windows, you must install a keyboard hook and single step the assembler code to figure out where Windows is saving this information. Then, you can write a device driver that watches this memory area for changes.
Another problem is that at least one keylogger works by injecting itself into the keyboard's processor memory and running from there. Almost impossible to detect and if you can, you'll have to know a lot about how keyboards work.
Summary: If you have success with this task in any way, you will probably not cover all possible keyloggers. Bad news, I'm afraid.