I read what David Howells wrote on:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/dhowells/linux-modsign/+/modsign-rusty/Documentation/module-signing.txt
I heard that the CONFIG_MODULE_SIG has to be turned on, but it was not stated particularly how. I am also not sure how to use a kernel make command.
I am not able to piece together enough information to generate a mini signed LKM.
Would anyone here have done it before, and able to guide me on a minimallist example on signing a helloworld LKM?
For enabling CONFIG_MODULE_SIG, simply in configure file (.config), have this line:
CONFIG_MODULE_SIG=y
I've not tried, but I think even you can have CONFIG_MODULE_SIG=y in make command like:
make CONFIG_MODULE_SIG=y
For how to build a LKM for android, there is several tutorials in internet, for example take a look at this:
How do you create a loadable kernel module for Android?
CONFIG_MODULE_SIG=y only enables feature, to enforce it you also have to put CONFIG_MODULE_SIG_FORCE=y in the config file.
basically I found that there are three flags associated with this feature:
CONFIG_MODULE_SIG=y #to enable the feature
CONFIG_MODULE_SIG_ALL=y #to sign all the loadable modules during build process
CONFIG_MODULE_SIG_FORCE=y #to enforce the feature so that no unsigned module can be loaded.
Related
Looking around on the net I have seen a lot of code like this:
include(FindPkgConfig)
pkg_search_module(SDL2 REQUIRED sdl2)
target_include_directories(app SYSTEM PUBLIC ${SDL2_INCLUDE_DIRS})
target_link_libraries(app ${SDL2_LIBRARIES})
However that seems to be the wrong way about doing it, as it only uses the include directories and libraries, but ignored defines, library paths and other flags that might be returned by pkg-config.
What would be the correct way to do this and ensure that all compile and link flags returned by pkg-config are used by the compiled app? And is there a single command to accomplish this, i.e. something like target_use(app SDL2)?
ref:
include()
FindPkgConfig
First of, the call:
include(FindPkgConfig)
should be replaced with:
find_package(PkgConfig)
The find_package() call is more flexible and allows options such as REQUIRED, that do things automatically that one would have to do manually with include().
Secondly, manually calling pkg-config should be avoid when possible. CMake comes with a rich set of package definitions, found in Linux under /usr/share/cmake-3.0/Modules/Find*cmake. These provide more options and choice for the user than a raw call to pkg_search_module().
As for the mentioned hypothetical target_use() command, CMake already has that built-in in a way with PUBLIC|PRIVATE|INTERFACE. A call like target_include_directories(mytarget PUBLIC ...) will cause the include directories to be automatically used in every target that uses mytarget, e.g. target_link_libraries(myapp mytarget). However this mechanism seems to be only for libraries created within the CMakeLists.txt file and does not work for libraries acquired with pkg_search_module(). The call add_library(bar SHARED IMPORTED) might be used for that, but I haven't yet looked into that.
As for the main question, this here works in most cases:
find_package(PkgConfig REQUIRED)
pkg_check_modules(SDL2 REQUIRED sdl2)
...
target_link_libraries(testapp ${SDL2_LIBRARIES})
target_include_directories(testapp PUBLIC ${SDL2_INCLUDE_DIRS})
target_compile_options(testapp PUBLIC ${SDL2_CFLAGS_OTHER})
The SDL2_CFLAGS_OTHER contains defines and other flags necessary for a successful compile. The flags SDL2_LIBRARY_DIRS and SDL2_LDFLAGS_OTHER are however still ignored, no idea how often that would become a problem.
More documentation here http://www.cmake.org/cmake/help/latest/module/FindPkgConfig.html
If you're using cmake and pkg-config in a pretty normal way, this solution works.
If, however, you have a library that exists in some development directory (such as /home/me/hack/lib), then using other methods seen here fail to configure the linker paths. Libraries that are not found under the typical install locations would result in linker errors, like /usr/bin/ld: cannot find -lmy-hacking-library-1.0. This solution fixes the linker error for that case.
Another issue could be that the pkg-config files are not installed in the normal place, and the pkg-config paths for the project need to be added using the PKG_CONFIG_PATH environment variable while cmake is running (see other Stack Overflow questions regarding this). This solution also works well when you use the correct pkg-config path.
Using IMPORTED_TARGET is key to solving the issues above. This solution is an improvement on this earlier answer and boils down to this final version of a working CMakeLists.txt:
cmake_minimum_required(VERSION 3.14)
project(ya-project C)
# the `pkg_check_modules` function is created with this call
find_package(PkgConfig REQUIRED)
# these calls create special `PkgConfig::<MODULE>` variables
pkg_check_modules(MY_PKG REQUIRED IMPORTED_TARGET any-package)
pkg_check_modules(YOUR_PKG REQUIRED IMPORTED_TARGET ya-package)
add_executable(program-name file.c ya.c)
target_link_libraries(program-name PUBLIC
PkgConfig::MY_PKG
PkgConfig::YOUR_PKG)
Note that target_link_libraries does more than change the linker commands. It also propagates other PUBLIC properties of specified targets like compiler flags, compiler defines, include paths, etc., so, use the PUBLIC keyword with caution.
It's rare that one would only need to link with SDL2. The currently popular answer uses pkg_search_module() which checks for given modules and uses the first working one.
It is more likely that you want to link with SDL2 and SDL2_Mixer and SDL2_TTF, etc... pkg_check_modules() checks for all the given modules.
# sdl2 linking variables
find_package(PkgConfig REQUIRED)
pkg_check_modules(SDL2 REQUIRED sdl2 SDL2_ttf SDL2_mixer SDL2_image)
# your app
file(GLOB SRC "my_app/*.c")
add_executable(my_app ${SRC})
target_link_libraries(my_app ${SDL2_LIBRARIES})
target_include_directories(my_app PUBLIC ${SDL2_INCLUDE_DIRS})
target_compile_options(my_app PUBLIC ${SDL2_CFLAGS_OTHER})
Disclaimer: I would have simply commented on Grumbel's self answer if I had enough street creds with stackoverflow.
Most of the available answers fail to configure the headers for the pkg-config library. After meditating on the Documentation for FindPkgConfig I came up with a solution that provides those also:
include(FindPkgConfig)
if(NOT PKG_CONFIG_FOUND)
message(FATAL_ERROR "pkg-config not found!" )
endif()
pkg_check_modules(<some-lib> REQUIRED IMPORTED_TARGET <some-lib>)
target_link_libraries(<my-target> PkgConfig::<some-lib>)
(Substitute your target in place of <my-target> and whatever library in place of <some-lib>, accordingly.)
The IMPORTED_TARGET option seems to be key and makes everything then available under the PkgConfig:: namespace. This was all that was required and also all that should be required.
There is no such command as target_use. But I know several projects that have written such a command for their internal use. But every project want to pass additional flags or defines, thus it does not make sense to have it in general CMake. Another reason not to have it are C++ templated libraries like Eigen, there is no library but you only have a bunch of include files.
The described way is often correct. It might differ for some libraries, then you'll have to add _LDFLAGS or _CFLAGS. One more reason for not having target_use. If it does not work for you, ask a new question specific about SDL2 or whatever library you want use.
If you are looking to add definitions from the library as well, the add_definitions instruction is there for that. Documentation can be found here, along with more ways to add compiler flags.
The following code snippet uses this instruction to add GTKGL to the project:
pkg_check_modules(GTKGL REQUIRED gtkglext-1.0)
include_directories(${GTKGL_INCLUDE_DIRS})
link_directories(${GTKGL_LIBRARY_DIRS})
add_definitions(${GTKGL_CFLAGS_OTHER})
set(LIBS ${LIBS} ${GTKGL_LIBRARIES})
target_link_libraries([insert name of program] ${LIBS})
I tried to use CryptoObfuscator to obfuscate my Android app, but it doesn't generate all the pdb files.
My Xamarin.Forms solution has 11 projects, 7 of them should be obfuscated. I disabled most CryptoObfuscator features just to test it. My .obproj file contains these settings for all dlls:
<Assembly Load="true" Path=".\bin\Release\RoyalMobileApps.XF.dll" XapEntryName="" KeyFilePath="" KeyFileContainsPublicKeyOnly="False" CertFilePath="" TimeStampURL="" Rfc3161TimestampURL="False" SHA256SigningAlgorithm="False" Embed="True" AddExceptionReporting="False" PfxPassword="" PfxPasswordCert="" IsWinRTAssembly="False">
<ObfuscationSettings EncryptStrings="True" EncryptMethods="False" EncryptConstants="False" SuppressReflector="False" ReduceMetaData="False" ObfuscationDisposition="1" FlowObfuscation="2" CodeMasking="0" SuppressILDASM="True" SuppressReflection="False" CombineResources="True" EncryptResources="True" CompressResources="True" MarkAsSealed="False" EnableTamperDetection="False" EnableAntiDebugging="False" SymbolRenaming="True" HideExternalCalls="False" HideInternalCalls="False" GeneratePdbFile="True" ObfuscatePdbFileNames="True" IncludeLocalVariablesInPdbFile="False" Encrypt="False" Compress="False" MSBuild="False" ObfuscatedNamespace="A" RetainNamespace="False" ModuleInitializationMethod="" LicensingMerge="False" RemoveConstants="False" ProcessSatelliteAssemblies="True">
<Watermarks Watermark0="" Watermark1="" Watermark2="" Watermark3="" Watermark4="" Watermark5="" Watermark6="" Watermark7="" Watermark8="" Watermark9="" />
</ObfuscationSettings>
</Assembly>
As you can see I set GeneratePdbFile="True" for all 7 projects. I integrated co.exe in my build process and it claims to have run successfully. It generates 7 dlls but only 6 pdbs. The pdb file for my main PCL project which I pasted above is missing and therefore Xamarins linker fails and I cannot build an apk.
How can I get CryptoObfuscator to create all pdbs? Or can I generate the apk without them?
Unfortunately the CryptoObfuscator support did not respond to my emails and I couldn't find anybody else with a similar problem.
I got it working by disabling the Pdbs at all. I switched to release mode and opened up the properties of each project which should be obfuscated. In Build / Advanced you can set the Debug Info to None.
In Crypto Obfuscator I disabled Output Settings / Generate New Pdb File For Assembly.
Then nothing created Pdb files. I got warnings when building the solution, but they can be ignored.
This answer should actually be credited to #JonDouglas, but he wrote only a comment.
Unfortunately I had to disable Rename Symbols too. But this was the main reason why I wanted to use Crypto Obfuscator. Because I couldn't get the Name Protection in ConfuserEx running. So as it doesn't work in either tool and Crypto Obfuscators support still didn't answer my email I'm back to ConfuserEx. This is free and it cannot be deobfuscated with de4dot.
With Dynamic Debugging enabled in the Linux Kernel, I am able to control which prints show up by writing to /sys/kernel/debug/dynamic_debug/control. However, It seems that a reboot resets this file to its default settings (all prints disabled).
Is there a way to make the settings persist across a reset? I have a print which is emitted early in the boot process, and I am not able to get it to print, because the reboot disables this print in /sys/kernel/debug/dynamic_debug/control.
You should be able to add dyndbg='your query here' to the kernel command line using the bootloader configuration or manual options entry feature. This will vary with the bootloader although grub is the most common one
If you are using grub as a bootloader you would have to add it to the kernel command line in /boot/grub/grub.conf for the particular kernel you are launching at bootup.
A blog article about this can be found here. In particular it gives this example:
dyndbg='module xhci_hcd +p'
The article also discusses modifying grub as well.
This kernel howto about dynamic debugging has useful information about dyndbg. This section applies
To activate debug messages for core code and built-in modules during
the boot process, even before userspace and debugfs exists, use
dyndbg="QUERY", module.dyndbg="QUERY", or ddebug_query="QUERY"
(ddebug_query is obsoleted by dyndbg, and deprecated). QUERY follows
the syntax described above, but must not exceed 1023 characters. Your
bootloader may impose lower limits.
These dyndbg params are processed just after the ddebug tables are
processed, as part of the arch_initcall. Thus you can enable debug
messages in all code run after this arch_initcall via this boot
parameter.
On an x86 system for example ACPI enablement is a subsys_initcall and
dyndbg="file ec.c +p"
will show early Embedded Controller transactions during ACPI setup if
your machine (typically a laptop) has an Embedded Controller.
PCI (or other devices) initialization also is a hot candidate for using
this boot parameter for debugging purposes.
If foo module is not built-in, foo.dyndbg will still be processed at
boot time, without effect, but will be reprocessed when module is
loaded later. dyndbg_query= and bare dyndbg= are only processed at
boot.
You can do it as a part of post boot script. Say after Android boots(since i see Android tag added here), it runs certain sh scripts as a part of init procedure. Modify the sh files with the dynamic debug commands added and push it in and reboot .
Refer here for post boot script files info.
https://android.stackexchange.com/questions/6558/how-can-i-run-a-script-on-boot
You can have dynamic_debug for some kernel module foo activated automatically during boot using the /etc/modprobe.d/ directory.
### BEGIN prerequisite
# in case module "foo" is not yet automatically loaded during boot,
# then make it load during boot:
# create a file /etc/modules-load.d/foo.conf with contents "foo"
echo "foo" | sudo tee /etc/modules-load.d/foo.conf
### END prerequisite
# create a configuration file to activate dynamic debug for module "foo"
# at its "module initialization time"
echo "options foo dyndbg=+p" | sudo tee /etc/modprobe.d/foo.conf
Reference: Debug Messages at Module Initialization Time from kernel.org documentation.
i try to build Froyo for a given dev board, but i don't know how to configure the source tree, especially where should put the board specific code and the board configuration mkf ile, either in vendor or device ?
I first put my board specific code and config file in the vendor folder as:
vendor\cpyname\the_product_1\, with BoardConfig.mk that describe my board configuration.
I then have vendor\cpyname\product\ with the_product_1.mk to start the source tree build.
can't build with tapas, when giving product name (the_product_1), i get an error
build/core/product_configuration.mk
the_product_1 not found.
I also try with the device folder, like:
device\the_product_1\ with BoardConfig.mk,
and device\the_product_1\product\ with the_product_1.mk
tapas give the same result.
Note that first configuration can build and generate image with make PRODUCT-the_product_1-eng
I also personally find the build process quite obscure and missing documentation. Please help :)
Lionel
Froyo and the after use devices instead of vendor directory ,you will find sample there.
i'm trying to get android running on a gumstix overo system.
since i'm not planning to use the final "product" as a phone, i asked my self if it is possible to exclude applications like the phone/dialer-app from the kernel build-process (any config parameter probably?)
Just remove (or comment) these lines:
<project path="packages/apps/Phone" name="platform/packages/apps/Phone" />
<project path="packages/apps/VoiceDialer" name="platform/packages/apps/VoiceDialer" />
(and others if needed) from the platform manifest (default.xml) :
https://android.googlesource.com/platform/manifest/+/master/default.xml
Removing the app declarations in the repo manifest did not work for me, as there are other libraries that reference them that then fail to compile. The build system approach to this problem is to create/modify your product definition makefile to not include the specific apps.
So, for the overo you probably already have a products/overo.mk product file. You can manually set the PRODUCT_PACKAGES variable to which applications you want to ship. You will also want to take a look at the PRODUCT_POLICY variable, as it defines sets of applications for your product type.
It can take some fiddling to get everything to build correctly, due to interdependencies between applications, but the Android build output does a pretty good job of explaining the problems when they arise.