antek's tech blog - linux

Intercepting HTTPS traffic from a VM for debugging

2026-03-31T00:00:00+00:00

Hi,

In the good old days, when the Earth was young and the Internet was a wild west of plain, non-commercial unencrypted text, intercepting traffic during development was trivially easy. You'd fire up Ethereal (now Wireshark), pick the right interface, and watch every byte of every HTTP request fly by. Life was simple.

Then Let's Encrypt happened, HTTPS became mandatory, and now everything you want to inspect is wrapped in TLS. Not a bad thing for production, but not very convenient when you're trying to figure out why your HTTP client is sending malformed headers or why a third-party API is returning a 400 with no explanation. Especially in current times where application errors are signalled only by "please contact your administrator", or "something went wrong, please try again later" messages.

Anyway, there are a few ways to solve this inspection problem. SSLKEYLOGFILE</code> works if the library you're using supports it (libcurl</code> does, most things don't). Burp Suite is popular in the security world. Http Toolkit sometimes works. But the cleanest approach I've found for inspecting traffic from a VM is to run a transparent proxy on the host using mitmproxy</a>, and silently redirect all the VM's traffic through it with iptables</code>. No changes required inside the VM -- other than trusting the proxy's CA certificate.

Here's the full setup.

The environment</h2>
The VM is a Windows 10 guest running under libvirt</code>/QEMU on a Linux host.
The guest is connected to the default libvirt bridge virbr0</code>, which is a NAT
network -- meaning all traffic from the VM goes through the host. It's the
default and easiest setup possible, and that's the part we'll exploit.</p>
The host needs a few things to be in order. First, IP forwarding must be
enabled, because the host acts as a router for the VM:</p>
$</span> sysctl net.ipv4.ip_forward</span></span>
net.ipv4.ip_forward</span> =</span> 1</span>       # Must be 1</span></span></code></pre>
Good. Second, we need iptables</code> to be able to see traffic that flows through
the bridge. By default, bridged packets bypass the netfilter rules entirely.
The br_netfilter</code> kernel module fixes this:</p>
# modprobe br_netfilter</span></span>
# cat /proc/sys/net/bridge/bridge-nf-call-iptables</span></span>
1</span>                             # Must be 1</span></span></code></pre>
With that in place, iptables</code> rules will actually fire on packets arriving on
virbr0</code>.</p>
Redirecting traffic with iptables</h2>
Now we tell the kernel to redirect all TCP traffic from the VM on ports 80 and
443 to port 8000 on the host, where mitmproxy will be listening:</p>
# iptables -t nat -A PREROUTING -i virbr0 -p tcp --dport 443 -j REDIRECT --to-port 8000</span></span>
# iptables -t nat -A PREROUTING -i virbr0 -p tcp --dport 80  -j REDIRECT --to-port 8000</span></span></code></pre>
Verify with:</p>
# iptables -t nat -L -v -n</span></span>
Chain</span> PREROUTING</span> (policy</span> ACCEPT ...</span>)</span></span>
 pkts</span> bytes target     prot opt in     out     source               destination</span></span>
    0</span>     0</span> REDIRECT   tcp</span>  --</span>  virbr0</span> *</span>       0.0.0.0/0            0.0.0.0/0    tcp dpt:443 redir ports</span> 8000</span></span>
    0</span>     0</span> REDIRECT   tcp</span>  --</span>  virbr0</span> *</span>       0.0.0.0/0            0.0.0.0/0    tcp dpt:80  redir ports</span> 8000</span></span></code></pre>
The PREROUTING</code> chain intercepts packets as they arrive -- before any routing
decision is made -- which is exactly what we want. The REDIRECT</code> target
rewrites the destination to 127.0.0.1:8000</code> on the host.</p>
Note that these rules are not persistent</strong> across reboots. If you want them
to survive, use whatever mechanism your distro provides (iptables-save</code> /
iptables-restore</code>, or a service that loads the rules on startup). For
debugging sessions, I find temporary rules are actually more convenient -- they
disappear cleanly when you're done. You can always write yourself a script
to bring them up with just a simple script call.</p>
A note on nftables</h3>
On newer distributions, iptables</code> is often just a compatibility shim
over nftables</code>, the modern successor to the old
{ip,ip6,arp,eb}tables</code> family. If your distro has migrated fully, the
iptables</code> command might not even be available. If iptables</code> is missing
on your distro, verify that maybe you have the nft</code> command instead.</p>
If it's present, the equivalent ruleset in nft</code> syntax would look
like this:</p>
# nft add table ip nat</span></span>
# nft add chain ip nat PREROUTING '{ type nat hook prerouting priority -100; }'</span></span>
# nft add rule ip nat PREROUTING iifname "virbr0" tcp dport 443 redirect to :8000</span></span>
# nft add rule ip nat PREROUTING iifname "virbr0" tcp dport 80  redirect to :8000</span></span></code></pre>
In my case iptables</code> was still available and worked fine, so I stuck with it.</p>
HTTP/3 and the QUIC problem</h2>
There is a catch that's really easy to overlook. The rules above only
handle TCP traffic. The "good old" HTTP/1.1 and HTTP/2 run over TCP,
so they're covered. But HTTP/3 is a different story.</p>
HTTP/3 is built on top of QUIC</a> -- a transport protocol
standardized by the IETF (RFC 9000). Unlike its predecessors, QUIC
runs over UDP</strong>, not TCP. It was designed to solve some fundamental
Google problems, and since Google has tons of money to burn, they've
decided to burn it on QUIC adoption. So, we're stuck with it now. It
may address some of the HTTP/1.1 and HTTP/2 problems, but to be honest,
I don't really know.</p>
The practical implication for our setup is that if the client is a modern
browser, it will likely attempt HTTP/3 first (advertised via an Alt-Svc</code>
header or DNS HTTPS records), and that traffic will be UDP on port 443 --
completely bypassing the TCP redirect rules we set up.</p>
It's a question for your tool whether it supports HTTP3 / QUIC or not.
For example, mitmproxy</em> since version 11 supports it out of the
box. If you're using a tool that supports it, you can just add another rule
to catch UDP traffic and that's it:</p>
sudo</span> iptables</span> -t</span> nat</span> -A</span> PREROUTING</span> -i</span> virbr0</span> -p</span> udp</span> --dport 443 -j</span> REDIRECT</span> --to-port 8000</span></span></code></pre>
But if you're using some ancient tool, then one simple fix is to just
block UDP port 443 from the VM entirely, which forces the client to
fall back to HTTP/2 or HTTP/1.1 over TCP:</p>
# iptables -I FORWARD -i virbr0 -p udp --dport 443 -j REJECT</span></span></code></pre>
Using REJECT</code> instead of DROP</code> is friendlier -- it sends an active
ICMP rejection port unreachable</em> message back immediately, so the
client fails fast and falls back to TCP right away, rather than
waiting for a timeout.</p>
IPv6</h2>
If the VM has IPv6 connectivity, don't forget that iptables</code> only handles
IPv4. For IPv6 you need ip6tables</code> with the same rules:</p>
# ip6tables -t nat -A PREROUTING -i virbr0 -p tcp --dport 443 -j REDIRECT --to-port 8000</span></span>
# ip6tables -t nat -A PREROUTING -i virbr0 -p tcp --dport 80  -j REDIRECT --to-port 8000</span></span>
# ip6tables -I FORWARD -i virbr0 -p udp --dport 443 -j REJECT</span></span></code></pre>
In practice, the default libvirt NAT network (virbr0</code>) only does
IPv4, so this may not matter. But if you've configured IPv6 forwarding
on the bridge, or if the VM has a routable IPv6 address through some
other means, or you're reading this article in the future, when
libvirt's network is IPv6 by default, you'll want these rules too --
otherwise the browser will happily use IPv6 to bypass everything you
just set up.</p>
Starting mitmproxy</h2>
Run mitmproxy in transparent mode on the same port:</p>
$</span> mitmproxy</span> --mode</span> transparent</span> --listen-host 0.0.0.0 --listen-port 8000</span></span></code></pre>
Or, if you prefer a browser-based UI:</p>
$</span> mitmweb</span> --mode</span> transparent</span> --listen-host 0.0.0.0 --listen-port 8000</span></span></code></pre>
Transparent mode is important here -- it tells mitmproxy that connections are
being redirected to it, and that it should recover the original destination
address from the socket (via SO_ORIGINAL_DST</code>). Without this flag, mitmproxy
would expect a regular explicit proxy connection and everything would fail
immediately.</p>
Trusting the CA certificate in Windows</h2>
At this point, traffic from the VM is being redirected through mitmproxy, but
the browser (or any other HTTPS client) will reject the connection because
mitmproxy is presenting its own dynamically-generated certificate, not the real
one from the server. The client doesn't trust mitmproxy's CA yet.</p>
When mitmproxy starts for the first time, it generates its own CA certificate
and stores it in ~/.mitmproxy/</code>:</p>
~/.mitmproxy/mitmproxy-ca.pem        # CA key + cert (keep this private)</span></span>
~/.mitmproxy/mitmproxy-ca-cert.pem   # CA cert only</span></span>
~/.mitmproxy/mitmproxy-ca-cert.p12   # same, PKCS#12 format (for Windows/macOS)</span></span>
~/.mitmproxy/mitmproxy-ca-cert.cer   # same, DER format</span></span></code></pre>
This CA is what mitmproxy uses to sign the per-site certificates it generates
on the fly. For the HTTPS interception to work transparently, the VM must trust
it. You can either copy the certificate file directly from the host, or use the
convenient shortcut mitmproxy provides: from within the Windows VM, open a
browser and navigate to:</p>
http://mitm.it</span></span></code></pre>
mitmproxy intercepts this special hostname and serves a page with download
links for its CA certificate on all supported platforms. Download the Windows
version (.p12</code> or the certificate installer), then install it into the
Trusted Root Certification Authorities</strong> store.</p>
The exact steps in Windows 10:</p>

Double-click the downloaded certificate file.</li>
Select Local Machine</em> and click Next.</li>
Place the certificate in Trusted Root Certification Authorities</em>.</li>
Confirm and finish.</li>
</ol>
After that, HTTPS connections from the VM will go through mitmproxy silently
and without certificate errors. You'll see all the requests and responses --
headers, bodies, everything -- in mitmproxy's interface on the host.</p>
</p>
Cleaning up</h2>
When you're done, remove the rules:</p>
# iptables -t nat -D PREROUTING -i virbr0 -p tcp --dport 443 -j REDIRECT --to-port 8000</span></span>
# iptables -t nat -D PREROUTING -i virbr0 -p tcp --dport 80  -j REDIRECT --to-port 8000</span></span>
# iptables -D FORWARD -i virbr0 -p udp --dport 443 -j REJECT</span></span></code></pre>
And stop mitmproxy. The Windows CA store will still contain the
mitmproxy certificate, but generally Windows it's full of bloat and
trash anyway even (especially</em>) after default fresh install, so that
shouldn't matter that much I guess.</p>
Limitations of mitmproxy / MITM approach</h2>
A few things that can trip you up:</p>
Streaming and large responses.</strong> By default, mitmproxy buffers the entire
response body before displaying it. This means long-running connections --
server-sent events, chunked downloads, WebSocket streams -- will appear to hang
in the UI until the transfer finishes, or never complete at all. There is a
streaming mode</a>
that bypasses buffering, but then you lose the ability to inspect the full body.
You can pick your poison I guess.</p>
Certificate pinning.</strong> If the application hardcodes a specific
certificate or public key rather than pulling one from the OS CA
store, it will reject mitmproxy's certificate -- regardless of what
you installed in the Windows trust store. SSL pinning</a>
exists precisely to prevent what we're doing now: a man-in-the-middle
intercepting encrypted traffic. This is common in mobile apps and some
Electron apps. There is no clean workaround; you have to patch the
binary, for example using Frida</a>, which lets you hook into a
running process and disable the pinning check at runtime. How to disable
this check varies between the apps, because you need to patch the
code, but there are Frida scripts that automate this for popular systems,
all you need to do is to search for them.</p>
Per-application CA stores.</strong> Some apps don't use the Windows
certificate store at all. Firefox ships with its own, Java uses a
bundled cacerts</code> keystore -- you can add the mitmproxy CA to it with
keytool</code></a> -- and some Go or Rust binaries embed
Mozilla's CA bundle directly. For these, you need to import the
mitmproxy CA separately into whatever store the app actually reads.</p>
Happy sniffing!</p>
G.</p>



Fixing: Vivaldi opens Nautilus instead of Dolphin on KDE
2026-03-22T00:00:00+00:00
If you're on KDE with both Dolphin and Nautilus installed, you may have noticed
that clicking Open containing folder</em> in Vivaldi (or any Chromium-based
browser, really) opens Nautilus instead of Dolphin. Everything else seems fine
-- xdg-mime query default inode/directory</code> returns org.kde.dolphin.desktop</code>,
and KDE system settings agree. Yet there's the GNOME devs, pushing you their
stack even if you don't want it.</p>
One obvious way would be to get rid of GNOME, and I'd argue that would make the
most sense. However, if you want to leave it, maybe just because we need to know
our enemies, then read on.</p>
Root cause</h2>
The key point is that when a browser wants to open a containing
directory in the file manager, it doesn't call xdg-open</code>. Instead, it
calls the ShowItems</code> method on the org.freedesktop.FileManager1</code>
D-Bus service.</p>
The problem is that both Dolphin and Nautilus ship a D-Bus service file that
claims this name:</p>
Nautilus:</span></span>
/usr/share/dbus-1/services/org.freedesktop.FileManager1.service</span></span>
</span>
Dolphin:</span></span>
/usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service</span></span></code></pre>
Both files contain Name=org.freedesktop.FileManager1</code>. When the service isn't
already running, D-Bus auto-activates one of them. It picks up
org.freedesktop.FileManager1.service</code> first -- because it comes first
alphabetically -- and launches Nautilus.</p>
You can verify this by checking the two files:</p>
cat</span> /usr/share/dbus-1/services/org.freedesktop.FileManager1.service</span></span>
# Exec=/usr/bin/nautilus --gapplication-service</span></span>
</span>
cat</span> /usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service</span></span>
# Exec=/usr/bin/dolphin --daemon</span></span></code></pre>The fix</h2>
D-Bus checks $XDG_DATA_HOME/dbus-1/services/</code> before the system-level
directories. So creating a user-level override is enough:</p>
mkdir</span> -p</span> ~/.local/share/dbus-1/services</span></span>
</span>
cat</span> ></span> ~/.local/share/dbus-1/services/org.freedesktop.FileManager1.service</span> <<</span> 'EOF'</span></span>
[D-BUS Service]</span></span>
Name=org.freedesktop.FileManager1</span></span>
Exec=/usr/bin/dolphin --daemon</span></span>
EOF</span></span></code></pre>
That's the persistent fix. It survives reboots without touching any system
files.</p>
If it still doesn't work after creating the file</h2>
The service file only matters when the org.freedesktop.FileManager1</code> name is
not yet claimed on the session bus. If Nautilus is already running and holding
that name, D-Bus won't re-activate anything -- it'll just keep routing calls to
the existing Nautilus instance.</p>
Kill it:</p>
pkill</span> -f</span> "nautilus --gapplication-service"</span></span></code></pre>
After that, the next time Vivaldi triggers Show in folder</em>, D-Bus will activate
Dolphin using your new service file.</p>
Confirming it works</h2>
You can test the whole thing without opening a browser at all:</p>
pkill</span> -f</span> "nautilus --gapplication-service"</span></span>
pkill</span> -f</span> "dolphin --daemon"</span></span>
</span>
dbus-send</span> --session --print-reply \</span></span>
  --dest=org.freedesktop.FileManager1 \</span></span>
  /org/freedesktop/FileManager1</span> \</span></span>
  org.freedesktop.FileManager1.ShowItems</span> \</span></span>
  array:string:"file:///tmp" string:""</span></span></code></pre>
Dolphin should open. If Nautilus opens, double-check the service file contents
and path.</p>
If that'll work, you still have some work to do. Figuring out why you
still have GNOME is a non trivial task. I'm still working on it.</p>


Fixing: `Could not access KVM kernel module`
2026-03-16T00:00:00+00:00
Maybe you've seen this error, when you sometimes use virt-manager</code>:</p>
Error starting domain: internal error: process exited while connecting to monitor:</span></span>
qemu-system-x86_64: -accel kvm: Could not access KVM kernel module: No such file or directory</span></span>
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory</span></span></code></pre>
it sounds like something is pretty broken. Potential problems include:</p>

KVM module is missing,</li>
virtualization is disabled in BIOS,</li>
or /dev/kvm</code> does not exist due to missing support from the OS.</li>
</ul>
But there is another subtle cause: /dev/kvm</code> is created with wrong ownership/permissions because the kvm</code> group is not treated as a system group by udev</code>.</p>
This short blog post will dig through a solution to this problem.</p>
The problem</h2>
On an affected host, checks often look like this:</p>

lsmod | grep kvm</code> shows kvm</code> and kvm_intel</code>/kvm_amd</code> loaded.</li>
CPU supports virtualization (vmx</code> or svm</code> exists in /proc/cpuinfo</code>).</li>
/dev/kvm</code> exists, but is owned by root:root</code> and often mode 0600</code>:</li>
</ul>
crw------- 1 root root ... /dev/kvm</span></span></code></pre>

journalctl -u systemd-udevd</code> may contain:</li>
</ul>
Failed to resolve group 'kvm' ... Not a system group</span></span></code></pre>
That line is the key. "Not a system group" tells you exactly what is happening.</p>
Root cause</h2>
udev</code> rules (for example in /usr/lib/udev/rules.d/50-udev-default.rules</code>) typically expect:</p>
KERNEL=="kvm", GROUP="kvm", MODE="0666"</span></span></code></pre>
If your kvm</code> group has a GID outside the system range</strong> (commonly above SYS_GID_MAX</code> from /etc/login.defs</code>), then group resolution can fail during device setup</strong>.</p>
When that happens, /dev/kvm</code> may fall back</em> to root:root</code> and restrictive permissions, and QEMU launched by libvirt fails to initialize KVM.</p>
So the problem is not that /dev/kvm</code> has wrong permissions, but rather that the chosen group has wrong ID (outside of the SYS_GID range).</p>
Verification</h2>
# 1) Device ownership/mode</span></span>
ls</span> -l</span> /dev/kvm</span></span>
</span>
# 2) KVM modules</span></span>
lsmod</span> |</span> grep</span> -E</span> 'kvm|kvm_intel|kvm_amd'</span></span>
</span>
# 3) Group + GID</span></span>
getent</span> group kvm</span></span>
</span>
# 4) System group range</span></span>
grep</span> -E</span> '^(SYS_GID_MIN|SYS_GID_MAX)' /etc/login.defs</span></span>
</span>
# 5) udev hint</span></span>
journalctl</span> -u</span> systemd-udevd</span> --no-pager</span> |</span> grep</span> -i</span> 'Failed to resolve group.*kvm'</span></span></code></pre>
If /dev/kvm</code> is root:root</code> and logs mention “Not a system group”, this guide applies.</p>
Temporary workaround (until reboot)</h2>
sudo</span> chgrp kvm /dev/kvm</span></span>
sudo</span> chmod</span> 0660</span> /dev/kvm</span></span></code></pre>
Then retry VM start.</p>
This will simply give access to /dev/kvm</code> for everyone from the kvm</code> group (you should be included).</p>
Permanent fix</h2>

Move kvm</code> to a free system GID</strong> (inside SYS_GID_MIN..SYS_GID_MAX</code>).</li>
Reload/trigger udev (or reboot).</li>
Restart libvirt.</li>
</ol>
Example:</p>
sudo</span> groupmod</span> -g 78</span> kvm</span>    # be sure that 78 is not allocated to a group on your system</span></span>
sudo</span> udevadm control</span> --reload</span></span>
sudo</span> udevadm trigger</span> --name-match=/dev/kvm</span></span>
sudo</span> systemctl restart libvirtd</span></span></code></pre>
After that:</p>
ls</span> -l</span> /dev/kvm</span></span>
# expected: root kvm and mode usable for qemu/libvirt</span></span></code></pre>A bash script that fixes the problem</h2>
I prepared a script that:</p>

validates prerequisites,</li>
finds a free system GID,</li>
optionally updates kvm</code> group GID,</li>
reloads udev,</li>
fixes /dev/kvm</code>,</li>
restarts libvirt,</li>
prints final diagnostics.</li>
</ul>
See: fix-kvm-group.sh</a>. Remember to inspect the script yourself before running. Make sure it's safe.</p>
Run it as root:</p>
sudo</span> bash ./fix-kvm-group.sh</span></span></code></pre>
Optional dry run:</p>
sudo</span> bash ./fix-kvm-group.sh</span> --dry-run</span></span></code></pre>Takeaway</h2>

Always check systemd-udevd</code> logs when /dev/*</code> ownership looks wrong.</li>
</ul>
If you maintain a podman image or something similar, ensure kvm</code> is provisioned as a system group</strong> from the start.</p>


Standard actions of Linux package managers
2023-02-25T00:00:00+00:00
I keep forgetting the command line options for standard Linux package
manager actions, so I've decided to write a blog post about it. I'm
currently using Gentoo, ArchLinux and Fedora, so I'll include pacman, rpm
and deb flavors (for completion).</p>
Q: Locating the owner package of a specified file</h1>
Portage:</p>
$ qfile /usr/bin/ls    # or 'equery b /usr/bin/ls'</span></span>
sys-apps/coreutils: /usr/bin/ls</span></span></code></pre>
Pacman:</p>
$ pacman -Qo /usr/bin/ls</span></span>
/usr/bin/ls is owned by coreutils 9.1-3</span></span></code></pre>
dpkg:</p>
$ dpkg -S lspci</span></span>
pciutils: /usr/bin/lspci</span></span></code></pre>
rpm:</p>
$ rpm -qf /usr/bin/ps</span></span>
procps-ng-3.3.17-4.fc36.1.x86_64</span></span></code></pre>Q: Listing the contents of selected package</h1>
Portage:</p>
qlist coreutils       # or 'equery f coreutils'</span></span></code></pre>
Pacman:</p>
$ pacman -Ql coreutils</span></span></code></pre>
dpkg:</p>
$ dpkg -L coreutils</span></span></code></pre>
rpm:</p>
$ rpm -ql procps-ng</span></span></code></pre>Q: Dump information about a package</h1>
Portage:</p>
$ emerge --search coreutils</span></span>
</span>
or</span></span>
</span>
$ vim `equery w coreutils`</span></span></code></pre>
Pacman:</p>
$ pacman -Qi coreutils</span></span></code></pre>
dpkg:</p>
$ dpkg -s coreutils</span></span></code></pre>
rpm:</p>
$ rpm -qi coreutils</span></span></code></pre>
I'm not delusional enough to expect that I'll remember this, but at least
now I'll have a one-stop place where I can quickly look this up.</p>


Creating ssh proxies
2022-07-08T00:00:00+00:00
I always forget what are the proper arguments to create a ssh proxy in some specific way, so I'm leaving a small cheatsheet here for my future references. I've already written</a> a blog post about it a few years ago, but now I need a fast reference instead of a descriptive blog post.</p>
Example 1 (ssh -L)</h3>
There's a VM (heravm</code>) running on my MacMini (hera</code>) which doesn't have access to the Internet, only has network access to the host machine. I want to connect to SSH service on this VM, but I want to do it from my desktop instead of MacMini. The desktop machine is in the same network as MacMini (although it doesn't really matter).</p>
I can issue this command from the <desktop></code> machine:</p>
desktop$ ssh -Nf -L 7722:<heravm>:22 <hera></span></span></code></pre>
This will open port 7722</code> on the L</code>ocal machine (desktop</code>). When connecting to localhost:7722</code> from my desktop, ssh will connect to <hera>:22</code>, and then it will forward all traffic from <hera>:22</code> to <heravm>:22</code>. So make sure the heravm</code> is reachable from hera</code>.</p>
Example 2 (ssh -R)</h3>
There's a VM (heravm</code>) running on my MacMini (hera</code>) which doesn't have access to the Internet, but has network access to the host machine. I want to connect to this VM from another house (so, from a different network). I have a VPS server ostarion</code> with a public IP reachable from both networks that can help with NAT traversal.</p>
hera$ ssh -Nf -R 12345:<heravm>:22 <ostarion></span></span></code></pre>
This will open port 12345 on the R</code>emote machine <ostarion></code>. After relocating to another house and connecting to <ostarion>:12345</code>, I will effectively connect to <heravm>:22</code>, so directly onto the VM that has no Internet access.</p>
Example 3 (ssh -D)</h3>
I have a VPS ostarion</code>. I would like to browse the web so that websites will think I'm browsing from ostarion</code> instead of my local ISP.</p>
desktop$ ssh -D8080 <ostarion></span></span></code></pre>
This will create a SOCKS5 server on host 0.0.0.0:8080</code>. Use browser plugins like SwitchyOmega to use this proxy for chosen websites.</p>
Persistence</h3>
Temporary tunnels are fun, but persistent tunnels that spawn automatically and restart on network failures are what we're after. It's still a matter of empirical verification, but one persistence method is described below.</p>
The example scenario I'm trying to accomplish is this: there's a virtual machine heravm</code> running on some host (hera</code>) that is behind NAT. I want to be able to connect to this VM from another house. I can use an external VPS that I control (ostarion</code>) to setup ssh tunelling. The heravm</code> VM doesn't have Internet connection enabled, it's just able to connect to its host (hera</code>) and nothing else.</p>
This basically means that I need to create reverse tunneling from hera</code>:</p>
hera$ ssh -R 12345:<heravm>:22 ostarion</span></span></code></pre>
This means that when I connect to <ostarion>:12345</code>, I will effectively connect to <heravm>:22</code>.</p>
Now we need to make sure that this tunnel will be created for as long as it's possible, and will be re-created when the machine will be restarted from some reason (e.g. power failure).</p>
Persistence on macOS (tested on Monterey)</h4>
We're gonna utilise launchd to manage our tunnel. The tunnel will be (re)started when needed.</p>
But first, we're going to create a new ssh identity (a private and a public key) that won't use any password. If that sounds like a security risk, then I agree, but the proper solution for this depends entirely on your setup, and is out of scope for this blog post.</p>
Remember to NOT overwrite your main identity!</strong></p>
hera $ ssh-keygen -t ecdsa</span></span>
Generating public/private ecdsa key pair.</span></span>
Enter file in which to save the key (/home/antek/.ssh/id_ecdsa): /path/to/unattended</span></span>
Enter passphrase (empty for no passphrase):</span></span>
Enter same passphrase again:</span></span>
Your identification has been saved in /path/to/unattended</span></span>
Your public key has been saved in /path/to/unattended.pub</span></span>
The key fingerprint is:</span></span>
SHA256:xPB9hGEfqxhI2041ioN7urHxYt2rtQEAmvuOsArGDdA antek@host</span></span>
The key's randomart image is:</span></span>
+---[ECDSA 256]---+</span></span>
|  .   o   =oo    |</span></span>
| + . o O =.+ o   |</span></span>
|+ E o = O . +    |</span></span>
|..   o = o o     |</span></span>
|..  . o S .      |</span></span>
|..o  o .         |</span></span>
|oo..+. .o        |</span></span>
|++  o*...o       |</span></span>
|= ..o.o.o.       |</span></span>
+----[SHA256]-----+</span></span></code></pre>
Make sure to remove group</em> and other</em> read rights from /path/to/unattended</code> file, so that only the owner will be able to access the private key.</p>
Having an "unattended" private key created we can create a new ssh configuration entry inside ~/.ssh/config</code>:</p>
host host_unattended</span></span>
    hostname $hostname$</span></span>
    user antek</span></span>
    identityfile /path/to/unattended</span></span>
    identitiesonly yes</span></span></code></pre>
The $hostname$</strong> variable points to an external server that is always on, has a publicly reachable IP address and of course it's running sshd (e.g. a VPS).</p>
After the ssh config is ready, we can proceed with creation of the new launchd descriptor for our service (named servicename.plist</code>):</p>
<?</span>xml</span> version</span>=</span>"1.0"</span> encoding</span>=</span>"UTF-8"</span>?></span></span>
<!</span>DOCTYPE</span> plist</span> PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"></span></span>
<</span>plist</span> version</span>=</span>"1.0"</span>><</span>dict</span>></span></span>
    <</span>key</span>>Label</</span>key</span>></span></span>
    <</span>string</span>>org.anadoxin.servicename</</span>string</span>></span></span>
    <</span>key</span>>username</</span>key</span>></span></span>
    <</span>string</span>>$username$</</span>string</span>></span>   <!-- HERE --></span></span>
    <</span>key</span>>groupname</</span>key</span>></span></span>
    <</span>string</span>>staff</</span>string</span>></span></span>
    <</span>key</span>>ProgramArguments</</span>key</span>></span></span>
    <</span>array</span>></span></span>
        <</span>string</span>>/usr/bin/ssh</</span>string</span>></span></span>
        <</span>string</span>>-R 12345:$heravm$:22</</span>string</span>></span>   <!-- HERE --></span></span>
        <</span>string</span>>-NTC</</span>string</span>></span></span>
        <</span>string</span>>-o ExitOnForwardFailure=yes</</span>string</span>></span></span>
        <</span>string</span>>-o ServerAliveInterval=60</</span>string</span>></span></span>
        <</span>string</span>>-o ServerAliveCountMax=10</</span>string</span>></span></span>
        <</span>string</span>>host_unattended</</span>string</span>></span></span>
    </</span>array</span>></span></span>
    <</span>key</span>>StandardErrorPath</</span>key</span>></span></span>
    <</span>string</span>>/tmp/org.anadoxin.servicename.stderr</</span>string</span>></span></span>
    <</span>key</span>>StandardOutPath</</span>key</span>></span></span>
    <</span>string</span>>/tmp/org.anadoxin.servicename.stdout</</span>string</span>></span></span>
    <</span>key</span>>RunAtLoad</</span>key</span>></span></span>
    <</span>true</span>/></span></span>
    <</span>key</span>>KeepAlive</</span>key</span>></span></span>
    <</span>true</span>/></span></span>
</</span>dict</span>></</span>plist</span>></span></span></code></pre>
Make sure you notice the $heravm$</strong> and $username$</strong> variables! Change them according to your requirements. You should probably change the org.anadoxin.servicename</strong> as well.</p>
In the example above, the ssh binary is called with the following options:</p>

-N</strong> -- don't execute any command. This option is used often when forwarding ports (so, perfect for our case),</li>
-T</strong> -- disables pseudo-terminal allocation (no point if we're not spawning any interactive sessions),</li>
-C</strong> -- enable data compression -- useful only for slow links. Disable if you have fast Internet connection.</li>
Remember to NOT</em> use the -f</strong> flag here. This flag will fork ssh to the background. Normally this would be useful, but used in this descriptor it will confuse launchd; it will think that sshd has exited, and will try to start it again (over and over again).</li>
</ul>
After the launchd descriptor has been created, it can be started with launchctl</code>:</p>
hera$ sudo launchctl load servicename.plist</span></span></code></pre>
If you're getting errors, please verify that the syntax of the XML file is OK (plutil -p servicename.plist</code>), the access rights are not too loose, and inspect both stderr and stdout streams created in /tmp</code>.</p>
Because the descriptor uses RunAtLoad=true</code>, it should be executed on load. Verify the tunnel is working by e.g. using ps</code>:</p>
hera$ ps aux | grep "/usr/bin/ssh"</span></span>
antek             5011   0.1  0.0 408667760   5472   ??  Ss    8:31PM   0:00.23 /usr/bin/ssh -R 12345:192.168.64.2:22 -NTC -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -o ServerAliveCountMax=10 ostarion_unattended</span></span></code></pre>
If from any reason the tunnel will collapse (e.g. network failure, power failure), it should be automatically re-created by launchd.</p>
Notes</h3>
The -L</code>, -R</code> and -D</code> switches accept also the listening interface</code>. Default listening interface settings open up the port for everyone (binding the socket to 0.0.0.0</code>). This may not be what you want, and you might limit the bind address to 127.0.0.1</code>. So, for "example 3", the more secure command would be:</p>
$ ssh -D 127.0.0.1:8080 <ostarion></span></span></code></pre>
You can find the proper syntax for all options in man ssh</code>.</p>


Sniffing HTTPS during development
2022-01-28T00:00:00+00:00


When programming, developer sometimes needs to contact a server, use API, etc.</p>
</li>

HTTPS is now a must. Letsencrypt makes it easy. There are several frameworks for easy HTTPS communication.</p>
</li>

Libs are high-level. They are easy to use, but they sometimes do some of the work behind the scenes.
This sometimes makes it difficult to know what exactly is being sent and how. Sometimes we need to check
if a header is being sent. Sometimes there are bugs in libraries, or non-intuitive uses (e.g. httpclient
in esetctl).</p>
</li>

HTTP would make it easy. We would need to use Wireshark and that's it, we have full communication recorded.</p>
</li>

But we're using HTTPS, so we can't simply sniff TLS traffic.</p>
</li>
</ol>
First option: SSLKEYLOGFILE -- per library support. curl/libcurl supports it, java doesn't. This means that
it's a de-facto standard, and support is pretty spotty.</p>
BURP potrafi sniffowac ssl?</p>
Second option: mitmproxy</p>


Removing the unwanted Konsole toolbar
2021-07-19T00:00:00+00:00
Generally I'm pretty happy with my KDE desktop, although I'm among those people who think that KDE hasn't been the same since version 3. Having version KDE v5.22.3 currently installed on my machine I do see lots of bugs, but the advantages like the feature list, and not assuming the user is an idiot (comparing to GNOME) easily convinces me that KDE is the best thing Linux Desktop has to offer for me (I also refuse to use the Plasma</em> terminology, because I'm still not sure what is it).</p>
That being said, some bugs are pretty frustrating. One of the bugs that has popped up recently is a Konsole bug that doesn't allow the user to hide its toolbar. Normally I do mind when I see some pixels that are out of place, and in this particular case a whole toolbar is out of place, so I couldn't continue until I've found a solution. I considered switching to a different distro because of it, but ultimately I didn't have to because of a quick walkaround.</p>
Normally this bug is active on my openSUSE distribution, but I don't see it under ArchLinux. This is how it looks like on openSUSE:</p>
</iframe>
(the video shows a toolbar that can't be hidden)</p>
Lucky users (on e.g. ArchLinux) have these options to their disposal, freeing them from this problem:</p>


The problem is that some distributions bundle KDE in a way that this option is simply not available, as shown in the video.</p>
So, the first workaround I've found is:</p>

Ensure that the menu bar is visible (Ctrl+Shift+M),</li>
Right-click on the menu bar,</li>
Hide the toolbar from there,</li>
Hide the menu bar again (if needed).</li>
</ol>
This does</em> hide the toolbar, but the problem is that this method won't work in another instance of Konsole. So it fixes the problem only for current Konsole window.</p>
Another workaround, which might be better, is to open this configuration file:</p>
~/.local/share/kxmlgui5/konsole/konsoleui.rc</span></span></code></pre>
and comment out this section inside it:</p>
<!--<ToolBar name="mainToolBar"></span></span>
 <text>Main Toolbar</text></span></span>
 <index>0</index></span></span>
 <Action name="new-tab"/></span></span>
 <Action name="split-view-left-right"/></span></span>
 <Action name="split-view-top-bottom"/></span></span>
</ToolBar>--></span></span></code></pre>
This effectively hides the toolbar, maybe not in the best way possible, but it appears to work! At least maybe until some update will show up that properly fixes the problem, or someone else will figure out a better solution.</p>


Usage of encrypted file containers
2014-11-09T00:00:00+00:00
Lots of modern systems (Linux, BSDs) support encryption of block devices, or
file containers, in a similar way that TrueCrypt does it. It is basically (more
or less) a built-in TrueCrypt that gives you the possibility to build a secure
medium and store your sensitive files inside.</p>
Device-mapper</h2>
There is a subsystem in the Linux kernel called device-mapper</code>. It allows the
creation of arbitrary devices that are controlled by software applications.
This means that if device-mapper</code> creates a file, its content is being served
by another program, not the filesystem module like it's done with conventional
files.</p>
This, in turn, means that device-mapper</code> allows to create "dynamic" files
(these are actually 'devices', but on Linux there's not a big functional
difference between those two). The content of these files are being generated
during a read request. It's a very handy mechanism for on-demand file
decryption: if a program tries to read an encrypted file, the software driver
that controls this file's contents (via device-mapper</code>) reads the encrypted
content from the disk, decrypts it, and serves decrypted data to requesting
application. No plaintext is ever written to the disk.</p>
Device-mapper stacking</h2>
One of the nicest features of device-mapper</code> is the ability to stack with
itself. Consider this example:</p>
</p>
In theory, it's possible to create a device-mapper</code> device (so: a 'virtual
device') that will generate unlimited amount of NULL</code> bytes on read request --
in similar fashion that it is done with the /dev/null</code> device.</p>
It is also possible to create another device, an 'xor virtual device' that reads
data from its input file, XORs them with 0xA1</code>, and emits the output. This is
different from /dev/null</code>, because in this case the device needs another device
to be able to read data from it, perform some manipulation, and output altered
data.</p>
The example also depicts a third example, 'invert byte virtual device', that
works similarily to 'xor virtual device', but instead of XORing each byte, it
inverts it.</p>
All of these devices can be stacked one on another. In our example we can read
data from 'invert byte virtual device'. This will put in motion several other
devices as well:</p>

'invert byte device' will ask 'xor device' for data,</li>
'xor device' will ask 'zero-byte device' for data,</li>
'zero-byte device' will generate a NULL byte, and will return it to the
caller,</li>
'xor device' will acquire this NULL byte, and it will perform an XOR 0xA1</code>
operation on it. Then, it will return the XORed data to the 'invert byte device'.</li>
'invert byte device' will get the XORed data, and will invert each byte of it.</li>
</ul>
The result of this operation will probably be next to useless, but it
demonstrates the stacking capability of device-mapper</code>. If we switch the
zero-byte generator to a normal file, we suddenly have a poor-man encryption
system, based on XOR and NEG! ;)</p>
Cryptsetup</h2>
Our system of choice is LUKS, without any particular reason other than because
it supports a wide range of secure encryption algorithms. Before using it,
please be aware that one thing that LUKS doesn't implement is support for
plausible deniability -- LUKS actually inserts its header into the encrypted
file, so everyone can see that this is an encrypted container.</p>
This shouldn't be a problem in sensitive scenarios, because we can always add
another device-mapper</code> device that will encrypt the LUKS encrypted data, along
with its header. That's why the device stacking feature is so useful.</p>
We won't use LUKS directly, because it's designed to be used by the cryptsetup</code>
frontend. To properly use LUKS, we have to specify the container (or the "input
data"). The device will store its encrypted data inside this container. We can
choose to have a simple file as the container, a disk drive, or another device.
Let's choose a simple file, container.bin</code>.</p>
Let's create a 100MB file that will be the container:</p>
# dd if=/dev/zero of=container.bin bs=1M count=100</span></span></code></pre>
Then, let's create the LUKS structure inside it:</p>
# cryptsetup luksFormat container.bin</span></span>
</span>
WARNING!</span></span>
========</span></span>
This will overwrite data on container.bin irrevocably.</span></span>
</span>
Are you sure? (Type uppercase yes): YES</span></span>
Enter passphrase:</span></span>
Verify passphrase:</span></span>
</span>
# file container.bin</span></span>
container.bin: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 02dc91ee-e1d8-4918-bcd4-7536f91811a8</span></span></code></pre>
It used xts-plain64</code> as a default encryption algorithm. You can tune up this
behavior by command-line settings.</p>
Now we can create a device-mapper</code> device by using luksOpen</code> command:</p>
# cryptsetup luksOpen container.bin container</span></span>
Enter passphrase for container.bin:</span></span>
</span>
# ls -la /dev/mapper/container</span></span>
lrwxrwxrwx 1 root root 7 09.11.2014 16:36 /dev/mapper/container -> ../dm-2</span></span></code></pre>
As you can see, we have our first virtual device, /dev/mapper/container</code>. When
we read from this device, LUKS will decrypt the data from container.bin</code> by
using the xts-plain64</code> algorithm, and will feed our request with decrypted
data. When we'll write into this device, LUKS will encrypt this data and store
it inside container.bin</code> in encrypted form.</p>
Now we can operate on this device as on any other device. We can create a
filesystem on it:</p>
# mkfs.ext4 /dev/mapper/container</span></span>
mke2fs 1.42.12 (29-Aug-2014)</span></span>
Creating filesystem with 100352 1k blocks and 25168 inodes</span></span>
Filesystem UUID: ceb14da6-714a-4a53-9739-428bbffa336e</span></span>
Superblock backups stored on blocks:</span></span>
    8193, 24577, 40961, 57345, 73729</span></span>
</span>
Allocating group tables: done</span></span>
Writing inode tables: done</span></span>
Creating journal (4096 blocks): done</span></span>
Writing superblocks and filesystem accounting information: done</span></span>
</span>
# mkdir /tmp/x</span></span>
# mount /dev/mapper/container /tmp/x</span></span>
# ls -la /tmp/x</span></span>
total 13</span></span>
drwxr-xr-x  3 root root  1024 09.11.2014 16:39 ./</span></span>
drwxrwxrwt 20 root root   560 09.11.2014 16:39 ../</span></span>
drwx------  2 root root 12288 09.11.2014 16:39 lost+found/</span></span></code></pre>
We have created our first encrypted container! We can close it gracefully by
unmounting the filesystem and performing a luksClose</code> command:</p>
# umount /tmp/x</span></span>
# cryptsetup luksClose container</span></span></code></pre>Limitations</h2>
This approach has its limitations. We have created a 100MB container file, and
then we have created a filesystem on it. Our free space available for use is:</p>
# df -h /tmp/x</span></span>
Filesystem             Size  Used Avail Use% Mounted on</span></span>
/dev/mapper/container   91M  1.6M   83M   2% /tmp/x</span></span></code></pre>
It's 83MB. What if, in the future, we would like to increase the size of this
container?</p>
One option is to simply increase the size of the container.bin</code> container file
(after removing all mappings first and performing luksClose</code>). Then, after
mounting the filesystem, invoking a filesystem resize operation (for example by
using resize2fs</code> if you're using ext4</code> filesystem, or xfs_growfs</code> if you're
on xfs</code>) should be enough.</p>
But there are scenarios that this won't suffice. One such example is when using
a Dedicated Host bought in some server room, or a VPS, where you can just add
another storage nodes instead of resizing them. You can't make the file larger
than the partition used to hold the file.</p>
You can get around this limitation by entering one abstraction above physical
limitations. Enter Logical Volume Management!</p>
lvm2: Logical Volume Management</h2>
The topic is as large as Pacific Ocean, so we will simply skip most of it,
focusing only on our use-case.</p>
We can use lvm</code> to create a new virtual drive (again, with device-mapper</code>)
that will use our containers as physical file storage. This way, by having
multiple container files, each with its own file size, we can create a device
that will be as large as the sum of each container's length. lvm</code> driver will
figure out the best way to dispatch read and write reqests to proper file
containers, just like RAID controllers do. One big difference between LVM and
RAID is that LVM is more dynamic, and allows you to create, modify, resize and
deactivate logical volumes when the system is on-line and working. It actually
also supports performing filesystem snapshots, but this is one feature we won't
actually use.</p>
So, the layout of our system will look something like this:</p>
</p>
The 'Main Logical Volume' will be our virtual drive, which will contain a
filesystem. By using this layout, we will be able to increase the size of it
simply by adding more container files. Every container will be encrypted by
LUKS, so nothing will be stored as plaintext.</p>
The nodes marked as 'PV' are physical volumes</code>, which are described in the next
subsection.</p>
To properly create the LVM layout, we need four things:</p>

A 'logical volume', which will be a mountable device,</li>
A 'volume group', which will group our logical volumes (we will have only one
logical volume, but a group still is needed),</li>
A 'physical volume', which will specify where exactly is the place for the
data to be written,</li>
An encrypted space for the physical volume -- this was covered in previous
sections of this post.</li>
</ul>
Let's create everything that is needed, going from the end of this list.</p>
LUKS containers</h3>
We will create three containers: container1.bin</code>, container2.bin</code> and
container3.bin</code>. Each container will have a capacity of 100MB.</p>
$ for i in `seq 1 3`; do dd if=/dev/zero of=container$i.bin bs=1M count=100; done</span></span>
100+0 records in</span></span>
100+0 records out</span></span>
104857600 bytes (105 MB) copied, 0.0443074 s, 2.4 GB/s</span></span>
100+0 records in</span></span>
100+0 records out</span></span>
104857600 bytes (105 MB) copied, 0.0390611 s, 2.7 GB/s</span></span>
100+0 records in</span></span>
100+0 records out</span></span>
104857600 bytes (105 MB) copied, 0.0388189 s, 2.7 GB/s</span></span>
</span>
$ ls -la</span></span>
total 307212</span></span>
drwxr-xr-x 2 antek users      4096 Nov 11 12:05 .</span></span>
drwxr-xr-x 8 antek users      4096 Nov 11 12:05 ..</span></span>
-rw-r--r-- 1 antek users 104857600 Nov 11 12:05 container1.bin</span></span>
-rw-r--r-- 1 antek users 104857600 Nov 11 12:05 container2.bin</span></span>
-rw-r--r-- 1 antek users 104857600 Nov 11 12:05 container3.bin</span></span></code></pre>
Then, we create three LUKS devices from each container, each with some password
(you can choose different password for each container, or one password for
everything -- depends on your paranoia level).</p>
$ for i in `seq 1 3`; do cryptsetup luksFormat container$i.bin; done</span></span>
</span>
WARNING!</span></span>
========</span></span>
This will overwrite data on container1.bin irrevocably.</span></span>
</span>
Are you sure? (Type uppercase yes): YES</span></span>
Enter passphrase:</span></span>
Verify passphrase:</span></span>
</span>
WARNING!</span></span>
========</span></span>
This will overwrite data on container2.bin irrevocably.</span></span>
</span>
Are you sure? (Type uppercase yes): YES</span></span>
Enter passphrase:</span></span>
Verify passphrase:</span></span>
</span>
WARNING!</span></span>
========</span></span>
This will overwrite data on container3.bin irrevocably.</span></span>
</span>
Are you sure? (Type uppercase yes): YES</span></span>
Enter passphrase:</span></span>
Verify passphrase:</span></span>
</span>
$ file container*</span></span>
container1.bin: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 282f487a-b708-42ab-b403-667af624f667</span></span>
container2.bin: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 2d95d5bd-8528-4fdf-8954-57b3268c20c9</span></span>
container3.bin: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: ffa92cc0-c5e9-45dd-95d0-f33469e09dd1</span></span></code></pre>
Then we open all containers to create proper device-mapper</code> devices:</p>
$ sudo su</span></span>
[root@hydra blogpost]# for i in `seq 1 3`; do cryptsetup luksOpen container$i.bin container$i; done</span></span>
Enter passphrase for container1.bin:</span></span>
Enter passphrase for container2.bin:</span></span>
Enter passphrase for container3.bin:</span></span>
</span>
[root@hydra blogpost]# ls -la /dev/mapper/container*</span></span>
lrwxrwxrwx 1 root root 7 11.11.2014 12:10 /dev/mapper/container1 -> ../dm-0</span></span>
lrwxrwxrwx 1 root root 7 11.11.2014 12:10 /dev/mapper/container2 -> ../dm-1</span></span>
lrwxrwxrwx 1 root root 7 11.11.2014 12:10 /dev/mapper/container3 -> ../dm-2</span></span></code></pre>
As you can see, we have created three encrypted devices in
/dev/mapper/container*</code>.</p>
Physical Volumes (PV)</h3>
Now it's time to create a LVM on the top of it. We
will use each /dev/mapper/container*</code> device as a LVM Physical Volume (PV</code>).
Let's create those PV's:</p>
[root@hydra blogpost]# pvcreate /dev/mapper/container{1,2,3}</span></span>
Physical volume "/dev/mapper/container1" successfully created</span></span>
Physical volume "/dev/mapper/container2" successfully created</span></span>
Physical volume "/dev/mapper/container3" successfully created</span></span></code></pre>
We can verify that LVM registered those PVs properly:</p>
[root@hydra blogpost]# pvscan</span></span>
PV /dev/mapper/container2         lvm2 [98.00 MiB]</span></span>
PV /dev/mapper/container1         lvm2 [98.00 MiB]</span></span>
PV /dev/mapper/container3         lvm2 [98.00 MiB]</span></span>
Total: 3 [294.00 MiB] / in use: 0 [0   ] / in no VG: 3 [294.00 MiB]</span></span></code></pre>
We have about 300MB in all three physical volumes.</p>
Volume Group (VG)</h3>
We can now create a Volume Group (VG</code>). Volume group is a pool of physical
volumes (PVs). We group PVs together in a VG, to be able to create a virtual
Logical Volume (LV), that will be contained inside the VG.</p>
[root@hydra blogpost]# vgcreate example_vg /dev/mapper/container{1,2,3}</span></span>
Volume group "example_vg" successfully created</span></span></code></pre>
Let's verify that everything is in order:</p>
[root@hydra blogpost]# vgscan</span></span>
Reading all physical volumes.  This may take a while...</span></span>
Found volume group "example_vg" using metadata type lvm2</span></span>
</span>
[root@hydra blogpost]# vgdisplay example_vg</span></span>
--- Volume group ---</span></span>
VG Name               example_vg</span></span>
System ID</span></span>
Format                lvm2</span></span>
Metadata Areas        3</span></span>
Metadata Sequence No  1</span></span>
VG Access             read/write</span></span>
VG Status             resizable</span></span>
MAX LV                0</span></span>
Cur LV                0</span></span>
Open LV               0</span></span>
Max PV                0</span></span>
Cur PV                3</span></span>
Act PV                3</span></span>
VG Size               288.00 MiB</span></span>
PE Size               4.00 MiB</span></span>
Total PE              72</span></span>
Alloc PE / Size       0 / 0</span></span>
Free  PE / Size       72 / 288.00 MiB</span></span>
VG UUID</span></span>
G2YvoH-YwIn-VB8V-aC92-9XPC-Ykj0-2EYdCR</span></span></code></pre>Logical Volumes (LV)</h3>
As you can see, we have 288MB free space in our VG. This means that we can
create one LV with the size of 288MB. We can also create 288 LV's, each of size
of 1MB, but that won't be very practical. Let's create one LV, using all of
available space:</p>
[root@hydra blogpost]# lvcreate example_vg -L 288MB</span></span>
Logical volume "lvol0" created</span></span></code></pre>
Now we have a logical volume lvol0</code>, existing inside a volume group named
example_vg</code>, distributed across container*.bin</code> files. Here is our device:</p>
[root@hydra blogpost]# ls -la /dev/mapper/example_vg*</span></span>
lrwxrwxrwx 1 root root 7 11.11.2014 12:23 /dev/mapper/example_vg-lvol0 -> ../dm-3</span></span></code></pre>
As previously, we can create a filesystem on it. Let's try xfs</code>:</p>
[root@hydra blogpost]# mkfs.xfs /dev/mapper/example_vg-lvol0</span></span>
meta-data=/dev/mapper/example_vg-lvol0 isize=256    agcount=4, agsize=18432 blks</span></span>
         =                       sectsz=512   attr=2, projid32bit=1</span></span>
         =                       crc=0        finobt=0</span></span>
data     =                       bsize=4096   blocks=73728, imaxpct=25</span></span>
         =                       sunit=0      swidth=0 blks</span></span>
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0</span></span>
log      =internal log           bsize=4096   blocks=853, version=2</span></span>
         =                       sectsz=512   sunit=0 blks, lazy-count=1</span></span>
realtime =none                   extsz=4096   blocks=0, rtextents=0</span></span></code></pre>
We can also mount it:</p>
[root@hydra blogpost]# mkdir /tmp/x</span></span>
[root@hydra blogpost]# mount /dev/mapper/example_vg-lvol0 /tmp/x</span></span>
[root@hydra blogpost]# df -h /tmp/x</span></span>
Filesystem                    Size  Used Avail Use% Mounted on</span></span>
/dev/mapper/example_vg-lvol0  285M   15M  271M   6% /tmp/x</span></span></code></pre>
Now we can put files in /tmp/x</code>, we have 271MB free space!</p>
Resizing</h3>
Let's try resizing our virtual filesystem by additional 100MB. Here's what we need to do:</p>

Unmount it,</li>
Add a new PV to our VG,</li>
Resize our LV, increasing its size,</li>
Resize the filesystem on the LV.</li>
</ul>
Unmounting is easy:</p>
# unmount /tmp/x</span></span></code></pre>
Now let's create a new container file, and initialize a LUKS filter on it:</p>
[root@hydra blogpost]# dd if=/dev/zero of=container4.bin bs=1M count=100</span></span>
100+0 records in</span></span>
100+0 records out</span></span>
104857600 bytes (105 MB) copied, 0.0398605 s, 2.6 GB/s</span></span>
</span>
[root@hydra blogpost]# cryptsetup luksFormat container4.bin</span></span>
</span>
WARNING!</span></span>
========</span></span>
This will overwrite data on container4.bin irrevocably.</span></span>
</span>
Are you sure? (Type uppercase yes): YES</span></span>
Enter passphrase:</span></span>
Verify passphrase:</span></span>
</span>
[root@hydra blogpost]# cryptsetup luksOpen container4.bin container4</span></span>
Enter passphrase for container4.bin:</span></span></code></pre>
Then let's create a PV in the new container:</p>
[root@hydra blogpost]# pvcreate /dev/mapper/container4</span></span>
Physical volume "/dev/mapper/container4" successfully created</span></span></code></pre>
Then, let's add this PV into the pool of VG's physical volumes, so that our LV
can use it. We're performing this by using the vgextend</code> command:</p>
[root@hydra blogpost]# vgextend example_vg /dev/mapper/container4</span></span>
Volume group "example_vg" successfully extended</span></span>
</span>
[root@hydra blogpost]# vgdisplay example_vg</span></span>
--- Volume group ---</span></span>
VG Name               example_vg</span></span>
System ID</span></span>
Format                lvm2</span></span>
Metadata Areas        4</span></span>
Metadata Sequence No  3</span></span>
VG Access             read/write</span></span>
VG Status             resizable</span></span>
MAX LV                0</span></span>
Cur LV                1</span></span>
Open LV               1</span></span>
Max PV                0</span></span>
Cur PV                4</span></span>
Act PV                4</span></span>
VG Size               384.00 MiB</span></span>
PE Size               4.00 MiB</span></span>
Total PE              96</span></span>
Alloc PE / Size       72 / 288.00 MiB</span></span>
Free  PE / Size       24 / 96.00 MiB</span></span>
VG UUID</span></span>
G2YvoH-YwIn-VB8V-aC92-9XPC-Ykj0-2EYdCR</span></span></code></pre>
As you can see in the output of vgdisplay</code> command, our VG has a size of 384MB.
288MB of those are used by our LV. 96MB are free -- this is our fourth container
file, created and added just now.</p>
Now we can resize the LV, since we acquired some free space inside our VG. The
-l 100%VG</code> specifier describes the new size of the LV -- it means: '100% of
current VG', so it simply changes the LV to fill up 100% of its VG. Note that
there is no space between the percent character %</code> and VG</code>.</p>
[root@hydra blogpost]# lvextend /dev/example_vg/lvol0 -l 100%VG</span></span>
Size of logical volume example_vg/lvol0 changed from 288.00 MiB (72 extents) to 384.00 MiB (96 extents).</span></span>
Logical volume lvol0 successfully resized</span></span></code></pre>
So far so good. Now it's time to tell xfs</code> filesystem to make use of new free
space.</p>
[root@hydra blogpost]# xfs_growfs /dev/mapper/example_vg-lvol0</span></span>
meta-data=/dev/mapper/example_vg-lvol0 isize=256    agcount=4, agsize=18432 blks</span></span>
         =                       sectsz=512   attr=2, projid32bit=1</span></span>
         =                       crc=0        finobt=0</span></span>
data     =                       bsize=4096   blocks=73728, imaxpct=25</span></span>
         =                       sunit=0      swidth=0 blks</span></span>
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0</span></span>
log      =internal               bsize=4096   blocks=853, version=2</span></span>
         =                       sectsz=512   sunit=0 blks, lazy-count=1</span></span>
realtime =none                   extsz=4096   blocks=0, rtextents=0</span></span>
data blocks changed from 73728 to 98304</span></span></code></pre>
Let's try to mount the xfs</code> volume now, and see its new size:</p>
[root@hydra blogpost]# mount /dev/mapper/example_vg-lvol0 /tmp/x</span></span>
[root@hydra blogpost]# df -h /tmp/x</span></span>
Filesystem                    Size  Used Avail Use% Mounted on</span></span>
/dev/mapper/example_vg-lvol0  381M   20M  362M   6% /tmp/x</span></span></code></pre>
We have now 362MB of free space. Our volume has been resized by adding another
file into the LVM pool. Our work is done ;).</p>
Please note that xfs</code> doesn't support shrinking</em> the filesystem. So growing it
is a one-way trip! There may be other filesystems that support shrinking
operation though.</p>
Rebooting the system</h2>
How to mount the volume after rebooting the system? On modern Linux
distributions LVM should pick up all PVs and VGs that are appearing in the
system automatically. So all you need to do is to open LUKS containers:</p>
# cryptsetup luksOpen container{1,2,3,4}</span></span>
...</span></span></code></pre>
After luksOpen</code>'ing them all, you should have /dev/mapper/example_vg-lvol0</code>
already present on your system, ready to be mounted into the mountpoint you've
chosen.</p>



Control over symbol exports in GCC
2014-10-30T00:00:00+00:00
When dealing with creation of shared objects, one should keep in mind that the
longer is the list of their exported symbols, the longer time is taken by the
dynamic linker during the loading process.</p>
There is much information regarding the rules which should be followed when one
tries to create a shared object. There is a great paper written by the glibc</code>
maintainer, Ulrich Drepper, which covers most of the topics. You can find the
paper on your favourite search engine (try searching for "How to write shared
libraries by Ulrich Drepper").</p>
One of the important points is the restriction of exported symbols in a shared
object. When creating an ELF shared object (by convention, a file named as
lib*.so</code>), all symbols are marked as public, hence included in the object's
export symbol table. Obviously, existence of every symbol in the export table is
not optimal. Export table should be populated only by the API of the shared
object, because nobody every will (nobody ever should</em>) use any of the internal
structures, which the symbols are describing. Exported symbols are often
considered as an Application Binary Interface (ABI</code>), which should be
compatible between different library versions. Maintaining the ABI of an
internal structure effectively removes the possibility of any practical
modification.</p>
Normally, when you create a shared object on Linux, all of its symbols are
exported by default. Consider this example:</p>
#include</span> <iostream></span></span>
using namespace std;</span></span>
</span>
void</span> function1</span>() {</span></span>
	cout </span><<</span> "hi</span>\n</span>"</span>;</span></span>
}</span></span>
</span>
void</span> entry_point</span>() {</span></span>
	function1</span>();</span></span>
}</span></span></code></pre>
The example shows a shared object that contains an API function (that is a
function designed to be called from a different module, an entry point to the
shared library's functionality). This entry_point</code> API function uses a helper
function, function1</code> to perform some task. Let's compile this shared object:</p>
$ g++ code.cpp -o libcode.so -shared -fPIC</span></span></code></pre>
and let's glance at the export table:</p>
$ nm -CD libcode.so | grep " T "</span></span>
00000000000007c8 T entry_point()</span></span>
00000000000007ac T function1()</span></span>
0000000000000868 T _fini</span></span>
0000000000000668 T _init</span></span></code></pre>
We have 4 symbols insite the text</code> segment of libcode.so</code>. _fini</code> and _init</code>
are automalically added export symbols that relate to initialization and
finalization of the object. Two other symbols are ours. Our goal is to make a
shared library that will put entry_point</code> in the export table, and at the same
time leaving function1</code> from this table.</p>
There are two methods for doing this: by using the -fvisibility</code> option, and
linker (ld</code>) version script.</p>
Using `fvisibility' compiler option</h1>
The compiler flag -fvisibility=hidden</code> is designed for dealing with exactly
this kind of problems. By using this option, the user tells the compiler to
exclude all</em> of the symbols from the export table:</p>
$ g++ code.cpp -o libcode.so -shared -fPIC -fvisibility=hidden</span></span>
$ nm -CD libcode.so | grep " T "</span></span>
00000000000007e8 T _fini</span></span>
00000000000005f8 T _init</span></span></code></pre>
But, we want also to include the entry_point</code> function in the table, because
it's our API function. This is why we need to change the source code a little
bit:</p>
#include</span> <iostream></span></span>
using namespace std;</span></span>
</span>
void</span> function1</span>() {</span></span>
	cout </span><<</span> "hi</span>\n</span>"</span>;</span></span>
}</span></span>
</span>
__attribute__</span> ((</span>visibility</span> (</span>"default"</span>)))</span> void</span> entry_point</span>() {</span></span>
	function1</span>();</span></span>
}</span></span></code></pre>
After compilation, our goal is matched:</p>
$ g++ code.cpp -o libcode.so -shared -fPIC -fvisibility=hidden</span></span>
$ nm -CD libcode.so | grep " T "</span></span>
0000000000000778 T entry_point()</span></span>
0000000000000818 T _fini</span></span>
0000000000000628 T _init</span></span></code></pre>
The __attribute__ ((visibility ("default")))</code> is very similar to
__declspec(dllexport)</code> that can be found on Microsoft's compilers. In fact, GCC
should handle it as well. The attribute overrides the -fvisibility=hidden</code>
compiler option only for only one symbol, and makes it public. That's why it's
included in the export table.</p>
Static library used by a shared library problems</h2>
However, there is one problem with this approach. If our shared library is large
enough, it may use other libraries that are statically linked. Let's consider
another example.</p>
Let's suppose we have a static library, libutil.a</code>, that is statically linked
into our shared library, libcode.so</code>.</p>
Here is our util.cpp</code> file, that is the source of the static library:</p>
#include</span> <iostream></span></span>
using namespace std;</span></span>
</span>
void</span> util_function</span>() {</span></span>
	cout </span><<</span> "hello from util function</span>\n</span>"</span>;</span></span>
}</span></span></code></pre>
Let's compile it, and build a static library from this code:</p>
$ g++ util.cpp -o util.o -c -fPIC</span></span>
$ ar r libutil.a util.o</span></span></code></pre>
We have now libutil.a</code> static library which can be used in our shared object.
Let's modify the shared object to include a reference to the code of
libutil.a</code> (without it, libutil.a</code> would be dropped in the linking process):</p>
#include</span> <iostream></span></span>
using namespace std;</span></span>
</span>
extern void</span> util_function</span>();</span></span>
</span>
void</span> function1</span>() {</span></span>
	util_function</span>();</span></span>
	cout </span><<</span> "hi</span>\n</span>"</span>;</span></span>
}</span></span>
</span>
__attribute__</span> ((</span>visibility</span> (</span>"default"</span>)))</span> void</span> entry_point</span>() {</span></span>
	function1</span>();</span></span>
}</span></span></code></pre>
Let's compile our shared library and see its export table:</p>
$ g++ code.cpp libutil.a -o libcode.so -shared -fPIC -fvisibility=hidden</span></span>
$ nm -CD libcode.so | grep " T "</span></span>
00000000000007ed T entry_point()</span></span>
0000000000000858 T util_function()</span></span>
0000000000000918 T _fini</span></span>
0000000000000688 T _init</span></span></code></pre>
As you can see, util_function</code> is included in the list, but we don't want it
there. How to fix this?</p>
One solution is to add -fvisibility=hidden</code> to libutil.a</code> library's build
process, but sometimes we don't have the control over it. What then?</p>
Linker scripts to the rescue.</p>
Using `ld' linker version script</h1>
We need to get rid of the util_function</code> symbol during the linking process,
because we may not have any control over the compilation of libutil.a</code> library.</p>
Fortunately, ld</code> supports export table filtering (and much more) by using a
"version script", which will contain some definitions on what to include, and
what to skip. It even supports wildcards which also may help.</p>
So, let's skip the -fvisibility=hidden</code> option for now, and build our shared
library like this:</p>
$ g++ code.cpp libutil.a -o libcode.so -shared -fPIC</span></span></code></pre>
Then, create a text file, libcode.version</code>, with this content:</p>
CODEABI_1.0 {</span></span>
	global: *entry_point*;</span></span>
	local: *;</span></span>
};</span></span></code></pre>
This version file tells the linker, that all symbols (*</code>) should be considered
as local</em> symbols (that is: hidden), and all symbols that match the wildcard
*entry_point*</code> should be considered as global</em> (so, visible).</p>
Compilation is done by the g++</code> driver:</p>
$ g++ code.cpp libutil.a -o shared -fPIC -Wl,--version-script=libcode.version</span></span></code></pre>
Verification:</p>
$ nm -CD libcode.so | grep " T "</span></span>
000000000000074d T entry_point()</span></span></code></pre>
It even stripped out the _init</code> and _fini</code> symbols. Job done!</p>
The problem with this approach is that it can't handle some more complicated
scenarios, like filtering only some symbols that are using C++ templates. Some
of the template-based symbols in C++ can easily grow up to few hundred
characters, but you probably know what I mean. Once you start using functions
from std::</code>, you'll know</em>.</p>
Please do some reading about the linker's version scripts, because it allows you
to perform some really cool things, like symbol versioning!</p>


Sending ATA commands on Linux
2014-09-12T00:00:00+00:00
It appears that any user can send an ATA message on Linux. The function that
allows this is called ioctl</code>, by using message identifier 0x31F</code>
(HDIO_DRIVE_CMD</code>).</p>
It is possible to send, i.e. ATA IDENTIFY</code> message by using 0xEC</code> message.
This command should return a device identification information. Other status
indication message is implemented by the 0xA1</code> message, but the device needs to
properly implement PACKET extensions, so it needs to be an ATAPI device.</p>
#include</span> <iostream></span></span>
#include</span> <fcntl.h></span></span>
#include</span> <unistd.h></span></span>
#include</span> <errno.h></span></span>
#include</span> <string.h></span></span>
#include</span> <stdlib.h></span></span>
#include</span> <stdio.h></span></span>
#include</span> <stdint.h></span></span>
#include</span> <sys/ioctl.h></span></span>
</span>
using namespace std;</span></span>
</span>
int</span> main</span>(</span>void</span>) {</span></span>
	int</span> fd </span>=</span> ::open</span>(</span>"/dev/sda"</span>, O_RDONLY </span>|</span> O_DIRECT);</span></span>
	if</span>(fd </span>!= -</span>1</span>) {</span></span>
		uint8_t</span> buf</span>[</span>512</span>]</span> =</span> {</span> 0x</span>EC</span>,</span> 0</span>,</span> 0</span>,</span> 1</span>,</span> 0</span> };</span></span>
		int</span> ret </span>=</span> ::ioctl</span>(fd,</span> 0x</span>31F</span>, buf);</span></span>
</span>
		for</span>(</span>int</span> i </span>=</span> 0</span>; i </span><</span> 512</span>;</span> ++</span>i) {</span></span>
			::putchar</span>(</span>buf</span>[i]);</span></span>
		}</span></span>
	}</span> else</span> {</span></span>
		::perror</span>(</span>"open"</span>);</span></span>
	}</span></span>
</span>
	::close</span>(fd);</span></span>
	return</span> 0</span>;</span></span>
}</span></span></code></pre>
The data you'll get will be encoded in big endian notation, so you need to fix
this by using necessary shifts and bswaps.</p>
</p>



Fixing ugly Java fonts
2014-09-08T00:00:00+00:00
Today I got an e-mail from Jetbrains about the release of their new Integrated Development
Environment called CLion ("SeaLion"). Being a curious creature I decided to
check it out by using the Early Access Program which is open to public. After
running the IDE, my biggest problem was the font rendering, which can be seen on
this screenshot (click to see the full size):</p>
</a></p>
Swing and Java are nice in theory, but in practice they're often not so nice. CLion is
not an exception. Fortunately, some shortcomings can be fixed pretty easily.</p>
To fix the font issue, just force Java's awt.useSystemAAFontSettings</code> setting
to on</code>. You can do this in many different ways, but I decided to use
$_JAVA_OPTIONS</code> variable in my shell's startup script, .zshrc</code>. For bash</code>,
the method is almost identical, you just have to put your settings inside
.bashrc</code> (but you already knew that).</p>
export</span> _JAVA_OPTIONS</span>=</span>"-Dawt.useSystemAAFontSettings=on"</span></span></code></pre>
After this modification, CLion started to look more friendly:</p>
</a></p>
Still not as good as in my Vim in the terminal window, but close enough!</p>
The IDE itself is also quite nice. Slow speed can be irritating, but it's
bearable, provided the product is good.</p>



Enabling core dumps on Linux
2014-08-16T00:00:00+00:00
When creating a Linux application in a native language, such as C or
C++, it's obvious that eventually a bug will appear. Some are easy to
fix, but sometimes they're not. Normally you could just run gdb</code> to
figure out how to fix it, but what about a situation when the program
runs smoothly under gdb</code>, but crashes when running without any
debugger?</p>
There is one feature that can be used to troubleshoot the problem, and
its name is: core dumps</em>.</p>
A core dump is a special file that is created when the process
crashes. It's stored in binary format, but with tools like gdb</code> it's
not hard to analyze it. In fact, you don't need to analyze it at all
-- it simply stores the current crashed environment of the process in
such a way, that gdb</code> can be used normally, like in every other
debugging session. The only difference is that you won't be able to
execute anything from such crashed process.</p>
You can enable core dump file generation by using the ulimit</code> command:</p>
$ ulimit -c unlimited</span></span></code></pre>
This will enable core dump generation for crashed applications invoked
from the current shell</em>:</p>
$ ./crash</span></span>
Segmentation fault</span></span>
</span>
$ ls core*</span></span>
core.2123</span></span></code></pre>
2123</code> is the process id</em> of the crashed application. You can load
this core dump to gdb</code> by providing its name in the argument list for
gdb</code>:</p>
$ gdb crash core.2123</span></span></code></pre>
Gdb</code> will notify about loading the file with messages like:</p>
$ gdb crash core.2123</span></span>
....</span></span>
Core was generated by `./crash'.</span></span>
....</span></span></code></pre>
You can use standard bt</code> command to build the offending stacktrace:</p>
(gdb) bt</span></span>
#0  0x00007f8955ba4d67 in raise () from /usr/lib/libc.so.6</span></span>
#1  0x00007f8955ba6118 in abort () from /usr/lib/libc.so.6</span></span>
#2  0x00007f8955be4f93 in __libc_message () from /usr/lib/libc.so.6</span></span>
#3  0x00007f8955bea88e in malloc_printerr () from /usr/lib/libc.so.6</span></span>
#4  0x00007f8955beb04b in _int_free () from /usr/lib/libc.so.6</span></span>
#5  0x00007f89564fdacc in std::string::assign(std::string const&) () from /usr/lib/libstdc++.so.6</span></span>
#6  0x000000000044b551 in DataVisualizer::setCaptionText (this=0x1b831f0, s="ls") at /home/antek/workspace/mdhexedit/lib/plugins/interfaces/DataVisualizer.h:24</span></span>
#7  0x0000000000448eda in MainInstance::getFileContextForNewFile (this=0x1aea058, captionText="ls") at ../src/ui/MainInstance.cpp:138</span></span>
#8  0x0000000000432bb6 in FileMenu::loadFile (this=0x1af4e00, fileName="/bin/ls") at ../src/ui/menus/FileMenu.cpp:78</span></span></code></pre>
Way better than printf-debugging, don't you think?</p>
I did everything from above, and I'm still not getting any coredumps!</h2>
Are you using systemd</code>? It probably depends on the distribution, but sometimes
systemd</code> eats all the coredumps and stores them inside its own journal.</p>
You can test if this is the case for your system by issuing a simple command:</p>
$ coredumpctl</span></span></code></pre>
For example, on my home system, the output of coredumpctl</code> looks something like
this:</p>
pon 2014-06-30 20:21:59 CEST   6705  1000   100  11 /personal/antek/.local/share/Steam/SteamApps/common/dota 2 beta/dota_linux</span></span>
wto 2014-07-01 15:49:17 CEST   1660     0     0   6 /usr/bin/python3.4</span></span>
wto 2014-07-01 21:50:30 CEST  18408  1000   100   6 /home/antek/.local/share/Steam/SteamApps/common/Sid Meier's Civilization V/Civ5XP</span></span>
śro 2014-07-02 15:38:49 CEST   1422     0     0   6 /usr/bin/python3.4</span></span>
czw 2014-07-03 10:05:46 CEST   1410     0     0   6 /usr/bin/python3.4</span></span>
czw 2014-07-03 12:06:45 CEST   2515  1000   100  11 /home/antek/dev/mtf/mtf</span></span>
czw 2014-07-03 12:07:15 CEST   2538  1000   100  11 /home/antek/dev/mtf/mtf</span></span></code></pre>
You can extract the coredump you're interested in by using coredumpctl</code>. For
example, to extract the crash from 2014-07-03 12:07:15, you can simply invoke:</p>
$ coredumpctl dump 2538 -o core.out</span></span></code></pre>
This will dump this coredump directly into the core.out</code> file. But, consider
using the coredumpctl gdb</code> command as well.</p>



New GCC on an old Linux distribution
2014-08-05T00:00:00+00:00
Sometimes you need to have a new version of gcc</code> (i.e. to be able to leverage
the features from C++11</code> standard), but you have an old distribution which
doesn't have new gcc</code> inside its repository. Here's how you can compile your
own gcc</code> on that distribution.</p>
Acquire gcc tarball</h2>
First you need to download the main gcc</code> tarball from the official gcc</code>
website</a>:</p>
$ wget ftp://gd.tuwien.ac.at/gnu/gcc/releases/gcc-4.9.0/gcc-4.9.0.tar.bz2</span></span></code></pre>
After downloading, unpack the archive to some directory. Make sure you'll have
enough space to compile the whole package though. I don't remember exactly how
much space it will take, but it's safe to assume that it will take a lot</em>.</p>
If you're installing it on a virtual machine (I did), maybe it's a good idea to
use some kind of networked file system solution, like NFS</code>, or at last Samba</code>
(sshfs</code> should also work). This way you would host all of the temporary object
files on you host machine, which probably has lots of gigabytes of free space,
ready to be used (right?).</p>
$ tar xfj gcc-*.tar.bz2</span></span></code></pre>
This will unpack the package to the current directory. For the purposes of this
post, I'll assume this directory will be named /srv/vm</code>.</p>
Acquire prerequisites</h2>
Next, you'll need some thirdparty libraries required by gcc</code>.</p>
1. GMP</h4>
GMP</code> (GNU Multiple Precision Library) - website</a>. Unpack it with:</p>
$ tar xfj gmp-*.tar.bz2</span></span></code></pre>
Then create symbolic link of newly created directory to the gmp</code> directory,
like this:</p>
$ ln -sf gmp-6.0.0 gmp</span></span></code></pre>
It should result in having the directory placed in /srv/vm/gcc-4.9.0/gmp</code>.</p>
This way the build system of gcc</code> should handle building this library together with gcc</code> itself.</p>
2. MPFR</h4>
MPFR</code> (Multiple-Precision Floating-point computations with correct Rounding) -
website</a>. Unpack it, and create a symbolic link of its
directory to the mpfr</code> directory.</p>
3. MPC</h4>
MPC</code> (expansion over MPFR</code> if I understand it correctly) -
website</a>. Unpack it, and create a symbolic
link of its directory to the mpc</code> directory.</p>
4. ISL</h4>
ISL</code> (Integer Set Library) - website</a>. Unpack
it, and create a symbolic link of its directory to the isl</code> directory.</p>
If you're getting some compilation errors related to isl_int</code>, use an older
version of the library, before 0.13</code>. The 0.13</code> version removes the
isl_int</code> symbol, so this major update could be too major</em> for other
libraries (like CLooG). The version that worked for me is 0.12.2</code>.</p>
If you do need to change the version of the ISL</code> library, make sure you'll
clean the current configuration cache, created after running configure</code>
script. Best way is to remove the whole source directory and recreate it from
scratch. Oh, maybe make distclean</code> will help too.</p>
5. CLooG</h4>
CLooG</code> (Chunky LOOp Generator) - website</a>. Unpack it, and
create a symbolic link of its directory to the cloog</code> directory.</p>
Of course, you will also need standard combo in the form of autotools</code>, older
version of the compiler, but that's pretty obvious, so I'll just skip it.</p>
Compilation</h2>
After installing the dependencies, next step is pretty straightforward:</p>
$ ./configure --disable-multilib --prefix=/usr/local/gcc49 --enable-threads --enable-languages=c,c++</span></span>
$ make</span></span></code></pre>
It is probably OK to get some errors, as long they're not stopping the build
process. Please note that this process will</em> take a long time, so you'll have
to plan it ahead.</p>
If you're trying to compile it through an ssh</code> connection, I suggest you use
a terminal detaching tool like screen</code> or tmux</code>, so you'll be able to close
the connection without interrupting the build.</p>
To finish the process, don't forget to make install</code>. Your new gcc will be
installed to /usr/local/gcc49</code>.</p>
Please note that you may need to use -static-libstdc++</code> and
-static-libgcc</code> options when linking your executable file! See the
proper documentation of gcc</code> to read more about characteristics of
these options.</p>



Defeating NAT with reverse SSH proxies
2014-07-07T00:00:00+00:00
Having a public IP is not as popular as 10 years ago. In earlier days the user
could pay extra cash for this useful service, but now it's often an option that is
simply not for sale. Is it possible to access your home network, when this
network sits behind countless NAT layers?</p>
Short answer is yes</em>, but you need to control an external server with public IP
capability, preferably with a fast network connection. You could use some kind
of a personal VPS, which are not as expensive as they were few years ago.</p>
Let's assume that you have a remote host R</code>, a home network H</code>, and a computer
at work W</code>, from which you'd like to connect to the home network H</code>, to start
the download of latest episode of Game of Thrones</em>, so it'll be ready when
you'll get home. ;) Of course I'm assuming that H</code> and R</code> are running Linux
(or a different, a posix-ly unix-ish, variant). On Windows you may get away with
downloading some binaries like ssh.exe</code>, but I haven't got a chance of testing
this approach.</p>
Theory</h2>
The plan is:</p>


Running the ssh</code> command from H</code>, that connects to R</code>, to port 22</code>,
specifying the remote proxy port 19500</code> (it's an arbitrary number, choose
another if you'd like).</p>
</li>

Then, with this connection active, you can connect from W</code> to R</code> to port
19500</code>. ssh</code> on the R</code> will forward any packet sent to port 19500</code> to H</code>
automatically.</p>
</li>
</ol>
</p>
This will result in having a connection initiated by W</code> to the home network
H</code>, with R</code> machine serving as a proxy. It may be not what you want if you
want to play games, but for remote administation it works OK.</p>
Practice</h2>
For example purposes, let's use a host with the name
yourproxy.externalvps.com</strong>, which uses port 19500.</p>
They say that the commandline is worth a thousand images</em>, so:</p>
# STEP 1</span></span>
[H]OME home $ ssh -R 19500:localhost:22 yourproxy.externalvps.com</span></span>
[H]OME Enter ssh password: (</span>...</span>)</span></span>
</span>
# STEP 2</span></span>
[W]ORK work $ ssh yourproxy.externalvps.com</span></span>
[W]ORK Enter ssh password: (</span>...</span>)</span></span>
[W]ORK yourproxy $ ssh localhost -p 19500</span></span>
[W]ORK Enter ssh password: (</span>...</span>)</span></span>
[W]ORK home $ _</span></span></code></pre>Automatization</h2>
You can use public key authentication</em> to disable the password-based
protection. First, generate your public key for H</code> machine by using ssh-keygen</code>:</p>
[H]OME $ ssh-keygen -t rsa</span></span>
[H]OME ...</span></span></code></pre>
Then, copy the ~/.ssh/id_rsa.pub</code> file to the R</code> host, and append it to its
~/.ssh/authorized_keys</code> file:</p>
[R]EMOTE $ cat id_rsa-home.pub </span>>> ~</span>/.ssh/authorized_keys</span></span></code></pre>
WARNING</em>: make sure you're using >></code>, not ></code>!</p>
You should now be able to perform step 1</em> without entering the password to
yourproxy.externalvps.com</code>. This should suit automated scripts, invoked at
system startup, or periodically from your WAN router!</p>
Router setup</h2>
Every router is different, but most of them contain the BusyBox</code> binary, along
with the dropbear</code> ssh server & client. One thing to note is that dropbear</code>
expects the private key to be stored in its private dropbear format, so you need
to create the private key by using dropbearkey</code> instead of ssh-keygen</code>:</p>
router</span> $</span> dropbearkey</span> -t</span> rsa</span> -f</span> id_rsa.dropbear</span></span>
# dropbearkey -t rsa -f example</span></span>
Will</span> output</span> 1024</span> bit rsa secret key to 'id_rsa.dropbear'</span></span>
Generating</span> key, this may take a while...</span></span>
Public</span> key portion is:</span></span>
ssh-rsa</span> AAAAB3NzaC1yc2EAAAADAQABAAAAgwCh2w0Xv/5n7XldpdHo3XQ5VPKZbybsfVUGnYK9uwK294A4Y/R8IzSw8vuwZ+Ld9X+N7eQ7aN2H2Ez/3TYGHMHoCWnEFhNHmsxJ3LQCtsNm9fBOl58YoE4xGnZHQ1Ig3E2ee/j8Xi2tcKdrzE+hKQcoQ0FR2A+HqkUy7Z6TjCd3nIvH</span></span>
root@router</span></span>
Fingerprint:</span> md5 be:5f:34:27:a0:4c:9f:20:f9:bc:7b:f1:f9:19:85:d7</span></span></code></pre>
You need to append the line below Public key portion is:</code> to the
authorized_keys</code> file on the R</code> host. Then, by using this commandline from the
router:</p>
ssh</span> -R</span> 19500:localhost:22</span> -N -i</span> /jffs/id_rsa.dropbear user@yourproxy.externalvps.com</span></span></code></pre>
you will be able to create a step 1</em> reverse proxy connection from your router
to the R</code> host.</p>
After creating the connection from W</code> to yourproxy.externalvps.com</code>'s port 19500</code> (but
remember, you need to connect to it through localhost</code>), you will connect to
your router. From your router, it should be easy to access your box by just
ssh</code>'ing on it.</p>
Of course, you can also go even further than that:</p>
</p>
In Tomato</code> firmware, you can create a script that will be executed on startup.
/jffs</code> partition can be setup to persist between router restarts, so you can
put your scripts there. Consult the documentation if you want to know more about
both the /jffs</code> partition and this particular Tomato administration option.</p>


PCI device enumeration using ports 0xCF8, 0xCFC
2014-07-02T00:00:00+00:00
This is how you can enumerate your PCI devices by using ports 0xCF8</code> and
0xCFC</code>. Please note that this code is intended to run from the privileged mode
(ring 0</code>), thus it's compiled as a kernel module for Linux.</p>
The PCI specification can be downloaded from here</a> (or, alternatively, you
can search here</a> if the previous link is no longer working).</p>
The example below will read the uint32_t</code> from the address of 0</code> (which is the
last argument of the r_pci_32</code> function) of this structure:</p>
</p>
This is the PCI Configuration Space structure, which holds basic information
about the PCI device.</p>
Here is the source code of the module:</p>
#include</span> <linux/kernel.h></span></span>
#include</span> <linux/init.h></span></span>
#include</span> <linux/module.h></span></span>
#include</span> <asm/io.h></span></span>
</span>
const</span> u32 PCI_ENABLE_BIT     </span>= 0x</span>80000000</span>;</span></span>
const</span> u32 PCI_CONFIG_ADDRESS </span>= 0x</span>CF8</span>;</span></span>
const</span> u32 PCI_CONFIG_DATA    </span>= 0x</span>CFC</span>;</span></span>
</span>
// func - 0-7</span></span>
// slot - 0-31</span></span>
// bus - 0-255</span></span>
u32 </span>r_pci_32</span>(u8 </span>bus</span>, u8 </span>device</span>, u8 </span>func</span>, u8 </span>pcireg</span>) {</span></span>
        // unsigned long flags;</span></span>
        // local_irq_save(flags)</span></span>
</span>
        outl</span>(PCI_ENABLE_BIT </span>|</span> (bus </span><<</span> 16</span>)</span> |</span> (device </span><<</span> 11</span>)</span> |</span> (func </span><<</span> 8</span>)</span> |</span> (pcireg </span><<</span> 2</span>), PCI_CONFIG_ADDRESS);</span></span>
        u32 ret </span>=</span> inl</span>(PCI_CONFIG_DATA);</span></span>
</span>
        // local_irq_restore(flags);</span></span>
        return</span> ret;</span></span>
}</span></span>
</span>
static</span> __init </span>int</span> init_pcilist</span>(</span>void</span>) {</span></span>
        u8 bus, device, func;</span></span>
        u32 data;</span></span>
</span>
        for</span>(bus </span>=</span> 0</span>; bus </span>!= 0x</span>ff</span>; bus</span>++</span>) {</span></span>
                for</span>(device </span>=</span> 0</span>; device </span><</span> 32</span>; device</span>++</span>) {</span></span>
                        for</span>(func </span>=</span> 0</span>; func </span><</span> 8</span>; func</span>++</span>) {</span></span>
                                data </span>=</span> r_pci_32</span>(bus, device, func,</span> 0</span>);</span></span>
</span>
                                if</span>(data </span>!= 0x</span>ffffffff</span>) {</span></span>
                                        printk</span>(KERN_INFO </span>"bus </span>%d</span>, device </span>%d</span>, func </span>%d</span>: vendor=0x</span>%08x\n</span>"</span>, bus, device, func, data);</span></span>
                                }</span></span>
                        }</span></span>
                }</span></span>
        }</span></span>
        return</span> 0</span>;</span></span>
}</span></span>
</span>
static</span> __exit </span>void</span> exit_pcilist</span>(</span>void</span>) {</span></span>
        return</span>;</span></span>
}</span></span>
</span>
module_init</span>(init_pcilist);</span></span>
module_exit</span>(exit_pcilist);</span></span></code></pre>
This code is not adapted for production code, because if suffers from race
conditions. It doesn't lock the access to the ports, so the risk of using it is
that you will end up with some device in unspecified state. In a controlled,
home environment (virtual machine) it works quite nicely though.</p>
The locking part could be probably implemented by using:</p>
raw_spin_lock_irqsave</span>(</span>&</span> pci_config</span>, lock, ...);</span></span></code></pre>
It should also temporarily disable interrupts. You could probably also lock the
access by using request_region</code>. But, instead of directly reading those ports
by outl</code> and inl</code>, it's better to use Linux' mechanism of reading PCI data,
which lives insite the pci_bus</code> object in the ops</code> field. More information
about this mechanism can be found inside the arch/x86/pci/direct.c</code> file.</p>


D-Bus, UDisks and Glibmm bindings
2014-07-01T00:00:00+00:00
One day I was having a problem with simple D-Bus concept. I was using Glibmm
D-Bus bindings (Gio::DBus</code> namespace) to access the UDisks</code> interface. I
wanted to read some attributes of every hard disk found in the system, so first
I needed to enumerate all disks that UDisks</code> was reporting, like this:</p>
Glib</span>::RefPtr</span><</span>Gio</span>::</span>DBus</span>::Connection</span>></span> bus;</span></span>
</span>
int</span> main</span>() {</span></span>
    using namespace</span> Glib</span>;</span></span>
    using namespace</span> Gio</span>;</span></span>
</span>
    Glib</span>::</span>init</span>();</span></span>
    Gio</span>::</span>init</span>();</span></span>
</span>
    bus </span>=</span> DBus</span>::</span>Connection</span>::</span>get_sync</span>(</span>Gio</span>::</span>DBus</span>::BUS_TYPE_SYSTEM);</span></span>
    RefPtr</span><</span>DBus</span>::Proxy</span>></span> udisks_proxy </span>=</span> DBus</span>::</span>Proxy</span>::</span>create_sync</span>(bus,</span> "org.freedesktop.UDisks"</span>,</span> "/org/freedesktop/UDisks"</span>,</span> "org.freedesktop.UDisks"</span>);</span></span>
</span>
    VariantContainerBase devices_variant </span>=</span> udisks_proxy-></span>call_sync</span>(</span>"EnumerateDevices"</span>);</span></span>
    VariantIter</span> iterator</span>(devices_variant.</span>get_child</span>(</span>0</span>));</span></span>
</span>
    Variant</span><</span>ustring</span>></span> var;</span></span>
    while</span>(iterator.</span>next_value</span>(var)) {</span></span>
        ustring name </span>=</span> var.</span>get</span>();</span></span>
</span>
        LOG</span>(</span>"device: '</span>%s</span>"</span>, name.</span>c_str</span>());</span></span>
        process_device</span>(name);</span></span>
    }</span></span>
</span>
    return</span> 0</span>;</span></span>
}</span></span></code></pre>
This seemed to work OK, because call_sync()</code> returned a VariantContainerBase</code>,
which holds the (ao)</code> object, which basically is: one struct of an array of
object paths</em>. From the documentation I read that the object path</em> type is
handled in the same way as a string</em> type, that's why the untyped VariantBase</code>
that is created during get_child(0)</code> allows itself to be casted into
Variant<ustring></code> object. Using this parametrized Variant</code>, it's trivial to
extract the string by using var.get()</code>.</p>
But then I was trying to read some stuff (in that particular case, the
NativePath</code> attribute) from the attributes of each drive using this method:</p>
void</span> process_device</span>(</span>const</span> Glib</span>::</span>ustring</span>&</span> objpath</span>) {</span></span>
	using namespace</span> Glib</span>;</span></span>
	using namespace</span> Gio</span>;</span></span>
</span>
	RefPtr</span><</span>DBus</span>::Proxy</span>></span> attrs </span>=</span> DBus</span>::</span>Proxy</span>::</span>create_sync</span>(bus,</span> "org.freedesktop.UDisks"</span>, objpath,</span> "org.freedesktop.DBus.Properties"</span>);</span></span>
</span>
	std</span>::vector</span><</span>VariantBase</span>></span> args;</span></span>
	args.</span>push_back</span>(</span>Variant</span><</span>ustring</span>>::</span>create</span>(objpath));</span></span>
	args.</span>push_back</span>(</span>Variant</span><</span>ustring</span>>::</span>create</span>(</span>"NativePath"</span>));</span></span>
	VariantContainerBase data </span>=</span> attrs-></span>call_sync</span>(</span>"Get"</span>,</span> VariantContainerBase</span>::</span>create_tuple</span>(args));</span></span>
</span>
	LOG</span>(</span>"return type: </span>%s</span>"</span>, data.</span>get_type_string</span>().</span>c_str</span>());</span></span>
}</span></span></code></pre>
The problem was that the VariantContainerBase</code> object contained the (v)</code>
signature. This means that the object is variant</em>, so I couldn't cast it to
anything.</p>
Introspection of the attributes showed that NativePath</code> was holding a string</em>
value. So why the call_sync()</code> method was returning an object of a variant
type? How the NativePath</code> attribute could be read, without using get_data()</code>
method and without doing memcpy</code> of the data into manually allocated buffer?</p>
The solution would suggest that probably it was a bug in glibmm</code>'s bindings.</p>
Instead of calling VariantContainerBase</code>'s get_child(0)</code>, a proper way is to
call a direct glib</code> function: g_variant_get_child()</code>, like this:</p>
GVariant </span>*</span>output;</span></span>
g_variant_get_child</span>(data.</span>gobj</span>(),</span> 0</span>,</span> "v"</span>,</span> &</span> output</span>);</span></span></code></pre>
It will properly set the output</code>'s variant type to one that's insive v</code> (in my
case it will set the type of output</code> to s</code>). After this, when I got the remote
data in the s</code> type, I could cast it to Variant<ustring></code> type like this:</p>
Variant</span><</span>Glib</span>::</span>ustring</span>></span> item</span>(</span>output</span>);</span></span>
Glib</span>::ustring text </span>=</span> item.</span>get</span>();</span></span></code></pre>
since, fortunately, Variant</code>'s constructor accepts the old, glib-ish GVariant *</code> type.</p>
I'm still not sure whether it was a bug, or a feature.</p>


Friendly GDB
2013-07-11T00:00:00+00:00
The gdb</code> debugger is a very old application, used widely in the past, when a
computer was not yet a part of every house's inventory. Contrary to what many
people say, it's very usable even today, mainly because of its extensibility,
which lets the user to adapt it to his/hers specific needs.</p>
It's quite easy to add custom renderers</em> to gdb</code>. They are a piece of code
that convert data types into human readable form, so it's easy to understand
given type by just looking at the data dump.</p>
Here is an example data dump of the QString</code> structure (it's a container for
strings in the Qt Framework), created by using the print</code> command:</p>
</p>
As you can see, you can't see much ;). Maybe this kind of information is useful
for a Qt developer, which is debugging the functionality of QString</code> structure,
but our case is completely different. The solution for this problem is to tell
gdb</code> what kind of information we seek and make it display only these fields
which match our interest.</p>
The first step is to acquire the Qt renderer pack</a>. You can get it from i.e. KDevelop's
repository. It was written by Niko Sams, and it definitely does the job well. We
have to use the qt4.py</code> file, which contains the code to convert raw structure
dump into more eye-friendly notation. As you can also probably see, the same
directory in the repository also contains another file named libstdcxx.py</code>
which does the same thing for classes from std</code> library (standard C++ library),
like std::string</code>, std::map</code>, and others. These files can be copied into any
directory. For example, here seems to be a good spot for it:
/usr/share/gdb/auto-load/usr/lib</code>.</p>
Step two is to create the ~/.gdbinit</code> file. It will be automatically loaded
during every invocation of gdb</code>. Here's what you can put into it:</p>
python</span></span>
import</span> sys</span></span>
</span>
sys.path.insert(</span>0</span>,</span> '/usr/share/gdb/auto-load/usr/lib'</span>)</span></span>
from</span> qt4</span> import</span> register_qt4_printers</span></span>
from</span> libstdcxx</span> import</span> register_libstdcxx_printers</span></span>
register_qt4_printers(</span>None</span>)</span></span>
register_libstdcxx_printers(</span>None</span>)</span></span>
end</span></span>
</span>
set</span> auto</span>-</span>load local</span>-</span>gdbinit on</span></span>
set print</span> pretty</span> 1</span></span>
set</span> auto</span>-</span>load safe</span>-</span>path</span> /</span>usr</span>/</span>share</span>/</span>gdb</span>/</span>auto</span>-</span>load</span></span></code></pre>
If you'll get errors after invoking gdb</code>, you may want to check if:</p>

Your path is correct, contains both .py</code> files (qt4.py</code> and libstdcxx.py</code>),</li>
The python interpreter is correctly configured (is it v2.7? or maybe v3.0?),</li>
You can also review your security settings related to initialization script path
whitelisting ({SafePath}[related link]).</li>
</ol>
If no errors will occur, the next time you will use print</code> command on a
supported data type, it will display something that is more friendly than ever
before:</p>
</p>
Much better! Other examples:</p>
Example 1</h2>
Without printers:</p>
(gdb) p strings</span></span>
$1 = {</span></span>
  _M_t = {</span></span>
    _M_impl = {</span></span>
      <std::allocator<std::_Rb_tree_node<std::pair<QString const, int> > >> = {</span></span>
        <__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<QString const, int> > >> = {<No data fields>}, <No data fields>},</span></span>
      members of std::_Rb_tree<QString, std::pair<QString const, int>, std::_Select1st<std::pair<QString const, int> >, std::less<QString>, std::allocator<std::pair<QString const, int> > >::_Rb_tree_impl<std::less<QString>, false>:</span></span>
      _M_key_compare = {</span></span>
        <std::binary_function<QString, QString, bool>> = {<No data fields>}, <No data fields>},</span></span>
      _M_header = {</span></span>
        _M_color = std::_S_red,</span></span>
        _M_parent = 0x6040c0,</span></span>
        _M_left = 0x604050,</span></span>
        _M_right = 0x604140</span></span>
      },</span></span>
      _M_node_count = 3</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
With printers:</p>
(gdb) p strings</span></span>
$1 = std::map with 3 elements = {</span></span>
  ["hello world"] = 1,</span></span>
  ["test"] = 2,</span></span>
  ["test2"] = 3</span></span>
}</span></span></code></pre>Example 2</h2>
Without printers:</p>
(gdb) p v</span></span>
$1 = {</span></span>
  <std::_Vector_base<int, std::allocator<int> >> = {</span></span>
    _M_impl = {</span></span>
      <std::allocator<int>> = {</span></span>
        <__gnu_cxx::new_allocator<int>> = {<No data fields>}, <No data fields>},</span></span>
      members of std::_Vector_base<int, std::allocator<int> >::_Vector_impl:</span></span>
      _M_start = 0x6051c0,</span></span>
      _M_finish = 0x6051cc,</span></span>
      _M_end_of_storage = 0x6051d0</span></span>
    }</span></span>
  }, <No data fields>}</span></span></code></pre>
With printers:</p>
(gdb) p v</span></span>
$1 = std::vector of length 3, capacity 4 = {1, 2, 3}</span></span></code></pre>Example 3</h2>
Without printers:</p>
(gdb) p strmap</span></span>
$1 = {</span></span>
  {</span></span>
    d = 0x6061f0,</span></span>
    e = 0x6061f0</span></span>
  }</span></span>
}</span></span></code></pre>
With printers:</p>
(gdb) p strmap</span></span>
$1 = QMap<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >> = {</span></span>
  ["a"] = "b",</span></span>
  ["b"] = "c",</span></span>
  ["c"] = "d"</span></span>
}</span></span></code></pre>Conclusion</h2>
Okay, the last part could be better (more condensed), but having the access to
the source code you can just fix it for yourself. And still it's better than the
un-friendly version!</p>


Accessing libvirt's virtual machines from a script
2013-01-19T00:00:00+00:00
Everyone who has ever used the libvirt</code> library probably knows that it's
impossible to use it from scripts without previous authorization in the polkit</code>
daemon.</p>
This complicates things when the user would like to create a script to control
some virtual machines. The script that is probably configured to be invoked
periodically is running from the context of normal user. Popping up the polkit</code>
messagebox which requires to enter authorization credentials at every execution
of this script is probably not what most people would like to have.</p>
</p>
This problem can be fixed by creating two polkit rules. There is however some
confusion about the format of the files which hold the rules.</p>
Until polkit</code> version 106</code> it was possible to create the pkla</code> descriptor
(polkit local authority</em> file), which was a simple .ini</code> file. It was possible
to put the rules in there, by using the simple INI</code> file format. However, since
version 106</code>, it's not possible</a> anymore, because this version forces the use of
JavaScript language to create new polkit</code> rules. All of your existing rules you
have written until now are expired, and need to be rewritten to the new
JavaScript syntax.</p>
To allow authorization of the libvirt</code> library in polkit</code>, taking as an
example the virt-manager</code> frontend application, you need to find the proper
action of libvirt</code> 's polkit rule provider. You can find it by using the
pkaction</code> command:</p>
(</span>2:504</span>)</span>$</span> for i in `</span>pkaction</span> |</span> grep</span> libvirt`</span>;</span> do</span> pkaction</span> --action-id</span> $i</span> --verbose</span>;</span> done</span></span>
org.libvirt.unix.manage:</span></span>
  description:</span>       Manage local virtualized systems</span></span>
  message:</span>           System policy prevents management of local virtualized systems</span></span>
  vendor:</span></span>
  vendor_url:</span></span>
  icon:</span></span>
  implicit</span> any:      auth_admin_keep</span></span>
  implicit</span> inactive: auth_admin_keep</span></span>
  implicit</span> active:   auth_admin_keep</span></span>
</span>
org.libvirt.unix.monitor:</span></span>
  description:</span>       Monitor local virtualized systems</span></span>
  message:</span>           System policy prevents monitoring of local virtualized systems</span></span>
  vendor:</span></span>
  vendor_url:</span></span>
  icon:</span></span>
  implicit</span> any:      yes</span></span>
  implicit</span> inactive: yes</span></span>
  implicit</span> active:   yes</span></span></code></pre>
It seems that the org.libvirt.unix.manage</code> action is responsible for allowing
or declining the access to libvirt</code>. This action needs to be used in the
declaration of our directive which defines the authorization permission.</p>
The rules themselves are placed inside the /etc/polkit-1/rules.d</code> directory (or
/usr/share/polkit-1/rules.d</code>). The default action (on ArchLinux), in the time
of writing this post, is located inside the 50-default.rules</code> file, but we
should create a new file, named i.e. 50-virtmgr.rules</code>, and put this content
inside the file:</p>
polkit.</span>addRule</span>(</span>function</span>(</span>action</span>,</span> subject</span>) {</span></span>
        if</span>(action.id</span> ==</span> "org.libvirt.unix.manage"</span> &&</span> subject.</span>isInGroup</span>(</span>"wheel"</span>)) {</span></span>
                return</span> polkit.Result.</span>YES</span>;</span></span>
        }</span></span>
});</span></span></code></pre>
Which means, more or less: if currently evaluating action is named
org.libvirt.unix.manage</code> and the user, who asks for authorization, belongs to
the wheel</code> system group (see the /etc/group</code> file), then allow the
authorization. Just remember to add yourself to the wheel</code> group before using
this rule.</p>


Compiling glibmm on Windows
2012-11-02T00:00:00+00:00
Here is a short list of steps which need to be taken to successfully install the
glibmm</code> library, using gcc 4.7.1, in Windows environment. Use-case scenario for
this install would be to use a virtual machine, not a physical one. In the case
anyone would choose to use real</em> system, all configuration steps should be
changed to include the --prefix</code> option, to avoid creating mess in the system.
Also, by using prefixes you will be able to remove everything later by only
deleting one directory.</p>
Primary requirements are:</p>

MinGW ("MinGW Shell"),</li>
TDM-GCC</a>, which was v4.7.1 in the time of writing this post.</li>
</ol>
Step 1: zlib</h3>
Zlib</a>, which compiles normally, according to the instructions shown on
the screen:</p>
$</span> make</span> -f</span> win32/Makefile.gcc</span></span></code></pre>Step 2: iconv</h3>
Iconv</a>, also installs normally:</p>
$</span> ./configure</span></span>
$</span> make</span></span>
$</span> make install</span></span></code></pre>Step 3: gettext</h3>
Gettext</a>. First, the configure step needs to be taken:</p>
$</span> CPPFLAGS="-I /usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure</span></span></code></pre>
If you're getting any errors about suporfluous space between -L</code> and
/usr/local/lib</code>, you need to manually amend Makefile</code> and remove this space
from the file. You can use this oneliner to accomplish this task:</p>
$</span> find .</span> -iname</span> 'Makefile'</span> -exec</span> sed</span> -i</span> "{}"</span> -e</span> 's/-L /-L/g'</span> \;</span></span></code></pre>
It should fix the problem. Last step is to run the compilation and installation,
without further complications:</p>
$</span> make</span> &&</span> make</span> install</span></span></code></pre>Step 4: glib</h3>
Glib</a>. All you need to do is to inform configure</code> script about the existence
of library dependencies. In the place of /c/gnome</code>, insert your own path, where
sources of the dependencies are located.</p>
$</span> CPPFLAGS="-I /c/gnome/gettext/gettext-0.18.1.1/gettext-runtime/intl -I/c/gnome/zlib/zlib-1.2.7" LDFLAGS="-L/c/gnome/zlib/zlib-1.2.7 -L/c/gnome/gettext/gettext-0.18.1.1/gettext-runtime/intl/.libs" ./configure</span></span>
$</span> make</span></span>
$</span> make install</span></span></code></pre>Step 5: mm-common</h3>
mmcommon</a> macro set -- they can be downloaded by git</code>. The configure</code> script
should download any dependencies, so you need to enable networking in your
virtual machine.</p>
$</span> ./autogen.sh</span></span>
$</span> ./configure</span> --enable-network</span></span>
$</span> make</span> &&</span> make</span> install</span></span></code></pre>Step 6: pkg-config</h3>
PkgConf</a>. Easiest way is to use its internal glib</code> when compiling. The
-march=i486</code> option is required (but you can try to use a higher setting if you
want).</p>
$</span> CFLAGS="-march=i486" ./configure</span> --with-internal-glib</span></span>
$</span> make</span></span>
$</span> make install</span></span></code></pre>Step 7: libsigc++</h3>
Sigc++</a>. It is an important dependency of glibmm</code>, because it's the core of
signal and slot mechanism. The library itself seems to be quite complicated, but
the usage is rather simple. Luckily, the compilation is trivial.</p>
$</span> ./configure</span></span>
$</span> make</span> &&</span> make</span> install</span></span></code></pre>Step 8: glibmm</h3>
Glibmm</a>. I suspect that the version of the glibmm</code> library must match the
version of glib</code> ({glib}) from step 4.</p>
First, we need to use autogen.sh</code> while pointing it to the m4</code> macro
collection from mm-common</code> macro set (installed in step 5). Then, we need to
invoke the configure</code> script remembering that TDM-GCC uses the C++11</code> standard
by default. This is the reason why I'm using the CXXFLAGS</code> environment
variable, where I've used the -std=c++03</code> option, to turn off C++11</code>. I'm not
sure if this step is necessary -- in case of any errors you should get rid of
this option. Just be aware that C++11 used in tdm-gcc 4.7 breaks some binary
compatibility between the previous, 4.6, version, so i.e. the <list></code> class in
C++11</code> got some new fields. After succesfull (I hope) compilation, you need to
open up the config.h</code> file and place #undef</code> 's for these symbols:</p>
#undef GLIBMM_HAVE_WIDE_STREAM</span></span>
#undef GLIBMM_HAVE_ALLOWS_STATIC_INLINE_NPOS</span></span></code></pre>
Best would be to use the appropriate places for these directives (just use the
Find option of your favorite text editor).</p>
So, the list of steps:</p>
$</span> ACLOCAL_FLAGS="-I /usr/local/share/aclocal" ./autogen.sh</span></span>
$</span> CXXFLAGS="-std=c++03" ./configure</span></span>
</span>
# remember about #undef's!</span></span>
</span>
$</span> make install</span></span></code></pre>
For the last make install</code> to work, you need to install the doxygen</code> and
xsltproc</code> packages. The reason for this is that the pkg-config</code> definition
files (.pc</code>) are installed after</em> installing the documentation, which needs to
be generated first. Not the best idea, but probably the sequence was generated
automatically and since it doesn't make any problems for anybody, probably noone
really cares about it.</p>
Testing</h3>
This should do the trick. Now you should have the glibmm</code> library installed,
together with the pkg-config</code> definition files, so compilation of your sources
should work:</p>
$</span> g++ glibmmtest.cpp</span> -o</span> glibmmtest `</span>pkg-config</span> --cflags --libs</span> glibmm-2.4`</span></span>
$</span> ./glibmmtest</span></span>
Hello,</span> world</span></span></code></pre>
Here's the source for glibmmtest.cpp</code>:</p>
#include</span> <stdio.h></span></span>
#include</span> <glibmm.h></span></span>
</span>
int</span> main</span>(</span>int</span> argc</span>,</span> char *</span>argv</span>[]) {</span></span>
	Glib</span>::</span>thread_init</span>();</span></span>
	Glib</span>::Mutex m;</span></span>
	Glib</span>::ustring testStr </span>=</span> "Hello, world</span>\n</span>"</span>;</span></span>
	::</span>printf</span>(</span>"</span>%s</span>"</span>, testStr.</span>c_str</span>());</span></span>
	return</span> 0</span>;</span></span>
}</span></span></code></pre>


The Linux binfmt subsystem
2012-06-16T00:00:00+00:00
The binfmt subsystem is a special mechanism which allows the kernel to extend
its ability to recognize different executable binary formats. It's invoked by
the kernel when the user wants to execute a file with the executable (+x) flag,
and its purpose is to help the kernel to understand the binary structure of
chosen file. This structure is crucial in determining which segments are
responsible for holding the program code and program data. Only by knowing such
information it is possible to interpret in a proper (and deterministic) way.</p>

Some history</h2>
On UNIX systems, the executable file format went through a quite big evolution,
similar to what the Windows file formats did. On UNIX'es, one of the oldest form
of executable formats was the a.out file, which was replaced by more functional
and user-friendly COFF format, which was — in turn — replaced by the ELF format.
ELF got its name from Executable and Linkable Format, or — in a different time
span — Extensible Linking Format, and it rules the executable format kingdom
until this very day.</p>
Additionally, the variety of executable formats can be seen in more visible
colors when you start to consider the fact, that ELF structure is slightly
different on x86 and amd64 architectures. The problem is that the system needs
to support backward compatibility issues when running the software; thus it
needs to support both old formats, and new ones, to be regarded as usable. This
is where the binfmt subsystem comes in; it's an easy way to allow the kernel to
choose which binary interpreter is the proper one for chosen executable file.</p>
Overview</h2>
The file execution process begins in the exec</code> function, implemented in your
local libc library. Every function from the exec</code> family at some point will
enter the execve()</code> function. It's realized using the 0x80 interrupt (or by
sysenter instruction, or sometimes syscall), which is a standard way of
implementing a system service. The 0x80 interrupt, along with a number 11 in the
command register (more on this later) lets you switch the user-mode execution
context in favor of the kernel-mode execution context (ring 0). The interrupt,
when the command argument number is 11, is realized in the sys_execve()</code> function
in the kernel, which resides inside arch/x86/kernel/process.c</code> file. So, to sum
it up: the code flow, after calling the execve()</code> function inside libc, during
invocation of interrupt 0x80, goes through a “gate” living inside the IDT, which
tells the processor to start allowing more privileged instructions than standard
ring 3 ones (along with a bunch of other information), and jumps to the
sys_execve()</code> function in the kernel (also, for completion: if the int 80h
instruction is implemented by sysenter or syscall instructions, the IDT part of
this transition is replaced by a read of special MSR registers allowing the
relocation of code flow pointer into the acquired address). The sys_execve()</code>
function does the boring job of copying the arguments from ring 3 address space
into current ring 0 space, and invokes another function: do_execve()</code>. This one
is just a temporary place for us, not doing anything of importance
related to our subject. The crucial part is the invocation of
do_execve_common()</code>, which actually is doing something important, and interesting
;).</p>
More or less, this function is designed to verify the security context of the
process, and to make sure that only the few selected handles will be inherited
by the new process, which at this point is yet to be created. It initializes the
memory management structures, which is of most importance for us. To
successfully perform this task, it invokes the search_binary_handler()</code> function,
which tries to find a proper binary file interpreter, which knows how to walk
through the structure of our executable file.</p>
In the kernel, every binary interpreter is implemented in its own source file,
like this:</p>
fs/binfmt_aout.c,</span></span>
fs/binfmt_elf.c,</span></span>
fs/binfmt_script.c,</span></span>
etc.</span></span></code></pre>
Every interpreter sticks to a few important rules, which allow them to live
inside the kernel ecosystem. One of the most important ones is to invoke the
register_binfmt()</code> function, which notifies the kernel about the existence of the
interpreter. The function will pass the linux_binfmt</code> structure, which contains
the load_binary</code> field containing the pointer to a callback which gets invoked by
the kernel when it wants to match the interpreter with a specified binary file.
If the file structure is not what the interpreter understands (like trying to
use the ELF interpreter with a PE executable), it returns the -ENOEXEC</code> error, to
notify the binfmt subsystem about a bad match. Then, the kernel will try another
interpreter from its pool of interpreters, until a final failure (no
interpreters match), or a success.</p>
In other words: each built-in interpreter will issue a load_binary</code> structure to
the kernel, to register itself in the kernel pool of interpreters. Interpreters
which live inside the Loadable Kernel Modules will also do the same stuff; it
means that the kernel constantly maintains a special table of interpreters (the
pool), and uses it to find an interpreter suitable for current task. I thought
it would be a nice idea to be able to peek though this table, to know what
executable interpreters are allowed by my current operating system ;)</p>
The Loadable Kernel Module (LKM)</h2>
Before we dive into creation of our LKM, let's think of what the module should
do. The draft plan has been already created, but we need to dig some details to
know what structure fields are important for us and need reading, to get the
information we need. For this purpose it would be a good idea to quickly go
through the search_binary_handler()</code>, which could be named as a core of binfmt
subsystem.</p>
The function starts with a for loop after a block of sanity checks. The loop
uses the list_for_each_entry</code> macro, which is a standard (for the kernel) method
of iterating over a double-linked list. The first argument (fmt</code>) is the
iterator; this is a variable which points to a new row of data — it's valid in
the whole scope inside the for expression, but not afterwards. The second
argument, & formats</code>, is a pointer to the list we want to iterate on. Third
argument is a result of some peculiarities of the C language and the
container_of</code> macro, and it's a way of adjusting the compiler to properly cast
the type of the value in a type-safe fashion, to which the iterator points to.
More or less -- it's not important at the moment, right now it's just a “glue
code” for us. The important thing is that this for loop iterates over the
formats array, and allows the code inside its scope to access the member
objects, which are of the linux_binfmt</code> type. Every iteration reads the
load_binary</code> field, which is a pointer to a callback, invokes it, and checks the
return value. So, in other words, formats</code> table is a table which holds
information about all the currently registered binary file interpreters. By
dumping the contents of this table we can get the list of binary formats that
are possible to be invoked on our system.</p>
Let's write a LKM, which — after insmod</code>'ing — will find its way into the formats
array and dump its contents to the user, but in a form, which would be
understandable by her without any addidional postprocessing, so it could be
possible to only use cat</code> utility to read the contents of the file.
Unfortunately, there is a slight problem with that; the module can't simply
display something on the screen. Such user interaction level is beyond the
abstraction level imposed by the module subsystem. The exchange of information
between the LKM and the user is done in a different way; best thing is to use a
combination of ring 3 application and ring 0 module. A normal ring 3 application
will send a question to the module, which the module will process, rendering the
answer to a simple flat byte buffer, which will in turn be sent to the
application as a response. Then the application will be able to display the
buffer on the screen by using printf()</code>, a message box, or similar, whatever
method is needed by the user. The question sending part could be resolved by
using the procfs</code> subsystem, which is a standard Linux way of sending information
between ring 3 and ring 0 in a full-duplex fashion. We will get into that
shortly, but for now it'll suffice to say that it's based on all of those
/proc</code> files, which could be read by simple tools like cat</code>. These strings, which you
can observe while cat</code>'ing one of the files from /proc</code>, are generated inside the
kernel, sent through the standard I/O mechanisms to ring 3 application, to be
returned by standard I/O functions like read()</code>, and finally displayed on the
screen.</p>
Notabene</em>, there is a shortcut we can use, when we want to quickly send some
information from the LKM to the user. It's name is printk</code> and it's very similar
to standard printf. Two important details which you should note is that it
normally only works on the first physical console (ctrl+alt+f1</code>; though this can
be configured later), and for it to work, you must first activate it by echo'ing
9 9 9 9</code> to /proc/sys/kernel/printk</code>. These numbers control the printk logs and
they specify the log levels, which kernel has to pass into the console output.
Log levels higher than the ones specified in this control file are ignored and
passed to /dev/null</code> instead of the console (well, not exactly to /dev/null</code>, but
I think you get the idea). Sometimes, by using daemons like klogd</code>, the content
of printk</code>'s buffer is stored inside system log files, like /var/log/kern.log</code>, so
you can also check if that's the case for your system. Working or not, this
metod is valid only for communication between ring 0 and the developer, and you
shouldn't use it on production code. You can peek into my other post, the Device Enumeration on PCI bus</a>,
to see how printk</code> can be used. It's small and uncomplicated, so
it shouldn't generate any further questions on this subject</em>.</p>
OK, so here's the plan.</p>

Create the module skeleton, which is compiled into the binary module file,
accepted by the insmod utility,</li>
Find our way into the tables array, and interpret its contents,</li>
Create our special /proc entry, which will be used to exchange information
between ring 0 and ring 3.</li>
</ol>
Here's a short demonstration, which is more friendly to the eye than naked text,
and catches the point of what we are to do:</p>

    
    </iframe>
</div>
Before I venture to the second point, I suggest to take a closer look
to the third one. The characteristic traits of the /proc</code> filesystem handling can
influence the method which we will use to read the formats</code> array. Not as much to
completely change the approach, but different enough to be worthy for a
dedicated description ;).</p>
The /proc filesystem</h2>
Some time ago I already wrote some stuff about this subject, along with some
information about process dumping on Linux systems in ring 3 (unfortunately,
this blog post is available only in Polish language, at this moment at least).
We're going to take a look at the similar picture of /proc filesystem interface,
but this time we'll do it from ring 0 perspective.</p>
A driver that wishes to create a new file in the /proc</code> directory has to call the
create_proc_entry</code> function. It takes three arguments: the name of the file we
wish to create, the access rights to the file (encoded in a standard notation,
666 for rwxrwxrwx</code>, 755 for rwxr-xr-x</code>), and the pointer to the parent directory
in the /proc filesystem. Last argument is only used when we want to create a
file in a subdirectory in /proc</code>; if we don't plan on having any subdirectories,
it's safe to just pass NULL</code> to the third argument. Our example will not use any
directories, so we will use the function like this:</p>
proc_kformats = create_proc_entry(“kformats”, 755, NULL);</span></span></code></pre>
The global variable named proc_kformats</code>, which is of type proc_dir_entry</code>, will
contain a pointer to a new file descriptor, or NULL</code>, if there will be some
problem with file creation (make sure you propely handle the fauly logic, f.e.
by returning -EFAULT</code>). Before the system will actualy “show” the file to the
user, you will still need to provide some more information. The kernel will need
a list of callback functions, which are executed in case of a specific event
being triggered in the system. These callbacks should handle the open()</code>, read()</code>,
lseek()</code>, and close()</code> functions.</p>
Here's an example. Standard use case for the cat</code> command can look like the
following: first, after executing a cat /proc/kformats</code> command, the
/proc/kformats</code> file is being opened by the open()</code> function, which is implemented
in your system libc. Then, the current read pointer is being set, just as by
invoking the lseek()</code> function. Then the cat</code> command reads the file by using the
read()</code> function until it hits the end of file. After breaking the read loop, it
closes the file with the close()</code> function. This is of course a very simplified
description of what the cat program does, but is accurate enough for our
example. So, by matching the callback list inside the LKM and the list of
actions which are going to be executed by cat</code>, you can instruct the kernel that
if it gets an open()</code> request on our file, it should invoke the
my_driver_proc_file_open()</code> function from our LKM's adress space. This function
should, of course, implement an “opening” logic for our file. When cat</code> invokes
lseek()</code>, the kernel will use my_driver_proc_file_lseek()</code> function from our LKM,
which should implement a logic to set the offset from the input data source to a
specified value (only if our data source supports such operation).</p>
The “list of actions”, “list of callbacks” is a variable of file_operations</code>
type, and its definition can look like this:</p>
static struct</span> file_operations kformats_file_ops </span>=</span> {</span></span>
    .owner </span>=</span> THIS_MODULE,</span></span>
    .open </span>=</span> kformats_open,</span></span>
    .read </span>=</span> kformats_read,</span></span>
    .llseek </span>=</span> kformats_lseek,</span></span>
    .release </span>=</span> kformats_release</span></span>
};</span></span></code></pre>
Make sure to remember that if you don't “bind” the file descriptor (which is a
structure, and it's what the create_proc_entry()</code> function returned) to the
kformats_file_ops</code>, no callback from this structure will be invoked. The
“binding” part is very easy, and you can do it by taking the kformats_file_ops</code>
address, and putting it into proc_fops</code> field to the structure returned by
create_proc_entry()</code>. After this operation the kernel will know how to route the
I/O request from the /proc/kformats</code> file into your module, then into your
structure, and finally into your callback handler. You can resort to the source
code to see how it's done in the practice.</p>
This approach could be described as a poor man's object oriented programming,
and it's very popular across the whole kernel — mostly because it suits the
purpose very well. The file_operations</code> structure, as well as many others, use a
constant convention of function assignment to structure fields. This means that
the fields are becoming callbacks, ready to be invoked in different places in
the code. Object oriented purists will probably scream and attack us by saying
that of course that's not a real object oriented programming, but we can simply
ignore them, because everyone who expects object orientation from the C language
should be treated like that :).</p>
The main problem which everyone faces when implementing the read()</code> function is
the need to manually manage data buffers, which are to hold our data. In other
words, when we have a structure, which we'd like to copy to memory accessible by
ring 3 application, we can't simply take the pointer to the beginning of the
structure and copy sizeof(structure)</code> bytes from it. That's because when
implementing the read()</code> function we are told (by the kernel) which part of the
structure needs to be copied, and how much bytes we're allowed to copy.
Sometimes kernel tells us to copy the whole structure in one run, sometimes we
have to split it on two parts, sometimes copy it in chunks of 1 byte — it
depends on the arguments we'll get from the kernel. Every call to read()</code> should
increment an internal (also implemented by our code) counter which points to the
actual position (“cursor”) in our data stream. When you consider functions like
lseek()</code>, or ftell()</code>, you'll probably be able to figure that they operate on this
cursor position: first one sets the cursor to a specified value, and the second
one returns the current value of it. Maybe all of this could be an easy thing to
do, but sometimes interaction with the hardware (which is what the LKM were
designed to do, afterall) can be tricky, also data cache'ing can increase the
complexity level of the problem.</p>
This is why the kernel lends us a helping hand by providing us an abstraction
level for the basic I/O functions. The level is implemented slightly higher than
the file_operations</code> structure and it uses special callbacks, which are to be
used, instead of basic read()</code>, write()</code>, llseek()</code> and close()</code>. This mechanism
uses a different set of functions which are somewhat similar when it comes to
execution, but conceptually they operate on lines, instead of bytes, like the
basic mechanism. For the sake of stimulating your imagination, you can imagine
yourself the putc()</code> function, which writes 1 character to the screen, and
printf()</code> function, which is of course more advanced. printf()</code> eventually will
call putc()</code> at some point, but the truth is, we don't need to know how
putc()</code>
works; we can print stuff on the screen by just knowing how printf()</code> works. Same
thing here; The  seq</code> subsystem of which I'm writing about operates on lines, so
we only need to know how produce the next line in the stream. When we'll feed
this line into the seq</code>'s “flow”, it will implement a proper read()</code> callback so
the kernel will get the whole line, without needing to take care of buffering
issues, cursors, pointers, etc. That's plain convinience! Of course, at some
point it'll be very useful to know the internals of the standard I/O mechanism,
but if you want, you can postpone learning of it (the shorter the better).</p>
So, our declaration will change a little:</p>
static struct</span> file_operations kformats_file_ops </span>=</span> {</span></span>
    .owner </span>=</span> THIS_MODULE,</span></span>
    .open </span>=</span> kformats_open,</span></span>
    .read </span>=</span> seq_read,</span></span>
    .llseek </span>=</span> seq_lseek,</span></span>
    .release </span>=</span> seq_release</span></span>
};</span></span></code></pre>
You can probably see very well that the read()</code> function is implemented in
seq_read()</code> (which is already done and you don't need to change it), llseek()</code> is
replaced by seq_lseek()</code>, same thing with release()</code> and seq_release()</code>. So, the
only function which needs to be implemented in this structure, is the body of
open() function. And even then, it's very likely that lots of your open()</code>
functions will look like this:</p>
static int</span> kformats_open</span>(</span>struct</span> inode </span>*</span>inode</span>,</span> struct</span> file </span>*</span>file</span>) {</span></span>
    return</span> seq_open</span>(file,</span> &</span> kformats_seq_ops);</span></span>
}</span></span></code></pre>
It's not complicated, but it's important. Its only role is invocation of
seq_open()</code> function, which registers this file reading session with the seq</code>
subsystem. The subsystem needs to be initialized with the seq_operations</code>
structure, which is passed into the second argument of seq_open()</code>. Here's what
this structure looks like:</p>
static struct</span> seq_operations kformats_seq_ops </span>=</span> {</span></span>
    .start </span>=</span> seq_file_start,</span></span>
    .next </span>=</span> seq_file_next,</span></span>
    .stop </span>=</span> seq_file_stop,</span></span>
    .show </span>=</span> seq_file_show</span></span>
};</span></span></code></pre>
So what is the purpose of those fields? The .start</code> callback gets called when seq</code>
wants to start the streaming process. .next</code> will be used to notify your code that
it needs to prepare itself to be able to provide another line of data. .show</code> will
be called when the line will be rendered, and finally .stop</code> will be a
notification for finishing the streaming process. So, in practice, in .open</code> you
initialize your structures, in .next</code> you position the “cursor” on to the next
item to read, in .show</code> you read the data from the “cursor's” position, and in
.finish</code> you deinitialize everything that you did in the initialization step.
Every callback function in one of the arguments will contain the pointer to the
file descriptor you're going to manipulate on, so implementations of these
functions will have to use that information instead of any global variables you
might have. Every call to these functions will have to be reentrant, or at least
thread-aware, so best practice would be to not use any of the shared data at
all. Unfortunately, in our case, we have to use the reference to shared data
(the formats</code> array), so we will have to implement a proper locking code to make
our implementations thread-aware, and the invocation of our module safe both to
the system and to our module.</p>
Now it's finally the time to think about the process of getting into the formats</code>
array, from the seq</code>'s interface point of view. The .start</code> callback will
initialize the access to the structure, by locking the mutexes guarding the
array (so the structure won't change when we're walking over it). The .next</code>
callback will increase the “cursor” (“iterator”) forward by 1 position. .show</code>
callback will read the element pointed to by the cursor (iterator), and will
convert binary data into the human-readable form (by using printf(), for
example). Finally, the .stop</code> callback will have to unlock the guard mutex,
because if we'd leave it locked, it would hang the whole system up (the
formats</code>
array is used every time a process is created, after all). Before we enter the
realm of implementation, I'd like to write about two more things, which are
important in our case. The first one is a method which we'll use to find the
formats</code> table in the memory labirynth, and the second one is how we actually
handle that mutex part, that is: how to fit into the multithreaded system, and
find out the exact moment when we're able to saftely read the structure, without
risking invalid memory access exceptions.</p>
Dynamic symbol localization — kallsyms</h2>
The kernel must have this subsystem compiled in. Luckily, it seems that most
systems fulfill this prerequisite. It's very easy to check if that's the case
for your system; it's enough to check if the /proc/kallsyms</code> file exists.</p>
(2:1003)$ ls -la /proc/kallsyms</span></span>
-r--r--r-- 1 root root 0 09-13 21:58 /proc/kallsyms</span></span></code></pre>
The contents of this file is the same thing (or should be) as the contents of
the /boot/System.map file, and it basically is a list of variable names,
function names and their current addresses in the memory. This addresses are
generated automatically by the compiler when compiling the kernel, and their
value depends on many things, but I think it's safe to assume that it's mostly
the optimization level which the compiler is using, and the number of things
compiled in the kernel. These settings are so peculiar that it's safe to assume,
that the kernel on every installation is different. To be more specific, most
differences occur between distributions, not between versions of one distro, but
still there can be many versions of the kernel in different time span (thanks to
automatic updates) in the boundary of one distribution. Of course, when we take
into account distributions such as Gentoo, Sabayon, or similar, or distros on
which the user compiles her own kernel, the “different kernel on every
installation” assumption makes sense. This means we simply can't just write down
the memory location of our variable, which we'll find on our system. If we'd do
that then the module would probably work only on our system, and that's only
before automatic updates will replace the kernel to newer version. We need a
more robust solution for looking up variables in the memory.</p>
The subsystem which will be perfect for our case is called kallsyms. The main
function which we're going to use is named kallsyms_lookup_name()</code> and it's
designed to do lookup the variable name, which we'll supply in its first
argument. The return value is the current address of this symbol in current
memory, so it's possible to dereference it, and just use it (most of the time,
not counting dynamic allocations). So, using kallsyms, looking up the address of
the formats array is trivial:</p>
	g_formats_list </span>=</span> (</span>struct</span> list_head </span>*</span>)</span> kallsyms_lookup_name</span>(</span>"formats"</span>);</span></span></code></pre>
The code above will save the address of the formats</code> table in the
g_formats_list</code>
variable, which is declared in our module. The type of g_formats_list</code> is a
standard double-linked list, used in various places across the whole kernel. You
can look that information up on Google, because it goes slightly our of scope of
the subject of this post.</p>
Synchronization</h2>
Writing a kernel module is similar to writing a plugin to a bigger system (not
necessarily an operating system). Many aspects of the runtime environment in
which our module is working is based on an event-driven architecture and there
can be many reasons why our code will execute. Sometimes it will be called from
one thread, sometimes from the other thread, and sometimes it'll be called from
two (or more) threads at the same time. On a single-CPU machine, the first
instance will be interrupted and put into sleep, so other instance can jump into
its place and begin execution for a specified amount of time. Then, the control
is again reclaimed by the first module, during the time when the second one
sleeps. On a multi-CPU machine, many copies of one function can run at the same
time — that copies will operate on the same data sets. It's best to assume that
an unlimited number of threads, laid out on an unlimited set of CPUs is running
at the same time. So, where does that bring us?</p>
To the same point that any other multithreaded application brings us. So, we
simply use mutexes and spinlocks (along with some variations, like: mutex
locking the code only on write requests), atomic counters (atomic_t — atomic
means “not divisable”, or “uniform”, not explosive!), but there are also more
sophisticated methods of synchronization, like RCU — read-copy update (where the
write request copies the data into another memory location, updating the
reference pointers where its needed — this way the reading thread is not locked
and can operate on the old data set, and the new thread and every otherthread
which will access the data set after this point, will operate on new data set).</p>
Check this article</a> if you want to learn something about kernel mechanisms for
synchronization. This article is slightly out of date, because the Big Kernel
Lock it describes is no longer in the kernel, but still it's a valuable piece of
information for everyone who wants to learn about the subject.</p>
So where's the common point of this and our project? Well, the point is: it's
very important. Consider this example: you take the address of the formats
table. Then you start to iterate on every element of this table, printing the
address of the element on the screen. Very little can go wrong with this easy
example, right? Nope, wrong, if you include another thread in this scenario.
When during the first thread's iteration phase, the second thread will try to
remove an item, it can lead us into a situation where the first thread accesses
the memory that has just been freed by the second thread. Of course, the first
thread, when dereferencing the iterator, won't detect any errors, because the
memory still exists and it's valid; but even one instruction later, the first
thread's code can be preempted, or interrupted, and the second thread will jump
in, where it'll do its removal logic. Then, the first thread will resume its
execution, and this is where we are at: the first thread, in the block of code
that assumes the memory is valid (because it already did the checks), but the
memory is not valid. Kernel panic ahead! So where's the problem and how to fix
it? The problem is that the second thread did the removal stuff, but it didn't
knew that somebody else is reading the same data set at the same time. So, it
would be good to have some kind of mechanism, so that threads can broadcast the
information about the data set they're reading or writing to, so other threads
can wait until this access is finished. After waiting, they broadcast the read,
or modification signal themselves, so other threads won't start to read what
they intend to modify. After removing, or writing their part, they broadcast the
signal that the data set is free to process again. This is called locking, or
blocking a data set (structure, or anything that's a variable).</p>
So, if you'd like to acquire a data set with exclusive access, you can use, for
example, a Mutex. The broadcasting part is called locking a structure, or
entering a critical section. Many structures, and variables, in the kernel have
their respective mutex objects, which are used to lock the structure, so it's
accessed only by one thread at a time. It's no different in our case of the
formats</code> table; the locking object for this table is a read write lock (which is
a mutex) in the form of the binfmt_lock</code> variable. I suggest you look it up in
the kenrel sources to know where it's located and learn the pattern for this,
because — as I already wrote — it's popular among other kernel structures. To
add things up, before you do anything with the formats</code> table, you need to lock
the binfmt_lock</code> object according to your action. When you're finished with
whatever you do with the formats</code> table, just unlock the mutex, so other threads
can process this table, and you're done. I've also told you that many kernel
structures have their own respective locking objects; but it's up to you to find
them. There's no standard “slot” in the structure you can put the
synchronization objects in; you have to read the source code and figure out
which ones to use, by yourself.</p>
The address of the binfmt_lock</code> mutex can be acquired in the same way you acquire
the formats</code> table's address:</p>
g_binfmt_lock </span>=</span> (</span>rwlock_t</span> *</span>)</span> kallsyms_lookup_name</span>(</span>"binfmt_lock"</span>);</span></span></code></pre>
You can read-lock this mutex by using the read_lock()</code> function, and read-unlock
it by using read_unlock()</code>.</p>
Implementation</h2>
I think I've managed to describe most of the theoretical aspects of the approach
I'll be using in the code: you should know what the binfmt system is, and what
we are to do. You also should know the place that holds the data which is of
most importance for us and you should know how to access that data. Last section
described the method of reading the data, and the first one described how to
present the data to the user.</p>
So, let's go into some details.</p>
Getting the address of the formats</code> table and its synchronization mutex,
binfmt_lock</code>. If the kallsyms subsystem is not compiled in the kernel, the
module won't allow itself to be loaded. The insmod program will return an
error. But in the optimistic case (which is the majority), here's the code.</p>
static int</span> __init </span>kefdump_init</span>(</span>void</span>) {</span></span>
    g_formats_list </span>=</span> (</span>struct</span> list_head </span>*</span>)</span> kallsyms_lookup_name</span>(</span>"formats"</span>);</span></span>
    g_binfmt_lock </span>=</span> (</span>rwlock_t</span> *</span>)</span> kallsyms_lookup_name</span>(</span>"binfmt_lock"</span>);</span></span>
</span>
    if</span>(</span>!</span> g_formats_list </span>|| !</span> g_binfmt_lock)</span></span>
            return -</span>EFAULT;</span></span></code></pre>
The module creates the virtual file inside a virtual file system /proc</code>:</p>
proc_kformats </span>=</span> create_proc_entry</span>(</span>"kformats"</span>,</span> 755</span>,</span> NULL</span>);</span></span>
if</span>(</span>!</span> proc_kformats) {</span></span>
    printk</span>(KERN_ERR </span>"can't create_proc_entry</span>\n</span>"</span>);</span></span>
    return -</span>ENOMEM;</span></span>
}</span></span></code></pre>
The action list of the kformats</code> file is defined by the kformats_file_ops</code>
structure. This structure uses a convention imposed by the seq</code> subsystem, so the
read</code>, llseek</code> and release</code> fields are pointing to the seq</code> domain.</p>
proc_kformats</span>-></span>proc_fops </span>= &</span> kformats_file_ops;</span></span></code></pre>
Initialization is complete, the module is loaded.</p>
	TRACE0</span>(</span>"kformats installed"</span>);</span></span>
	return</span> 0</span>;</span></span>
}</span></span></code></pre>
Now, the user needs to read the /proc/kformats</code> file, so we can analyze further
what the module does. The cat /proc/kformats</code> command should do the trick. The
cat</code> command first opens the file (by using the fopen()</code> function, for example,
which in turn uses the open()</code> syscall), then it reads the data from it, and
closes the file in the epilogue of its execution (the close()</code> syscall). Let's
consult that with our action structure:</p>
static struct</span> file_operations kformats_file_ops </span>=</span> {</span></span>
    .owner </span>=</span> THIS_MODULE,</span></span>
    .open </span>=</span> kformats_open,</span></span>
    .read </span>=</span> seq_read,</span></span>
    .llseek </span>=</span> seq_lseek,</span></span>
    .release </span>=</span> seq_release</span></span>
};</span></span></code></pre>
So, first the kformats_open</code> will be invoked, because cat</code> opens the file.</p>
static int</span> kformats_open</span>(</span>struct</span> inode </span>*</span>inode</span>,</span> struct</span> file </span>*</span>file</span>) {</span></span>
    return</span> seq_open</span>(file,</span> &</span> kformats_seq_ops);</span></span>
}</span></span></code></pre>
We initialize the seq</code> subsystem here. This is the control structure for seq</code>:</p>
static struct</span> seq_operations kformats_seq_ops </span>=</span> {</span></span>
    .start </span>=</span> seq_file_start,</span></span>
    .next </span>=</span> seq_file_next,</span></span>
    .stop </span>=</span> seq_file_stop,</span></span>
    .show </span>=</span> seq_file_show</span></span>
};</span></span></code></pre>
What it means is that the control of serving the /proc/kformats</code> file is given to
the seq</code> filesystem, so we stick to its rules; then we only need to implement a
simple loop-like construct to be able to fully implement serving of the file
contents. .start</code> is the beginning of the loop, and it's the initialization of
data structure we want to print. In our case we will lock the binfmt_lock</code> here,
so no other thread will be able to write-access the formats</code> table, not even the
operating system itself (remember, by writing the kernel module, you're writing
the operating system itself). Read-access will be allowed for anyone. That's
the advantage of using the rwlock instead of a conventional lock.</p>
static void *</span>seq_file_start</span>(</span>struct</span> seq_file </span>*</span>s</span>,</span> loff_t</span> *</span>pos</span>) {</span></span>
    TRACE0</span>(</span>"lock"</span>);</span></span>
    read_lock</span>(g_binfmt_lock);</span></span>
</span>
    if</span>(</span>*</span> pos </span>>=</span> 1</span>)</span></span>
        return</span> 0</span>;</span></span>
    else</span></span>
        return</span> g_formats_list->next;</span></span>
}</span></span></code></pre>
The function will return a pointer to the first item in the table. By the way;
if the user will request read from f.e. a middle of the file, the function will
return zero. This is because our module doesn't support starting reading from
any other element that is not the first element.</p>
The cat</code> program, after opening the file, will start reading from it. This will
result in triggering the next</code> and show</code> actions, all the way down until the next
function will return NULL</code> — signalling the end of the data. This is our
implementation of the next</code> function. Its job is to increment the data iterator
together with fetching the pointer to the next</code> element, and here's how it does
this:</p>
static void *</span>seq_file_next</span>(</span>struct</span> seq_file </span>*</span>s</span>,</span> void *</span>iterator</span>,</span> loff_t</span> *</span>pos</span>) {</span></span>
	struct</span> list_head </span>*</span>next </span>=</span> NULL</span>;</span></span>
</span>
	(</span>*</span> pos)</span>++</span>;</span></span>
	next </span>=</span> ((</span>struct</span> list_head </span>*</span>) iterator)->next;</span></span>
</span>
	if</span>(next </span>!=</span> g_formats_list) {</span></span>
		return</span> next;</span></span>
	}</span> else</span></span>
		return</span> NULL</span>;</span></span>
}</span></span></code></pre>
The formats</code> table uses the standard double-linked list structure. The
characteristic part of this table is that the last element is linked with the
first one; so by incrementing the iterator, while standing on the last element,
we'll end up on the first element again. This is the reason for our expression
above: if the next</code> var is the same as g_formats_list</code>, it means that we're on the
beginning again, so we already got past the end of the table, so we can break
the loop. We return NULL</code> to signal that we got the end of the data. When the
kernel will see the NULL</code> value, it won't call the next function anymore.</p>
static int</span> seq_file_show</span>(</span>struct</span> seq_file </span>*</span>s</span>,</span> void *</span>iterator</span>) {</span></span>
    struct</span> linux_binfmt </span>*</span>fmt </span>=</span> NULL</span>;</span></span>
    char</span> namebuf</span>[</span>512</span>]</span> =</span> {</span> 0</span> };</span></span>
</span>
    fmt </span>=</span> container_of</span>(iterator,</span> struct</span> linux_binfmt, lh);</span></span>
    sprint_symbol</span>(namebuf, (</span>unsigned long</span>) fmt->load_binary);</span></span>
    seq_printf</span>(s,</span> "</span>%s\n</span>"</span>, namebuf);</span></span>
</span>
    return</span> 0</span>;</span></span>
}</span></span></code></pre>
So, nothing complicated here. The sprint_symbol()</code> is a function that is a
logical mirror of the kallsyms_lookup_name</code> — that is, it's designed to perform
the opposite — it will convert the address of the symbol to the symbol name. Of
course, the address must be valid in order to do it. The container_of</code> macro is a
method of iterator dereferencing, and I encourage you to read about it.</p>
That's about it. In case you'd like to share your thoughts or point out any
errors, feel free to use the “comment” link below.</p>
Source Codes</a> (5kb)</p>

antek's tech blog - linux

Intercepting HTTPS traffic from a VM for debugging

Fixing: Vivaldi opens Nautilus instead of Dolphin on KDE

Fixing: `Could not access KVM kernel module`

The problem</h2> On an affected host, checks often look like this:</p> lsmod | grep kvm</code> shows kvm</code> and kvm_intel</code>/kvm_amd</code> loaded.</li> CPU supports virtualization (vmx</code> or svm</code> exists in /proc/cpuinfo</code>).</li>

Takeaway</h2> Always check systemd-udevd</code> logs when /dev/*</code> ownership looks wrong.</li> </ul> If you maintain a podman image or something similar, ensure kvm</code> is provisioned as a system group</strong> from the start.</p>

Standard actions of Linux package managers

Creating ssh proxies

Sniffing HTTPS during development

Removing the unwanted Konsole toolbar

Usage of encrypted file containers

Control over symbol exports in GCC

Sending ATA commands on Linux

Fixing ugly Java fonts

Enabling core dumps on Linux

New GCC on an old Linux distribution

Defeating NAT with reverse SSH proxies

PCI device enumeration using ports 0xCF8, 0xCFC

D-Bus, UDisks and Glibmm bindings

Friendly GDB

Conclusion</h2> Okay, the last part could be better (more condensed), but having the access to the source code you can just fix it for yourself. And still it's better than the un-friendly version!</p>

Accessing libvirt's virtual machines from a script

Compiling glibmm on Windows

The Linux binfmt subsystem

Takeaway</h2>

Always check `systemd-udevd</code> logs when /dev/*</code> ownership looks wrong.</li> </ul> If you maintain a podman image or something similar, ensure kvm</code> is provisioned as a system group</strong> from the start.</p>`

Conclusion</h2>
Okay, the last part could be better (more condensed), but having the access to the source code you can just fix it for yourself. And still it's better than the un-friendly version!</p>