foxido

Fuzzing

Tue, 15 Jul 2025 20:00:00 +0300

Overview

Fuzzing is a software testing technique that involves feeding a program with random generated data to identify corner-case errors. There are different types of fuzzers:

“Black-box” fuzzers, that runs your program as-is, without any instrumentation and knowledge.
“Grey-box” fuzzers, that instruments your program at compile time or runs it inside QEMU (efficiently), gaining insight about control flow.

Grey-box fuzzers, also known as feedback-driven fuzzers, are superior to black-box ones but require full access to the binary or source code. By leveraging control-flow knowledge, they can employ genetic algorithms for input mutation, save new discovered path and explore your program step-by-step.

Understanding PostgreSQL internals, part 2: Executor (with JIT)

Mon, 09 Jun 2025 20:00:00 +0300

In the previous part, we discussed how PostgreSQL transforms declarative queries into imperative steps. Therefore, it seems logical to discuss the execution part next.

Overview

A basic understanding of how PostgreSQL executes trees can be obtained from the following source code comment:

/*
 *	 NOTES
 *		This used to be three files.  It is now all combined into
 *		one file so that it is easier to keep the dispatch routines
 *		in sync when new nodes are added.
 *
 *	 EXAMPLE
 *		Suppose we want the age of the manager of the shoe department and
 *		the number of employees in that department.  So we have the query:
 *
 *				select DEPT.no_emps, EMP.age
 *				from DEPT, EMP
 *				where EMP.name = DEPT.mgr and
 *					  DEPT.name = "shoe"
 *
 *		Suppose the planner gives us the following plan:
 *
 *						Nest Loop (DEPT.mgr = EMP.name)
 *						/		\
 *					   /		 \
 *				   Seq Scan		Seq Scan
 *					DEPT		  EMP
 *				(name = "shoe")
 *
 *		ExecutorStart() is called first.
 *		It calls InitPlan() which calls ExecInitNode() on
 *		the root of the plan -- the nest loop node.
 *
 *	  * ExecInitNode() notices that it is looking at a nest loop and
 *		as the code below demonstrates, it calls ExecInitNestLoop().
 *		Eventually this calls ExecInitNode() on the right and left subplans
 *		and so forth until the entire plan is initialized.  The result
 *		of ExecInitNode() is a plan state tree built with the same structure
 *		as the underlying plan tree.
 *
 *	  * Then when ExecutorRun() is called, it calls ExecutePlan() which calls
 *		ExecProcNode() repeatedly on the top node of the plan state tree.
 *		Each time this happens, ExecProcNode() will end up calling
 *		ExecNestLoop(), which calls ExecProcNode() on its subplans.
 *		Each of these subplans is a sequential scan so ExecSeqScan() is
 *		called.  The slots returned by ExecSeqScan() may contain
 *		tuples which contain the attributes ExecNestLoop() uses to
 *		form the tuples it returns.
 *
 *	  * Eventually ExecSeqScan() stops returning tuples and the nest
 *		loop join ends.  Lastly, ExecutorEnd() calls ExecEndNode() which
 *		calls ExecEndNestLoop() which in turn calls ExecEndNode() on
 *		its subplans which result in ExecEndSeqScan().
 *
 *		This should show how the executor works by having
 *		ExecInitNode(), ExecProcNode() and ExecEndNode() dispatch
 *		their work to the appropriate node support routines which may
 *		in turn call these routines themselves on their subplans.
 */

In PostgreSQL, trees execute with a ‘pull strategy’: the plan is executed from top to bottom, and each node pulls content row by row from child nodes. As an alternative approach, we could try to execute queries from bottom to top, but among other cons, this approach lacks laziness. For example, select * from very_big_table limit 1 would scan the whole table and then filter everything out instead of pulling just one row. You might argue that this can be optimized by pushing the limit operator into the scan node, but in reality it won’t work - consider a limit above a join. In that case, we can’t predict how many rows we’ll need from each table because we can’t predict how successful the row joins will be. Therefore, the pull strategy is the only way to implement laziness, and its overhead can be optimized via batching (pulling multiple rows at once, though this is currently not implemented in PostgreSQL).

Understanding PostgreSQL internals, part 1: Planner

Wed, 04 Jun 2025 20:00:00 +0300

Introduction

This is a small translation of my homework for an MIPT course, where I describe how PostgreSQL internals work with references to the source code.

All source code references are based on the REL_17_5 PostgreSQL git tag. For building PostgreSQL, you can refer to the dockerbuild directory.

During this series, I assume that you have following tables:

CREATE TABLE t1(a int, b1 int);
CREATE TABLE t2(a int, b2 int);
CREATE TABLE t3(a int, b3 int);

INSERT INTO t1 SELECT i, (i * 5) % 7 from generate_series(1, 10) i;
INSERT INTO t2 SELECT i * 2, (i * 5) % 7 from generate_series(1, 10) i;
INSERT INTO t3 SELECT i * 3, (i * 5) % 7 from generate_series(1, 10) i;

VACUUM (ANALYZE, FULL);

Why we need planner at all?

Well, SQL is a declarative (not imperative) language: it specifies what we want from the database but not how to get it. So because we can execute only imperative statements, we need to transform these wishful queries into executable plans — and like any good developer, we want this transformation to be optimal.

[DRAFT] cutie.team announce

Sun, 10 Nov 2024 21:13:00 +0300

TODO

right now just for redirect from cutie.team

Partial VPN for docker-compose and ... email

Fri, 01 Nov 2024 21:13:00 +0300

Если честно, я так долго откладывал написание этой заметки, что контекст уже слегка потерян… Но я все-таки решил ее написать, как напоминание о моей лени и наставление писать такие вещи сразу. Ну и чтобы опыта было побольше, хех

Для начала постановка задачи: поднять собственный email сервер рофла ради. При этом homelab у меня состоит из двух устройств: VPS сервера в качестве gateway (nginx + пару мелких сервисов) и основной машины за серым IP (где и поднималась почта), соединненных wg туннелем.

Raspberry Pi + Archlinux ARM + btrfs

Sat, 28 May 2022 14:09:13 +0300

Simple instructions for installing arch linux with btrfs root partition instead of default ext4.

$ whoami

Mon, 01 Jan 0001 00:00:00 +0000

This page is currently being rewritten

But I love system programming:

Developed a C-like compiler in Rust + LLVM.
Wrote virtio-net and virtio-gpu drivers, including necessary PCIe, sockets, and file descriptor subsystems, as well as an SDL-like library for an educational operating system, which had zero infrastracture for this. Later, with other students, ported TinySSH and Pong game to it.
Wrote something simular to Go runtime in C++: stackfull coroutines, thread pool, lock free syncronization primitives
Had fun with raytracing, small unity games, FPV drones, selfhosting, simple stack CPU emulators and so on

Formerly a database developer on Huawei’s GaussDB team; now part of Huawei’s Linux kernel team, working on memory managment and RCU algorithms.