FOSDEM 2018 talks are now available

FOSDEM is one of the major open source conferences all around the globe. It’s organized by volunteers since 2000 and takes place in Brussels (Belgium) once a year. 2018th edition, on February 3rd and 4th, featured 651 speakers, 690 events and 57 tracks -according to the conference website-. It’s really amazing the diversity of projects and the wide range of topics discussed: from Linux to language runtimes, from community to deeply technical talks. Recordings are now available at https://fosdem.org/2018/schedule/

I strongly suggest to watch Exploiting modern microarchitectures Meltdown, Spectre, and other hardware attacks by Jon Masters.

Some noise to C1 JIT compiler for x86_64 (OpenJDK JVM – Hotspot)

Quarkslab folks proposed an interesting hacking challenge:  modify a compiler to generate code that has innocuous instructions in-between. That is: put some noise but keep the program logic and state validity. It works like a very simple obfuscator.

This was the perfect excuse for me to learn a bit more about C1 (OpenJDK JVM 1st tier JIT compiler) and have some fun.

You can add your “noise” instructions at different stages of the C1 compilation process. However, the earlier you do it, the more risk of having them removed by a later optimization pass. On the other hand, you may have the advantage of a “multi-arch” noise.

The very basic flow for C1 is the following: Java bytecodes -> IR (Intermediate Representation) -> LIR (Low-level Intermediate Representation) -> assembly (arch specific). A few key functions involved in these transformations: GraphBuilder::iterate_bytecodes_for_block (for IR generation), LIRGenerator::block_do (for LIR generation) and LIR_Assembler::emit_lir_list (for assembly generation).

Continue reading “Some noise to C1 JIT compiler for x86_64 (OpenJDK JVM – Hotspot)”

Open Source Development Group initiative

It’s been a long time since I first come with this idea and today I’d like to finally introduce the”Open Source Development Group” initiative.

Our goal is to invite every developer to get on board and start collaborating to an open source project. The idea is to build a network to share knowledge, experience, work in pairs, publish our work and mentor new developers.

We don’t have fixed structures, schedules, sponsors or any formality: everything is on-demand and flexible enough to accommodate different needs.

Every body is welcomed. No matter your previous experience, background or open source exposure. Read further information on our page and join us! http://martin.uy/dev

Thanks to Netlabs!

This week I’ve been hosted by Netlabs and felt very welcomed in their office! I want to thank Pablo, Diego and all their staff for being so nice with me. Who is Netlabs? Netlabs provides software engineering and site reliability services along the region, with focus on open source and Linux technologies. Based on their highly qualified staff and a strong record of success, they became the largest Red Hat partner in Uruguay.

If you are interested in networking, operating systems, back-ends, Linux and open source, have a look at their current openings!

Simple Patching Tool v1.0 (OpenJDK)

When writing test cases for Java, I sometimes need to mock method calls or set specific variable values so interesting paths can be executed. I am not a big fan of these hacks, but in certain cases there is no-option or triggering the execution path from a user API comes at a high cost.

Just as an example, a few weeks ago I had to modify java.net.DatagramSocket default constructor to use a fixed port (instead of using 0 and getting a random port from the OS).

Instrumenting Java bytecode with ASM is a good option for this purpose. However, some patches require more logic and “coding” in ASM can turn cumbersome. It would be easier if we can insert a static method call in ASM and then implement the hook method in Java. That’s why I developed this very simple tool.

Continue reading “Simple Patching Tool v1.0 (OpenJDK)”

How to debug compiled (JIT generated) code in Hotspot (OpenJDK JVM – Linux x86_64)?

First of all, I suggest to run the JVM with a few parameters to get information about compiled (JIT generated) methods:

Note: in order to disassembly JIT code using +PrintAssembly option, a Hotspot plugin called hsdis is required.  Plugin source code can be found in hotspot/src/share/tools/hsdis directory. Open a command line there and run:

Replace “<path-to-binutils>” with your path to binutils in the previous command. Once built, copy build/linux-amd64/hsdis-amd64.so library to jre/lib/amd64 and jre/lib/amd64/server directories.

We now place a breakpoint in the interpreter transition stubs to/from compiled code, and recompile the JVM (see Debugging Hotspot (OpenJDK JVM) x86_64 interpreter in Linux for further information). These stubs are generated by SharedRuntime::generate_i2c2i_adapters method (located in sharedRuntime_x86_64.cpp file).

Continue reading “How to debug compiled (JIT generated) code in Hotspot (OpenJDK JVM – Linux x86_64)?”

Debugging Hotspot (OpenJDK JVM) x86_64 interpreter in Linux

Debugging CPython VM interpreter is fairly easy because it is just C code: you attach a debugger to the Python process, set a breakpoint in the opcodes interpreter main loop and that is all.

Doing the same on Hotspot (OpenJDK JVM) is not straight forward for those architectures in which the interpreter is made of assembly stubs (generated in boot time). Oversimplifying this process, several C++ functions are called -which look like pseudo-assembly- generating a stream of native opcodes. This stream is put on executable memory and is the responsible of processing Java bytecodes. There are entry points for calls from the interpreter assembly to JVM C++ functions, intended for more complex and slow path operations.

Continue reading “Debugging Hotspot (OpenJDK JVM) x86_64 interpreter in Linux”

Support net neutrality

Net Neutrality

The recently approved FCC rules in the US don’t longer guarantee net neutrality: Internet Service Providers are now allowed to prioritize or block contents on their economic or ideological interests. This obviously favors big media companies and seriously damages freedom and equality, which were Internet core values.

Net neutrality matters: learn about it and join the effort now!

Statically linking a binary against glibc (x86)

Developing a proof-of-concept for a Return Oriented Programming example I came across the necessity of statically linking a binary against glibc (Linux, x86). As you can imagine, I needed tons of gadgets at fixed virtual addresses and that’s why dynamically linking was not suitable in this case.

Even though this may seem to be easy at first sight, it has some drawbacks. What it finally worked for me -in Fedora 25- was the following:

Continue reading “Statically linking a binary against glibc (x86)”

Debug Watchdog for Linux (v1.0)

Debug Watchdog for Linux (v1.0). Fedora 25.

Linux Debug Watchdog for Linux (v1.0) has been released as an open source project (under GPL). The goal of this tool is to globally monitor a Linux system and stop chosen executable binaries immediately after launched. This enables to attach a debugger (i.e.: gdb) and debug the process from the first instruction, as if gdb –wait-process existed. It may also be useful to analyze the executable binary parameters, in particular for short-lived processes.

Every executable binary is caught: no matter how it was launched (command line, graphical user interface, ssh daemon, etc.), with which user or privileges nor how long it is expected to live. This effectiveness is achieved  by patching the syscalls table in kernel space and hooking sys_execve at runtime. Values are restored when Debug Watchdog is turned off.

User-space approaches like periodically polling the list of processes and attaching a debugger are not effective enough for short-lived processes nor for attaching the debugger from the very beginning of the execution.

Continue reading “Debug Watchdog for Linux (v1.0)”