CharlieQiu2017

import crafttweaker.api.events.CTEventManager;
import crafttweaker.api.event.player.MCItemCraftedEvent;
import crafttweaker.api.item.IItemStack;
import crafttweaker.api.item.MCItemDefinition;

var tag = <tag:items:minecraft:flowers>;

CTEventManager.register<MCItemCraftedEvent>((event) => {
  if(event.player == null) { return; }
  var elem = tag.elements[0] as IItemStack;

CharlieQiu2017

[01:02:29.696][CONSTRUCT][CLIENT][INFO] Starting building internal Registries
[01:02:30.527][CONSTRUCT][CLIENT][INFO] The following mods have explicit CraftTweaker support:
'crafttweaker' at version '7.1.2.508'
'initialinventory' at version '5.0.3.23'
[01:02:31.289][CONSTRUCT][CLIENT][INFO] Completed building internal Registries
[01:02:42.945][COMMON_SETUP][CLIENT][INFO] Started loading Scripts for Loader 'setupCommon'!
[01:02:44.815][COMMON_SETUP][CLIENT][INFO] Finished loading Scripts!
[01:03:07.120][DONE][CLIENT][INFO] Started loading Scripts for Loader 'crafttweaker'!
[01:03:07.184][DONE][CLIENT][INFO] Loading file: 'demo.zs' with priority: 10
[01:03:07.211][DONE][CLIENT][ERROR] Bad type on operand stack

CharlieQiu2017

Building and Running Mainline Kernel for Rock 4C Plus

This document describes my procedure for building and running a mainline Linux kernel for the single-board computer (SBC) Rock 4C Plus by Radxa.

Support for Rock 4C Plus has been upstreamed since Linux 6.0, but it is still difficult to find a single online resource that describes all the steps needed to run a mainline kernel on the SBC.

Material Preparation

The Rock 4C Plus Starter Kit sold by Okdo contains an SD card reader which is very useful.

CharlieQiu2017

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 6.12.5 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="aarch64-none-elf-gcc (GCC) 14.2.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=140200
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=24301

CharlieQiu2017

Position Independent Executables Without Dynamic Relocations

Recall that the process of turning source files into executables usually consists of the following steps:

1. A compiler generates assembly code from source code;
2. An assembler turns assembly code into object files;
3. A static linker resolves the interdependency between object files and produces an executable;
4. A dynamic loader resolves the external dependencies of the executable and builds a complete program image.

When the dynamic loader builds the program image, it needs to decide where to map the executable file and the dynamic libraries it depends on.

CharlieQiu2017

From Coq Require Import
  List
  Equalities
  Orders
  OrdersFacts
  OrdersLists.
From RBTree Require Import
  RBTree.
Import Notations ListNotations.

CharlieQiu2017

Running an AArch64 Linux Environment on x86 Desktop

When developing applications for AArch64 single-board computers, it is often more convenient to test the application in an emulated environment first, before going through the steps to deploy the application onto the board.

In this document, I describe how to build such an (emulated) AArch64 Linux environment on an x86 Linux desktop.

Building the Linux kernel

Follow the steps described at https://gist.github.com/CharlieQiu2017/9cb214683ec0f078f0fdab6d33a68b2c to build a mainline kernel.

CharlieQiu2017

Tracing Instructions and Memory Accesses of AArch64 Applications

In developing cryptographic applications one must always be aware of side-channel attacks. The most common kind of side-channel attack is timing attack, where an attacker learns information about secret inputs by measuring the amount of time taken by a computation. Fortunately it is also relatively easy to defend against timing attacks. In most cases, making the control flow and memory access pattern of the cryptographic algorithm independent of its secret inputs is sufficient to eliminate timing side-channels.

Here I describe how to trace the control flow and memory access pattern of an AArch64 application using DynamoRIO.

CharlieQiu2017

Calling the vDSO getrandom() Function

The Linux kernel provides a cryptographically-secure random number generator, via the interface getrandom(), or the device file /dev/urandom. However, performance will hurt if we make a getrandom() syscall every time we need some random bytes. Recently, Linux introduced an alternative way to get random bytes through the vDSO (Virtual Dynamic Shared Object) mechanism. Essentially, the kernel maps a pseudorandom generator into the image of every executable. Now instead of making a getrandom() syscall, we call into this generator function, which periodically reseeds itself via getrandom(), but otherwise works purely in userspace.

In this blogpost, I document how to find the entry point of the userspace getrandom() function, and how to call this function.

CharlieQiu2017

A Deep Dive into libgcc And libsupc++

According to the specifications of the C and the C++ programming languages, implementations of C and C++ can be classified into hosted ones and freestanding ones, depending on whether the implementation has access to functionalities that require operating system (OS) support, such as memory allocation and multi-threading. A hosted implementation has full access to these functionalities, and can provide the full range of features required by the language. A freestanding implementation, on the other hand, does not have access to any functionality that requires support from the execution environment. Such implementations are only required to provide a subset of the language features. Freestanding implementations are important when developing operating systems, the standard C library,