DEV Community: Leandro Proença

Taming non-determinism: from logic gates to LLMs

Leandro Proença — Thu, 19 Feb 2026 03:47:38 +0000

Or: how engineering keeps turning chaos into reliable computation. And why agentic AI still hasn't solved this.

There's a pattern that repeats across the entire history of computing: we take something fundamentally non-deterministic and engineer enough layers on top of it until it behaves deterministically. Logic gates did it. Artificial neural networks (ANNs) replicated it at some level. LLMs are the next frontier, and the hardest one yet.

In this article, we'll explore how engineering is crucial to facing non-determinism, and analyse the current state of the art for LLMs.

Agenda

Part I - The lie inside a logic gate
- Noise margins
- The CPU clock
Part II - Aspirina: teaching non-determinism to behave
- Where the chaos lives
- Composition does the rest
- The cost compared
Part III - LLMs and the "Unresolved Problem"
- Tests as noise margins
- The agentic loop as clock
- The type system and compiler
- What's missing: timing analysis
- How to mitigate that?
Conclusion

Part I - The lie inside a logic gate

A logic gate is taught in school as a simple binary machine. You give it 0s and 1s, you get 0s and 1s back.

AND, OR and XOR are example of logic gates. They are clean, mathematical, deterministic. And that's a useful fiction.

At the physical level, a gate is a transistor (or a few of them) through which electrons flow. Electrons don't care about your Boolean algebra. The voltage on a wire is a continuous, analog value that fluctuates due to thermal noise, manufacturing variance, electromagnetic interference, and even cosmic radiation flipping bits in memory.

Fun fact: in May 2003, in Belgium, an electronic voting machine gave a candidate exactly 4096 extra votes. More than she could possibly have received. After investigation, the error was attributed to the spontaneous creation of a 13th bit in the memory of the computer. The leading explanation: a cosmic ray flipped a single bit, turning a 0 into a 1 at position 2^12, adding exactly 4096 to the candidate count.

Ok, but how does the industry get determinism out of this mess?

Noise margins

Engineers define voltage thresholds: anything below 0.8V is a 0, anything above 2.0V is a 1. The zone between those values is declared "forbidden". The circuit is designed to never operate stably there. This isn't physics; it's an engineering contract. (More on noise margins)

The CPU clock

A CPU clock isn't just a metronome. It's also a sampling strategy. You let the signal propagate through the gate (which takes time, called propagation delay), and only read the value at a specific moment: the clock edge. By then, the signal has had time to cross the threshold and stabilise. Timing is calculated to guarantee this.

But when timing fails, things may get weird. If a signal is sampled while it's still in the forbidden zone, a flip-flop can enter metastability, which is an unstable equilibrium where the output isn't quite 0 or 1 and can oscillate for an indeterminate time. This may cause real crashes in real systems.

Think of metastability as what happens when two clocks on a wall are unsynchronized. Each showing a slightly different time. "What time is it right now?", one may ask. The answer depends on which clock you look at, but you can't decide which one is right.

Inside the CPU, when facing a forbidden zone, the flip-flop faces the same dilemma. It can't decide if it's a 0 or a 1, which can corrupt the system state. Engineers mitigate this with synchronizer chains, but never eliminate it entirely.

It's the non-determinism of physics leaking through the engineering abstraction!

The key insight: the determinism of digital computing is not a property of nature. It's an engineering achievement. It's paid with noise margins, timing analysis and careful design.

Yes, it's all about engineering.

Part II - Aspirina: teaching non-determinism to behave

Aspirina is my personal project that builds a complete CPU entirely from artificial neural networks (ANNs) trained to behave as logic gates, written in Rust.

Actually I created the very first version almost 10 years ago in Elixir, when I was learning about ANNs and Elixir. Recently I decided to write a Rust version while I was learning Rust.

The inversion from Part I brings the beauty: instead of physical electrons that need to be tamed into bits, here we have ANNs - systems whose weights are initialised randomly and whose outputs are continuous floating-point numbers - that need to be tamed into 0 and 1 too.

The non-determinism here is introduced deliberately, and then engineered away. Bear with me.

Where the chaos lives - unleash the madness

A neural network starts with random weights. Its output for any input is whatever the math happens to produce. Not 0, not 1, but something like 0.6312. In case you missed, I already have an article in my blog about neural networks.

Backpropagation is the engineering response. It's the algorithm that adjusts the weights iteratively, measuring how wrong the output is (the loss) and leading weights in the direction that reduces the error. Run this for 10,000 epochs - 10,000 passes over the training data - and the network converges to weights that produce 0.002 for inputs that should be 0, and 0.997 for inputs that should be 1.

The sigmoid function (a.k.a the logistic curve) does in Aspirina what noise margins do in hardware: it squashes any continuous value into the range 0..1. It doesn't give you exact binary outputs, but it pushes values toward the extremes.

And that's exactly what we need

Combined with a threshold decision - below 0.5 we could consider 0, above 0.5 we consider 1 -, we get in Aspirina the same effect: a circuit that behaves deterministically even though its internals are continuous and learned.

Composition does the rest

Once gates are trained, they're composed to:

XOR + AND => Half Adder => Full Adder => 4-bit ALU => Memory => Registers => CPU => Assembler => Interpreter

Each layer treats the layer below as if it were perfectly deterministic, which is exactly the abstraction hierarchy of real hardware.

The non-determinism was contained at the lowest level (training), and every layer above it benefits from the illusion of determinism.

Yes, determinism is an illusion. Deal with it.

The cost compared

Compute time during training. Just as chip fabrication invests energy upfront to create reliable silicon, Aspirina invests 10,000 epochs upfront to create reliable logic. After that, inference is cheap and stable.

Now, enter LLMs.

Part III - LLMs and the "Unresolved Problem"

A large language model (LLM) is non-deterministic in a deeper and more stubborn way than either of the above.

Its weights are the result of a stochastic training process over vast data. Its output is sampled probabilistically (even with temperature=0), and there's pseudo-randomness baked in. And crucially, unlike a neural network trained on a clean truth table, an LLM's "correct output" for most inputs is fundamentally ambiguous.

Yet we're building agentic systems (Claude Code, Codex, Cursor etc) that use LLMs to write, run and iterate on code autonomously. How do we tame this?

The pattern repeats, but the engineering is particularly messier on LLM's.

Tests as noise margins

A test suite could behave as a binary verdict on the LLM's output: green or red. It doesn't matter if the model generated three different valid implementations in three runs: if all tests pass, they're equivalent from the system's perspective. The non-determinism of the model is contained below the threshold of "passes tests". This works, but only as well as the tests themselves. And unlike voltage thresholds, test coverage is always incomplete.

The agentic loop as clock

An agentic system like Claude Code doesn't generate once and deliver. It reads state (files, compiler output, test results), acts, observes the new state, and repeats. This feedback loop is structurally similar to the fetch-decode-execute cycle of a CPU or the iterative of Aspirina. Each iteration constrains the space of valid next actions. Errors are observable, and the agent can correct.

The type system and compiler as low-level validators

In a Rust project like Aspirina, the borrow checker rejects invalid outputs before tests even run. The LLM can generate wrong code and hallucinate, the compiler then refuses it, the agent observes the error message, and iterates.

This is a lower-level noise margin: just a formal filter beneath the test layer and type system.

And that's why I think that languages with strict compilers like Rust will thrive in the agentic era. Let's see.

What's missing: the equivalent of timing analysis

In hardware, engineers can prove that a circuit will work at a given clock frequency. They run static timing analysis and guarantee that every signal stabilises before every clock edge. There's no equivalent for agentic LLM systems.

We don't know how many iterations an agent will need. We can't bound the convergence time. We can't guarantee termination. An agent can loop indefinitely, or enter what I'd call "agentic metastability": making and undoing the same change repeatedly, unable to reach a stable state.

Anyone who has used Claude Code or Codex for long enough has seen this - the model oscillates between two approaches, each creating a problem that motivates reverting to the other.

Despite we can retry, add guardrails, skills, and set token budgets, in the end, we can't prove termination the way a hardware engineer proves timing closure on metastability

How to mitigate that?

In hardware, the fix for metastability is design. In agentic systems, the analog fix is clearer context, more granular tests, explicit checkpoints and tighter feedback loops; which can be described with the following practical list of skills I created and have been using on a daily basis for every project in production:

PO (product owner): agent receives a prompt and outputs a well-scoped task based on initial requirements and prior knowledge on the codebase. Clearer context.
TDD (test-driven development): the developer agent outputs the code, guided by TDD - red, green, refactor. Granular tests as noise margins.
Review: agent and human checks before merging. Explicit checkpoint.
Small PRs: small PR's enable development and testing with reviewable increments. Tighter feedback loops.

Yes, that's software engineering practices all the way down (and they are not new). Yet we don't have the formal tools to prove these fixes work. It's totally empirical.

Conclusion

At least for me, what's interesting is that each level's "solved" status depends on bounded, well-defined tasks. Logic gates are deterministic for Boolean logic. Aspirina's networks converge reliably because truth tables are finite and exact. LLMs work well on narrow, testable tasks with earlier and good feedback.

The frontier is: what does it take to engineer reliable agentic behaviour on open-ended, ambiguous, long-horizon tasks? The answer probably looks like what came before: more layers of verification, better sampling strategies (the clock), formal specifications (the truth table), and tools that can analyse convergence before execution. We just don't have those yet.

Non-determinism doesn't go away. It never has. We just keep finding better ways to push it where it can't hurt us. From voltage thresholds to synchronizer chains to temperature tuning. Every generation of computing has faced the same enemy and responded with the same weapon: engineering. Besides hype, LLMs are no different. We're just earlier in the cycle.

References

You don't need Kafka: Building a message queue with only two UNIX signals

Leandro Proença — Tue, 21 Oct 2025 00:06:14 +0000

Have you ever asked yourself what if we could replace any message broker with a very simple one using only two UNIX signals? Well, I'm not surprised if you didn't. But I did. And I want to share my journey of how I achieved it.

If you want to learn about UNIX signals, binary operations the easy way, how a message broker works under the hood, and a bit of Ruby, this post is for you.

And if you came here just because of the clickbait title, I apologize and invite you to keep reading. It'll be fun, I promise.

It's all about UNIX

A few days ago, I saw some discussion on the internet about how we could send messages between processes. Many people think of sockets, which are the most common way to send messages, even allowing communication across different machines and networks. Some don't even realize that pipes are another way to send messages between processes:

$ echo 'hello' | base64
aGVsbG8K

Here's what's happening:

The process echo is started with the content "hello"
echo is a program that prints the message to STDOUT
Through the pipe, the content in STDOUT is sent directly to the STDIN of the base64 process
The base64 process encodes its input to Base64 and then puts the result in STDOUT

Note the word "send". Yes, anonymous pipes are a form of IPC (Inter-process communication). Other forms of IPC in UNIX include:

named pipes (mkfifo)
sockets
regular files
or even a simple signal

UNIX signals

According to Wikipedia:

A UNIX signal is a standardized message sent to a program to trigger specific behaviour, such as quitting or error handling

There are many signals we can send to a process, including:

SIGTERM - sends a notification to the process to terminate. It can be "trapped," which means the process can do some cleanup work before termination, like releasing OS resources and closing file descriptors
SIGKILL - sends a termination signal that cannot be trapped or ignored, forcing immediate termination
SIGINT - the interrupt signal, typically sent when you press Ctrl+C in the terminal. It can be trapped, allowing the process to perform cleanup before exiting gracefully
SIGHUP - the hangup signal, originally sent when a terminal connection was lost. Modern applications often use it to reload configuration files without restarting the process
SIGQUIT - similar to SIGINT but also generates a core dump for debugging
SIGSTOP - pauses (suspends) a process. Cannot be trapped or ignored
SIGCONT - resumes a process that was paused by SIGSTOP
SIGCHLD - sent to a parent process when a child process terminates or stops
SIGUSR1 and SIGUSR2 - user-defined signals that applications can use for custom purposes

Sending messages using signals

Okay, we know that signals are a primitive form of IPC. UNIX-like systems provide a syscall called kill that sends signals to processes. Historically, this syscall was created solely to terminate processes. But over time, they needed to accommodate other types of signals, so they reused the same syscall for different purposes.

For instance, let's create a simple Ruby script sleeper.rb which sleeps for 60 seconds, nothing more:

puts "Process ID: #{Process.pid}"
puts "Sleeping for 60 seconds..."
sleep 60

After running we see:

Process ID: 55402
Sleeping for 60 seconds...

In another window, we can send the SIGTERM signal to the process 55402 via syscall kill:

$ kill -SIGTERM 55402

And then, in the script session:

[1]    55402 terminated  ruby sleeper.rb

Signal traps

In Ruby, we can also trap a signal using the trap method in Ruby:

puts "Process ID: #{Process.pid}"
puts "Sleeping for 60 seconds..."

trap('SIGTERM') do 
  puts "Received SIGTERM, exiting gracefully..."
  exit
end

sleep 60

Which in turn, after sending the signal, will gracefully:

Process ID: 55536
Sleeping for 60 seconds...
Received SIGTERM, exiting gracefully...

After all, we cannot send messages using signals. They are a primitive way of sending standardized messages which will trigger specific behaviours. At most, we can trap some signals, but nothing more.

Okay Leandro, but what's the purpose of this article then?

Hold on. That's exactly why I'm here. To prove points by doing useless stuff, like when I simulated OOP in Bash a couple of years ago (it was fun though).

To understand how we can "hack" UNIX signals and send messages between processes, let's first talk a bit about binary operations. Yes, those "zeros" and "ones" you were scared of when you saw them for the first time. But they don't bite (🥁 LOL), I promise.

What is a message?

If we model a message as a sequence of characters, we could say that at a high-level, messages are simply strings. But in memory, they are stored as bytes.

We know that bytes are made of bits. In computer terms, what's a bit? It's simply an abstraction representing only two states:

zero
one

That's it. For instance, using ASCII, we know that the letter "h" has the following codes:

104 in decimal
0x68 in hexadecimal
01101000 in binary

Binary-wise, what if we represented each "0" with a specific signal and each "1" with another? We know that some signals such as SIGTERM, SIGINT, and SIGCONT can be trapped, but intercepting them would harm their original purpose.

But thankfully, UNIX provides two user-defined signals that are perfect for our hacking experiment.

Sending SIGUSR1 and SIGUSR2

First things first, let's trap those signals in the code:

puts "Process ID: #{Process.pid}"
puts "Sleeping forever. Send signals to this process to see how it responds."

trap('SIGUSR1') do 
  puts "Received SIGUSR1 signal"
end

trap('SIGUSR2') do
  puts "Received SIGUSR2 signal"
end

sleep

Process ID: 56172
Sleeping forever. Send signals to this process to see how it responds.

After sending some kill -SIGUSR1 56172 and kill -SIGUSR2 56172, we can see that the process prints the following content:

Process ID: 56172
Sleeping forever. Send signals to this process to see how it responds.
Received SIGUSR1 signal
Received SIGUSR2 signal
Received SIGUSR2 signal
Received SIGUSR1 signal
Received SIGUSR1 signal
Received SIGUSR2 signal

Signals don't carry data. But the example we have is perfect for changing to bits, uh?

Received SIGUSR1 signal # 0
Received SIGUSR2 signal # 1
Received SIGUSR2 signal # 1
Received SIGUSR1 signal # 0
Received SIGUSR2 signal # 1
Received SIGUSR1 signal # 0
Received SIGUSR1 signal # 0
Received SIGUSR1 signal # 0

That's exactly 01101000, the binary representation of the letter "h". We're simply encoding the letter as a binary representation and sending it via signals

Again, we're encoding it as a binary and sending it via signals.

How cool is that?

Decoding the binary data

On the other side, the receiver should be capable of decoding the message and converting it back to the letter "h":

sender encodes the message
receiver decodes the message

So, how do we decode 01101000 (the letter "h" in ASCII)? Let's break it down into a few steps:

1) First, we need to see the 8 bits as individual digits in their respective positions
2) The rightmost bit is at position 0, whereas the leftmost bit is at position 7. This is how we define the most significant bit (MSB, the leftmost) and the least significant bit (LSB, the rightmost)
3) For this example, we perform a left shift operation on each bit and then sum all the values, in this case from MSB to LSB (the order doesn't matter much for now): (0 << 7) + (1 << 6) + (1 << 5) + (0 << 4) + ... + (0 << 0):
left shift on _zeros will always produce a zero_

0 << 7 = (2 ** 7) * 0 = 128 * 0 = 0
1 << 6 = (2 ** 6) * 1 = 64 * 1 = 64

Similarly to the remaining bits:

1 << 5 = 32
0 << 4 = 0
1 << 3 = 8
0 << 2 = 0
0 << 1 = 0
0 << 0 = 0

So, our sum becomes, from MSB to LSB:

MSB                          LSB
0   1    1    0   1   0   0   0
0 + 64 + 32 + 0 + 8 + 0 + 0 + 0 = 104

104 is exactly the decimal representation of the letter "h" in ASCII.

How wonderful is that?

Sending the letter "h"

Now let's convert these operations to Ruby code. We'll write a simple program receiver.rb that receives signals in order from LSB to MSB (positions 0 to 7) and then converts them back to ASCII characters, printing to STDOUT.

Basically, we'll accumulate bits and whenever we form a complete byte, we'll decode it to its ASCII representation. The very basic implementation of our accumulate_bit(bit) method would look like as follows:

@position = 0 # start with the LSB
@accumulator = 0

def accumulate_bit(bit)
  # The left shift operator (<<) is used to 
  # shift the bits of the number to the left.
  #
  # This is equivalent of: (2 ** @position) * bit
  @accumulator += (bit << @position)
  return @accumulator if @position == 7 # stop accumulating after 8 bits (byte)

  @position += 1 # move to the next bit position: 0 becomes 1, 1 becomes 2, etc.
end

# Letter "h" in binary is 01101000
# But we'll send from the LSB to the MSB
#
# 0110 1000 (MSB -> LSB) becomes 0001 0110 (LSB -> MSB)
# The order doesn't matter that much, it'll depend on 
# the receiver's implementation.
accumulate_bit(0)
accumulate_bit(0)
accumulate_bit(0)
accumulate_bit(1)
accumulate_bit(0)
accumulate_bit(1)
accumulate_bit(1)
accumulate_bit(0)

puts @accumulator # should print 104, which is the ASCII code for "h"

Pay attention to this code. It's very important and builds the foundation for the next steps. If you didn't get it, go back and read it again. Try it yourself in the terminal or using your preferred programming language.

Now, how to convert the decimal 104 to the ASCII character representation? Luckily, Ruby provides a method called chr which does the job:

irb> puts 104.chr
=> "h"

We could do the same job for the rest of the word "hello", for instance. According to the ASCII table, it should be the following:

e in decimal is 101
l in decimal is 108
o in decimal is 111

Let's check if Ruby knows that:

104.chr    # "h"
101.chr    # "e"
108.chr    # "l"
111.chr    # "o"

We can even "decode" the word to the decimal representation in ASCII:

irb> "hello".bytes
=> [104, 101, 108, 108, 111]

Now, time to finish our receiver implementation to properly print the letter "h":

@position = 0 # start with the LSB
@accumulator = 0

trap('SIGUSR1') { decode_signal(0) }
trap('SIGUSR2') { decode_signal(1) }

def decode_signal(bit)
  accumulate_bit(bit)
  return unless @position == 8 # if not yet accumulated a byte, keep accumulating

  print "Received byte: #{@accumulator} (#{@accumulator.chr})\n"

  @accumulator = 0 # reset the accumulator
  @position = 0 # reset position for the next byte
end

def accumulate_bit(bit)
  # The left shift operator (<<) is used to 
  # shift the bits of the number to the left.
  #
  # This is equivalent of: (2 ** @position) * bit
  @accumulator += (bit << @position)
  @position += 1 # move to the next bit position: 0 becomes 1, 1 becomes 2, etc.
end

puts "Process ID: #{Process.pid}"
sleep

Read that code and its comments. It's very important. Do not continue reading until you really get what's happening here.

Whenever we get SIGUSR1, we accumulate the bit 0
When getting SIGUSR2, accumulate then the bit 1
When accumulator reaches the position8, it means we have a byte. At this moment we should print the ASCII representation using the .chr we seen earlier. Then, reset bit position and accumulator

Let's see our receiver in action! Start the receiver in one terminal:

$ ruby receiver.rb
Process ID: 58219

Great! Now the receiver is listening for signals. In another terminal, let's manually send signals
to form the letter "h" (which is 01101000 in binary, remember?):

  # Sending from LSB to MSB: 0, 0, 0, 1, 0, 1, 1, 0
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR2 58219  # 1
  $ kill -SIGUSR1 58219  # 0
  $ kill -SIGUSR2 58219  # 1
  $ kill -SIGUSR2 58219  # 1
  $ kill -SIGUSR1 58219  # 0

And in the receiver terminal, we should see:

Received byte: 104 (h)

How amazing is that? We just sent the letter "h" using only two UNIX signals!

But wait. Manually sending 8 signals for each character? That's tedious and error-prone. What if we wanted to send the word "hello"? That's 5 characters × 8 bits = 40 signals to send manually. No way.

We need a sender.

Building the sender

The sender's job is the opposite of the receiver: it should encode a message (string) into bits and send them as signals to the receiver process.

Let's think about what we need:

Take a message as input (like "hello")
Convert each character to its byte representation
Extract the 8 bits from each byte
Send SIGUSR1 for bit 0, SIGUSR2 for bit 1
Repeat for all characters

The tricky part here is the step 3: how do we extract individual bits from a byte? To extract the bit at position i, we can use the following formula:

bit = (byte >> i) & 1

Let me break this down:

byte >> i performs a right shift by i positions
& 1 is a bitwise AND operation that extracts only the rightmost bit

For the letter "h" (01101000 in binary, 104 in decimal):

Position 0 (LSB):

(104 >> 0) = 104 / (2 ** 0) = 104 / 1 = 104
01101000 >> 0 = 01101000
01101000 & 00000001 = 0 (one AND zero is zero)

Position 1:

(104 >> 1) = 104 / (2 ** 1) = 104 / 2 = 52
01101000 >> 1 = 00110100
00110100 & 00000001 = 0

Position 2:

(104 >> 2) = 104 / (2 ** 2) = 104 / 4 = 26
01101000 >> 2 = 00011010
00011010 & 00000001 = 0

Position 3:

(104 >> 3) = 104 / (2 ** 3) = 104 / 8 = 13
01101000 >> 3 = 00001101
00001101 & 00000001 = 1 (one AND one equals one)

And so on for positions 4, 5, 6, and 7. This gives us: 0, 0, 0, 1, 0, 1, 1, 0 — exactly the bits we need from LSB to MSB!

(104 >> 0) & 1 = 104 & 1 = 0
(104 >> 1) & 1 = 52 & 1 = 0
(104 >> 2) & 1 = 26 & 1 = 0
(104 >> 3) & 1 = 13 & 1 = 1
(104 >> 4) & 1 = 6 & 1 = 0
(104 >> 5) & 1 = 3 & 1 = 1
(104 >> 6) & 1 = 1 & 1 = 1
(104 >> 7) & 1 = 0 & 1 = 0

Pay close attention to this technique. It's a fundamental operation in low-level programming.

So now time to build the sender.rb which is pretty simple:

receiver_pid = ARGV[0].to_i
message = ARGV[1..-1].join(' ')

def encode_byte(byte)
  8.times.map do |i|
    # Extract each bit from the byte, starting from the LSB
    (byte >> i) & 1
  end
end

message.bytes.each do |byte|
  encode_byte(byte).each do |bit|
    signal = bit == 0 ? 'SIGUSR1' : 'SIGUSR2'
    Process.kill(signal, receiver_pid)
    sleep 0.001 # Delay to allow the receiver to process the signal
  end
end

For each byte (8-bit structure) we extract the bit performing the right shift + AND oprerations. The result is the extracted bit.

In the receiver window:

$ ruby receiver.rb
Process ID: 68968

And in the sender window:

$ ruby sender.rb 68968 h

The receiver will print:

$ ruby receiver.rb
Process ID: 68968
Received byte: 104 (h)

Processes sending messages with only two signals! How wonderful is that?

Sending the "hello" message

Now, sending the hello message is super easy. The sender is already able to send not only a letter but any message using signals:

$ ruby sender.rb 68968 hello

# And the receiver:
Received byte: 104 (h)
Received byte: 101 (e)
Received byte: 108 (l)
Received byte: 108 (l)
Received byte: 111 (o)

Just change the receiver implementation a little bit:

def decode_signal(bit)
  accumulate_bit(bit)
  return unless @position == 8 # if not yet accumulated a byte, keep accumulating

  print @accumulator.chr # print the byte as a character

  @accumulator = 0 # reset the accumulator
  @position = 0 # reset position for the next byte
end

And then:

$ ruby sender.rb 96875 Hello

# In the receiver's terminal
Process ID: 96875
Hello

However, if we send the message again, the receiver will print everything in the same line:

$ ruby sender.rb 96875 Hello
$ ruby sender.rb 96875 Hello

# In the receiver's terminal
Process ID: 96875
HelloHello

It's obvious: the receiver doesn't know where the sender finished the message, so it's impossible to know where we should stop one message and print the next one on a new line with \n.

We should then determine how the sender indicates the end of the message. How about being it all zeroes (0000 0000)?

We send the message: first 5 bytes representing the "hello" message
Then we send a "NULL terminator", just one byte 0 (0000 0000)

0110 1000 # h
0110 0101 # e
0110 1000 # l
0110 1000 # l
0110 1111 # o
0000 0000 # NULL

Hence, when the receiver gets a NULL terminator, it will print a line feed \n. Let's change the sender.rb first:

receiver_pid = ARGV[0].to_i
message = ARGV[1..-1].join(' ')

def encode_byte(byte)
  8.times.map do |i|
    # Extract each bit from the byte, starting from the LSB
    (byte >> i) & 1
  end
end

message.bytes.each do |byte|
  encode_byte(byte).each do |bit|
    signal = bit == 0 ? 'SIGUSR1' : 'SIGUSR2'
    Process.kill(signal, receiver_pid)
    sleep 0.001 # Delay to allow the receiver to process the signal
  end
end

# Send NULL terminator (0000 0000)
8.times do
  Process.kill('SIGUSR1', receiver_pid)
  sleep 0.001 # Delay to allow the receiver to process the signal
end

puts "Message sent to receiver (PID: #{receiver_pid})"

Then, the receiver.rb:

@position = 0 # start with the LSB
@accumulator = 0

trap('SIGUSR1') { decode_signal(0) }
trap('SIGUSR2') { decode_signal(1) }

def decode_signal(bit)
  accumulate_bit(bit)
  return unless @position == 8 # if not yet accumulated a byte, keep accumulating

  if @accumulator.zero? # NULL terminator received
    print "\n"
  else
    print @accumulator.chr # print the byte as a character
  end

  @accumulator = 0 # reset the accumulator
  @position = 0 # reset position for the next byte
end

def accumulate_bit(bit)
  # The left shift operator (<<) is used to 
  # shift the bits of the number to the left.
  #
  # This is equivalent of: (2 ** @position) * bit
  @accumulator += (bit << @position)
  @position += 1 # move to the next bit position: 0 becomes 1, 1 becomes 2, etc.
end

puts "Process ID: #{Process.pid}"
sleep

Output:

$ ruby sender.rb 96875 Hello, World!
$ ruby sender.rb 96875 You're welcome
$ ruby sender.rb 96875 How are you?

# Receiver
Process ID: 97176
Hello, World!
You're welcome
How are you?

OMG Leandro! That's amazing!

Amazing, right? We just built an entire communication system between two processes using one of the most primitive methods available: UNIX signals.

The sky's the limit now! Why not build a full-fledged message broker using this crazy technique?

A modest message broker using UNIX signals

We'll break down the development into three components:

Broker: the intermediary that routes messages
Consumer: processes that receive messages
Producer: processes that send messages
Let's start with the Broker. It should register itself with the producer, then trap incoming signals, decode them, and enqueue the messages for delivery to consumers via outgoing signals:

#!/usr/bin/env ruby

require_relative 'signal_codec'
require_relative 'consumer'

class Broker 
  PID = 'broker.pid'.freeze

  def initialize
    @codec = SignalCodec.new
    @queue = Queue.new
    @consumer_index = 0
  end

  def start 
    register_broker

    trap('SIGUSR1') { process_bit(0) }
    trap('SIGUSR2') { process_bit(1) }

    puts "Broker PID: #{Process.pid}"
    puts "Waiting for messages..."

    distribute_messages

    sleep # Keep alive
  end 

  private

  def process_bit(bit)
    @codec.accumulate_bit(bit) do |message|
      @queue.push(message) unless message.empty?
    end
  end

  def register_broker 
    File.write(PID, Process.pid)
    at_exit { File.delete(PID) if File.exist?(PID) }
  end

  def distribute_messages
    Thread.new do
      loop do
        sleep 0.1

        next if @queue.empty?

        consumers = File.exist?(Consumer::FILE) ? File.readlines(Consumer::FILE).map(&:to_i) : []
        next if consumers.empty?

        message = @queue.pop(true) rescue next

        consumer_pid = consumers[@consumer_index % consumers.size]
        @consumer_index += 1

        puts "[SEND] #{message} → Consumer #{consumer_pid}"

        @codec.send_message(message, consumer_pid)
      end
    end
  end
end

if __FILE__ == $0 
  broker = Broker.new
  broker.start
end

The broker registers itself
Traps incoming signals USR1 (bit 0) and USR2 (bit 1)
Enqueues the messages
Send messages to consumers using outgoing signals (USR1 and USR2 too)

Note that we're using a module called SignalCodec which will be explained soon. Basically this module contains all core components to encode/decode signals and perform bitwise operations.

Now the Consumer implementation:

#!/usr/bin/env ruby

require_relative 'signal_codec'

class Consumer
  FILE = 'consumers.txt'.freeze

  def initialize
    @codec = SignalCodec.new
  end

  def start
    register_consumer

    trap('SIGUSR1') { process_bit(0) }
    trap('SIGUSR2') { process_bit(1) }

    puts "Consumer PID: #{Process.pid}"
    puts "Waiting for messages..."

    sleep # Keep alive
  end

  private

  def process_bit(bit)
    @codec.accumulate_bit(bit) do |message|
      puts "[RECEIVE] #{message}"
    end
  end

  def register_consumer
    File.open(FILE, 'a') { |f| f.puts Process.pid }
    at_exit { deregister_consumer }
  end

  def deregister_consumer
    if File.exist?(FILE)
      consumers = File.readlines(FILE).map(&:strip).reject { |pid| pid.to_i == Process.pid }
      File.write(FILE, consumers.join("\n"))
    end
  end
end

if __FILE__ == $0
  consumer = Consumer.new
  consumer.start
end

The consumer starts and registers itself with the broker
Consumer then traps incoming signals (bit 0 and bit 1)
Decodes and prints messages

Last but not least, the Producer implementation, which is pretty straightforward:

#!/usr/bin/env ruby

require_relative 'signal_codec'
require_relative 'broker'

unless File.exist?(Broker::PID)
  abort "Error: Broker not running (#{Broker::PID} not found)"
end

broker_pid = File.read(Broker::PID).strip.to_i
message = ARGV.join(' ')

if message.empty?
  puts "Usage: ruby producer.rb <message>"
  exit 1
end

codec = SignalCodec.new

puts "Sending: #{message}"
codec.send_message(message, broker_pid)
puts "Message sent to broker (PID: #{broker_pid})"

Producer receives a ASCII message from the STDIN
Encode and sends the message to the broker via outgoing signals

So far, this architecture should look familiar. Many broker implementations follow these basic foundations.

Of course, production-ready implementations are far more robust than this one. Here, we're just poking around with hacking and experimentation

The coolest part is the SignalCodec though:

class SignalCodec 
  SIGNAL_DELAY = 0.001 # Delay between signals to allow processing

  def initialize
    @accumulator = 0
    @position = 0
    @buffer = []
  end

  def accumulate_bit(bit)
    @accumulator += (bit << @position)
    @position += 1

    if @position == 8 # Byte is complete
      if @accumulator.zero? # Message complete - NULL terminator
        decoded = @buffer.pack("C*").force_encoding('UTF-8')
        yield(decoded) if block_given?
        @buffer.clear
      else 
        @buffer << @accumulator
      end

      @position = 0
      @accumulator = 0
    end
  end

  def send_message(message, pid)
    message.each_byte do |byte|
      8.times do |i|
        bit = (byte >> i) & 1
        signal = bit == 0 ? 'SIGUSR1' : 'SIGUSR2'
        Process.kill(signal, pid)
        sleep SIGNAL_DELAY
      end
    end

    # Send NULL terminator (0000 0000)
    8.times do
      Process.kill('SIGUSR1', pid)
      sleep SIGNAL_DELAY
    end
  end
end

If you've been following along, this shouldn't be hard to understand, but I'll break down how this beautiful piece of code works:

The codec is initialized with the bit position at zero, as well as the accumulator
A buffer is also initialized to store accumulated bits until a complete byte is formed
The accumulate_bit method should be familiar from our earlier implementation, but it now accepts a closure (block) that lets the caller decide what to do with each decoded byte
send_message encodes a message into bits and sends them via UNIX signals

Everything in action:

How cool, amazing, wonderful, impressive, astonishing is that?

Conclusion

Yes, we built a message broker using nothing but UNIX signals and a bit of Ruby magic. Sure, it's not production-ready, and you definitely shouldn't use this in your next startup (please don't), but that was never the point.

The real takeaway here isn't the broker itself: it's understanding how the fundamentals work. We explored binary operations, UNIX signals, and IPC in a hands-on way that most people never bother with.

We took something "useless" and made it work, just for fun. So next time someone asks you about message brokers, you can casually mention that you once built (or saw) one using just two signals. And if they look at you weird, well, that's their problem. Now go build something equally useless and amazing. The world needs more hackers who experiment just for the fun of it.

Happy hacking!

[Boost]

Leandro Proença — Sun, 12 Jan 2025 21:42:59 +0000

O que realmente agregou profissionalmente quando eu era Junior

Jessilyneh ・ Jan 10

#career #beginners

[Boost]

Leandro Proença — Thu, 02 Jan 2025 16:15:20 +0000

Um resumo do meu 2024

Leandro Proença ・ Dec 31 '24

#braziliandevs

Um resumo do meu 2024

Leandro Proença — Tue, 31 Dec 2024 20:27:13 +0000

31 de Dezembro de 2024.
Sentado no sofá e assistindo Frozen, tive a ideia de escrever sobre minha retrospectiva deste ano. Nunca fiz isso antes, então bora lá, porque acho que foi muita coisa.

Mas antes, um aftermath de 2023

2023 foi um ano bastante agitado pra mim. Passei por uma tireoidectomia (mas estou bem, obrigado) e também foi o ano em que resolvi fazer "learn in public" e deixar tudo gravado no meu canal do Youtube.

Iniciei cobrindo a rinha de compiladores, onde submeti uma versão em Ruby, e depois fui trazendo conteúdo para iniciantes em Rust.
Teve também transmissão ao vivo criando uma Rede Neural Artificial em Ruby, então vi que eu realmente estava gostando de compartilhar minha jornada coding in public.

Na parte de artigos, escrevi muita coisa em 2023:

Introdução ao Tekton CI/CD
Kubernetes 101
Um guia completo cobrindo os fundamentos de Git
Criando redes neurais em Ruby
Teve até artigo sobre ponto flutuante
Fundamentos de recursão
Resumo da rinha de compiladores e trampolim
Mais Rust

E o famoso Guia Web 101 também.

Mentira, esse guia web foi em 2021, mas eu quis colocar ele aqui só pra fazer propaganda mesmo

As metas para 2024

No fim de 2023 estabeleci algumas metas pra 2024 nessa parte de criação de conteúdo. Mas não foram metas muito arrojadas pois eu queria dar uma desaquecida do que foi o agitado 2023.

Dentre as metas estava continuar explorando Rust; escrever um guia completo de concorrência; criar um interpretador em Ruby; fazer lives com Kubernetes; falar sobre tédio e; Awk.

Sim, Awk

Podemos confirmar isto em meio a tantos rascunhos que tenho nesta plataforma:

E chegou 2024

Comecei o ano de 2024 focado em me aprofundar em Rust, tanto que em Janeiro até cheguei a criar o crust (outro CRUD, mas desta vez em Rust) e o aspirina (outra rede neural, mas desta vez em Rust) durante algumas lives. Queria também iniciar meus estudos em Rust na parte de I/O assíncrono. Era esse o plano.

Era.

A Rinha de Backend, 2ª edição

Mas aí veio a rinha de backend do Zan pra tirar meu foco e resolvi fazer lives compartilhando minha solução submetida, que inicialmente seria em Ruby, com o agostinho.

Ledo engano. Acabei por submeter 5 diferentes soluções:

3 em Ruby: agostinho, que usa meus micro frameworks favoritos Adelnor e Chespirito; tortuga que não usa framework nem biblioteca alguma, o puro suco de uma linguagem criada no Japão; e tonico, uma versão sem frameworks que usa I/O assíncrono all the way down
1 em Rust: quokka, criado durante uma live
e claro, a famosa versão em Bash, canabrava

Foram muitas horas em lives, inclusive esta onde eu mostrava como criar uma thread pool e connection pool em Rust.

Nossa Leandro, como você arranja tempo pra fazer lives? Eu não consigo ter tempo pra isso

Isso é problema seu, e não meu.

Um leve sopro do Gleam e o grande tutorial de Assembly

No início do ano notei um pequeno hype em cima do Gleam. Decidi explorar em live. Até que gostei da linguagem, e estava determinado a continuar estudando.

Mas aí minha amiga e meu amigo, algumas pessoas do trabalho começaram a me provocar. Ficavam colocando Assembly na minha frente. Foi quando numa 6a feira sem pretensão, no Discord, eu e mais alguns colegas fizemos um tutorial rápido de Assembly x86.

Foi quando pensei "ta aí, vou aprender esse negócio e criar um web server multi-threaded simples em Assembly, compartilhando a jornada tanto em artigos quanto em lives".

A saga do Assembly x86

Fiz várias lives pela manhã (que eu chamava de lives matinais, duh), mostrando o desenvolvimento do web server e minha saga de aprendizado. Foi incrível, pude ter contato com pessoas como o Blau Araújo que é referência em conteúdo pt-BR em Assembly e outras coisas de baixo nível.

Tem um vídeo no meu canal, que é a minha "sincera" reação quando o server finalmente funcionou devolvendo a primeira resposta HTTP, ao vivo em live.

Não obstante, resolvi também escrever artigos em live. Me diga, quem em sã consciência acompanha alguém escrevendo um artigo em live durante umas 4 ou 5 horas?

Não sei quem é mais maluco

Brincadeiras a parte, e ideia é mesmo compartilhar o processo. É sobre o modus operandi, a forma como eu quebro o raciocínio em partes na hora de escrever. E também o que me inspira.

No mundo dos artigos, eu comecei em Abril a saga "Escrevendo um Web server em Assembly x86". Foram um total de 6 artigos, onde no final conseguimos implementar um web server simples, porém multi-threaded em Assembly. Foram 3 meses escrevendo, fazendo lives e muitos conceitos abordados, muita coisa mesmo.

Aproveitei também para escrever sobre Arrays em Assembly x86.

Esta saga foi muito enriquecedora pra mim. Pude aprender e firmar muitos conceitos. Vale muito a pena aprender Assembly e coisas de baixo nível.

Enfim o "Guia de Concorrência 101"

Quando finalizei a saga de Assembly, resolvi voltar para uma das coisas que eu tinha como meta para 2024: escrever sobre concorrência. Este é um tema que estudo há mais de 5 anos quase que diariamente, experimentando e validando conceitos.

Foi então que bem agora, agorinha mesmo (risos) no final de Novembro que comecei a escrever o guia de concorrência (pt-BR). Por enquanto já abordei conceitos de concorrência no sistema operacional e como a linguagem C implementa as principais primitivas de concorrência. Mas o intuito é cobrir com mais linguagens de programação: Ruby, Python, PHP, NodeJS, Go, Rust, Elixir, Java, Kotlin e mais o que vier à cabeça.

Com uma brincadeira no bluesky, o Rodolfo de Nadai (meu primeiro investidor) deu uma ideia de eu lançar um "buy me a coffee" neste guia. Lancei e gostei da ideia, tanto que no momento são 23 apoiadores do projeto. Apesar de que faço de forma genuína sem interesse financeiro, pois defendo muito o conhecimento livre, este apoio da galera tem sido crucial para que eu continuasse, desde o apoio com Pix, revisão ou mesmo compartlihamento do conteúdo.

Gratidão a todos vocês que fazem isto acontecer ❤

Misc

Outras coisas que explorei ao longo deste ano, enquanto ia focando nas coisas de Assembly e concorrência:

leandronsp/necelu, brincando com Lucene em Java (relembrando the good old days)
open telemetry: OTel é um assunto bem interessante, onde quero me aprofundar em 2025
leandronsp/yacs, Yet Another City Search, uma busca textual ultra-rápida em PostgreSQL em mais de 12 milhões de geonames/cidades

O que esperar pra 2025

Para 2025, espero mergulhar mais fundo em Rust, explorar OpenTelemetry e, quem sabe, encarar outra linguagem inusitada.

Afinal, aprender nunca é demais. 🚀

Feliz 2025 a todes <3

Arrays em Assembly x86

Leandro Proença — Sat, 17 Aug 2024 21:49:05 +0000

Recentemente escrevi uma saga de 6 artigos sobre Assembly x86, abordando conceitos fundamentais de arquitetura de computadores e programação low-level enquanto ia desenvolvendo um web server minimalista multi-threaded.

Durante o processo, acabei deixando de lado alguns conceitos importantes para artigos posteriores, pois se fosse abordar durante a saga, iria ficar maior do que já foi. Entretanto são conceitos que podem ser tratados à parte, como no caso das filas implementadas na thread pool.

E quando falamos de filas, fica inevitável abordar arrays e como estes são organizados na memória do computador.

Neste artigo, vamos abordar conceitos fundamentais como manipulação de memória, registradores e memória heap ao longo da implementação de arrays.

Vou assumir que você já tem familiaridade com Assembly x86 e a ferramenta GDB. Caso não tenha, recomendo fortemente a leitura da minha saga.

Agenda

Arrays não existem
Strings também não existem
O array mais simples do universo
Utilizando um array com dados não inicializados
- Índice para o resgate
- Atingindo o limite do array
Heap, heap, hooray!
- Alocação dinâmica de memória com brk
- Ponteiros, ponteiros everywhere
- Resize com brk
O programa final
Conclusão
Referências

Arrays não existem

Arrays não existem. Simples assim.

Como vimos na parte IV da saga, a memória é organizada de forma contígua, onde as informações são alocadas uma após a outra.

Supondo que queremos declarar a seguinte sequência de informações:



1, 2, 'H', 0

Eu sei, eu sei, os tipos estão misturados, mas isto não importa para este momento. Todos eles cabem em 1 byte

Em assembly x86 (vamos chamar de asm no restante do artigo), podemos declarar estas informações da seguinte forma na seção de dados:



section .data
stuff: db 0x1, 0x2, 0x48, 0x0

Lembrando que o caracter 'H' na tabela ASCII representa 0x48 em hexadecimal

Ao utilizarmos o gdb para fazer debugging, podemos confirmar que esta sequência de hexadecimal no rótulo stuff está armazenada da seguinte forma:



# Leitura do primeiro hexabyte em stuff
(gdb) x/1xb (void*) &stuff
0x402000 <stuff>:       0x01

# Leitura do segundo hexabyte em stuff
(gdb) x/1xb (void*) &stuff+1
0x402001:       0x02

# Leitura do terceiro hexabyte em stuff
(gdb) x/1xb (void*) &stuff+2
0x402002:       0x48

Podemos também representar o hexadecimal 0x48 em formato de string utilizando x/s



(gdb) x/s (void*) &stuff+2
0x402002:       "H"

É tudo hexadecimal!

Com isto, caso queiramos representar a string "Hello", de acordo com a tabela ASCII, poderia ficar assim:



section .data
msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x0

No gdb vamos verificar a representação string do rótulo msg:



(gdb) x/s &msg
0x402000 <msg>: "Hello"

Em asm, é possível declarar a string já com a representação direta da tabela ASCII:



section .data
msg: db "Hello", 0x0

; é o mesmo que
; msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x0

Strings também não existem

Ou seja, é tudo hexadecimal na memória. Um array, assim como uma string, é simplesmente uma sequência contígua de dados com mesmo tamanho na memória.

A diferença é que a string é um "array especial" que tem dados que representam caracteres da tabela ASCII (note que ambos precisam delimitar um byte "final" para representar o término da string ou array):

O array mais simples possível

A seguir temos a implementação de um array bastante simples em asm, pelo que iremos explorar cada passo nas seções subsequentes:



global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0

section .data
array: db 1, 2, 3, 0

section .text
_start:
    mov al, [array]        ; array[0]
    mov bl, [array + 1]    ; array[1]
    mov cl, [array + 2]    ; array[2]
    mov sil, [array + 3]   ; array[3]
.exit:
    mov rdi, EXIT_SUCCESS
    mov rax, SYS_exit
    syscall

Na seção de dados inicializados .data, declaramos um array com 3 elementos de 1 byte cada (inteiros de 1 a 3), utilizando o número 0 como término do array:



section .data
array: db 1, 2, 3, 0

A seguir, na seção .text, que é onde vai o código fonte do programa, podemos acessar os elementos do array utilizando aritmética de ponteiros, armazenando o resultado em registradores:



section .text
_start:
mov al, [array]        ; array[0]

No código acima, estamos acessando o valor contido no endereço de memória 0x402000 e armazenando o resultado em um registrador (AL) que tem o tamanho de 1 byte, ou seja, vai ser armazenado no registrador apenas o primeiro byte do array.

Vamos conferir com gdb:



# O array está armazenado no endereço 0x402000
# e contém o valor em hexa 0x00 0x03 0x02 0x01,
# lembrando que esta arquitetura utiliza o formato little-endian
(gdb) x &array
0x402000 <array>:       0x00030201

(gdb) b 13
(gdb) run
(gdb) next

# No registrador AL temos o primeiro elemento do array
(gdb) i r al
al             0x1                 1

# É o mesmo que acessar o primeiro hexabyte contido no endereço
# 0x402000
(gdb) x/1xb 0x402000
0x402000 <array>:       0x01

Lembrando que o registrador AL representa os 8-bits menores dentro do espectro do registrador RAX que contempla um total de 64-bits na arquitetura x86_64

Para acessar os demais elementos do array, basta fazer aritmética de ponteiros e ir armazenando em outros registradores de 1 byte:



mov al, [array]        ; array[0] => 1
mov bl, [array + 1]    ; array[1] => 2
mov cl, [array + 2]    ; array[2] => 3
mov sil, [array + 3]   ; array[3] => 0 (aqui termina o array)

Utilizando um array com dados não inicializados

Até agora, estamos declarando o array na seção .data onde os dados são inicializados. Mas podemos deixar o programa mais "dinâmico", declarando o array na seção de dados não inicializados, que é a .bss.

Mantendo a compatibilidade com o exemplo anterior, vamos declarar um array de 4 bytes utilizando a diretiva resb que significa "reserve byte", onde os 3 primeiros bytes são reservados para armazenar elementos do array e o último byte representando 0x0 que é o término do array.



section .bss
array: resb 4 ; 3 bytes + 1 byte de término

No gdb, podemos ver que o array está inicializado com os valores tudo a zero, o que indica que o array está vazio mas com 4 bytes reservados:



(gdb) x &array
0x402004 <array>:       0x00000000

(gdb) x/4xb &array
0x402004 <array>:       0x00    0x00    0x00    0x00

Para adicionar elementos no array, precisamos também utilizar aritmética de ponteiros, tal como fizemos no exemplo anterior para acessar um array com dados pré-inicializados.



; Move o valor 1 para o primeiro byte do endereço de memória em array
mov byte [array], 1  ; array[0] = 1

Com gdb confirmamos que no endereço 0x402000 que é onde está o array, foi adicionado o byte 1:



(gdb) x &array
0x402000 <array>:       0x00000001

E se quisermos adicionar o valor 2 no próximo byte do array?



mov byte [array + 1], 2



(gdb) x &array
0x402000 <array>:       0x00000201

Repare que o que modifica é o "índice" do array. Na posição inicial do array, é como se o índice fosse zero, e na posição subsequente, utilizamos o índice 1, podendo incrementar até o término array.

Seria muito complicado ficar manipulando índice hard-coded. Precisamos de um ponteiro para representar este índice.

Índice para o resgate

Assumindo que o ponteiro do array começa com zero, que é o endereço de memória onde está o array, podemos declará-lo na seção de dados inicializados .data:



section .bss
array: resb 4 ; 3 bytes + 1 byte de término

section .data
pointer: db 0

Logo, poderíamos adicionar o primeiro elemento da seguinte forma, certo?



mov byte [array + pointer], 1   ; array + 0

Ao rodar o programa, temos o seguinte erro:



src/live.asm:14: error: invalid effective address: multiple base segments

Este erro indica que estamos tentando fazer manipulação de ponteiros a partir de múltiplos segmentos na memória, no caso o array e pointer.

Para resolver isto, precisamos fazer manipulação de ponteiros com valores imediatos (que foi o caso anterior com número hard-coded) ou com registradores:



; append(1)
mov al, byte [pointer]
mov byte [array + rax], 1   ; array + 0

a primeira instrução move o primeiro byte contido no endereço de pointer e armazena no registrador AL
a segunda instrução move o valor imediato 1 (elemento do array) para o endereço de memória do array. Como em RAX (versão 64-bits de AL) temos o valor 0x0 que representa o ponteiro, então estamos fazendo a inserção no primeiro byte do array

E para armazenar o segundo elemento no array?



; append(2)
mov al, byte [pointer]
mov byte [array + rax], 2

No gdb, vamos verificar o que está acontecendo:



(gdb) x &array
0x402004 <array>:       0x00000002

Uh, oh... Desta forma estamos sobrescrevendo o valor anterior. Queremos na verdade que o ponteiro "ande", ou seja, precisa ser incrementado em um byte para que o append(2) resulte com os 2 elementos no array.

Com a instrução INC podemos resolver este problema:



mov al, byte [pointer]      ; pointer -> 0
mov byte [array + rax], 1   ; array + 0
inc byte [pointer]          ; pointer -> 1

mov al, byte [pointer]
mov byte [array + rax], 2   ; array + 1



(gdb) x &array
0x402004 <array>:       0x00000201

Yay! Que dia maravilhoso!

Atingindo o limite do array

E se continuarmos incrementando o ponteiro até atingir o limite do array?



mov al, byte [pointer]
mov byte [array + rax], 1   ; array + 0
inc byte [pointer]

mov al, byte [pointer]
mov byte [array + rax], 2   ; array + 1
inc byte [pointer]

mov al, byte [pointer]
mov byte [array + rax], 3   ; array + 2
inc byte [pointer]



# Lendo os primeiros 4 hexabytes do array, temos a representação
# do array cheio com todos os espaços ocupados, lembrando que
# o último byte é o término do array
(gdb) x /4xb &array
0x402004 <array>:       0x01    0x02    0x03    0x00

# O ponteiro está no fim do array
(gdb) x &pointer
0x402000 <pointer>:     0x03

Maravilha, e se adicionar mais um elemento, nosso programa deveria permitir?



mov al, byte [pointer]
mov byte [array + rax], 4   ; array + 3
inc byte [pointer]



# Não deveríamos permitir que mais um elemento fosse adicionado,
# pois nosso array já estava cheio
(gdb) x /4xb &array
0x402004 <array>:       0x01    0x02    0x03    0x04

# O ponteiro está para além da capacidade array (not good...)
(gdb) x &pointer
0x402000 <pointer>:     0x04

Vamos utilizar um jump condicional (explico mais sobre isto na saga) para não permitir que o elemento seja adicionado. Com isto, antes de fazer o append no array, devemos verificar se o ponteiro já não está no fim do array:



cmp byte [pointer], 3   ; verifica se o array está cheio
je .exit                ; salta para a rotina .exit caso a flag seja levantada

Assim fica o programa completo:



global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0

section .bss
array: resb 4 ; 3 bytes + 1 byte de término

section .data
pointer: db 0

section .text
_start:
    cmp byte [pointer], 3   ; verifica se o array está cheio
    je .exit

    mov al, byte [pointer]
    mov byte [array + rax], 1   ; array + 0
    inc byte [pointer]

    cmp byte [pointer], 3   ; verifica se o array está cheio
    je .exit

    mov al, byte [pointer]
    mov byte [array + rax], 2   ; array + 1
    inc byte [pointer]

    cmp byte [pointer], 3   ; verifica se o array está cheio
    je .exit

    mov al, byte [pointer]
    mov byte [array + rax], 3   ; array + 2
    inc byte [pointer]

    cmp byte [pointer], 3   ; verifica se o array está cheio
    je .exit

    ; não deveria permitir adicionar o quarto elemento,
    ; pois o array suporta até 3 elementos. desta forma,
    ; estaríamos escrevendo no endereço de memória de outros
    ; dados do programa
    mov al, byte [pointer]
    mov byte [array + rax], 4   ; array + 3
    inc byte [pointer]
.exit:
    mov rdi, EXIT_SUCCESS
    mov rax, SYS_exit
    syscall



(gdb) x &pointer
0x402000 <pointer>:     0x00000003
(gdb) x &array
0x402004 <array>:       0x00030201

Perfeito, vamos agora fazer um pequeno refactoring no código separando a lógica de append para uma subrotina:



global _start

%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb CAPACITY + 1

section .data
pointer: db 0

section .text
_start:
    mov rdi, 1
    call .append

    mov rdi, 2
    call .append

    mov rdi, 3
    call .append

    mov rdi, 4
    call .append
.exit:
    mov rdi, EXIT_SUCCESS
    mov rax, SYS_exit
    syscall
.append:
    cmp byte [pointer], CAPACITY ; verifica se o array está cheio
    je .done

    mov al, byte [pointer]
    mov byte [array + rax], dil
    inc byte [pointer]
.done:
    ret

Se você quer entender mais sobre conditional jump, rotinas, call, ret e flags, sugiro a leitura da minha saga que foi referenciada diversas vezes neste artigo

Executando com gdb e...



(gdb) x &array
0x402004 <array>:       0x00030201

(gdb) x &pointer
0x402000 <pointer>:     0x00000003

Um grande Yay!

Entretanto, podem haver situações onde queremos que nosso array seja redimensionado para suportar mais elementos, ou seja, o tamanho do array seria dinâmico.

Como adicionar mais elementos além da capacidade inicial de forma que não podemos escrever em outras áreas da memória que pertencem ao array?

Heap, heap, hooray!

Antes de falar sobre o heap, vamos relembrar como funciona o layout de memória de um programa de computador:

o layout é representado como uma área na memória do computador onde temos os endereços de memória mais baixos do programa em direção aos endereços mais altos que ficam no topo
nos endereços de memória mais baixos, temos a seção .text, onde já vimos que é referente ao programa em si
depois temos a seção de dados que contempla os dados inicializados .data e a seção a seguir que representa os dados não-inicializados .bss
nos endereços mais altos, temos a stack do programa, que armazena metadados tais como o nome do programa, seus argumentos e qualquer informação do programa que tenha um tamanho fixo cabendo dentro da stack, bem como chamadas de funções e seus respectivos argumentos
a stack tem um formato de pilha e "cresce pra baixo", ou seja, conforme adicionamos elementos na stack, esta cresce em direção aos endereços mais baixos na memória

No "meio" do layout, entre a seção de dados e a stack, temos uma grande área na memória que muitos acabam associando como heap. No heap, podemos alocar dados de forma dinâmica, diferente da forma estática que fazemos na seção de dados.

Para acomodar um array de tamanho dinâmico que suporte redimensionamento (resize), temos de alocar memória nesta área.

Neste artigo, vamos chamar esta região no meio da memória que fica entre a seção de dados e a stack de heap

Alocação dinâmica de memória com brk

Uma das formas de manipular esta área da memória é através da syscall brk, que muda o program break, que é onde termina a seção de dados.

Com brk, podemos modificar esse program break para endereços mais altos, ou seja, permitindo a manipulação de áreas na memória que vão além da seção de programa e dados.

A primeira coisa que precisamos fazer é mapear a syscall e fazer a chamada que traz o endereço do break atual:



%define SYS_brk 12
....

section .text
_start:
; syscall para acessar o program break (0x403000), que é onde termina 
; a seção de dados e começa o heap
mov rdi, 0
mov rax, SYS_brk
syscall
....

Com gdb, vamos analisar o estado do programa:



# Breakpoint na linha da syscall brk
(gdb) b 18
(gdb) run

# O início do programa fica na seção .text e começa com 
# 0x401000
(gdb) x _start
0x401000 <_start>:      0x000000bf

# O pointer está na seção .data um pouco mais acima e começa com
# 0x402000
(gdb) x &pointer
0x402000 <pointer>:     0x00000000

# O array está na seção .bss um pouco mais acima e começa com 
# 0x402004
(gdb) x &array
0x402004 <array>:       0x00000000

# Executa a syscall brk
(gdb) n

# A syscall brk armazena em RAX o endereço de memória do program break, 
# no caso um pouco mais acima em 0x403000
(gdb) i r rax
rax            0x403000            4206592

0x401000: seção .text que é onde começa o programa
0x402000: seção .data onde ficam os dados inicializados
0x402004: seção .bss onde ficam os dados não-inicializados
0x403000: program break, que é onde termina a seção de dados e começa o nosso "heap"

Com isto, a partir do endereço 0x403000 é onde vamos colocar os elementos do nosso array, pelo que o endereço do array pode utilizar apenas um byte, que aponta para o endereço onde começa o primeiro elemento no heap.

Na syscall que fizemos, se o argumento em RDI tiver zero, significa que brk vai retornar o program break atual, no caso 0x403000. Mas podemos fazer mais syscalls brk com o argumento RDI diferente (incrementado), sinalizando que estamos mudando o program break.

A partir de agora, na seção de dados .bss, não precisamos mais reservar 4 bytes para o array, pelo que é necessário apenas 1 byte que irá representar o endereço de memória do array no heap:



global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

; inicialmente começa com 0x000000, mas depois irá conter 
; o endereço 0x403000
section .bss
array: resb 1  

section .data
pointer: db 0

section .text
_start:
    mov rdi, 0
    mov rax, SYS_brk
    syscall

    mov rdi, rax
    add rdi, CAPACITY
    mov rax, SYS_brk
    syscall

...
...

Ao analisarmos com gdb:



# Breakpoint na primeira syscall
(gdb) b 18

(gdb) run

# Executa a linha da syscall
(gdb) n

# Em RAX a syscall armazena o endereço do program break, no caso
# 0x403000
(gdb) i r rax
rax            0x403000            4206592

(gdb) x 0x403000
0x403000:       Cannot access memory at address 0x403000

Neste momento, este endereço ainda não é acessível pois não reservamos novos bytes no heap. Vamos andar com a próxima syscall:



(gdb) n
(gdb) n

# Antes de executar a syscall, verificamos que o argumento RDI vai 
# conter o endereço desejado para o novo program break, no caso com
# 3 bytes adicionados, 0x403003
(gdb) i r rdi
rdi            0x403003            4206595

# Executa a syscall...
(gdb) n
(gdb) n

# Após a execução da segunda syscall, vemos que em RAX, o program break foi alterado para 0x403003
(gdb) i r rax
rax            0x403003            4206595

Agora, podemos acessar os endereços de memória entre 0x403000 e 0x403003:



(gdb) x 0x403000
0x403000:       0x00000000
(gdb) x 0x403001
0x403001:       0x00000000
(gdb) x 0x403002
0x403002:       0x00000000
(gdb) x 0x403003
0x403003:       0x00000000

Uau! Agora temos no heap uma área reservada especialmente para o nosso querido array, olha que coisa!

Como vamos manipular o array nesta região da memória?

Ponteiros, ponteiros everywhere

Após a primeira syscall, devemos pegar o endereço de memória 0x403000 que representa o primeiro program break e armazenar no ponteiro do array que está em .bss:



...
mov rdi, 0
mov rax, SYS_brk
syscall
mov [array], rax      ; <---- breakpoint aqui

mov rdi, rax
add rdi, CAPACITY
mov rax, SYS_brk
syscall
...

Vamos verificar com gdb o breakpoint na linha que muda o ponteiro do array:



(gdb) b 19
(gdb) run

(gdb) x &array
0x402004 <array>:       0x00000000

# Executa a linha que muda o ponteiro
(gdb) n

# Agora o ponteiro aponta para o endereço 0x403000, 
# é isto o que queremos
(gdb) x &array
0x402004 <array>:       0x00403000

Importante notar que array está no endereço 0x402004, na seção .bss, pelo que seu valor representa outro endereço de memória 0x403000 que é onde deve começar o primeiro elemento do array no heap.

Agora, quando fizermos a próxima syscall para alocar 3 bytes no heap, o program break será modificado e iremos conseguir manipular o array pois o ponteiro já aponta para o endereço correto.

Após a segunda syscall, já não podemos mais manipular o array pelo seu valor, pois agora o valor do array já não é mais um elemento de fato, mas sim um endereço para outro lugar na memória.

Vamos ao programa na versão atual:



global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb 1   ; 0x403000

section .data
pointer: db 0

section .text
_start:
    mov rdi, 0
    mov rax, SYS_brk
    syscall
    mov [array], rax

    mov rdi, rax
    add rdi, CAPACITY
    mov rax, SYS_brk
    syscall

    mov rbx, [array]

    mov r8, 1
    call .append

    mov r8, 2
    call .append

    mov r8, 3
    call .append

    mov r8, 4
    call .append
.exit:
    mov rdi, EXIT_SUCCESS
    mov rax, SYS_exit
    syscall
.append:
    cmp byte [pointer], CAPACITY ; verifica se o array está cheio
    je .done

    mov sil, byte [pointer]
    mov byte [rbx + rsi], r8b
    inc byte [pointer]
.done:
    ret

Explicando cada bloco:



mov rdi, 0
mov rax, SYS_brk
syscall
mov [array], rax

busca o program break atual e armazena o endereço no ponteiro array



mov rdi, rax
add rdi, CAPACITY
mov rax, SYS_brk
syscall

modifica o program break atual, incrementando 3 bytes que é a capacidade inicial do array no heap



; atribuir ao registrador o endereço de memória ao qual o
; ponteiro "array" está apontando
mov rbx, [array]

armazena o endereço de memória do ponteiro no registrador RBX. Isto é necessário pois não queremos fazer aritmética diretamente no ponteiro da seção .bss, mas sim através de um registrador que permite



mov r8, 1
call .append

como agora o RDI foi usado como argumento na syscall brk, não convém mais utilizarmos este registrador para representar o elemento a ser adicionado no array, pelo que trocamos pelo registrador R8



.append:
    cmp byte [pointer], CAPACITY ; verifica se o array está cheio
    je .done

    mov sil, byte [pointer]
    mov byte [rbx + rsi], r8b    ; indirect-mode addressing
    inc byte [pointer]
.done:
    ret

Agora a rotina .append foi modificado para que a manipulação do array no heap seja através do registrador RBX. Também não podemos mais usar o registrador RAX para representar o ponteiro pois a syscall brk também utilizou como retorno do program break; neste caso trocamos para o RSI (que tem o SIL como sua representação de 8-bits menores).

Ao executar com gdb, podemos verificar que os elementos estão sendo adicionados no endereço 0x403000 que fica no heap, através do ponteiro que foi armazenado no registrador RBX:



# Array aponta para o endereço 0x403000
(gdb) x &array
0x402004 <array>:       0x00403000

# No endereço, temos os elementos adicionados. Yay!
(gdb) x 0x403000
0x403000:       0x00030201

# E o ponteiro de "índice" corretamente representando o fim do array no heap
(gdb) x &pointer
0x402000 <pointer>:     0x00000003

Neste momento, o programa está com o mesmo comportamento do exemplo anterior com array estático em .bss, não permitindo adicionar mais elementos quando o array atinge seu limite.

Vamos mudar isto, redimensionando o array e permitir que novos elementos sejam adicionados.

Resize com brk

A seguir, iniciamos os passos para que o redimensionamento do array seja feito quando este atingir o limite da capacidade. Começamos por alterar a rotina .append:



.append:
    cmp byte [pointer], CAPACITY ; verifica se o array está cheio
    je .resize

    mov sil, byte [pointer]
    mov byte [rbx + rsi], r8b
    inc byte [pointer]
.done:
    ret
.resize:
    ...

Ao invés de fazer jump para .done quando o array estiver cheio, fazemos jump para outra sub-rotina chamada .resize, que deverá fazer a syscall brk novamente, modificando assim o program break em uma nova área na memória, obedecendo a capacidade inicial do array:



.append:
    cmp byte [pointer], CAPACITY ; verifica se o array está cheio
    je .resize

    mov sil, byte [pointer]
    mov byte [rbx + rsi], r8b
    inc byte [pointer]
.done:
    ret
.resize:
    mov rdi, 0
    mov rax, SYS_brk
    syscall

    mov rdi, rax            ; RDI passa a representar o break atual
    add rdi, CAPACITY       ; adiciona 3 bytes, ficando 0x403006
    mov rax, SYS_brk
    syscall
    jmp .append

a primeira syscall de resize traz o break atual, no caso já sabemos que é 0x403003, que foi alocado no início do programa para o array
a segunda syscall de resize modifica o break atual, alocando assim mais 3 bytes no heap
ao fim do resize, ao invés de retornar a função, vamos voltar para o início do .append e executar a lógica necessária para adicionar o elemento no array

Desta forma, podemos manipular esta nova área na memória para adicionar mais elementos no array, modificando assim sua capacidade dinamicamente.

Se executarmos o programa exatamente assim, vamos enfrentar um problema, pois:

a cada vez que é feito o resize, salta para o início da rotina
é verificado o tamanho do array (pointeiro) com a capacidade inicial, que no caso é 3. Como o ponteiro atingiu o valor 3, então vai entrar novamente no resize caracterizando assim um loop infinito com resize infinito até acabar a memória

Para resolver isto, precisamos comparar o pointer com a capacidade atual (modificada), e portanto vamos adicionar um valor na seção .data que representa a capacidade atual:



%define CAPACITY 3

section .data
pointer: db 0
currentCapacity: db CAPACITY ; começa com 3

Na rotina .append, vamos fazer a comparação com o currentCapacity, que vai ser modificado a cada resize, ao invés de ser com CAPACITY, que vai permanecer fixo com o valor inicial enquanto durar o programa.



.append:
    mov r9, [currentCapacity]
    cmp byte [pointer], r9b     ; verifica se o array está cheio
    je .resize
...

E, após o redimensionamento antes de voltar pro .append, vamos incrementar o valor da capacidade inicial à capacidade atual:



.resize:
    mov rdi, 0
    mov rax, SYS_brk
    syscall

    mov rdi, rax
    add rdi, CAPACITY
    mov rax, SYS_brk
    syscall

    mov r10, currentCapacity
    add byte [r10], CAPACITY
    jmp .append

Ao executar o programa, podemos ver que o elemento 4 foi adicionado com sucesso no array após o redimensionamento:



(gdb) x 0x403000
0x403000:       0x04030201

E se adicionarmos mais e mais elementos?



...
    mov r8, 4
    call .append

    mov r8, 5
    call .append

    mov r8, 6
    call .append

    mov r8, 7
    call .append
...



# Podemos ver que o currentCapacity é 9, ou seja, foram feitos 
# 2 redimensionamentos. Nosso array consegue agora acomodar até 9 elementos, 
# pelo que ao adicionar o décimo elemento, mais um resize seria feito.
(gdb) x &currentCapacity
0x402001 <currentCapacity>:     0x09

# Buscando os 9 primeiros hexabytes no endereço do array no heap
(gdb) x/9xb  0x403000
0x403000:       0x01    0x02    0x03    0x04    0x05    0x06    0x07    0x00
0x403008:       0x00

How cool is that?

O programa final

A seguir o programa final, com um array de capacidade inicial de 3 elementos no heap que pode ser redimensionado utilizando a syscall brk, conforme mais elementos vão sendo adicionados no array:



global _start

%define SYS_brk 12
%define SYS_exit 60
%define EXIT_SUCCESS 0
%define CAPACITY 3

section .bss
array: resb 1

section .data
pointer: db 0
currentCapacity: db CAPACITY ; capacidade inicial é 3

section .text
_start:
    mov rdi, 0
    mov rax, SYS_brk
    syscall
    mov [array], rax

    mov rdi, rax
    add rdi, CAPACITY
    mov rax, SYS_brk
    syscall

    mov rbx, [array]

    mov r8, 1
    call .append

    mov r8, 2
    call .append

    mov r8, 3
    call .append

    mov r8, 4
    call .append

    mov r8, 5
    call .append

    mov r8, 6
    call .append

    mov r8, 7
    call .append
.exit:
    mov rdi, EXIT_SUCCESS
    mov rax, SYS_exit
    syscall
.append:
    mov r9, [currentCapacity]
    cmp byte [pointer], r9b ; verifica se o array está cheio
    je .resize

    mov sil, byte [pointer]
    mov byte [rbx + rsi], r8b
    inc byte [pointer]
.done:
    ret
.resize:
    mov rdi, 0
    mov rax, SYS_brk
    syscall

    mov rdi, rax
    add rdi, CAPACITY
    mov rax, SYS_brk
    syscall

    mov r10, currentCapacity
    add byte [r10], CAPACITY
    jmp .append

Conclusão

Neste artigo, mostramos a implementação de um array em Assembly x86, passando por conceitos importantes como layout de memória, manipulação de registradores e alocação dinâmica de memória com brk.

Este artigo é base para artigos futuros sobre estruturas de dados, onde pretendo escrever sobre a implementação de filas e posteriormente listas ligadas.

Stay tuned!

Referências

Addressing modes
https://www.tutorialspoint.com/assembly_programming/assembly_addressing_modes.htm
Syscall brk
https://man7.org/linux/man-pages/man2/brk.2.html
ASCII table
https://www.asciicharstable.com/_site_media/ascii/ascii-chars-table-landscape.jpg

Construindo um web server em Assembly x86, the grand finale, multi-threading

Leandro Proença — Sun, 14 Jul 2024 02:37:25 +0000

Uma vez que temos um web server funcional, podemos dar o próximo (e último) passo, que é deixar o servidor minimamente escalável fazendo uso de uma pool de threads.

Neste artigo, vamos mergulhar nas entranhas da implementação de uma pool de threads com sincronização através de locks, e para atingir tal feito em assembly abordaremos filas, alocação dinâmica de memória e controle de locks com futex.

Ao fim deste artigo, que é o último da saga, teremos uma visão mais holística sobre como funciona um web server e como uma pool de threads poderia ser implementada em linguagens de baixo nível.

Respira e vem comigo, esta última parte será uma avalanche de conceitos.

Agenda

Simulando a latência com nanosleep
Simulando requests em escala com xargs
Concorrência com forking de processos
Concorrência com clone de processo
Concorrência com threads
- Entendendo a criação de uma thread
- Thread flags
- Alocação de memória com brk
- Modificando o server para suportar multi-threading
Concorrência com thread pool
- Uma thread em loop
- 5 threads em loop
- Sincronização com futex
Alocação de memória com mmap
Conclusão
Referências

Simulando a latência com nanosleep

Quando uma requisição é feita a um web server, o tempo de resposta total é um somatório de toda a latência envolvida na comunicação, desde o momento em que o pedido sai da origem (client), passando pela rede de computadores (internet), chegando no destino (server), sendo processado, para então a resposta fazer o caminho inverso até voltar ao client.

Quanto maior a latência em qualquer parte do processo, maior o tempo de resposta, e portanto menor a capacidade de entregar respostas de diferentes requisições em um determinado intervalo de tempo.

A esta capacidade de processar requisições em um intervalo de tempo chamamos de throughput. O que queremos no fim das contas é aumentar o throughput sem comprometer a latência. Esta é uma das premissas para sistemas escaláveis, mas o foco deste artigo não será em escalabilidade necessariamente.

No artigo anterior, finalizamos o web server que apenas responde no socket uma mensagem HTML contendo "Hello, world". A seguir o código inicial do server, que será a base para o restante do artigo:

global _start

%define SYS_socket 41
%define SYS_bind 49
%define SYS_listen 50
%define SYS_accept4 288
%define SYS_write 1
%define SYS_close 3

%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0
%define BACKLOG 2
%define CR 0xD
%define LF 0xA

section .data
sockaddr:
    sa_family: dw AF_INET   ; 2 bytes
    port: dw 0xB80B         ; 2 bytes
    ip_addr: dd 0           ; 4 bytes
    sin_zero: dq 0          ; 8 bytes
response: 
    headline: db "HTTP/1.1 200 OK", CR, LF
    content_type: db "Content-Type: text/html", CR, LF
    content_length: db "Content-Length: 22", CR, LF
    crlf: db CR, LF
    body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response

section .bss
sockfd: resb 1

section .text
_start:
.socket:
    ; int socket(int domain, int type, int protocol)
    mov rdi, AF_INET
    mov rsi, SOCK_STREAM
    mov rdx, SOCK_PROTOCOL
    mov rax, SYS_socket
    syscall
.bind:
    mov [sockfd], rax
    ; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
    mov rdi, [sockfd]
    mov rsi, sockaddr
    mov rdx, 16
    mov rax, SYS_bind
    syscall
.listen:
    ; int listen(int sockfd, int backlog)
    mov rdi, [sockfd]
    mov rsi, BACKLOG
    mov rax, SYS_listen
    syscall
.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0
    mov rdx, 0
    mov r10, 0
    mov rax, SYS_accept4
    syscall
    mov r8, rax
    call handle
    jmp .accept
handle:
    ; int write(fd)
    mov rdi, r8
    mov rsi, response
    mov rdx, responseLen
    mov rax, SYS_write
    syscall

    ; int close(fd)
    mov rdi, r8
    mov rax, SYS_close
    syscall
    ret

Até aqui tudo normal. A rotina accept fica em loop chamando a rotina handle que escreve "Hello, world" na resposta de cada requisição que chega no socket.

Com strace, podemos ver as chamadas que foram feitas após uma requisição com curl:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0

socket, bind, listen, para então iniciar o accept, que ao receber uma requisição HTTP, passa para write, close e então voltar ao accept novamente em loop.

Para simular um pouco de latência, vamos fazer com que a resposta demore cerca de 1 segundo, e para tanto precisamos utilizar uma syscall no Linux chamada nanosleep, que suspende a execução da thread atual até atingir um tempo decorrido especificado com base no relógio monotônico do sistema:

Primeiro definimos a syscall, que tem o código 35:

%define SYS_nanosleep 35

Na rotina handle, antes de escrever a resposta no socket, fazemos a chamada de sistema para nanosleep passando como argumento uma struct que representa um timespec, que contempla o tempo decorrido em segundos e nano-segundos:

handle:
    ; int nanosleep(timespec duration)
    lea rdi, [timespec]
    mov rax, SYS_nanosleep
    syscall

    ; int write(fd)
    ...

    ; int close(fd)
    ...

E na seção de dados, definimos o tempo decorrido em segundos, que são os primeiros 8 bytes da struct, deixando a zero os 8 bytes restantes que representam o tempo em nano-segundos

section .data
timespec:
    tv_sec: dq 1
    tv_nsec: dq 0

Neste exemplo queremos que o sleep seja de 1 segundo

Com strace, podemos ver que a syscall nanosleep foi executada após o accept e antes do write:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0

accept4(3, NULL, NULL, 0)               = 4
nanosleep({tv_sec=1, tv_nsec=0}, NULL)  = 0
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86

close(4)                                = 0
accept4(3, NULL, NULL, 0

Calculando o tempo decorrido com o utilitário time:

$ time curl localhost:3000

<h1>Hello, World!</h1>
real    0m1.040s
user    0m0.005s
sys     0m0.009s

Podemos também encurtar a resposta do time trazendo apenas o tempo real, exportando a variável na sessão shell atual ou adicionando no bashrc:

export TIMEFORMAT=%R

$ time curl localhost:3000
<h1>Hello, World!</h1>1.036

Yay! Já conseguimos simular uma latência de 1 segundo em Assembly. Agora vamos ver se nosso web server tem a capacidade de atender a requests em escala.

Simulando requests em escala com xargs

Para começar, vamos simular 10 requests sequenciais com curl. Poderíamos ficar digitando curl localhost:3000 10 vezes, ou então ser pragmáticos, automatizar sem reinventar a roda e nem instalar nada adicional no sistema.

Como?

xargs.

xargs é um utilitário presente na maioria dos sistemas operacionais UNIX-like, que lê strings a partir de arquivos ou standard input e utiliza estas strings como argumentos para comandos arbitrários.

Vamos ter como exemplo uma sequência de 1 a 10 em bash:

$ echo ${1..10}
1 2 3 4 5 6 7 8 9 10

Podemos utilizar cada valor do echo como argumento para o xargs:

$ echo {1..10} | xargs -n1
1
2
3
4
5
6
7
8
9
10

A opção -n1 significa a quantidade de argumentos que serão usados para o comando que vem a seguir ao xargs, que no caso queremos apenas 1 argumento, o que neste caso tanto faz pois não queremos fazer nada com o argumento: queremos apenas executar o comando curl 10 vezes.

Podemos então agora executar o curl com o time para saber o tempo decorrido de cada request:

$ time echo {1..10} | xargs -n1 bash -c "time curl localhost:3000"

<h1>Hello, World!</h1>1.037
<h1>Hello, World!</h1>1.033
<h1>Hello, World!</h1>1.025
<h1>Hello, World!</h1>1.037
<h1>Hello, World!</h1>1.032
<h1>Hello, World!</h1>1.026
<h1>Hello, World!</h1>1.019
<h1>Hello, World!</h1>1.046
<h1>Hello, World!</h1>1.053
<h1>Hello, World!</h1>1.041
10.426

Claramente, vemos que cada request demorou cerca de 1 segundo, o que no total o tempo decorrido foi de 10,4 segundos. Esta é a latência total para o caso de fazermos requisições sequenciais.

E se fizermos requisições simultâneas? Num cenário mais próximo do real, vamos supor que nossa aplicação web recebe 10 requisições no mesmo segundo em horários de pico.

Para isto, conseguimos também utilizar o xargs para simular, através da opção -P, que representa a quantidade de processos simultâneos que o xargs irá utilizar para realizar os comandos.

Incrível! Com isto nosso web server atende 10 requisições simultâneas, fazendo com que o throughput total dos 10 requests fique em torno de 1 segundo, certo?

Calma, calabreso, vamos testar.

$ time echo {1..10} | xargs -n1 -P10 bash -c "time curl localhost:3000"

<h1>Hello, World!</h1>1.053
<h1>Hello, World!</h1>2.071
<h1>Hello, World!</h1>3.076
<h1>Hello, World!</h1>4.087
<h1>Hello, World!</h1>5.088
<h1>Hello, World!</h1>6.106
<h1>Hello, World!</h1>7.140
<h1>Hello, World!</h1>8.154
<h1>Hello, World!</h1>9.168
<h1>Hello, World!</h1>10.183
10.214

Não melhorou nada! Ter 10 requests simultâneos não quer dizer que nosso server consiga atender os 10 requests ao mesmo tempo. Muito pelo contrário, pode até piorar e prejudicar a latência total, pois há diversos requests na fila esperando para serem atendidos.

o primeiro request demora 1 segundo
o segundo request chega ao mesmo tempo mas demora 2 segundos
o terceiro request chega ao mesmo tempo mas demora 3 segundos
e assim sucessivamente...

Nosso server é síncrono, e com isto podemos criar gargalos. Precisamos então que o server consiga lidar com concorrência.

Concorrência com forking de processos

Uma das formas primitivas de concorrência e escalar um web server para atender mais de um request em simultâneo é com o uso de processos. Como cada processo no sistema operacional tem sua memória isolada dos demais, podemos fazer com que cada request seja atendido em um processo diferente.

Para entender esta técnica, precisamos compreender que todo programa de computador roda em um processo no sistema operacional, e isto vimos bastante nos artigos anteriores. Dentro deste processo, o programa ainda roda em uma unidade de execução no SO chamada thread.

Todo processo tem uma thread chamada thread principal, que é onde está sendo executado o programa

No exemplo anterior, quando chamamos o sleep, a thread que está sendo suspensa por um tempo determinado é justamente a thread principal do programa.

A thread compartilha a memória do processo o qual ela faz parte, mas como precisamos criar outro processo, temos de fazer um forking, que basicamente cria um processo filho copiando tudo o que o programa principal tem.

Repare que cada processo filho tem uma cópia do processo principal. O loop é basicamente o accept do nosso web server, que fica em loop. Desta forma cada request pode ser atendido por um processo diferente, de forma concorrente.

Podemos fazer forking de processo com o uso da syscall fork:

%define SYS_fork 57

A rotina handle mantém igual, com o sleep antes de escrever a resposta no socket:

handle:
    lea rdi, [timespec]
    mov rax, SYS_nanosleep
    syscall

    ; int write(fd)
    mov rdi, r8
    mov rsi, response
    mov rdx, responseLen
    mov rax, SYS_write
    syscall

    ; int close(fd)
    mov rdi, r8
    mov rax, SYS_close
    syscall
    ret

E na rotina accept, adicionamos a chamada do fork logo após o request chegar no socket:

.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0
    mov rdx, 0
    mov r10, 0
    mov rax, SYS_accept4
    syscall
    mov r8, rax

    ; fork de processo
    mov rax, SYS_fork
    syscall

    ; se o retorno do fork for ZERO, significa que está sendo executado
    ; a partir do processo filho. Então a rotina "handle" é executada
    test rax, rax
    jz handle

    ; quando o retorno não é ZERO, significa que a execução do programa 
    ; principal continuou. Então o processo principal volta para o loop
    jmp .accept

depois de uma chamada ao fork, a syscall retorna ZERO quando se está dentro do processo filho. Neste caso, a execução do processo filho continua com a rotina handle e depois termina
após a chamada do fork, se o retorno NÃO for ZERO, significa que a execução é do programa principal, então neste caso volta-se ao loop para esperar um novo request no socket

Ao executar com strace, podemos ver várias chamadas à syscall fork:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
fork(strace: Process 12787 attached
)                                  = 12787
[pid 12786] accept4(3, NULL, NULL, 0 <unfinished ...>
[pid 12787] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 12786] <... accept4 resumed>)      = 5
[pid 12786] fork(strace: Process 12788 attached
)                      = 12788
[pid 12788] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 12786] accept4(3, NULL, NULL, 0)   = 6
[pid 12786] fork(strace: Process 12789 attached
)                      = 12789
[pid 12786] accept4(3, NULL, NULL, 0)   = 7
[pid 12786] fork( <unfinished ...>
[pid 12789] nanosleep({tv_sec=1, tv_nsec=0}, strace: Process 12790 attached
 <unfinished ...>
[pid 12786] <... fork resumed>)         = 12790
[pid 12790] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 12786] accept4(3, NULL, NULL, 0)   = 8
[pid 12786] fork(strace: Process 12791 attached

E os tempos de resposta para 10 requests simultâneos:

$ time echo {1..10} | xargs -n1 -P10 bash -c "time curl localhost:3000"

<h1>Hello, World!</h1>1.049
<h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1>1.051
1.053
1.052
1.055
<h1>Hello, World!</h1>1.051
<h1>Hello, World!</h1>1.052
<h1>Hello, World!</h1>1.056
<h1>Hello, World!</h1>2.106
<h1>Hello, World!</h1>2.116
2.138

Yay! Podemos ver que os requests são atendidos de forma concorrente, e que o tempo total ficou em 2,1 segundos para 10 requests simultâneos!

Lembrando que, quando estamos lidando com concorrência, não temos controle da ordem de execução dos processos, que são escalonados pelo sistema operacional. Esta preempção de processos pode fazer com que um request que chegou depois seja atendido primeiro. É uma das características de race condition e é por isso que vemos os requests chegando fora de ordem.

Mas no nosso caso não importa. Cada request é único e não depende do anterior.

Concorrência com clone de processo

Outra forma muito similar à chamada fork é através da syscall clone, que basicamente clona um processo, tal como fizemos no exemplo anterior, garantindo isolamento e concorrência.

%define SYS_clone 56

E a diferença é que chamamos a syscall de clone, ao invés da syscall fork:

.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0
    mov rdx, 0
    mov r10, 0
    mov rax, SYS_accept4
    syscall
    mov r8, rax

    ; chamada à syscall clone
    ; com argumentos a ZERO, significa que será feito um clone do processo
    mov rdi, 0
    mov rsi, 0
    mov rax, SYS_clone
    syscall

    ; se o retorno for zero, execução é a partir do processo filho
    test rax, rax
    jz handle

    ; continuação da execução do processo principal
    jmp .accept

depois de uma chamada ao clone, a syscall retorna ZERO quando se está dentro do processo filho. Neste caso, a execução do processo filho continua com a rotina handle e depois termina
após a chamada do clone, se o retorno NÃO for ZERO, significa que a execução é do programa principal, então neste caso volta-se ao loop para esperar um novo request no socket

Executamos com strace e:

<h1>Hello, World!</h1><h1>Hello, World!</h1>1.062
1.064
<h1>Hello, World!</h1><h1>Hello, World!</h1>1.063
1.061
<h1>Hello, World!</h1><h1>Hello, World!</h1>1.071
1.061
<h1>Hello, World!</h1>1.059
<h1>Hello, World!</h1>1.069
<h1>Hello, World!</h1><h1>Hello, World!</h1>2.135
2.128
2.148

Ainda servindo 10 requests simultâneos perto dos 2 segundos! Not bad.

Entretanto, forking ou clone de processos leva a um gasto excessivo de memória, pois cada processo filho é exatamente uma cópia do processo principal. Se o principal tem 200MB de memória, com 4 forks teríamos um gasto total de 800MB de memória.

Chegou o momento de falarmos das threads.

Concorrência com threads

Vamos relembrar o que falamos no início do artigo:

Todo processo tem uma thread chamada thread principal, que é onde está sendo executado o programa

Apesar de todo programa rodar dentro de uma thread, podemos também criar mais threads que compartilham a memória do mesmo processo, e para isto podemos fazer uso da mesma syscall clone, mas passando argumentos diferentes que tornam este clone uma thread dentro do mesmo processo, e não uma cópia inteira do processo.

Desta forma, ficamos sempre com UM processo mas atendendo requests em threads diferentes, gastando assim menos memória se comparado com forking de processos.

Entendendo a criação de uma thread

Antes de adaptarmos o código do server para utilizar threads, vamos dar um passo atrás e entender como se cria uma thread em Assembly.

Para criar uma thread, fazemos uso da syscall clone. De acordo com a documentação, a syscall clone cria um processo "filho", similar ao que fizemos no fork. Mas a diferença é que a syscall clone permite um maior controle sobre o que será compartilhado entre o processo principal e o processo filho.

%define SYS_clone 56

Coisas que podem ser compartilhadas (ou não):

espaço de endereço de memória virtual
tabela de descritores de arquivos
tabela de handlers de sinais
entre outros recursos...

No exemplo anterior utilizamos a syscall clone passando argumentos a ZERO, o que significa que não queríamos compartilhar nada entre os processos, portanto uma cópia seria feita como no forking de processos

Para a execução da syscall, precisamos enviar 2 argumentos:

rdi: representa as flags, que modificam o comportamento do que será compartilhado com o processo filho (thread)
rsi: ponteiro para a função que a thread irá executar, que precisa ser definido dentro de uma área reservada na memória, ou seja, precisamos alocar um novo bloco de memória para a thread poder colocar a função e seus argumentos

Portanto, para criar uma thread, precisamos de thread flags e alocação de memória.

Thread flags

Em RDI, vamos passar as seguintes flags:

CLONE_VM: processo principal e processo filho compartilham o mesmo espaço de memória virtual
CLONE_FS: processos compartilham o mesmo sistema de arquivos
CLONE_FILES: processos compartilham a mesma tabela de descritor de arquivos (file descriptor table)
CLONE_SIGHAND: processos compartilham a mesma tabela de handlers de sinais (signal handlers)
CLONE_PARENT: processos compartilham o mesmo parent, ou seja, o processo "filho" na verdade é filho do processo parent do processo original (mesmo porque estamos falando de uma thread que compartilha o mesmo processo)
CLONE_THREAD: o processo filho é colocado no mesmo grupo de threads do processo original
CLONE_IO: processos compartilham o mesmo contexto de I/O

No fim das contas, estamos criando um processo "filho" mas que compartilha recursos com o processo principal. Este é o princípio da thread.

mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO

Alocação de memória com brk

Em RSI, precisamos indicar o ponteiro para a função na memória, neste caso o ponteiro da rotina handle, que tem a lógica de imprimir a mensagem e etc. Mas aqui não basta indicar o ponteiro, mas sim em que região da memória do processo a thread irá armazenar a função, seus argumentos e variáveis locais.

Cada thread precisa ter sua própria região na memória para armazenar a função e argumentos. É como se a thread tivesse uma área de "stack" só dela

Para alocar memória, vamos relembrar como funciona o layout de um programa na memória:

Nos endereços de memória mais baixos, temos o programa, e a seguir temos os dados estáticos (data). No topo, que é onde ficam os endereços mais altos, temos a stack.

E no meio, o que temos a seguir a seção de dados é uma área enorme disponível na memória. A syscall brk permite mudar o ponto onde termina a seção de dados, também chamado de program break.

Podemos ficar mudando este break em direção aos endereços mais altos. Por exemplo, se chamarmos a syscall brk passando argumento ZERO, ela devolve o endereço de memória do program break, que é onde termina a seção de dados:

%define SYS_brk 12

...

mov rdi, 0
mov rax, SYS_brk
syscall

O que temos em RAX é 0x403000, que é exatamente o endereço de memória onde termina a seção de dados. Vamos modificar o break andando UM byte pra frente:

mov rdi, rax
add rdi, 1
mov rax, SYS_brk
syscall

Agora, RAX traz o endereço do novo program break, que é 0x403001. Ou seja, agora podemos manipular este endereço de memória no nosso programa.

E o quê isto tem a ver com a thread?

Podemos alocar uma quantidade arbitrária de bytes para a thread utilizar nesta área na memória. Como o break é sempre modificado, a próxima thread irá utilizar outra área de memória, e assim sucessivamente!

Um "Hello, world" com threads em Assembly

Vamos escrever um exemplo simples antes de ir para o web server. Primeiro, definimos as constantes, dentre elas as syscalls e as flags pra criação de threads:

global _start

%define SYS_brk 12
%define SYS_clone 56
%define SYS_write 1        
%define SYS_exit 60

%define STDOUT 1
%define CHILD_STACK_SIZE 4096

%define CLONE_VM 0x00000100
%define CLONE_FS 0x00000200
%define CLONE_FILES 0x00000400
%define CLONE_PARENT 0x00008000
%define CLONE_THREAD 0x00010000
%define CLONE_IO 0x80000000
%define CLONE_SIGHAND 0x00000800

A seguir, na seção de dados, temos a mensagem "Hello, world" que a thread irá imprimir:

section .data
msg: db "Hello"
msgLen: equ $ - msg

Na seção text, o entrypoint do programa faz uma chamada à rotina da thread e a seguir termina:

section .text
_start:
    call thread

    mov rdi, 0
    mov rax, SYS_exit
    syscall

Agora, a definição da rotina handle que a thread irá executar:

handle:
    mov rdi, STDOUT
    mov rsi, msg
    mov rdx, msgLen
    mov rax, SYS_write
    syscall

    mov rdi, 0
    mov rax, SYS_exit
    syscall

A thread imprime a mensagem no STDOUT e termina. Sim, a thread precisa terminar, caso contrário o sistema emite um segmentation fault

E por fim, vamos detalhar o processo da rotina da thread (explicação nos comentários do exemplo a seguir):

thread:
    ; Busca o break atual e guarda em RDX. Na primeira vez, o valor
    ; é 0x403000
    mov rdi, 0
    mov rax, SYS_brk
    syscall
    mov rdx, rax

    ; Modifica o break atual andando 4096 bytes à frente.
    ; Após esta chamada, o break passa a ser 0x404000
    mov rdi, rax
    add rdi, CHILD_STACK_SIZE
    mov rax, SYS_brk
    syscall

    ; (1) Thread flags: como deve ser feito o compartilhamento de recursos
    ; entre o processo principal e o processo filho
    mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO

    ; (2a) Endereço de memória em RSI: é o break atual + 4096 bytes.
    ; Retiramos também 8 bytes para caber o ponteiro da função
    lea rsi, [rdx + CHILD_STACK_SIZE - 8]

    ; (2b) No endereço em RSI colocamos o ponteiro da função "handle".
    ; Como endereçamento em x86_64 é de 8 bytes, é por isto
    ; que no passo anterior fizemos [rdx + 4096 - 8]
    mov qword [rsi], handle
    mov rax, SYS_clone
    syscall
    ret

E pronto, ao executar o programa, temos a mensagem "Hello" na saída do programa que foi feita pela thread.

Caso o programa principal faça call thread 2 vezes, a próxima thread irá ter em RSI o break modificado, iniciando em 0x404000.

Modificando o server para suportar multi-threading

Agora vamos trazer o código necessário para modificar o server:

%define SYS_clone 56
%define SYS_brk 12

Thread flags:

%define CHILD_STACK_SIZE 4096
%define CLONE_VM 0x00000100
%define CLONE_FS 0x00000200
%define CLONE_FILES 0x00000400
%define CLONE_PARENT 0x00008000
%define CLONE_THREAD 0x00010000
%define CLONE_IO 0x80000000
%define CLONE_SIGHAND 0x00000800

Rotina accept:

.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0
    mov rdx, 0
    mov r10, 0
    mov rax, SYS_accept4
    syscall
    mov r8, rax

    ; Chamada da thread. Irá ser executada assincronamente tal como no
    ; forking de processos, mas compartilhando a memória do
    ; processo principal
    call thread

    ; Processo principal volta para o loop
    jmp .accept

Definição da thread:

thread:
    mov rdi, 0
    mov rax, SYS_brk
    syscall
    mov rdx, rax

    mov rdi, rax
    add rdi, CHILD_STACK_SIZE
    mov rax, SYS_brk
    syscall

    mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO
    lea rsi, [rdx + CHILD_STACK_SIZE - 8]
    mov qword [rsi], handle
    mov rax, SYS_clone
    syscall
    ret

Aqui seguimos o mesmo padrão do exemplo anterior: aloca memória com brk e a seguir executa a syscall clone com as flags de compartilhamento de recursos

E a lógica da rotina handle que será executada pela thread, que faz o sleep, a seguir escreve no socket a mensagem, fecha o socket da requisição e por fim termina sua execução:

handle:
    lea rdi, [timespec]
    mov rax, SYS_nanosleep
    syscall

    ; int write(fd)
    mov rdi, r8
    mov rsi, response
    mov rdx, responseLen
    mov rax, SYS_write
    syscall

    ; int close(fd)
    mov rdi, r8
    mov rax, SYS_close
    syscall

    mov rdi, 0
    mov rax, SYS_exit
    syscall

Com 1 chamada isolada, temos o seguinte output com strace:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
brk(NULL)                               = 0x9da000
brk(0x9db000)                           = 0x9db000
clone(child_stack=0x9daff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13078 attached
) = 13078
[pid 13078] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 13077] accept4(3, NULL, NULL, 0 <unfinished ...>
[pid 13078] <... nanosleep resumed>0x9daff8) = 0
[pid 13078] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
[pid 13078] close(4)                    = 0
[pid 13078] exit(0)                     = ?
[pid 13078] +++ exited with 0 +++
<... accept4 resumed>)                  = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
accept4(3, NULL, NULL, 0

Vamos reparar na sequência de chamadas:

depois do accept, foi feita uma chamada a brk modificando o program break (alocando memória)
a seguir, vemos a chamada clone, que acoplou o processo filho 13078
a thread (13078) é suspensa com nanosleep por 1 segundo
o processo principal (13077) volta para o accept e fica a espera de mais requests
a thread escreve no socket
a thread fecha o socket
a thread é encerrada com exit

Agora, simulando os 10 requests simultâneos:

<h1>Hello, World!</h1>1.060
<h1>Hello, World!</h1>1.064
<h1>Hello, World!</h1>1.064
<h1>Hello, World!</h1>1.062
<h1>Hello, World!</h1>1.068
<h1>Hello, World!</h1>1.073
<h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1>2.098
2.094
2.097
2.091
2.113

Superb! Temos o mesmo tempo total de 2,1 segundos mas gastando muito menos memória!

Entretanto, temos um pequeno problema. Imagina que num momento de grande número de acessos, a nossa aplicação recebe 1000 requests concorrentes. E se receber 5000? Ou então dezenas de milhares de requests simultâneos?

Uma chamada de sistema tem custo. O sistema operacional oferece um limite de threads que podem ser criadas ao mesmo tempo por processo. Se deixarmos assim, nossa aplicação corre um grande risco de ultrapassar esse limite, além de que chamadas a brk + clone têm seus custos de criação.

E se pudéssemos reciclar um número limitado de threads? Sim, estamos falando de pool de threads.

Concorrência com thread pool

A forma mais comum de trabalhar com thread é com thread pool. Basicamente, definimos um número arbitrário de threads que nunca terminam, mas ficam em loop consumindo mensagens de alguma estrutura de dados. Esta estrutura pode ser uma fila.

Uma thread em loop

Vamos inicialmente definir que teremos apenas UMA thread em loop lendo mensagens da fila. O processo deverá ser o seguinte:

processo principal inicia uma thread
a thread fica em loop lendo mensagens (socket) da fila. Quando tiver vazia, repete o loop. Quando houver algum socket na fila, a thread executa a lógica que é fazer o nanosleep, escrever no socket, fechar o socket, e voltar para o loop de leitura da fila
processo principal continua execução após criação da thread, onde fica em loop lendo requisições que chegam no socket (accept). Quando uma requisição chega, adiciona o socket na fila e volta para o loop do accept.

Vamos passo a passo, começando pelas constantes:

global _start

%define SYS_socket 41
%define SYS_bind 49
%define SYS_listen 50
%define SYS_accept4 288
%define SYS_write 1
%define SYS_close 3

%define SYS_nanosleep 35
%define SYS_clone 56
%define SYS_brk 12
%define SYS_exit 60

%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0
%define BACKLOG 2
%define CR 0xD
%define LF 0xA

%define CHILD_STACK_SIZE 4096
%define CLONE_VM 0x00000100
%define CLONE_FS 0x00000200
%define CLONE_FILES 0x00000400
%define CLONE_PARENT 0x00008000
%define CLONE_THREAD 0x00010000
%define CLONE_IO 0x80000000
%define CLONE_SIGHAND 0x00000800

A seguir, a seção de dados:

section .data
sockaddr:
    sa_family: dw AF_INET   ; 2 bytes
    port: dw 0xB80B         ; 2 bytes
    ip_addr: dd 0           ; 4 bytes
    sin_zero: dq 0          ; 8 bytes
response: 
    headline: db "HTTP/1.1 200 OK", CR, LF
    content_type: db "Content-Type: text/html", CR, LF
    content_length: db "Content-Length: 22", CR, LF
    crlf: db CR, LF
    body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response
timespec:
    tv_sec: dq 1
    tv_nsec: dq 0
queuePtr: db 0

section .bss
sockfd: resb 8
queue: resb 8

Repare que a fila representa 8 bytes fixos (para nosso exemplo é o suficiente), utilizando também um ponteiro para manipular a fila.

Seguindo com o código, o programa inicia logo disparando a thread:

section .text
_start:
    call thread

A seguir vêm as rotinas habituais (vou omitir pra poupar caracteres neste artigo): socket, bind e listen.

O accept fica da seguinte forma:

.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0
    mov rdx, 0
    mov r10, 0
    mov rax, SYS_accept4
    syscall

    mov r8, rax
    call enqueue

    jmp .accept

Okay, agora, ao invés de chamar uma thread, o programa principal enfileira o socket da requisição. Lógica do enqueue:

enqueue:
    xor rdx, rdx
    mov dl, [queuePtr]  
    mov [queue + rdx], r8   
    inc byte [queuePtr]
    ret

Aqui, estamos manipulando o ponteiro em queue utilizando queuePtr, incrementando um byte quando algo é adicionado na fila.

Agora vamos à implementação da rotina da thread:

thread:
    mov rdi, 0
    mov rax, SYS_brk
    syscall
    mov rdx, rax

    mov rdi, rax
    add rdi, CHILD_STACK_SIZE
    mov rax, SYS_brk
    syscall

    mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO
    lea rsi, [rdx + CHILD_STACK_SIZE - 8]
    mov qword [rsi], handle
    mov rax, SYS_clone
    syscall
    ret

Nada de novo por enquanto. O que modifica é a rotina handle (explicação detalhada nos comentários):

handle:
    ; Verifica se a fila está vazia. Se estiver, fica em loop infinito.
    ; Repare que este código não está otimizado. Loop infinito 
    ; acarreta alto consumo de CPU. Nas próximas seções vamos resolver isto.
    ; Por ora, vamos aceitar este consumo de CPU.
    cmp byte [queuePtr], 0
    je handle

    ; Remove (faz pop) da fila de socket, e guarda em R8.
    call dequeue
    mov r8, rax

    ; Processo normal, faz o nanosleep de 1 segundo simulando latência
    lea rdi, [timespec]
    mov rax, SYS_nanosleep
    syscall

    ; Escreve no socket que está em R8
    ; int write(fd)
    mov rdi, r8
    mov rsi, response
    mov rdx, responseLen
    mov rax, SYS_write
    syscall

    ; Fecha o socket
    ; int close(fd)
    mov rdi, r8
    mov rax, SYS_close
    syscall

    ; Volta para o início (loop)
    jmp handle

E por último, a lógica da rotina dequeue:

dequeue:
    xor rax, rax
    xor rsi, rsi

    mov al, [queue]
    mov rcx, 0
.loop_dequeue:
    cmp byte [queuePtr], 0
    je .return_dequeue

    cmp cl, [queuePtr]
    je .done_dequeue

    ; shift
    xor r10, r10
    mov r10b, [queue + rcx + 1]
    mov byte [queue + rcx], r10b

    inc rcx
    jmp .loop_dequeue
.done_dequeue:
    dec byte [queuePtr]
.return_dequeue:
    ret

Por enquanto não vou entrar em detalhes em como trabalhar com filas em Assembly. Vou deixar estes detalhes para outro artigo, que irá tratar especificamente de arrays, filas e listas ligadas. Em breve!

Pronto, já podemos executar o server e...

<h1>Hello, World!</h1>1.042
<h1>Hello, World!</h1>2.059
<h1>Hello, World!</h1>3.071
<h1>Hello, World!</h1>4.083
<h1>Hello, World!</h1>5.090
<h1>Hello, World!</h1>6.094
<h1>Hello, World!</h1>7.112
<h1>Hello, World!</h1>8.121
<h1>Hello, World!</h1>9.140
<h1>Hello, World!</h1>10.150
10.166

Ouch! Voltamos aos 10 segundos. Mas isto se deve ao fato de termos apenas uma thread em loop. Vamos aumentar o número de threads na pool.

5 threads em loop

A seguir modificamos o programa para inicializar 5 threads, para que desta forma nosso server tenha mais capacidade em atender requests simultâneos:

section .text
_start:
.initialize_pool:
    mov r8, 0
.pool:
    call thread        
    inc r8
    cmp r8, 5
    je .socket
    jmp .pool
....
....

Com este loop fazemos call thread 5 vezes, pelo que cada thread, e ainda utilizando o exemplo anterior, irá ficar em loop buscando mensagens na fila.

Executamos o código com 1 request e temos sucesso:

$ time curl localhost:3000

<h1>Hello, World!</h1>1.022

Mas no output do strace, após a resposta, vemos uma sequência de erros das threads:

<h1>Hello, World!</h1>[pid 13483] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86 <unfinished ...>
[pid 13482] write(0, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86 <unfinished ...>
[pid 13480] write(0, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86 <unfinished ...>
[pid 13484] <... write resumed>)        = 86
[pid 13481] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 22

<h1>Hello, World!</h1> <unfinished ...>
[pid 13480] <... write resumed>)        = 86
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 22

<h1>Hello, World!</h1>[pid 13484] close(0 <unfinished ...>
[pid 13483] <... write resumed>)        = 86
[pid 13482] <... write resumed>)        = 86
[pid 13480] close(0 <unfinished ...>
[pid 13484] <... close resumed>)        = 0
[pid 13481] <... write resumed>)        = 86
[pid 13484] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 13483] close(4 <unfinished ...>
[pid 13482] close(0 <unfinished ...>
[pid 13481] close(4 <unfinished ...>
[pid 13480] <... close resumed>)        = -1 EBADF (Bad file descriptor)
[pid 13483] <... close resumed>)        = 0
[pid 13482] <... close resumed>)        = -1 EBADF (Bad file descriptor)
[pid 13481] <... close resumed>)        = -1 EBADF (Bad file descriptor)

A thread tentou fechar o socket descriptor da requisição mas outra thread tentou ler o socket de forma concorrente (Bad file descriptor).

Quando envolve mais de uma thread consumindo o mesmo recurso (neste caso a fila), precisamos de um mecanismo de sincronização, que no caso são locks.

Sincronização com futex

Com locks, conseguimos controlar o acesso a um recurso compartilhado entre diferentes threads.

Através da syscall futex, podemos suspender uma thread baseando-se em uma "variável condicional". De forma oposta, podemos tornar uma thread de volta à execução baseando-se também na variável condicional.

Esta técnica de variável condicional (condvar) é um primitivo de sincronização bastante utilizado. No nosso caso para controle da fila, queremos o seguinte cenário:

a thread verifica se há algo na fila. Caso a fila esteja vazia, a thread é suspensa com futex wait através de uma variável condicional
quando algo for adicionado na fila, outra thread/processo "emite um sinal" chamando a syscall futex wake na mesma variável condicional.
quando o sinal é emitido, neste momento a thread que tem o acesso ao lock (variável condicional) é trazida de volta ao contexto, então lê a mensagem da fila e executa a ação necessária. Após, se a fila estiver vazia, repete o processo com futex wait e fica novamente suspensa

Desta forma, garantimos que as threads não ficam consumindo a CPU em loop indefinidamente

Modificando o código, começamos por definir a syscall:

%define SYS_futex 202

A seguir, na seção de dados .bss declaramos a variável condicional ocupando 8 bytes, que será utilizada como sincronização do futex:

section .bss
...
condvar: resb 8

Na rotina enqueue, emitimos o sinal após o socket ser adicionado na fila:

enqueue:
    xor rdx, rdx
    mov dl, [queuePtr]  
    mov [queue + rdx], r8   
    inc byte [queuePtr]

    call emit_signal
    ret

A lógica o emit_signal (explicação nos comentários):

emit_signal:
   ; Endereço de memória para a variável condicional (8 bytes)
   mov rdi, condvar

   ; Flags do Futex (WAKE), que irá trazer a thread
   ; de volta ao contexto
   mov rsi, FUTEX_WAKE | FUTEX_PRIVATE_FLAG 

   ; Argumentos adicionais, que neste caso vamos deixar a ZERO
   xor rdx, rdx
   xor r10, r10
   xor r8, r8

   ; Chamada da syscall
   mov rax, SYS_futex
   syscall
   ret

Agora, modificamos a rotina handle:

handle: 
    ; Caso a fila esteja vazia, fazemos jump para "wait"
    cmp byte [queuePtr], 0         
    je .wait           

    ; Faz pop do socket da fila e segue o fluxo normal
    call dequeue      
    mov r10, rax

    lea rdi, [timespec]
    mov rax, SYS_nanosleep
    syscall

    ; int write(fd)
    mov rdi, r10
    mov rsi, response
    mov rdx, responseLen
    mov rax, SYS_write
    syscall

    ; int close(fd)
    mov rdi, r10
    mov rax, SYS_close
    syscall

    ; Volta para o início
    jmp handle       
.wait:
    ; Chamada para wait_condvar, que vai suspender a thread atual com FUTEX
    call wait_condvar 
    jmp handle

E, por último e não menos importante, a lógica da rotina wait_condvar, que suspende a thread de execução:

wait_condvar:
   ; Endereço de memória para a variável condicional (8 bytes)
   mov rdi, condvar   

   ; Flags do Futex (WAIT), que irá suspender a thread
   mov rsi, FUTEX_WAIT | FUTEX_PRIVATE_FLAG 
   xor rdx, rdx
   xor r10, r10              
   xor r8, r8               
   mov rax, SYS_futex
   syscall
   test rax, rax
   jz .done_condvar
.done_condvar:
   ret

Assim que iniciamos o server com strace, podemos ver as syscalls em ação:

brk(NULL)                               = 0x155c000
brk(0x155d000)                          = 0x155d000
clone(child_stack=0x155cff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13539 attached
) = 13539
[pid 13539] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x155d000
[pid 13538] brk(0x155e000)              = 0x155e000
[pid 13538] clone(child_stack=0x155dff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13540 attached
) = 13540
[pid 13540] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x155e000
[pid 13538] brk(0x155f000)              = 0x155f000
[pid 13538] clone(child_stack=0x155eff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13541 attached
) = 13541
[pid 13541] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x155f000
[pid 13538] brk(0x1560000)              = 0x1560000
[pid 13538] clone(child_stack=0x155fff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13542 attached
) = 13542
[pid 13542] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] brk(NULL)                   = 0x1560000
[pid 13538] brk(0x1561000)              = 0x1561000
[pid 13538] clone(child_stack=0x1560ff8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IOstrace: Process 13543 attached
) = 13543
[pid 13538] socket(AF_INET, SOCK_STREAM, IPPROTO_IP <unfinished ...>
[pid 13543] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 13538] <... socket resumed>)       = 3
[pid 13538] bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid 13538] listen(3, 2)                = 0
[pid 13538] accept4(3, NULL, NULL, 0)   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
[pid 13538] --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
[pid 13538] accept4(3, NULL, NULL, 0

Repare que cada thread faz a chamada a futex com FUTEX WAIT, e isto vemos acontecer 5 vezes no trace. Ou seja, as 5 threads estão suspensas sem consumir CPU.

Ao fazer o primeiro request, temos o seguinte resultado:

)   = 4
[pid 13538] futex(0x402088, FUTEX_WAKE_PRIVATE, 0) = 1
[pid 13539] <... futex resumed>)        = 0
[pid 13538] accept4(3, NULL, NULL, 0 <unfinished ...>
[pid 13539] nanosleep({tv_sec=1, tv_nsec=0}, NULL) = 0
[pid 13539] write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
[pid 13539] close(4)                    = 0
[pid 13539] futex(0x402088, FUTEX_WAIT_PRIVATE, 0, NULL

o processo principal recebeu a mensagem no socket, enfileirou e executou futex com FUTEX_WAKE
uma das threads foi trazida de volta ao contexto e fez a sua devida execução (nanosleep + write + close)
o processo principal voltou para o accept a espera de mais requests no socket
a thread terminou seu trabalho, viu que não tinha mais nada na fila e executou futex com FUTEX_WAIT, ficando novamente suspensa

Finalmente, podemos executar 10 requests simultâneos e...

<h1>Hello, World!</h1><h1>Hello, World!</h1><h1>Hello, World!</h1>1.079
1.082
1.083
<h1>Hello, World!</h1><h1>Hello, World!</h1>1.062
1.083
<h1>Hello, World!</h1><h1>Hello, World!</h1>2.087
2.088
<h1>Hello, World!</h1>2.100
<h1>Hello, World!</h1>2.101
<h1>Hello, World!</h1>2.110
2.127

Nice! Com uma pool de 5 threads, conseguimos atingir 2,1 segundos para 10 requests concorrentes. Agora temos concorrência consumindo muito menos recursos:

menos memória, pois não é forking de processos
menos CPU, pois as threads não ficam em loop infinito
menos latência, pois com uma limitação de 5 threads, novos requests não criam novas threads

Alocação de memória com mmap

Um problema comum ao utilizar brk é que a memória pode ficar fragmentada. Uma vez que o program break foi modificado, aquela memória pode ser utilizada, mas torna muito difícil ser reciclada.

Uma forma de lidar com este problema de fragmentação é utilizar uma syscall que trata de reservar uma área na memória que pode ser reciclada futuramente. Estamos falando da syscall mmap.

thread:
    mov rdi, 0x0
    mov rsi, CHILD_STACK_SIZE
    mov rdx, PROT_WRITE | PROT_READ
    mov r10, MAP_ANONYMOUS | MAP_PRIVATE | MAP_GROWSDOWN
    mov rax, SYS_mmap
    syscall

    mov rdi, CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PARENT|CLONE_THREAD|CLONE_IO
    lea rsi, [rax + CHILD_STACK_SIZE - 8]
    mov qword [rsi], handle
    mov rax, SYS_clone
    syscall
    ret

Ao invés de chamar brk, podemos chamar mmap, especificando:

rdi: endereço de memória onde deve ser mapeado. Se tiver ZERO, o sistema operacional se encarrega de trazer um endereço de memória disponível
rsi: tamanho do espaço reservado na memória. No nosso caso, queremos 4096 bytes para a thread
rdx: proteção de memória, neste caso queremos que a memória possa ser tanto escrita (PROT_WRITE) quanto lida (PROT_READ) pela thread
r10: flags de mapeamento
- MAP_ANONYMOUS: o mapeamento não é associado a nenhum arquivo ou descritor de arquivo (modo anônimo)
- MAP_PRIVATE: mapeamento privado com copy-on-write, ou seja, os dados serão copiados à medida em que são escritos
- MAP_GROWSDOWN: o mapeamento é usado no formato "stack", ou seja, o mapeamento é dos endereços maiores em direção aos menores

Com mmap, podemos fazer uso da sua contrapartida, a syscall unmmap, que permite reciclar uma determinada área na memória que não é mais utilizada, evitando fragmentação.

Esta técnica é muito utilizada pela libc através da função malloc. Com mmap podemos definir uma memória heap para nosso programa

É isto, na prática não terá nenhum efeito com relação ao exemplo anterior. Mas esta seção foi apenas para trazer uma forma diferente de alocar memória para a thread.

Conclusão

Ufa! Finalmente chegamos ao final da saga. Passamos por uma introdução, onde a seguir fizemos uma abordagem pela história e arquitetura de computadores, para então analisar código de máquina, que foi a base para entrar em assembly x86 de fato, para finalmente concluir o desenvolvimento do web server.

Este último artigo foi uma abordagem para multi-threading em Assembly, passando por conceitos de concorrência como forking de processos, clone, threading, pool de threads e sincronização com locks.

Declaro aqui então o fim da saga desenvolvendo um web server em Assembly x86.

Até a próxima saga!

Referências

Synchronization: mutexes and condition variables
https://cs61.seas.harvard.edu/site/2018/Synch3/
Synchronization, atomics and mutexes
https://cs.brown.edu/courses/csci0300/2023/notes/l22.html
Basics of Futexes
https://eli.thegreenplace.net/2018/basics-of-futexes/
Raw Linux threads via syscalls
https://nullprogram.com/blog/2015/05/15/
Condition variables with Futex
https://www.remlab.net/op/futex-condvar.shtml

Construindo um web server em Assembly x86, parte V, finalmente o server

Leandro Proença — Sat, 25 May 2024 00:14:20 +0000

No artigo anterior, passamos pelos fundamentos de Assembly, onde foi possível entender alguns conceitos básicos tais como tipos de registradores, stack, loops, FLAGS etc, tudo sendo feito com debugging via GDB.

Agora, vamos de fato construir um web server muito simples que devolve um HTML com a frase "Hello, World". A meta é chegarmos nisto:

O processo para chegarmos a este objetivo consiste em cobrir fundamentos de Web, passando por sockets, TCP e HTTP, enquanto vamos explorando conceitos práticos em Assembly x86.

Agenda

Arquitetura Web
- Cliente-servidor
- Modelo OSI
- Sockets e TCP
- HTTP
Como funciona um servidor web
- 4 syscalls para o resgate
Um server modesto em Assembly
- Criando o socket
- Fazendo bind no socket
- Preparando para receber conexões
- Chegou o momento de aceitar clientes
- Resposta do servidor e fechamento da conexão
- Mas o servidor deve ficar em loop, não?
Conclusão
Referências

Arquitetura Web

Para criar um servidor web, precisamos manipular mensagens HTTP, que são transportadas via camada de transporte TCP/IP através de uma rede.

Estas mensagens são enviadas entre diferentes dispositivos conectados a uma rede, que pode ser privada (local) ou pública. Regularmente, comunicação HTTP é feita entre 2 dispositivos, sendo um deles o cliente e outro o servidor.

Vamos brevemente falar de cada um destes conceitos.

Cliente-servidor

Numa arquitetura cliente-servidor, temos 2 dispositivos conectados a uma rede de computadores:

Para um servidor web, é necessário que o cliente realize uma conexão com o servidor, em seguida faça uma requisição, pelo que o servidor deve devolver uma resposta e, por último, fechar a conexão.

Mas como esta mensagem deve ser enviada? Quem garante a entrega? E caso ocorra falha de sinal na camada física (cabeamento de rede), como assegurar que cada "pacote" da mensagem seja entregue em ordem?

É pra isto que foi criado o modelo de comunicação OSI.

Modelo OSI

OSI é um modelo de referência para comunicação entre diferentes dispositivos através de diferentes redes, que estabelece um conjunto de camadas que vai desde a camada física até a camada de formato de mensagens.

Camada física: responsável pelo tráfego de informações através de meios físicos, tais como bluetooth, frequência de rádio, cabos etc
Camada de enlace de rede: responsável pela decodificação e codificação de mensagens em frames, do meio físico para o meio digital e vice-versa
Camada de rede: é aqui que definimos protocolos de rede, tais como o protocolo de internet, também conhecido como IP (Internet Protocol)

Na web, os dados trafegam geralmente através de uma rede de computadores pública, global e descentralizada, neste caso a Internet

Camada de transporte: camada responsável por características de entrega, tais como definir critérios de confiabilidade e ordem dos pacotes de mensagens. Por exemplo, nesta camada temos o protocolo de controle de transmissão, ou TCP
Camada de sessão e apresentação: aqui vão critérios de informações que podem ser vinculadas a uma determinada conexão entre diferentes dispositivos, bem como o formato de apresentação das informações na rede
Camada de aplicação: nesta camada, temos a definição do formato de mensagens em um nível mais "aplicacional", como por exemplo protocolo HTTP (Hypertext Transfer Protocol), FTP, SSH entre outros

Entretanto fica aqui uma questão: como que todo esse modelo de comunicação em rede se converte em algo prático num programa dentro de um sistema operacional?

Chegou o momento de falar sobre sockets e TCP.

Sockets e TCP

Num computador, todos os programas são encapsulados dentro de uma estrutura chamada processo, como vimos em artigos anteriores.

Quando falamos em cliente na aquitetura cliente-servidor, estamos falando de um processo rodando dentro de um computador, e o mesmo vale para o servidor, onde cada processo tem seu próprio identificador, ou PID:

Sabendo que processos são isolados, foram definidas diferentes formas de comunicação entre processos (também conhecido como IPC, ou inter process communication), tais como pipes, arquivos do filesystem, descritores de arquivos e UNIX sockets.

Estamos baseando a saga em sistema "UNIX-like", mais especificamente GNU/Linux

Ou seja, temos ciência que é possível fazer 2 processos dentro de um mesmo computador se comunicarem através de UNIX sockets. Mas como fazer dois processos em computadores distintos se comunicarem?

Entramos então em Berkeley Sockets, que define uma API comum de comunicação utilizando sockets, onde diferentes sockets podem estar no mesmo computador, ou em uma mesma rede local, ou até mesmo em redes diferentes dentro da Internet.

É aqui que temos a introdução ao TCP, que é um protocolo de comunicação via sockets. Portanto, para fazer um cliente se comunicar com um servidor, é preciso estabelecer endpoints de comunicação, que são basicamente sockets, e neste caso para a web, vamos utilizar sockets TCP.

Estes sockets são abertos tanto do lado do cliente, quanto no servidor. No servidor, estes sockets são mapeados em descritores de arquivos, que representam um número especial e reservado, também chamado de porta de comunicação:

Ok Leandro, consegui entender o conceito de sockets e TCP. Mas qual deveria ser o formato da mensagem na web?

Com vocês, o HTTP.

HTTP

HTTP é um protocolo de formato de mensagem que faz parte da camada de aplicação.

Com HTTP, a mensagem é definida seguindo padrões de hipertexto, que são basicamente documentos que podem ter ligações com outros documentos em sites diferentes.

Na web, o padrão segue um formato de headline, que contém o tipo de pedido, seguido de quebra de linhas com cabeçalhos de metadados e por fim, opcionalmente e dependendo do tipo de pedido, um corpo com a mensagem principal contendo majoritariamente HTML, CSS e Javascript.

Até agora, passamos por conceitos que formam a web. Como nosso exemplo de web server é bastante simples, estes fundamentos já são o suficiente para entrarmos na próxima seção, que é de fato escrever o web server em Assembly x86.

Como funciona um servidor web

Conforme vimos na seção anterior, arquitetura web passa por manipulação de sockets TCP.

Tal manipulação é feita via chamadas de sistema (syscalls) no sistema operacional, portanto, para darmos início ao servidor, vamos entender como devem ser criados os sockets a nível do OS.

4 syscalls para o resgate

Resumidamente temos que fazer 4 syscalls para termos um server operante, que são:

socket
A syscall socket é responsável por criar um endpoint de comunicação de rede e retornar um descritor de arquivo (fd) relativo ao endpoint criado.

Na libc, socket é referenciada pelo número 41 e tem a seguinte assinatura:



int socket(int domain, int type, int protocol)

Lembrando que estamos utilizando arquitetura x86_64, ou x64

bind
bind atribui nome e porta ao socket previamente criado. Esta syscall na libc responde pelo número 49 e tem a assinatura a seguir:



int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)

listen
A syscall listen marca o socket criado (precisa ser do tipo stream, no caso TCP) para aceitar conexões. É conhecida pelo número 50 e tem a seguinte assinatura em C:



int listen(int sockfd, int backlog)

accept
A syscall accept admite uma conexão de um cliente no socket e cria um novo socket de conexão específico para aquele cliente. Esta syscall, a princípio, bloqueia o programa e só continua a execução quando uma nova conexão com novo cliente é estabelecida.

É referenciada pelo número 288 e tem a seguinte assintaura:



int accept(int sockfd, struct *addr, int addrlen, int flags)

Em resumo, tudo o que precisamos para criar um web server, independente do programa, linguagem de programação ou tecnologia, é de chamar estas 4 syscalls.

Não se engane, o teu servidor Express, Rails, Django ou NGINX, faz estas chamadas de sistema por baixo dos panos: socket, bind, listen e accept

Sem mais delongas, vamos ver como tudo isto se aplica naquilo que importa para esta saga: assembly.

Um server modesto em Assembly

Montar as syscalls para o web server em Assembly não é tão difícil quanto parece. Para começar, vamos fazer a primeira syscall, que é a socket.

Criando o socket

Como de costume, vamos montar as instruções de acordo com o manual e tabela de syscalls.

Já vimos na seção anterior quais são os números das syscalls e suas respectivas assinaturas na libc

Iniciamos definindo as constantes, apenas as necessárias para a syscall socket:



global _start

; syscalls constants
%define SYS_socket 41

; other constants
%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0

Após isto, vamos reservar 1 byte com a diretiva resb 1 que significa "reservar 1 byte". Este byte será utilizado para armazenar o número do descritor de arquivo que referencia o socket que vai ser criado.

Como não queremos inicializar o valor deste byte, não vamos colocar na seção .data como temos utilizado até o momento na saga, mas sim na seção .bss.

Na seção .data, ficam apenas dados inicializados
Na seção .bss, ficam os dados não-inicializados



section .bss
sockfd: resb 1

Vamos relembrar o layout de memória:

Como vemos na imagem, a seção .bss vem a seguir a seção .data, ou seja, fica em endereços de memória mais altos que a seção .data.

Agora, vamos montar os registradores seguindo a convenção de chamada e a ordem dos parâmetros da função socket na libc:



section .text
_start:
.socket:
    ; int socket(int domain, int type, int protocol)
    mov rdi, AF_INET
    mov rsi, SOCK_STREAM
    mov rdx, SOCK_PROTOCOL
    mov rax, SYS_socket
    syscall
    mov [sockfd], rax 
.exit:
    mov rdi, 0
    mov rax, 60
    syscall

domain: representa o domínio de comunicação. No caso queremos usar AF_INET, que significa IPv4, e tem o valor 2 conforme especificado no glibc
type: representa o tipo de comunicação, que no caso vamos usar SOCK_STREAM que é sequencial, confiável, duplex e baseado em conexão. O valor conforme glibc é 1
protocol: esta opção é usada no caso da utilização de um protocolo em específico. Neste caso, vamos deixar o valor como 0 que é o default para AF_INET e SOCK_STREAM, indicando que se trata de um socket TCP

Lembrando que existem sockets da família UNIX que não funcionam na camada de rede IP. É possível combinar socket UNIX com SOCK_STREAM, mas neste caso estamos combinando a família AF_INET (IPv4) com o tipo SOCK_STREAM (segmento de bytes, duplex), e esta combinação faz este socket ser TCP. Para mais detalhes sobre sockets, sugiro a leitura de um artigo que escrevi sobre UNIX Sockets

Vamos confirmar com GDB?



# Breakpoint na linha <syscall>
(gdb) break 22

(gdb) run

# Confirmando que os registradores estão com os valores corretos
# antes da execução da syscall...
(gdb) i r rdi rsi rdx rax
rdi            0x2                 2
rsi            0x1                 1
rdx            0x0                 0
rax            0x29                41

# Confirmando que `sockfd` continua com o valor zerado
(gdb) x &sockfd
0x402000 <sockfd>:      0x00000000

(gdb) next

Após a execução da syscall, podemos ver que o retorno da função, que representa o descritor de arquivo conforme documentação, está armazenado no registrador RAX (de acordo com a convenção de chamada):



(gdb) i r rax
rax            0x3                 3

(gdb) next

(gdb) x &sockfd
0x402000 <sockfd>:      0x00000003

Ou seja, após a syscall, temos em sockfd o número do socket que acabou de ser criado.

Executando com strace:



$ strace ./live

execve("./live", ["./live"], 0x7ffca20187e0 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
exit(0)                                 = ?
+++ exited with 0 +++

Sem erros, yay!

Vamos para a próxima syscall.

Fazendo bind no socket

Agora, é o momento de atribuir um endereço e uma porta como endpoint de comunicação para este socket. É para isto que serve a syscall bind.

Analisando a função:



; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)

Podemos ver que um dos argumentos é um ponteiro para uma struct na memória. Vamos entender melhor cada argumento.

sockfd
Em sockfd vai o inteiro que representa o descritor do socket criado

sockaddr **addr*
Representa o ponteiro para o endereço de memória que contém uma estrutura de dados que, de acordo com este guia, contempla: family, port, ip_address, sin_zero, onde sin_zero é apenas padding de preenchimento de bytes.

Para arquitetura x64, esta estrutura deve conter 16 bytes no total, onde:

2 bytes são para a família de protocolo
2 bytes para a porta
4 bytes para o endereço de IP
8 bytes de padding para o sin_zero, ou seja, preencher os 8 bytes restantes com ZERO

addrlen: tamanho do sockaddr, e já sabemos que são 16 bytes

Uma vez entendidos os parâmetros da função, vamos montar a chamada.



%define SYS_bind 49

; Data types in asm
; (db) byte => 1 byte
; (dw) word => 2 bytes
; (dd) doubleword => 4 bytes
; (dq) quadword => 8 bytes

section .data
sockaddr: 
    family: dw AF_INET   ; 2 bytes
    port: dw 0x0BB8      ; 2 bytes (representa a porta 3000)
    ip_address: dd 0     ; 4 bytes
    sin_zero: dq 0       ; 8 bytes

.bind:
    ; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
    mov rdi, [sockfd]
    mov rsi, sockaddr
    mov rdx, 16
    mov rax, SYS_bind
    syscall

Ao validar com GDB, podemos ver que o sockaddr está armazenando a estrutura necessária para ser enviada no parâmetro sockaddr *addr da syscall:



# Breakpoint na syscall de bind
(gdb) break 38

(gdb) run

(gdb) x &sockaddr
0x402000 <family>:      0xb80b0002

Se buscarmos os 2 primeiros bytes, confirmamos que é o valor 2 (repare que está invertido pois é o padrão little-endian da aquitetura x86_64:



(gdb) x /2xb &sockaddr
0x402000 <family>:      0x02    0x00

Quanto à porta, queremos que o server responda no número 3000. Portanto, verificamos que os próximos 2 bytes representam a porta:



# Em hexadecimal, 3000 equivale a 0x0BB8, mas por causa do formato
# little-endian da arquitetura x86_64, estamos visualizando 0xB80B
(gdb) x /2xb (void*) &sockaddr+2
0x402002 <port>:        0xb8    0x0b

Queremos também que o servidor responda no endereço de IP 0.0.0.0, então os próximos 4 bytes estarão todos a zero:



(gdb) x /4xb (void*) &sockaddr+4
0x402004 <ip_address>:  0x00    0x00    0x00    0x00

E, por fim, os 8 bytes restantes representando sin_zero, todos preenchidos com zero:



(gdb) x /8xb (void*) &sockaddr+8
0x402008 <sin_zero>:    0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00

Vamos executar com strace:



$ strace ./live

execve("./live", ["./live"], 0x7ffd51ed4650 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(47115), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
exit(0)                                 = ?
+++ exited with 0 +++

Ouch! Apesar da função bind ter retornado 0 indicando que não houve erros, temos um pequeno problema. Repare que a porta não está sendo mapeada para o número 3000, e sim para 47115, conforme vemos em htons(47115).

Entendendo a implicação de endianess na syscall bind
htons é uma função de rede utilizada para converter a ordem dos bytes do programa antes de serem utilizados na rede. Como a internet utiliza big-endian, esta função converte a ordem utilizada na arquitetura (no caso da x86_64, little-endian) para o formato big-endian da rede.

Entretanto htons(47115) não é o valor que queremos. O que precisamos é que o mapeamendo seja htons(3000). Por quê isto está acontecendo?

O valor que colocamos em hexadecimal representando 3000 é 0x0BB8, mas se prestarmos atenção no GBD, o valor de fato armazenado está com os bytes invertidos para little-endian, que é 0xB80B. Ocorre que 0xB80B em decimal é 47115!!!!!! Aí que está o problema!

Precisamos então inverter os bytes no programa, e assim sendo o valor que será passado para a função htons fica corrigido.



....
section .data
sockaddr: 
    family: dw AF_INET   ; 2 bytes
    port: dw 0xB80B      ; 2 bytes (aqui invertemos os bytes)
    ip_address: dd 0     ; 4 bytes
    sin_zero: dq 0       ; 8 bytes
....

E analisando novamente com GDB:



# Agora sim, apesar de estar invertido, é exatamente este valor que
# queremos que seja passado para htons: 0x0BB8 em decimal é 3000
(gdb) x /2xb (void*) &sockaddr+2
0x402002 <port>:        0x0b    0xb8

Executando novamente com strace:



$ strace ./live

execve("./live", ["./live"], 0x7ffd51ed4650 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
exit(0)                                 = ?
+++ exited with 0 +++

Superb! Podemos ver que a syscall bind foi executada com os parâmetros corretamente, inclusive o htons(3000), então retornando 0, que indica que não houve qualquer erro.

Preparando para receber conexões

Próximo passo consiste em preparar o socket para receber conexões, que basicamente é chamar a função listen:



%define SYS_listen 50
%define BACKLOG 2

.listen:
    ; int listen(int sockfd, int backlog)
    mov rdi, [sockfd]
    mov rsi, BACKLOG
    mov rax, SYS_listen
    syscall

Onde BACKLOG significa a quantidade de conexões "pendentes" no socket. Executamos com strace e:



$ strace ./live

execve("./live", ["./live"], 0x7ffe6b4eea30 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
exit(0)                                 = ?
+++ exited with 0 +++

Que noite maravilhosa! Listen funcionou lindamente, afinal, é uma função muito simples. Agora, hora de aceitar conexões de clientes no socket.

Chegou o momento de aceitar clientes

O grande momento chegou. Vamos montar as instruções da syscall accept, que de acordo com a função em libc, recebe um socket como primeiro argumento e os demais são opcionais.



%define SYS_accept 288

.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0              ; não precisa estabelecer um addr
    mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
    mov r10, 0
    mov rax, SYS_accept
    syscall

Se executarmos com GDB, podemos ver que o resultado da syscall fica bloqueado até que uma conexão seja feita:



# Breakpoint na syscall de socket
(gdb) break 55

(gdb) run
(gdb) next

O programa está parado na syscall de socket, aguardando resposta do kernel. Para que o kernel responda e o programa continue a execução, é preciso realizar um pedido usando um HTTP client, e neste caso vamos usar o curl:



$ curl localhost:3000

Repare que o programa continuou a execução. Vamos ver a resposta que está em RAX:



(gdb) i r rax
rax            0x4                 4

# Um número diferente do sockfd, que é o socket criado pelo server
(gdb) x &sockfd
0x402010 <sockfd>:      0x00000003

Podemos ver que é um número diferente (RAX contém 4 e sockfd contém 3). De acordo com a documentação, este é o número do descritor que representa um novo socket criado para comunicação entre um cliente específico e o servidor.

Vamos mover o valor de RAX para R8, apenas para preservar o socket, uma vez que RAX será usado novamente por outras syscalls de accept:



mov r8, rax             ; client socket

Resposta do servidor e fechamento da conexão

Uma outra coisa importante a se fazer é fechar a conexão com este socket do cliente depois de ter processado e respondido a requisição.

Vamos implementar a subrotina .write, que escreve a resposta na conexão (socket) do cliente:



%define SYS_write 1

%define CR 0xD
%define LF 0xA

section .data
response: 
    headline: db "HTTP/1.1 200 OK", CR, LF
    content_type: db "Content-Type: text/html", CR, LF
    content_length: db "Content-Length: 22", CR, LF
    crlf: db CR, LF
    body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response

section .text
...
.write:
    ; int write(int fd, buffer *bf, int bfLen)
    mov rdi, r8
    mov rsi, response
    mov rdx, responseLen
    mov rax, SYS_write
    syscall
    ret

No exemplo acima, assumimos que a string de resposta HTTP aponta para uma estrutura na memória, definida em .data.

Atenção para CR (carriage return), LF (line feed) que são constantes que representam \r\n que são separadores de linhas definidos pelo protocolo HTTP

Agora, definir a subrotina .close, que fecha a conexão com o cliente:



%define SYS_close 3

section .text
...
.close:
    ; int close(int fd)
    mov rdi, r8
    mov rax, SYS_close
    syscall
    ret

Ligando tudo no accept:



section .text
....
.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0              ; não precisa estabelecer um addr
    mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
    mov r10, 0
    mov rax, SYS_accept
    syscall
    mov r8, rax             ; client socket
    call .write             ; escreve no socket
    call .close             ; fecha o socket
    jmp .exit               ; termina o programa

E agora, vamos executar o programa com strace:



$ strace ./live

execve("./live", ["./live"], 0x7ffd811567c0 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0

primeiro foi feita a syscall socket
a seguir foi feito o bind
depois o listen
e por fim, o accept ficou bloqueado a espera de uma requisição

Em outra janela, vamos fazer a requisição:



$ curl localhost:3000
<h1>Hello, World!</h1>

E no servidor, a saída do strace no final ficou assim:



write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
exit(0)                                 = ?
+++ exited with 0 +++

Escreveu a resposta com write, fechou a conexão com close, e depois terminou o programa com exit.

Como não ficar feliz?

Mas o servidor deve ficar em loop, não?

Sim, o servidor deve ficar em loop, portanto ao invés de fazer o jmp .exit, fazemos jmp .accept na última linha da procedure:



...
.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0              ; não precisa estabelecer um addr
    mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
    mov r10, 0
    mov rax, SYS_accept
    syscall
    mov r8, rax             ; client socket
    call .write
    call .close
    jmp .accept             ; <-- MUDANÇA AQUI, mantém o server em loop infinito

Assim, o server nunca termina, e quando uma conexão com um cliente é fechada, voltamos no início do loop e ficamos a espera de nova conexão na syscall accept.

Código final do server:



global _start

%define SYS_socket 41
%define SYS_bind 49
%define SYS_listen 50
%define SYS_accept 288
%define SYS_write 1
%define SYS_close 3

%define AF_INET 2
%define SOCK_STREAM 1
%define SOCK_PROTOCOL 0
%define BACKLOG 2
%define CR 0xD
%define LF 0xA

; Data types in asm
; byte => 1 byte
; word => 2 bytes
; doubleword => 4 bytes
; quadword => 8 bytes

section .data
sockaddr: 
    family: dw AF_INET   ; 2 bytes
    port: dw 0xB80B      ; 2 bytes (47115 big endian becomes 3000 little endian)
    ip_address: dd 0     ; 4 bytes
    sin_zero: dq 0       ; 8 bytes
sockaddrLen: equ $ - sockaddr
response: 
    headline: db "HTTP/1.1 200 OK", CR, LF
    content_type: db "Content-Type: text/html", CR, LF
    content_length: db "Content-Length: 22", CR, LF
    crlf: db CR, LF
    body: db "<h1>Hello, World!</h1>"
responseLen: equ $ - response

section .bss
sockfd: resb 1

section .text
_start:
.socket:
    ; int socket(int domain, int type, int protocol)
    mov rdi, AF_INET
    mov rsi, SOCK_STREAM
    mov rdx, SOCK_PROTOCOL
    mov rax, SYS_socket
    syscall
    mov [sockfd], rax 
.bind:
    ; int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
    mov rdi, [sockfd]
    mov rsi, sockaddr
    mov rdx, sockaddrLen
    mov rax, SYS_bind
    syscall
.listen:
    ; int listen(int sockfd, int backlog)
    mov rdi, [sockfd]
    mov rsi, BACKLOG
    mov rax, SYS_listen
    syscall
.accept:
    ; int accept(int sockfd, struct *addr, int addrlen, int flags)
    mov rdi, [sockfd]
    mov rsi, 0              ; não precisa estabelecer um addr
    mov rdx, 0              ; não precisa do tamanho uma vez que não há addr
    mov r10, 0
    mov rax, SYS_accept
    syscall
    mov r8, rax             ; client socket
    call .write
    call .close
    jmp .accept
.write:
    ; int write(int fd, buffer *bf, int bfLen)
    mov rdi, r8
    mov rsi, response
    mov rdx, responseLen
    mov rax, SYS_write
    syscall
    ret
.close:
    ; int close(int fd)
    mov rdi, r8
    mov rax, SYS_close
    syscall
    ret

Executando tudo com strace e temos:



$ strace ./live

execve("./live", ["./live"], 0x7fff9fde7840 /* 24 vars */) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 2)                            = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0)               = 4
write(4, "HTTP/1.1 200 OK\r\nContent-Type: t"..., 86) = 86
close(4)                                = 0
accept4(3, NULL, NULL, 0

No lado do cliente:



$ curl localhost:3000

<h1>Hello, World!</h1>

$ curl localhost:3000

<h1>Hello, World!</h1>

$ curl localhost:3000

<h1>Hello, World!</h1>

Com vocês, o web browser

Esta saga não teria nenhuma graça se não fosse pra ser executada em um web browser, afinal estamos falando de um web server, não?

Conclusão

Incrivelmente chegamos no final da construção de um modesto web server. Aqui aprendemos conceitos sobre sockets, TCP e HTTP, com uma pitada leve de HTML.

Fala aí, quem não já conhecia a tag H1 do HTML? kk

Para além de termos visto sobre as syscalls de rede socket, bind, listen e accept em Assembly.

Ainda não chegamos ao fim da saga, pelo que no próximo artigo iremos abordar a criação de threads e aprender sobre alocação dinâmica de memória para as threads.

Stay tuned!

Agradecimentos a Rodrigo Gonçalves de Branco por ter revisado este artigo com o devido rigor

Referências

Building a web server in Bash
https://dev.to/leandronsp/series/19120
OSI Model
https://en.wikipedia.org/wiki/OSI_model
TCP
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
Berkeley Sockets
https://en.wikipedia.org/wiki/Berkeley_sockets
HTTP
https://en.wikipedia.org/wiki/HTTP
struct sockaddr_in
https://www.gta.ufrj.br/ensino/eel878/sockets/sockaddr_inman.html

Construindo um web server em Assembly x86, parte IV, um assembly modesto

Leandro Proença — Mon, 13 May 2024 11:33:03 +0000

Uma vez que temos uma compreensão sobre sistema binário, hexadecimal, ASCII e código de máquina, chegou o grande momento de entrarmos no assunto principal desta saga: assembly.

Vamos iniciar transportando o "Hello, World" feito em código de máquina para assembly x86 e, posteriormente, abordar um exemplo de programa que recebe argumento da linha de comando.

Ao longo deste artigo vamos aprender a base de conceitos como rótulos, segmentos de memória, muito gdb, layout de memória, muita stack, procedures (subrotinas, ou funções), loops, condicionais, flags, tipos de registradores e etc

Aperte os cintos, pois este será um artigo bem extenso. Sugiro ao leitor, - que tem interesse em aprender na prática com esta saga -, que tenha o ambiente preparado e que execute cada exemplo seguindo os passos aqui descritos.

Sem mais delongas, vamos ao que importa.

Agenda

Humanizar é preciso
- Mnemonics
Assemblers
Nosso primeiro programa
- A chamada de sistema exit
- Arquivos Objeto
- Linker
Depurando o programa
- O utilitário size
- Debugging com gdb
- Rastreando execução com strace
Evoluindo nosso primeiro programa
- Alocando bytes para "Hello, World"
- Adicionando a chamada de sistema write
- Layout de memória
- Definindo constantes
Um programa mais sofisticado
- Definindo labels
- Desvio de fluxo com jump
- Desvio de fluxo com call
- Brincando com pilhas
- Calculando tamanho dinamicamente com loop
- RFLAGS
- Botando mais pilha no negócio
- Depurando o programa final com strace
Falando um pouco de registradores
- Propósito dos registradores
- Registradores de propósito geral
- Registradores especiais
- Precisamos sempre utilizar todos os 64 bits?
Uma side note sobre stack frames
Conclusão
Referências

Antes de iniciar, quero novamente deixar uma menção especial ao excelente curso gratuito de Assembly x86 do Blau Araújo. É importante reforçar o quanto este material dele é necessário e foi crucial para que eu pudesse fundamentar diversos conceitos explorados ao longo desta saga

Humanizar é preciso

Como vimos no artigo anterior, CPU só entende código de máquina:

48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A  ; Hello, World

BF 01 00 00 00     ; RDI ⬅️ 1
48 BE 00 10 40     ; RSI ⬅️ 0x401000
BA 0D 00 00 00     ; RDX ⬅️ 13
B8 01 00 00 00     ; RAX ⬅️ 1
0F 05              ; SYSCALL
BF 00 00 00 00     ; RDI ⬅️ 0
B8 3C 00 00 00     ; RAX ⬅️ 60
0F 05              ; SYSCALL

Entretanto, para uma pessoa desenvolvedora manter um programa em código de máquina, é preciso ter muita paciência e atenção ao detalhe, pelo que também manter programas assim é muito propenso a bugs.

Precisamos de alguma forma, representar cada instrução em código de máquina em uma linguagem mais "human-friendly".

Mnemonics

É aí que entram os mnemonics, que são uma forma textual de representar informações visando facilitar a memorização para o cérebro humano.

Ao invés de trabalharmos com BF 01 00 00 00, podemos trocar por MOV RDI, 1, que significa:

estou movendo o valor imediato 1 para o registrador RDI

E assim vamos montando instrução por instrução, tal e qual faríamos com código de máquina, mas utilizando uma linguagem de fácil memorização.

Mas a CPU não entende essa "linguagem". Temos de construir um programa que faz a tradução de mnemonics para código de máquina, ou seja, de MOV RSI, 1 para BF 01 00 00 00.

Estamos falando de montadores, ou simplesmente assemblers.

Assemblers

Ao longo do tempo, foram desenvolvidos diversos assemblers para diferentes arquiteturas.

Para arquitetura x86, há diversos assemblers já construídos, GNU Assembler (as), NASM, FASM, pra mencionar alguns.

Assemblers para esta arquitetura em específico podem seguir 2 tipos de sintaxe que são predominantes:

AT&T, desenvolvida pela AT&T corporation
Intel, desenvolvida pela Intel

Nesta saga, vamos focar no Assembler NASM para arquitetura X86 64-bits (x64), com sintaxe Intel e rodando em sistema GNU/Linux, como já mencionamos algumas vezes em artigos anteriores.

Arquitetura x86_64 (x64)
Sistema Operacional GNU/Linux (Ubuntu)
Assembler NASM 2.16.01
GNU ld 2.38 (ligador, ou linker)
Debugger GNU gdb 12.1
strace 5.16 (tracing de syscalls)

Uma vez que definimos as ferramentas utilizadas, vamos seguir traduzindo o "Hello, World" para asm x86 enquanto entendemos o uso de cada uma delas.

A partir de agora, quando me referir a Assembly ou simplesmente "asm", leia-se Assembly x86_64

Nosso primeiro programa

Em Assembly, todo programa deve ter um ponto de entrada, também chamado de entry point:

global _start

_start:
    ; código do programa vai aqui

E a primeira coisa que nosso programa vai fazer é sair:

kkkkkkkkkk

A chamada de sistema exit

Brincadeiras à parte, a chamada de sistema que precisamos executar é a exit, definida da seguinte forma no glibc:

void _exit(int status);

Com isto, temos de seguir a lógica para montar as instruções tal como fizemos com os opcodes, que seguindo a mesma tabela de syscalls, é:

nome da syscall vai em RAX
primeiro argumento (o status de erro) vai em RDI

global _start

_start:
    mov rdi, 0   ; error status
    mov rax, 60  ; nome da syscall: SYS_exit
    syscall

Este programa simplesmente faz aquilo que mencionamos no artigo anterior: que todo programa deve terminar.

mov rdi, 0 move o valor imediato 1 para o registrador RDI; vai representar o error code da syscall exit: 0 para término sem erros
mov rax, 60 move o valor imediato 60 para o registrador RAX; vai representar o nome da syscall em si, exit
syscall faz a chamada de sistema da syscall exit, definida em RAX

Para que o programa seja compilado, precisamos primeiro fazer a "montagem" das instruções com NASM:

$ nasm -f elf64 hello.asm -o hello.o

-f elf64: arquitetura de destino, x64
hello.asm input, ou seja, o arquivo que contém o código fonte
-o hello.o: define saída para o arquivo hello.o

Mas o quê é este arquivo hello.o?

Arquivos objeto

Arquivo objeto (Object File) é um arquivo que contém código de máquina gerado por um assembler ou compilador.

Porém este arquivo ainda não é um executável final, porque podemos querer combinar com outros arquivos objeto e bibliotecas nativas do SO.

A partir deste arquivo, que geralmente tem a extensão .o, podemos utilizar outro programa para "ligar" com outros arquivos, se necessário, no intuito de gerar um arquivo com código de máquina final e executável.

Este programa se chama linker, pelo que utilizaremos a versão padrão do ld que vem com o GNU no nosso sistema operacional GNU/Linux.

Linker

Linker é o programa responsável por, a partir de um ou mais arquivos objeto, gerar um arquivo final executável com o código de máquina.

Como já geramos anteriormente o arquivo objeto hello.o utilizando o assembler NASM, podemos concluir o processo de compilação do nosso programa fonte asm x86 com ld

$ ld hello.o -o hello

E agora, vamos rodar o binário final executável hello:

$ ./hello
echo $?
0

Hurray! Nosso primeiro programa em Assembly concluído com sucesso!

Contudo, vamos lembrar de um ponto importante que vimos na parte II da saga: que o programa e seus dados ficam na memória. Queremos entender o que está acontecendo na memória com este simples programa.

Depurando o programa

Uma das etapas mais importantes, senão a mais importante, em desenvolvimento de software, é a depuração (ou debugging, em inglês).

Depurar é o ato de conseguir interceptar a execução do programa, analisar o estado, alterar o estado, adicionar pontos de parada (breakpoints) entre outras técnicas.

O processo de depuração também consiste em analisar a saída do programa como um todo, seu tamanho e trace de chamadas no sistema operacional.

O utilitário size

Vamos iniciar o processo de depuração do nosso programa analisando o tamanho, com o utilitário GNU size:

$ size hello

   text    data     bss     dec     hex filename
     12       0       0      12       c hello

Mas o quê significa "text, data, bss, etc"?

Cada programa no sistema operacional é dividido em seções, que representam alguma característica para o sistema operacional.

text
Esta seção contém todo o código fonte do programa, e assim o SO sabe que precisa buscar esta seção na memória principal

data
Seção de dados inicializados na memória

bss
Seção de dados não-inicializados na memória

O comando size traz justamente o tamanho (em bytes) de cada seção.

dec e hex não são seções, são apenas a representação do valor total (em bytes) tanto em decimal quanto hexadecimal

text: esta seção contém todo o código fonte do nosso programa, também chamado de "texto"
data: seção de dados inicializados, logo a seguir neste artigos entramos em detalhe
bss: seção de dados não-inicializados, logo a seguir também falaremos deste
dec: o tamanho total em decimal
hex: o tamanho total em hexadecimal

Nosso programa por enquanto só tem a seção text, que é exatamente todo o código a partir do rótulo _start.

Nossa, Leandro, nosso programa tem apenas 12 bytes?

Aparentemente sim. Vamos confirmar:

$ ls -lh hello

...... 4.6K ... hello

Como assim o arquivo tem 4,6Kb? O programa não ocupa 12 bytes apenas?

Bom, isto ocorre por causa dos headers que são adicionados pelo linker, que contém informação relevante para que o sistema operacional possa admitir a execução do arquivo.

Vamos novamente utilizar o comando size mas desta vez:

$ size --format sysv --radix 16 hello

hello  :
section   size       addr
.text    0xc   0x401000
Total    0xc

A opção --format indica o formato sysv que traz também os símbolos. E a opção --radix 16 permite visualizar o tamanho de cada seção em hexadecimal.

Na seção size, 0xc representa o número 12 em decimal. Nada de novo aqui. Mas se repararmos na coluna addr, temos um valor hexadecimal para a seção text (0x401000).

Já vimos isto no artigo anterior, que 0x401000 se referia ao endereço em hexadecimal de memória virtual que indica o início do programa, lembra?

Hora de confirmar isto com uma análise mais profunda na depuração, chegou o momento de utilizarmos GNU gdb.

Debugging com GDB

GDB é um depurador (debugger em inglês) que permite ver o que está acontecendo dentro de um programa em execução.

Com um depurador, podemos analisar as informações estáticas contidas no binário do programa, estabelecer breakpoints (pontos de parada) em qualquer parte do código, executar e analisar mudanças de estado do programa durante sua execução.

Para habilitar o programa com gdb, precisamos montar o programa com a opção -g, que exporta símbolos necessários para depuração:

$ nasm -g -f elf64 hello.asm -o hello.o
$ ld hello.o -o hello

Podemos verificar os símbolos exportados no binário com o comando size novamente:

$ size --format sysv --radix 16 hello

hello  :
section           size       addr
.text              0xc   0x401000
.debug_aranges    0x30        0x0
.debug_info       0x75        0x0
.debug_abbrev     0x1d        0x0
.debug_line       0x3d        0x0
Total            0x10b

##############

$ ls -lh hello
...... 5.1K ... hello

Como demonstrado acima, o binário agora contém seções adicionais de "debug" que serão utilizadas pelo gdb, e consequentemente o tamanho do programa teve um acréscimo de ~~500MB~~ 512 bytes!

Sem mais delongas, vamos entrar no gdb:

$ gdb --quiet

(gdb)

E agora, dentro do shell gdb, podemos utilizar diversos comandos de depuração. O comando help traz a lista de classes de comandos disponíveis:

help

...
aliases -- User-defined aliases of other commands.
breakpoints -- Making program stop at certain points.
data -- Examining data.
files -- Specifying and examining files.
internals -- Maintenance commands.
obscure -- Obscure features.
running -- Running the program.
stack -- Examining the stack.
status -- Status inquiries.
support -- Support facilities.
text-user-interface -- TUI is the GDB text based interface.
tracepoints -- Tracing of program execution without stopping the program.
user-defined -- User-defined commands.
...

Para o escopo deste artigo vamos utilizar apenas alguns comandos para depuração, mas a lista de comandos disponíveis é gigante. Deixo o desafio ao leitor para se aventurar com o help do gdb e brincar de depurar qualquer binário executável

Como queremos depurar o binário hello, podemos carregar os símbolos utilizando o comando file:

(gdb) file hello
Reading symbols from hello...
(gdb)

O comando info files traz alguns insights:

(gdb) info files
Symbols from "/code/asm-x64/hello".
Local exec file:
        `/code/asm-x64/hello', file type elf64-x86-64.
        Entry point: 0x401000
        0x0000000000401000 - 0x000000000040100c is .text
(gdb)

Que interessante! O entry point do programa começa justamente em 0x401000, que é o que está definido na seção .text.

Para visualizar o código fonte do programa, utilizamos o comando list:

(gdb) list
1       global _start
2
3       _start:
4               mov rdi, 0   ; error code
5               mov rax, 60  ; SYS_exit
6               syscall
(gdb)

Lembrando que o programa ainda não está em execução, estamos apenas analisando o binário executável com o gdb

Com o comando x, de examine, podemos examinar o rótulo _start que é o ponto de entrada do programa:

(gdb) x _start
0x401000 <_start>:      0x000000bf
(gdb)

Se quisermos executar o programa, podemos fazê-lo com o comando run:

(gdb) run
Starting program: /code/asm-x64/hello
[Inferior 1 (process 7991) exited normally]
(gdb)

Entretanto, podemos definir breakpoints antes de executar, assim temos controle do estado do programa em execução:

# Aqui, definimos um ponto de parada no rótulo _start_
(gdb) break _start
Breakpoint 1 at 0x401000: file hello.asm, line 4.

# Info sobre breakpoints
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000401000 hello.asm:4
(gdb)

Agora sim, vamos executar:

(gdb) run
Starting program: /code/asm-x64/hello

Breakpoint 1, _start () at hello.asm:4
4               mov rdi, 0   ; error code
(gdb)

O programa está parado na linha 4 como solicitado. Esta linha no código não foi avaliada, pelo que podemos analisar e alterar o estado do programa:

# Neste momento o valor no registrador RDI está 0 (default)
(gdb) info register rdi
rdi            0x0                 0

# Mudamos o valor do registrador para 42
(gdb) set $rdi = 42

# Agora verificamos que foi modificado diretamente do GDB
(gdb) info register rdi
rdi            0x2a                42
(gdb)

Para avaliar a linha atual, utilizamos o comando next:

(gdb) next
5               mov rax, 60  ; SYS_exit

# E podemos agora verificar que o valor de RDI foi modificado para 0, 
# conforme descrito no programa
(gdb) info register rdi
rdi            0x0                 0
(gdb)

Poderíamos continuar indo linha a linha com next, ou então continuar a execução do programa com continue que pára no próximo ponto de parada ou executa todas as instruções que faltam até terminar o programa.

# Inicia execução e pára no primeiro breakpoint definido
(gdb) run
Starting program: /Users/leandronsp/Documents/code/asm-x64/hello

Breakpoint 1, _start () at hello.asm:4
4               mov rdi, 0   ; error code

# Continua execução. Neste caso termina o programa pois
# não há mais breakpoints a partir deste ponto
(gdb) continue
Continuing.
[Inferior 1 (process 8000) exited normally]
(gdb)

Pronto, terminamos a demonstração do primeiro programa com gdb. Para sair, utilizamos o comando exit.

Rastreando execução com strace

O utilitário strace permite rastrear todas as chamadas de sistema e sinais que um programa faz. É bastante útil quando queremos saber o que pode ter acontecido com determinada syscall, quais parâmetros foram enviados e o que a syscall retornou.

$ strace ./hello

execve("./hello", ["./hello"], 0x7ffc504b5710 /* 24 vars */) = 0
exit(0)                                 = ?
+++ exited with 0 +++

Vamos entender a saída do strace por partes.

execve("./hello", ["./hello"], 0x7ffc504b5710 /_ 24 vars _/) = 0:

execve é uma chamada do Linux que executa um determinado programa
./hello é o caminho para o programa que será executado
["./hello"] é a lista de argumentos passados para o programa. Como só há o nome do programa (que entra na lista ARGV), indica que este programa não recebe argumentos extras na linha de comando
0x7ffc504b5710 é o endereço de memória onde as variáveis de ambiente do processo em execução estão armazenadas
/* 24 vars */ indica que há 24 variáveis de ambiente definidas no shell atual
=0 é o resultado da chamada execve, o que significa que foi bem-sucedido e executado com sucesso

exit(0) = ?:

exit é a chamada de sistema (syscall) feita no sistema operacional, e geralmente é definida no libc, sendo no caso de sistema GNU, glibc. Foi o valor 60 passado para o registrador RAX, lembra?
(0) é o parâmetro passado para a função, que neste caso foi o que determinamos no registrador RDI, indicando que nosso programa em execução vai terminar sem erros
= ? indica que o resultado da chamada de sistema não é conhecido, ou seja não houve um retorno explícito de valor da chamada de sistema

+++ exited with 0 +++:

+++ sinaliza o início de uma mensagem de saída do strace
exited with 0 indica que o programa terminou sem erros
+++ sinaliza o fim da mensagem de saída

Uma vez que entendemos como depurar nosso programa, podemos evolui-lo para imprimir a mensagem "Hello, World" na saída do terminal.

Evoluindo nosso primeiro programa

Vamos agora evoluir o programa anterior para que possamos imprimir a mensagem "Hello, World" na saída padrão STDOUT.

Para isto, conforme vimos na parte III da saga, "Código de Máquina", vamos por partes.

Alocando bytes para "Hello, World"

Precisamos primeiro definir os bytes de cada caracter da string em hexadecimal de acordo com a tabela ASCII, que resulta em 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A.

0x48 para "H", 0x65 para "e", 0x6C para "l" e assim por diante...

Portanto, se quisermos evoluir o primeiro programa que contém apenas a syscall exit, podemos começar por definir a string utilizando a diretiva db que significa define byte, utilizando o endereço do primeiro byte em um rótulo que iremos chamar de msg:

global _start

msg: db 0x48, 0x65, 0x6C, 0x6C, 0x6F, \
        0x2C, 0x20, 0x57, 0x6F, 0x72, \
        0x6C, 0x64, 0xA

_start:
    mov rdi, 0   ; error code
    mov rax, 60  ; SYS_exit
    syscall

Antes de sair adicionando mais código, vamos utilizar o gdb para analisar o que esta mudança provoca na memória:

# Examinar o que há no rótulo msg
(gdb) x msg
0x401000 <msg>: 0x6c6c6548

# Examinar o que há no rótulo _start
(gdb) x _start
0x40100d <_start>:      0x000000bf
(gdb)

Ora ora, o que temos aqui?

msg aponta para o endereço 0x401000 que era o endereço usado pelo _start no nosso programa anterior
e agora _start aponta para outro endereço, 0x40100d que está 13 bytes ("d" em hexa) acima de msg, exatamente os 13 bytes da string "Hello, World" adicionado com quebra de linha!!!!!1

Superb! Mas o que significa o valor 0x6c6c6548?

Se analisarmos com calma, dá pra perceber que se trata dos caracteres da string em ASCII segundo o que foi definido no programa. Mas eles estão invertidos, lembra de endianness que foi explicado no artigo anterior?

Então, esta arquitetura segue o padrão little-endian, onde os bytes são armazenados na ordem inversa, do menos relevante (expoentes menores da base 2) para o mais relevante (expoentes maiores).

Voltando ao gdb, podemos confirmar que todos os bytes da string estão alocados trabalhando com ponteiros de 4 em 4 bytes:

(gdb) x msg
0x401000 <msg>: 0x6c6c6548 ; Hell

(gdb) x msg+4
0x401004:       0x57202c6f ; o, W

(gdb) x msg+8
0x401008:       0x646c726f ; orld

Ou então, o comando x permite passar uma quantidade junto com o formato de apresentação, por exemplo queremos que traga os primeiros 13 hexabytes a partir do ponteiro msg:

(gdb) x/13xb msg
0x401000 <msg>: 0x48    0x65    0x6c    0x6c    0x6f    0x2c    0x20    0x57
0x401008:       0x6f    0x72    0x6c    0x64    0x0a

Exatamente os hexadecimais da string "Hello, World" com quebra de linha!

Mas em Assembly, não precisamos definir os bytes de uma string em hexadecimal. Podemos utilizar os quotes literais, assim o programa fica menos verboso e o assembler faz o processo de traduzir o caracter para o hexadecimal da tabela ASCII:

msg: db "Hello, World", 0xA

Não conseguimos representar a quebra de linha dentro de quotes literais, então vamos manter esta com 0xA

Adicionando a chamada de sistema write

Como já sabemos, o programa precisa utilizar a syscall write para escrever na saída, que está definida da seguinte forma no glibc:

ssize_t write(int fd, const void buf[.count], size_t count);

nome da syscall vai em RAX
primeiro argumento (file descriptor, no caso o STDOUT) vai em RDI
segundo argumento (ponteiro para o início do buffer) vai em RSI
terceiro argumento (quantidade de bytes a serem escritos) vai em RDX

global _start

msg: db "Hello, World", 0xA
_start:
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ; Chamada de sistema
    ; glibc -> ssize_t write(int fd, 
                             const void buf[.count], 
                             size_t count)
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    mov rdi, 1   ; STDOUT
    mov rsi, msg ; ponteiro para o início da string
    mov rdx, 13  ; quantidade de bytes a serem escritos
    mov rax, 1   ; nome da syscall: SYS_write
    syscall      ; chamada de sistema

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ; Chamada de sistema
    ; glibc -> void _exit(int status)
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    mov rdi, 0   ; erro de saída
    mov rax, 60  ; nome da syscall: SYS_exit
    syscall

Ao compilar o programa com nasm + ld, seguindo a mesma lógica do primeiro programa, temos de fato a saída tão desejada:

$ ./hello
Hello, World

Yay! que dia maravilhoso!

Vamos ver como fica o trace disso tudo agora?

$ strace ./hello

execve("./hello", ["./hello"], 0x7fff139437f0 /* 24 vars */) = 0
write(1, "Hello, World\n", 13Hello, World
)          = 13
exit(0)                                 = ?
+++ exited with 0 +++

Wow, podemos ver que, agora, o programa executa primeiro a syscall write, que retorna o valor 13, que é quantidade de bytes escritos com sucesso; e a seguir executa a syscall exit, também com sucesso, indicando que nosso programa imprime a string na saída e termina sem erros.

Como ficou o tamanho do programa agora?

$ size hello

   text    data     bss     dec     hex filename
     52       0       0      52      34 hello

Hmm, parece que a seção text aumentou de tamanho, que é a adição da string "Hello, World" e das instruções para a syscall write. Mas por enquanto é a única seção existente:

$ size --format sysv --radix 16 hello

hello  :
section           size       addr
.text             0x34   0x401000
(omitindo seções de debug)
Total            0x139

Podemos ver que a string definida no rótulo msg, que começa no endereço 0x401000 está contida na seção .text.

Isto é um problema?

Mais ou menos:

O rótulo msg , que é um "dado", contendo a string, está definido num endereço de memória anterior, ou seja, em endereço de memória mais baixo em direção a 0
O rótulo _start, que é o início do programa, está definido num endereço posterior, ou seja, em endereço de memória mais alto com relação à string

No sistema operacional, todo programa é encapsulado em um processo tal como vimos no artigo anterior. E sendo um processo, é submetido a um "layout" que deve seguir algumas regras.

Layout de memória

Fazendo paralelo com a saída do comando size, a memória do programa segue um layout, que basicamente contém as seguintes seções, ou segmentos de memória:

text
data
bss

Já falamos disto anteriormente neste artigo, mas basicamente na seção text fica todo o código, instruções do programa.

Na seção data, ficam dados inicializados (aqui deveria estar a nossa string). E na seção bss vão os dados não-inicializados, mas já com uma área pré-alocada na memória.

Em termos de espaço virtual de memória do programa, a seção text deve ficar nos endereços de memória mais baixos, próximos ao entry point 0x401000.

Com isto, o programa deve crescer a partir da seção text em direção a data e bss, dos menores endereços de memória para os maiores (da esquerda pra direita):

text -> data -> bss

Ou então, analisando numa imagem em vertical, de baixo pra cima:

Existem mais seções no layout mas vamos adicioná-las à medida que avançamos no artigo. Por agora, como nosso programa está tratando dados (msg) como text, devemos colocar na seção correta, que é data:

global _start

; segmento de dados (endereços mais altos)
section .data
msg: db "Hello, World", 0xA

; segmento de texto (endereços mais baixos)
section .text
_start:
    mov rdi, 1   ; STDOUT
    mov rsi, msg ; ponteiro para o início da string
    mov rdx, 13  ; quantidade de bytes a serem escritos
    mov rax, 1   ; nome da syscall: SYS_write
    syscall      ; chamada de sistema

    mov rdi, 0   ; erro de saída
    mov rax, 60  ; nome da syscall: SYS_exit
    syscall

Com gdb, podemos conferir que agora estamos obedecendo o layout de memória estabelecido para o programa:

(gdb) x _start
0x401000 <_start>:      0x000000bf

(gdb) x &msg
0x402000 <msg>: 0x6c6c6548
(gdb)

Note que para acessar msg no segmento de dados, precisamos examinar através da referência, com o operador &

Definindo constantes

Em Assembly podemos definir constantes que podem ser reutilizadas em diversas partes do programa, evitando assim alguma redundância com repetição de código e valores.

A diretiva %define permite definir valores constantes tanto para string quanto números:

global _start

%define SYS_write 1
%define SYS_exit 60
%define EXIT_STATUS 1
%define STDOUT 1
%define NEWLINE 0xA

section .data
msg: db "Hello, World", NEWLINE

section .text
_start:
    mov rdi, STDOUT
    mov rsi, msg 
    mov rdx, 13
    mov rax, SYS_write
    syscall      

    mov rdi, EXIT_STATUS
    mov rax, SYS_exit
    syscall

Podemos também definir uma constante baseada em uma expressão aritmética. Por exemplo, ao invés de deixarmos o tamanho em bytes com valor fixo 13, podemos fazer que isto seja calculado com base em aritmética de ponteiros na memória com a diretiva equ:

...
section .data
msg: db "Hello, World", NEWLINE
msgLen: equ $ - msg
...

O operador $ tem o ponteiro de memória para o último byte no programa, no caso o NEWLINE definido na linha anterior. Ao subtrair do ponteiro msg com a expressão $ - msg, temos o tamanho em bytes calculado e desta forma não precisa ser um valor fixo em RDX:

global _start

%define SYS_write 1
%define SYS_exit 60
%define EXIT_STATUS 1
%define STDOUT 1
%define NEWLINE 0xA

section .data
msg: db "Hello, World", NEWLINE
msgLen: equ $ - msg

section .text
_start:
    mov rdi, STDOUT
    mov rsi, msg 
    mov rdx, msgLen
    mov rax, SYS_write
    syscall      

    mov rdi, EXIT_STATUS
    mov rax, SYS_exit
    syscall

Wonderful! Nosso programa agora tá muito mais elegante!

Ufa, parece que terminamos o nosso primeiro programa e este por si só já foi uma jornada longa. Mas tenha um pouco mais de paciência, vem comigo, pois chegou o momento de escrevermos um programa um pouco mais sofisticado.

Hora de explorar mais funcionalidades no Assembly e entrar no mundo da stack.

Um programa mais sofisticado

Vamos começar por um programa simples e evoluindo conforme depuramos e entendemos a memória. Ao fim, o programa deve ser capaz de receber um nome através dos argumentos da linha de comando e imprimir "Hi, <nome>".

Desejado:

$ ./greeting Leandro
Hi, Leandro

Definindo labels

Já sabemos que o programa precisa imprimir "Hi, " alguma coisa. Então as instruções pra syscall write são necessárias, e já fazendo uso de constantes:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
    mov rdi, STDOUT
    mov rsi, greet
    mov rdx, 3
    mov rax, SYS_write
    syscall

    mov rdi, 0
    mov rax, SYS_exit
    syscall

Este programa imprime "Hi" apenas. Mas podemos melhorar a organização separando em blocos com algum valor semântico:

separar o bloco de exit
separar o bloco de write

Assembly emprega o conceito de labels, que são rótulos, mas que podem ser definidas em qualquer parte do código. Utilizando o caracter ponto (.), o programa fica bem mais expressivo:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
.print:
    mov rdi, STDOUT
    mov rsi, greet
    mov rdx, 3
    mov rax, SYS_write
    syscall
.exit:
    mov rdi, 0
    mov rax, SYS_exit
    syscall

Assim como qualquer rótulo, o programa vai executando top-down. O que fizemos aqui foi apenas colocar rótulos em determinadas partes do programa, mas sem alterar seu fluxo de execução.

Desvio de fluxo com jump

Se quisermos alterar o fluxo de execução, podemos utilizar a instrução JMP que altera o fluxo do programa para outro ponto, continuando a partir desde novo ponto.

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
    ; Faz o jump para a label .print, sem passar por .exit
    jmp .print
.exit:
    mov rdi, 0
    mov rax, SYS_exit
    syscall
.print:
    mov rdi, STDOUT
    mov rsi, greet
    mov rdx, 3
    mov rax, SYS_write
    syscall

    ; Faz o jump para a label .exit, caso contrário o programa não terminaria
    ; da forma adequada (todo programa deve terminar)
    jmp .exit

Este foi um exemplo bastante simples com jump e desvio de fluxo. Mas é possível também desviar o fluxo, executar a lógica do novo fluxo, e retornar ao ponto anterior.

Entretanto, para que isto funcione, vamos imaginar uma possível solução:

definir algum registrador "especial" que guarda sempre o ponteiro da próxima instrução
antes de desviar o fluxo, guardar o endereço de memória da próxima instrução do programa em alguma estrutura de dados para que possa ser resgatado quando a lógica do desvio terminar

Sim, estamos falando do desvio com call, ret, registradores e pilha.

Desvio de fluxo com call

Tendo o exemplo anterior, ao invés de fazer jmp, vamos utilizar a instrução call que faz o desvio para outra rotina:

call .print  ; <------ chamada da rotina

Além disso, a última linha da rotina .print deve "retornar" o fluxo desviado para o ponto anterior.

.print:
    mov rdi, STDOUT
    mov rsi, greet
    mov rdx, 3
    mov rax, SYS_write
    syscall
    ret  ; <------ retorno da rotina

Antes de analisarmos com gdb passo a passo, precisamos entender um aspecto importante dos programas no sistema operacional.

Quando um programa é executado, ele é definido em uma estrutura chamada processo (já falamos disto no artigo anterior). Todo processo carrega o layout de memória definido no binário do programa, conforme vimos anteriormente:

text -> data -> bss

Nos endereços mais altos da memória virtual do processo (programa em execução), o sistema operacional também define uma outra estrutura de dados, chamada stack, que tem um formato de pilha (LIFO, Last In, First Out).

text -> data -> bss ---------> <-------- stack

A stack fica nos endereços mais altos e carrega informações como argumentos do programa, lista de variáveis de ambiente definidas no shell, argumentos para funções entre qualquer informação pertinente para o programa. Stack sempre cresce para baixo em direção aos endereços menores.

rsp
Em um programa Assembly x86, é preciso armazenar o ponteiro atual do topo da stack, e esta informação fica no registrador RSP, ou stack pointer.

rip
Já o ponteiro da instrução atual fica no registrador RIP, ou instruction pointer.

Com estes dois registradores conseguimos demonstrar o uso de call e ret para desvio de fluxo. Voltando ao programa:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
    call .print     ; <--------- desvio do fluxo

    ; aqui neste ponto, já continua a execução normal em direção ao exit
    ; para terminar o programa
.exit:
    mov rdi, 0
    mov rax, SYS_exit
    syscall
.print:
    mov rdi, STDOUT
    mov rsi, greet
    mov rdx, 3
    mov rax, SYS_write
    syscall
    ret            ; <---------- retorno ao ponto anterior

E agora demonstrando com gdb:

$ gdb greeting

# Breakpoint em _start, início do programa
(gdb) break _start_
(gdb) run

# RIP apontando para 0x401000 (_start), o entry point do programa
(gdb) info register $rip
rip            0x401000            0x401000 <_start>

# RSP apontando para um endereço de memória
# Se formos examinar com x $rsp, temos
# 0x7fffffffe450: 0x00000001, que é a quantidade de argumentos
# passados, no caso 1 representa apenas o nome do programa, ou seja
# não há argumentos na linha de comando
(gdb) i r $rsp
rsp            0x7fffffffe450      0x7fffffffe450

Até aqui okay, agora vamos andar um step para que o desvio de call seja avaliado e analisar o RIP:

(gdb) step
18              mov rdi, STDOUT

# O RIP andou conforme esperado
(gdb) i r $rip
rip            0x401011            0x401011 <_start.print>

# RIP apontando para 0x000001bf, que é BF 01 00 00 
# Lembra? é o opcode pra MOV RDI, 1
# Exatamente onde paramos
(gdb) x $rip
0x401011 <_start.print>:        0x000001bf

E a stack (RSP) como ficou?

# A pilha andou alguns bytes (no caso foi feito um "push", o que a fez crescer para endereços de memórias menores)
# Lembra? Pilha "cresce pra baixo" na memória
(gdb) i r rsp
rsp            0x7fffffffe448      0x7fffffffe448

# Opaaa, o que temos aqui? 0x00401005
# É alguma pista...
(gdb) x $rsp
0x7fffffffe448: 0x00401005

# Examinando o ponteiro do início do programa...
(gdb) x _start
0x401000 <_start>:      0x00000ce8

# Se andarmos alguns bytes, 
# temos exatamente o endereço da label .exit, 0x401005
(gdb) x _start + 5
0x401005 <_start.exit>: 0x000000bf

Se você prestou atenção nos comentários do snippet acima...

É muito importante prestar atenção em todos os comentários, se não estiver fazendo isso, volte o artigo do início e tente acompanhar no terminal, é extremamente importante para entender os conceitos

...se prestarmos a devida atenção, este é o endereço que tá no topo da pilha agora, que foi adicionado pela instrução call.

Ok Leandro, mas como fazemos então para voltar ao ponto anterior?

Calma, jovem. Estamos parados no início da rotina .print. Vamos continuar a depuração com gdb até parar em ret:

(gdb) next
19              mov rsi, greet
(gdb) next
20              mov rdx, 3
(gdb) next
21              mov rax, SYS_write
(gdb) next
22              syscall
(gdb) next
Hi
_start.print () at greeting.asm:23
23              ret
(gdb)

Nice, antes de avaliar a instrução ret, podemos ver que RIP andou mas RSP continua na mesma, com o endereço da próxima instrução antes do desvio:

# RIP aponta para a instrução da linha "ret"
(gdb) x $rip
0x40102c <_start.print+27>:     0x000000c3

# RSP aponta para o endereço de memória que está a instrução .exit, que
# vem a seguir ao desvio feito com "call" lá em cima
(gdb) x $rsp
0x7fffffffe448: 0x00401005

Vamos andar com ret e....

# RIP agora aponta para 0x401005, que é a instrução .exit
(gdb) x $rip
0x401005 <_start.exit>: 0x000000bf

# Foi feito "pop" em RSP e agora este aponta para o topo da pilha
# com o valor exato quando estava no início do programa
(gdb) x $rsp
0x7fffffffe450: 0x00000001
(gdb)

OMG!! Acabamos de demonstrar manipulação de registradores e pilhas.

Brincando com pilhas

Pilhas é divertido.

Mas prefiro filas, gosto de tratar as coisas de modo ordenado. Quem chega primeiro precisa ser atendido primeiro kkkkkkkk

Mas com pilhas não é assim. Quem entra por último sai primeiro.

Com base nisto, como podemos manipular a stack do programa? Vamos alterar um pouco o código adicionando o ponteiro de greet na stack:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
    push greet    ; <----- adiciona o ponteiro de greet na stack
    call .print
.exit:
    mov rdi, 0
    mov rax, SYS_exit
    syscall
.print:
    mov rdi, STDOUT
    mov rsi, greet
    mov rdx, 3
    mov rax, SYS_write
    syscall
    ret

No gdb, vamos colocar um breakpoint na linha da chamada call:

# Breakpoint na linha 13
(gdb) b 13
Breakpoint 1 at 0x401005: file greeting.asm, line 13.

# Run
(gdb) r

# Examinando o topo da pilha
(gdb) x $rsp
0x7fffffffe448: 0x00402000

# Examinando o endereço de memória que tá no topo da pilha
(gdb) x 0x00402000
0x402000 <greet>:       0x2c0a6948

Cool, temos 0x48 0x69 0x0A (little-endian), exatamente a string "Hi" seguida de uma quebra de linha. Com esta rica informação, ao invés da rotina .print passar pro registrador RSI o ponteiro de greet, porque não passar o ponteiro do topo da pilha?

Algo nessa linha:

; ao invés disso (atual)
mov rsi, greet

; que tal mover o ponteiro que tá em rsp (topo da pilha) para rsi
mov rsi, rsp

Por enquanto, seguramos esta ideia no bolso. Ainda no gdb, vamos continuar analisando a pilha depois de entrar na rotina:

(gdb) step
_start.print () at greeting.asm:19

# Agora o topo da pilha foi modificado, "call" colocou o endereço de 
# memória da próxima instrução quando voltar do "ret"
(gdb) x $rsp
0x7fffffffe440: 0x0040100a

# O endereço de memória aponta justamente pra próxima instrução quando voltar do "ret", no caso a instrução que tá na label .exit do programa
(gdb) x 0x0040100a
0x40100a <_start.exit>: 0x000000bf

Mas agora o topo da pilha estraga nossa ideia de fazer mov rsi, rsp, mas podemos fazer aritmética com ponteiros e mover o conteúdo resultante, e é muito fácil:

# Topo da pilha apontando pra instrução guardada pelo "call"
(gdb) x $rsp
0x7fffffffe440: 0x0040100a

# Topo da pilha + 8 bytes apontando pro endereço onde tá a string "Hi"
(gdb) x $rsp+8
0x7fffffffe448: 0x00402000

Nesta arquitetura, a pilha, assim como os registradores, armazenam por padrão até 8 bytes por cada informação

Então teoricamente, tudo o que precisamos é mov rsi, [rsp + 8]

Note que é preciso usar [rsp + 8], com square brackets é uma forma de fazermos aritmética de ponteiros e acessar o valor resultante da operação na memória, no caso o endereço apontando para a string "Hi"

Para finalizar este primeiro exemplo, é muito importante fazermos "pop" da pilha. Todo push deve ter um pop, caso contrário podemos gastar a pilha desnecessariamente e talvez chegar a um stack overflow se exagerarmos bastante.

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi", 0xA

section .text
_start:
    push greet             ; <----- push na pilha
    call .print
    pop rbp                ; <----- pop da pilha, jogando o valor em rbp
                           ; note que rbp é outro registrador de propósito geral,
                           ; mas que é utilizado para manter a base da pilha
.exit:
    mov rdi, 0
    mov rax, SYS_exit
    syscall
.print:
    mov rdi, STDOUT
    mov rsi, [rsp + 8]     ; <----- 8 bytes depois do topo da pilha está o
                           ; endereço de memória da string
    mov rdx, 3
    mov rax, SYS_write
    syscall
    ret

Podemos reparar 2 coisas:

A rotina .print está ficando bastante genérica, ou seja ela não sabe o que está na pilha, simplesmente move para o registrador RSI e faz a syscall write
A rotina .print ainda usa o tamanho em bytes como valor fixo, no caso 3 bytes. Deveria ser dinâmico também se quisermos fazer com que esta rotina seja bem genérica

Colocamos o tamanho também na pilha? Nah, seria mais interessante ainda se calculássemos dinamicamente o que vem da pilha. Para fazer este cálculo, teríamos que "iterar", em forma de loop, por cada byte que queremos imprimir, incrementar em um registrador e utilizar isto na syscall.

Vamos entrar no mundo dos loops e condicionais.

Calculando tamanho dinamicamente com loop

Combinando labels e jumps, podemos criar um loop em assembly, como neste pequeno exemplo a seguir:

; Um loop infinito sem condição de parada
; Não façam isso

global _start

_start:
.loop
    jmp .loop

Entretanto para adicionarmos uma condição de parada do loop, é necessário utilizar uma instrução de comparação e outra que muda algum estado.

No nosso exemplo, vamos introduzir um loop que calcula o tamanho da string antes de fazer a syscall. Entendendo a necessidade:

; Pseudo-code

.print:
    mov rdi, STDOUT
    mov rsi, [rsp + 8]   ; string em RSI     

    mov rdx, ?           ; <--- aqui devemos introduzir um loop que vai
                         ; modificando o valor de RDX, lendo byte a byte
                         ; o conteúdo da string
    mov rax, SYS_write
    syscall
    ret

Para resolver isto, podemos criar uma label chamada .calculate_size que contém um jmp para ela mesma:

.print:
    mov rsi, [rsp + 8]       ; string em RSI 
    mov rdx, 0               ; RDX começa em 0
.calculate_size:             ; label
    jmp .calculate_size      ; jmp "recursivo"
.done:
    mov rdi, STDOUT
    mov rax, SYS_write
    syscall
    ret

Ao rodarmos o programa, obviamente caímos em loop infinito. Precisamos definir uma condição de parada, que consiste em:

mudar o estado de alguma variável condicional
desviar o fluxo para outra label quando a condição for verdadeira

Em Assembly, podemos fazer a mudança de estado utilizando a instrução inc:

.print:
    mov rsi, [rsp + 8]     
    mov rdx, 0             ; RDX (contador) começa em 0
.calculate_size:
    inc rdx                ; incrementa o valor que está em RDX (linha 23)
    jmp .calculate_size
.done:
    mov rdi, STDOUT
    mov rax, SYS_write
    syscall
    ret

Com gdb, verificamos que o valor de RDX está sempre sendo incrementado:

# Adicionar breakpoint na linha 23 (<<inc rdx>>)
(gdb) break 23
Breakpoint 1 at 0x401021: file live.asm, line 23.

# Executar o programa, que vai no primeiro breakpoint
(gdb) run
Breakpoint 1, _start.calculate_size () at live.asm:23
23              inc rdx

# Continuar execução até o próximo breakpoint ou fim do programa.
# Mas como estamos em loop, o programa vai parar de novo nesta linha
(gdb) continue

# Atalho para "info register rdx"
(gdb) i r rdx
rdx            0x1                 1

# Próxima iteração...
(gdb) continue
(gdb) i r rdx
rdx            0x2                 2

# E assim infinitamente pois não temos ainda a segunda premissa da condição de parada, que é a condicional
(gdb) continue
(gdb) i r rdx
rdx            0x19                25

Como podemos elaborar esta condicional, uma vez que o valor em RDX pode ser infinito, logo ter todas as possibilidades?

Uma ideia é irmos consumindo byte a byte da string até chegar a zero. Para isto, podemos definir o fim da string com 0x0 e fazer aritmética binária na própria string, consumindo os bytes até chegar a 0x0!

Eis o exemplo com um pseudo-código:

; "Hi", 0 
; que em hexabyte fica 0x49, 0x69, 0x00

INCREMENT
0x69 0x00   ; consumiu o byte mais à esquerda 0x49

INCREMENT   ; consumiu o byte mais à esquerda 0x69
0x00 0x...

Nossa Leandro, que fantástico! Podemos então fazer inc em um registrador que contém a string, nesse caso o próprio RSI?

Isso mesmo!

.....
section .data
greet: db "Hi", 0xA, 0      ; <--- adicionamos o "zero" para identificar o 
                            ; fim da string

.....

.print:
    mov rsi, [rsp + 8]     
    mov rdx, 0
.calculate_size:
    inc rdx                 ; incrementa o valor inteiro em RDX (contador)
    inc rsi                 ; <--- além de incrementar o RDX, incrementamos
                            ; também o RSI, que contém o endereço de
                            ; memória para a string. Aritmética em hexabytes
                            ; vai fazer o efeito de "consumir os bytes até zero
    jmp .calculate_size
.done:
    mov rdi, STDOUT
    mov rax, SYS_write
    syscall
    ret

Agora, com gdb, vamos verificar o que está acontecendo com nosso programa:

# Breakpoint na linha <jmp .calculate_size>
(gdb) break 25
Breakpoint 1 at 0x401027: file live.asm, line 25.

(gdb) run

# Cool, o contador RDX foi incrementado
(gdb) i r rdx
rdx            0x1                 1

# Em RSI, temos outro endereço de memória.
# Anteriormente era o início da string, 0x402000, mas agora está
# apontando para 0x402001
(gdb) i r rsi
rsi            0x402001            4202497

# Wow! Temos os bytes da string "i", seguido de "\n", e depois o 0x00
# Parece que o inc RSI funcionou como esperávamos?
(gdb)x /4xb 0x402001
0x402001:       0x69    0x0a    0x00    0x2c

# A vida continua...
(gdb) continue

# Caminho mais curto
# E parece que RSI andou mais ainda, agora apontando para o byte "\n"
(gdb) x $rsi
0x402002:       0x0a

# A vida continua...
(gdb) continue

# O nosso grande momento! Agora RSI aponta para 0x00
(gdb) x $rsi
0x402003:       0x00

Tudo o que precisamos fazer, neste momento, é comparar o valor que está em RSI com zero. Se chegou a zero, significa que podemos parar o loop. Vamos verificar o que está no contador RDX (esperamos que seja 3):

(gdb) i r rdx
rdx            0x3                 3

Yay! Que grande momento!

Mas como verificar em Assembly se chegou ou não no valor? Existe "IF" e "ELSE" em Assembly?

Hell no!

Não. Não tem "IF" e "ELSE" em Assembly.

Uma possível solução seria:

utilizar uma instrução que compare o valor de um registrador ou em algum endereço de memória com qualquer outro valor
esta instrução iria guardar o resultado da comparação em outro registrador "especial"
utilizar outra instrução para fazer desvio do fluxo de acordo com o valor que estive neste registrador especial

Sim, é aí que entramos no tal do registrador RFLAGS.

RFLAGS

O registrador de flags é um registrador de status que mantém sempre o estado atual da CPU, neste caso estamos referindo a uma CPU x86_64, pelo que chamamos este registrador de RFLAGS.

Este registrador guarda opcodes condicionais, que são resultado de diversas operações lógicas e aritméticas que afetam o estado da CPU.

Voltando ao nosso exemplo, podemos comparar o registrador RSI com o valor 0, e então verificar o que está acontecendo com o registrador eflags:

.print:
    mov rsi, [rsp + 8]     
    mov rdx, 0
.calculate_size:
    inc rdx
    inc rsi
    cmp byte [rsi], 0x00   ; <-- aqui comparamos (em byte) o valor que está
                           ; em RSI com o byte 0x00
    jmp .calculate_size
.done:
    mov rdi, STDOUT
    mov rax, SYS_write
    syscall
    ret

E com isto podemos conferir com gdb:

# Breakpoint na linha <cmp byte [rsi], 0x00>
(gdb) break 25

(gdb) run

# O que temos no primeiro byte de RSI? "i", pois o "H" já foi
# consumido no <inc rsi>
(gdb) x /1xb $rsi
0x402002:       0x69

# E no eflags?
# Nossa, temos o IF que estávamos precisando!!!!!11
(gdb) i r eflags
eflags         0x202               [ IF ]

Calma jovem, IF não é o que você está pensando!

IF é uma flag chamada interrupt flag, que está sempre presente no programa em execução. Ela determina se o programa pode ou não sofrer interrupções de hardware. No nosso caso, está sempre habilitada por padrão, e é por este motivo que podemos fazer chamadas de sistema (syscalls).

Continuando no gdb...

(gdb) continue

# O que temos em RSI? "\n"
(gdb) x /1xb $rsi
0x402002:       0x0a

# Executar a instrução <cmp byte [rsi], 0x00>
(gdb) next

# Ok, segunda iteração continua na mesma, sem flags adicionais
(gdb) i r eflags
eflags         0x202               [ IF ]

######## Próxima iteração ##########

(gdb) continue

# O que temos em RSI? 0x00, cool.
(gdb) x /1xb $rsi
0x402003:       0x00

# Executar a instrução <cmp byte [rsi], 0x00>
(gdb) next

# Outras flags foram adicionadas ao estado: PF e ZF
(gdb) i r eflags
eflags         0x246               [ PF ZF IF ]

PF é a parity flag, que é adicionada quando uma operação aritmética em qualquer registrador resulta em paridade ímpar.

Não é do escopo deste artigo entrar em detalhes sobre PF, sugiro a leitura sobre o assunto

Já a ZF é chamada zero flag, adicionada quando uma operação aritmética resulta em zero, que é exatamente o que estamos buscando aqui.

Agora o que precisamos é desviar o fluxo (lembra do jmp) quando a flag zero está presente. Para isto, temos a disposição diversas instruções de jump baseadas em flags:

jz (jump if zero)
jnz(jump if not zero)
je (jump if equal)
jne (jump if not equal)

Isto pra mencionar apenas algumas, existem muitas outras que podem ser consultadas aqui

Com isto, a instrução que precisamos é a jz, que verifica se a flag ZF está presente:

.print:
    mov rsi, [rsp + 8]     
    mov rdx, 0
.calculate_size:
    inc rdx
    inc rsi
    cmp byte [rsi], 0x00     ; <--- compara RSI com 0x00. Adiciona a flag ZF                                  ; quando chegar a zero
    jz .done                 ; <--- desvia fluxo para a label ".done" caso a
                             ; flag ZF esteja presente
    jmp .calculate_size
.done:
    mov rdi, STDOUT
    mov rax, SYS_write
    syscall
    ret

Com gdb, colocamos o breakpoint na linha mov rdi, STDOUT que é depois do loop. Caso o programa fique parado nesta linha, significa que o loop foi concluído com sucesso e os bytes da string devidamente calculados:

# Breakpoint na linha <mov rdi, STDOUT>
(gdb) break 29

(gdb) run

# Olha o que temos aqui
(gdb) i r rdx rsi
rdx            0x3                 3
rsi            0x402003            4202499

# E se formos examinar a string (com x/s) em RSI, temos isto:
(gdb) x/s $rsi
0x402003:       ""

Em RDX, temos o contador, que está em 3, que é a quantidade de bytes que será passada como terceiro argumento da syscall write. Okay, aqui ficou tudo certo.
Em RSI, temos 0x402003, e o valor está vazio, ou 0x00. Isto é um problema

O problema reside no fato de que RSI precisa ter o ponteiro para a string em si, e as operações de inc rsi modificaram o registrador, pelo que não queremos que isto aconteça.

Podemos então inicialmente mover o valor que está em RSI para outro registrador temporário, que pode ser um daqueles registradores de rascunho, chamados de draft registers:

.print:
    mov rsi, [rsp + 8]     
    mov r9, rsi          ; aqui preservamos RSI, movendo o valor para R9
    mov rdx, 0
.calculate_size:
    inc rdx
    inc r9               ; incrementar o valor em R9, preservando assim RSI
    cmp byte [r9], 0x00  ; comparar 0x00 com R9, e não mais RSI
    jz .done
    jmp .calculate_size
.done:
    mov rdi, STDOUT       
    mov rax, SYS_write
    syscall              ; no momento da syscall, RSI está intacto, contendo
                         ; o ponteiro para o endereço de memória onde está
                         ; localizada a nossa queridíssima string "Hi"
    ret

Após estas alterações, vamos executar o programa completo:

./greeting
Hi

Que dia maravilhoso! Nosso programa imprime a string "Hi" calculando dinamicamente o tamanho dos bytes da string!

Entretanto, queremos implementar a proposta inicial, não é, Leandro? O programa não tem que ler o nome da linha de comando e imprimir "Hi, Leandro"?

Botando mais pilha no negócio

Nosso objetivo é chamar ./greeting com argumento e assim o programa deve imprimir Hi, com o argumento enviado:

# Objetivo, isto ainda não funciona
./greeting Leandro
Hi, Leandro

Se pensarmos um pouco, podemos inferir que qualquer argumento pode ser armazenado na stack do processo, que é quando o programa está em execução.

Com gdb, podemos confirmar isto:

# Breakpoint na primeira linha do programa, depois do _start
(gdb) break 12

# Executa o programa com o argumento "Leandro"
(gdb) run Leandro

# Onde estará Leandro? Na pilha? (rsp)
#      -> x de examine
#      -> /8xb os primeiros 8 hexa bytes
(gdb) x /8xb $rsp
0x7fffffffe450: 0x02    0x00    0x00    0x00    0x00    0x00    0x00    0x00

Mas o quê significa esse número 2? Vamos examinar a stack e a ordem das informações contidas nela.

Voltando ao gdb, e se lermos os próximos 8 bytes na stack?

(gdb) x /8xb $rsp + 8
0x7fffffffe458: 0xb1    0xe6    0xff    0xff    0xff    0x7f    0x00    0x00

Lembrando que os bytes são escritos na stack em formato little-endian, ou seja estão invertidos

Com isto, temos um hexadecimal 0x7fffffffe6b1. Parece um endereço de memória, não?

# Examinando o endereço de memória no formato de string (/s)
(gdb) x /s 0x7fffffffe6b1
0x7fffffffe6b1: "/Users/..../code/asm-x64/live"

Wow, temos o primeiro argumento, também chamado de ARG0 que é o nome do programa com o caminho absoluto no sistema operacional.

Andando mais 8 bytes...

# Endereço de memória...
(gdb) x /8xb $rsp + 16
0x7fffffffe460: 0xdf    0xe6    0xff    0xff    0xff    0x7f    0x00    0x00

# Examinando o valor que está no endereço
(gdb) x /s 0x7fffffffe6df
0x7fffffffe6df: "Leandro"

Yay! Temos o nosso argumento, armazenado na stack. É o primeiro argumento, também chamado de ARG1.

Se continuarmos andando na stack de 8 em 8 bytes, vamos passar por todos os argumentos (no nosso caso não há mais), e a seguir vamos chegar no vetor ambiente, que contém todas as variáveis de ambiente contidas no shell que está executando o nosso programa

Com isto, sabemos que o primeiro argumento está localizado em rsp + 16:

rsp: quantidade de argumentos
rsp + 8: ARG0, nome do programa
rsp + 16: ARG1, primeiro argumento (se existir)
rsp + 24: ARG2, segundo argumento (se existir)
e assim sucessivamente...até chegar no vetor de variáveis de ambiente (vetor ambiente)

Sabendo que nossa sub-rotina .print já recebe uma string da stack e calcula dinamicamente o tamanho da string que foi passada, podemos passar pro topo da stack o nosso argumento (que por acaso também está na stack), e em seguida chamada a rotina .print novamente:

section .data
greet: db "Hi, ", 0

_start:
    push greet      
    call .print     
    pop rbp     

    ; aqui fazemos push pro topo da stack o valor que está em RSP + 16 (ARG1)
    ; utilizamos o tipo "qword" que significa "quadword"
    push qword [rsp + 16]
    call .print
    pop rbp
...

O quê significa quadword? Em assembly podemos definir tipos de bytes, que basicamente são grupos de bytes, podendo ou não caber em um registrador ou stack dependendo da arquitetura da CPU.

byte: especifica 1 byte (8-bit)
word: 2 bytes (16-bit)
dword: 4 bytes (32-bit)
qword: 8 bytes (64-bit)
tbyte: 10 bytes

Na arquitetura x86_64, precisamos especificar que o tipo de byte adicionado na stack, quando não vier de um registrador mas sim de um lugar arbitrário na memória ou stack, tem um determinado tamanho em bytes.

Neste caso, estamos utilizando qword que é justamente 8 bytes (ou 64-bit) que representa a arquitetura em questão.

Precisamos adicionar mais um caracter, que é o newline, ou \n, no fim da mensagem. Para isto, podemos definir um dado inicializado e chamar a rotina .print , que já está bem "crescidinha", não?

Programa completo, com comentários:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi, ", 0
newline: db 0xA, 0

section .text
_start:
    push greet             ; adiciona "Hi, " na stack para print
    call .print     
    pop rbp         

    push qword [rsp + 16]  ; adiciona ARG1 na stack para print
    call .print
    pop rbp

    push newline           ; adiciona newline na stack para print
    call .print
    pop rbp
.exit:                     ; label de término do programa
    mov rdi, 0
    mov rax, SYS_exit
    syscall
.print:                    ; rotina de print no STDOUT
    mov rsi, [rsp + 8]     
    mov r9, rsi
    mov rdx, 0
.calculate_size:           ; loop para calcular tamanho da string
    inc rdx
    inc r9
    cmp byte [r9], 0x00
    jz .done
    jmp .calculate_size
.done:                     ; label para finalizar a rotina print e retornar
    mov rdi, STDOUT
    mov rax, SYS_write
    syscall
    ret

Rodamos o programa e:

./greeting Leandro
Hi, Leandro

OMG! Eu não estou acreditando no que estou vendo!!!!!11

Depurando o programa final com strace

Com strace, podemos fazer o trace de syscalls do programa final. Olha que maravilha isto:

$ strace ./greeting Leandro

execve("./greeting", ["./greeting", "Leandro"], 0x7ffc30f75368 /* 24 vars */) = 0
write(1, "Hi, ", 4Hi, )                     = 4
write(1, "Leandro", 7Leandro)                  = 7
write(1, "\n", 1
)                       = 1
exit(0)                                 = ?
+++ exited with 0 +++

Foram feitas 4 chamadas de sistema, sendo:

1 write, "Hi, "
1 write "Leandro"
1 write "\n"
1 exit

Falando um pouco de registradores

Até o momento, vimos durante este artigo a utilização de alguns registradores que foram muito úteis para o desenvolvimento do programa, dentre eles RSI, RAX, RDX, RSP, RIP, RFLAGS e assim por diante.

Mas qual o propósito de cada registrador? Posso usar qualquer registrador para qualquer operação, de forma aleatória?

De forma prática, sim. Mas nem sempre convém.

Nada impede que o teu programa coloque qualquer valor em um registrador arbitrário. Por exemplo, com gdb vamos alterar alguns registradores e ver como o programa se comporta:

# Breakpoint & run
(gdb) break 13
(gdb) run Leandro

# Vamos alterar alguns registradores arbitrários
(gdb) set $rax = 42
(gdb) set $rdx = 33

# Confirmando que foram modificados
(gdb) i r rax rdx
rax            0x2a                42
rdx            0x21                33

# Continuando...
(gdb) continue
Continuing.
Hi, Leandro
[Inferior 1 (process 19231) exited normally]

Okay, podemos ver que ter mudado estes registradores para qualquer valor não impactou o programa. No meio do programa, provavelmente eles são sobrescritos novamente e utilizados de acordo com determinada lógica.

Mas e se alterarmos, por exemplo, um registrador como o rip, que é o ponteiro da próxima instrução?

# Breakpoint & run
(gdb) break 13
(gdb) run Leandro

# Antes de alterar o RIP, podemos ver qual o valor ele carrega,
# que é o ponteiro da próxima instrução
(gdb) i r rip
rip            0x401000            0x401000 <_start>

# Vamos alterar o registrador RIP
(gdb) set $rip = 42

# Confirmando que foi alterando
(gdb) i r rip
rip            0x2a                0x2a

# Continuando...
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x000000000000002a in ?? ()

Ouch! Agora o programa não pôde ser finalizado com sucesso. Confirmamos então que nem sempre convém mudar os registradores sem haver algum critério.

Propósito dos registradores

Os registradores, e falando especificamente da arquitetura x86, seguem um propósito original para o qual foram designados. Mas também podem ser utilizados em convenções de chamadas de sistema tal como vimos na montagem das syscalls write e exit, e neste caso a utilização correta importa bastante.

E além disso, alguns registradores contém dados importantes para a execução do programa, tais como o rip e eflags.

Propósito original
Convenções de chamadas
Funcionamento crítico do programa

Apesar destas características importantes de uso dos registradores, podem haver situações em que utilizar um registrador de propósito geral é o que faz mais sentido para o programa. Vamos a seguir destacar alguns registradores e seus propósitos originais.

Registradores de propósito geral

Podemos categorizar os registradores de uso geral em 2 partes: manipulação de dados diretos ou endereços de memória.

Dados
Registradores podem manipular dados, que chamamos de valor imediato, e nesta categoria podemos utilizar RAX, RBX, RCX, RDX e os registradores de rascunho que vão de R8 a R15.

RAX: operações aritméticas e armazenamento de resultados; também usado para o nome de chamadas de sistema em convenções de chamada (syscalls)
RBX: ponteiro de base, utilizado para o endereço de algumas informações na memória
RCX: geralmente usado como contador, para armazenar a quantidade de vezes que uma instrução deve ser executada
RDX: usado para algumas operações de multiplicação e divisão, muito utilizado para armazenar o resto de operações
R8 a R15: registradores de rascunho utilizados para propósito geral

Endereços de memória
Registradores também permitem manipular endereços de memória. Nesta categoria temos RSI, RDI, RBP e RSP.

RSI: utilizado como um ponteiro de origem em operações de transferências de dados, frequentemente usado em loops para iterar sobre arrays ou buffers de dados
RDI: utilizado como ponteiro de destino em operações de transferências de dados, frequentemente usado junto com RSI
RBP: frequentemente usado como ponteiro base em operações de memória, para referenciar variáveis locais e parâmetros de função na stack
RSP: ponteiro para o topo da pilha (stack) do programa em execução

Registradores especiais

Vamos destacar apenas 2 dos registradores considerados "especiais":

RFLAGS: utilizado para armazenar o estado da CPU, frequentemente modificado por instruções aritméticas e controle de paridade binária
RIP: ponteiro de instrução, que sempre contém o endereço da próxima instrução a ser executada. Por exemplo, a instrução ret busca o endereço do topo da pilha e modifica o rip para que o programa continue a partir daquele ponto

Precisamos sempre utilizar todos os 64 bits?

Sabemos que registradores nesta arquitetura ocupam 64 bits de memória. Mas e quando o dado que estamos manipulando não precisa dos 64 bits? Conseguimos otimizar o uso de memória?

A ideia seria algo do tipo "por favor me dê uma fatia dos 64 bits, não preciso de tudo"

Historicamente, como vimos na parte II desta saga, as CPU's x86 não começaram com 64 bits. Evoluíram de 8 bits, para 16, então 32 até chegar em 64 bits.

Para manter compatibilidade, os registradores "legados" podem ser utilizados na arquitetura x64, e assim quando não houver necessidade de utilizar todos os bits do registrador, podemos utilizar uma fatia menor.

Por exemplo, o registrador RAX de 64-bits tem o seu equivalente de 32-bits que é o EAX, que ocupa os 32 bits mais baixos.

O registrador EAX, por sua vez, tem o equivalente AX de 8-bits. Dentro deste AX, podemos utilizar ainda a parte maior que se chama AH ou a parte menor que se chama AL.

O "H" em AH vem de "high", e consequentemente "L" de AL significa "low". Óbvio, não? :P

Sendo assim, há situações em que ao invés de:

mov rax, 7  ; 1 byte mas ocupa 8 bytes (64 bits)

E sabendo que 42 não ocupa 64 bits, podemos mudar para:

mov eax, 7  ; 1 byte mas ocupa 4 bytes (16 bits)

Ou então:

mov ax, 7   ; 1 byte ocupando exatamente 1 byte (8 bits)

Assim o programa final passa a ocupar menos memória em sua totalidade.

Seguindo esta lógica, podemos aplicar para todos os registradores, trazendo alguns como exemplo:

RAX: EAX -> AX -> AH -> AL
RBX: EBX -> BX -> BH -> BL
RDX: RDX -> DX -> DH -> DL
R8: R8W -> R8B

E assim por diante.

Uma side note sobre stack frames

Depois de publicar o artigo, o Rodrigo Gonçalves de Branco decidiu dar um feedback ultra detalhado executando todos os exemplos aqui demonstrados, e um dos insights foi sobre a utilização de stack frames.

Foi um trabalho fenomenal, meus agradecimentos ao Rodrigo

Voltando ao exemplo dos argumentos na pilha, dentro da rotina _start, temos a pilha do programa com o seguinte layout:

Quando fazemos a chamada:

...
    push greet    ; adiciona "Hi, " na stack para print
    call .print     
...

Estamos basicamente manipulando a pilha original do programa. O push vai colocar no topo da pilha (RSP) o endereço de greet, como demonstrado a seguir no GDB:

# Breakpoint no <push greet>
(gdb) break 13   

(gdb) run
(gdb) next

(gdb) x $rsp
0x7fffffffe448: 0x00402000

Agora a pilha ficou assim:

Se fizermos step no GDB, podemos ver que o RSP foi modificado novamente, desta vez adicionando o endereço da próxima instrução por conta da chamada call:

(gdb) step

(gdb) x $rsp
0x7fffffffe440: 0x0040100a

Isso é o que acontece com a pilha em uma simples chamada de rotina com argumentos!

Bom, sabendo disso, vemos que o argumento que precisamos está em rsp + 8, exatamente como no nosso programa original. So far, so good.

O problema é que podemos reparar que o RSP é modificado durante as chamadas de funções no programa. Não temos controle sobre isso.

E podem acontecer comportamentos inesperados (bugs?) quando isso ocorre, pelo simples fato de estarmos apontando dados na pilha e eles já estarem em posições que não esperávamos.

Para mitigar este potencial problema, podemos preservar a base da pilha em algum registrador sempre no início de cada função, desta forma cada rotina/função pode ter sua própria "versão" da pilha sem correr riscos de apontar para o dado errado.

Esta técnica é chamada de stack frame.

E é pra isso que usamos o registrador RBP! No prólogo de cada rotina, adicionamos o rbp na pilha e em seguida colocamos o ponteiro de rsp dentro do registrador rbp, igualando assim ambos registradores:

_start:
    push rbp
    mov rbp, rsp
....

Repare que esta técnica consiste em igualar RSP com RBP, assim pode-se de forma segura manipular o ponteiro em RBP, pois mesmo RSP sendo modificado pelo programa, RBP continua intacto.

Continuando com o programa:

push rbp
mov rbp, rsp
....
push greet
call .print
....

Constatamos no GDB que a stack foi alterada, portanto RSP foi modificado para apontar para o endereço da próxima instrução, ao passo que RBP continua apontando pro valor anterior:

# RBP 
(gdb) x $rbp
0x7fffffffe448: 0x00000000

# RSP aponta para o endereço da próxima instrução 
# antes da chamada da rotina
(gdb) x $rsp
0x7fffffffe438: 0x0040100e

# RSP + 8 aponta para o primeiro argumento da rotina
(gdb) x $rsp + 8
0x7fffffffe440: 0x00402000

# RSP + 16 aponta para o mesmo valor de RBP (base da pilha),
# ou seja, `RBP = RSP + 16` neste caso porque houve um PUSH
# explícito do argumento e também outro push feito pelo CALL
(gdb) x $rsp + 16
0x7fffffffe448: 0x00000000

E modificando a rotina .print para também ter seu próprio stack frame, como fica a pilha depois de executar:

.print:
    push rbp
    mov rbp, rsp
....

Analisando com GDB:

(gdb) x $rbp
0x7fffffffe430: 0xffffe448

(gdb) x $rsp
0x7fffffffe430: 0xffffe448

RSP e RBP ficaram igualados novamente, dando uma característica de stack frame, preservando a pilha como podemos ver na imagem a seguir:

Portanto, o argumento da rotina, ao invés de ser rsp + 8, passa a ser rbp + 16 por conta da stack frame, ficando da seguinte forma:

.print:                  
    push rbp
    mov rbp, rsp

    mov rsi, [rbp + 16]     
    mov r9, rsi
    mov rdx, 0

Uma coisa importante: ao final de cada rotina, antes do retorno, devemos fazer pop do topo da pilha para voltar ao estado original antes do push rbp feito no início da rotina:

push rbp
mov rbp, rsp
....
pop rbp
ret

Desta forma, ao fazer o pop rbp, o que está em RSP é justamente o endereço de retorno antes da chamada da função:

Ao continuar com o programa, a instrução ret (já falamos sobre ela anteriormente) faz pop do topo da pilha (RSP) e continua a execução do programa na próxima instrução:

_start:
    push rbp
    mov rbp, rsp     ; <--- iguala RSP e RBP

    push greet       ; <--- adiciona <greet> na pilha
    call .print      ; <--- adiciona ponteiro da próxima 
                         ; instrução na pilha
    pop rax          ; <--- faz pop de <greet> da pilha      

............
.print:                 
    push rbp         
    mov rbp, rsp     ; <--- iguala RSP e RBP

    mov rsi, [rbp + 16]     
        .............
    syscall
    pop rbp          ; <--- remove frame RBP da pilha
    ret              ; <--- faz pop do pointeiro da 
                         ; próxima instrução e atualiza RIP

Quando o fluxo volta para quem chamou a rotina, a próxima instrução deve ser sempre o pop dos argumentos que entraram na pilha.

Neste caso no exemplo anterior estamos fazendo pop do argumento e descartando o valor em RAX com pop rax, deixando assim a pilha em seu estado anterior à chamada da rotina:

Ao fim do programa (rotina _start), devemos também fazer pop rbp, assim a pilha volta ao estado original de quando foi iniciado o programa.

Código completo:

global _start

%define SYS_write 1
%define SYS_exit 60
%define STDOUT 1

section .data
greet: db "Hi, ", 0
newline: db 0xA, 0

section .text
_start:
    push rbp               ; <-- cria um stack frame
    mov rbp, rsp           ; para preservar a pilha

    push greet             ; adiciona "Hi, " na pilha
    call .print            ; chama sub-rotina
    pop rax                ; remove "Hi, " da pilha

    push qword [rbp + 24]  ; adiciona argumento na pilha
    call .print            ; chama sub-rotina
    pop rax                ; remove argumento da pilhha

    push newline           ; adiciona newline na pilha
    call .print            ; chama-subrotina
    pop rax                ; remove newline da pilha

    pop rbp                ; remove RBP da pilha, 
                               ; retornando ao estado original
.exit:               
    mov rdi, 0
    mov rax, SYS_exit
    syscall                ; termina o programa
.print:                   
    push rbp               ; <-- cria um stack frame
    mov rbp, rsp           ; para preservar a pilha

    mov rsi, [rbp + 16]     
    mov r9, rsi
    mov rdx, 0
.calculate_size:               ; loop para calcular tamanho
    inc rdx
    inc r9
    cmp byte [r9], 0x00
    jz .done
    jmp .calculate_size
.done:                     
    mov rdi, STDOUT
    mov rax, SYS_write
    syscall

    pop rbp                ; <--- remove RBP da pilha, 
                               ; retornando ao estado anterior

    ret                    ; <--- retorna fluxo para o
                               ; estado anterior

É isto. Esta seção foi apenas uma demonstração de como utilizar boas práticas de manipulação da pilha quando utilizamos argumentos em funções, através da técnica de criar um frame como base da pilha com o registrador RBP.

Conclusão

É isto, pessoal. Esta parte da saga foi bastante densa. Passamos pela criação de um programa simples em Assembly, ao passo em que íamos depurando o programa com ferramentas como strace, size e muito gdb.

Também aprendemos sobre labels, tipos de registradores, desvio de fluxo com jmp, call, ret, muita stack, depurando tudo e mais um pouco, loops, FLAGS e aritmética de ponteiro.

Apesar de ter sido muito denso, os tópicos aqui abordados servirão de base para entendermos o próximo artigo que já começa pesado com syscalls de rede, para iniciarmos o nosso tão esperado web server.

Nos vemos no próximo artigo!

Referências

Mnemonics
https://en.wikipedia.org/wiki/Mnemonic
Comparison of Assemblers
https://en.wikipedia.org/wiki/Comparison_of_assemblers
Linker (computing)
https://en.wikipedia.org/wiki/Linker_(computing)
Assembly x86 tutorial
https://www.tutorialspoint.com/assembly_programming/index.htm
Data segment
https://en.wikipedia.org/wiki/Data_segment
FLAGS register
https://en.wikipedia.org/wiki/FLAGS_register
Debugging with GDB
https://ncona.com/2019/12/debugging-assembly-with-gdb/
GDB command reference
https://visualgdb.com/gdbreference/commands/
GDB cheatsheet
https://cs.brown.edu/courses/cs033/docs/guides/gdb.pdf
[Vídeo] Introdução ao GNU Debugger - Blau Araújo
https://www.youtube.com/watch?v=t9OKpBKbJ4Q

Construindo um web server em Assembly x86, parte III, código de máquina

Leandro Proença — Tue, 23 Apr 2024 23:18:02 +0000

Agora que já temos uma base de entendimento sobre hierarquia de memória, arquitetura de CPU e registradores, vamos aplicar estes conceitos em exemplos práticos: construindo programas de computador.

Mas o que é um programa de computador?

Teremos a resposta para esta pergunta ao longo deste artigo. Vamos abordar muitos conceitos, desde código de máquina (o mais importante na minha opinião), a sistemas de numeração binário, decimal e hexadecimal.

Iremos também compreender opcodes, chamadas de sistema, modo kernel, libc, ASCII, standard streams; e alterar arquivos binários em hexadecimal.

Ao final deste artigo vamos estar em um patamar de entendimento mais holístico de como um programa é interpretado na CPU.

Ainda não entraremos em Assembly. Foi escolhido desta forma pois o intuito com esta saga é detalhar ao máximo como as peças de encaixam, e acredito que trazer Assembly sem explicar outros conceitos primordiais pode confundir bastante.

Também não é esperado que você escreva os códigos de máquina deste artigo, pois aqui neste link providencio o binário já pronto para que você possa acompanhar com as ferramentas que irei utilizar. Basta apenas baixar o arquivo binário no link fornecido e atribuir permissão de execução com chmod +x, se necessário.

Lembrando que é importante que esteja em um ambiente Linux, caso contrário não irá funcionar. Se estiver em outro ambiente e não puder virtualizar, poderá acompanhar esta saga apenas lendo, pois a ideia é também trazer muitos conceitos fundamentais de baixo-nível

Ainda não será o código do web server, o programa proposto neste post é bastante simples, mas estamos quase lá. Vamos focar em conceitos fundamentais para que futuros artigos, que cobrem o desenvolvimento do web server, possam ser melhor compreendidos.

Sem mais delongas, prepare-se para a partir de agora entrar numa espiral de código de máquina e manipulação de memória.

Agenda

O que é um programa de computador
- Sistemas Operacionais e Processos
- Um programa deve sempre terminar
Nosso primeiro programa
- A linguagem das CPU's, o sistema binário
- O famoso sistema decimal
- Hexadecimal, o queridinho dos computadores
- Opcodes
- Endianness
Nosso segundo programa
- Alocando dados na memória do programa
- ASCII
- Syscalls
- Montando a syscall write
- Montando a syscall exit
Manipulando o nosso programa
A vida de quem programa é assim?
Conclusão
Referências

O que é um programa de computador

Como já vimos na parte II, a função primordial de uma CPU é ler uma instrução da memória, decodificar, executar e armazenar o resultado de volta na memória.

Então a grosso modo, um programa de computador é um conjunto de instruções pra a CPU processar. Em um cenário típico, teríamos diversos programas diferentes lendo e escrevendo da mesma memória do computador:

Mas um potencial problema, é que neste cenário poderíamos ter dois diferentes programas acessando ou modificando o mesmo endereço de memória:

Pra resolver isto, precisamos agrupar as instruções de um programa de modo a "isolar" de outros programas que também estão rodando no computador.

É aí que entra um dos papéis do sistema operacional com o conceito de processos.

Lembrando que nesta saga, vamos focar apenas em sistemas UNIX-like, mais precisamente distruibuições GNU/Linux

🔵 Sistemas Operacionais e Processos

Cada programa executado no SO é encapsulado em uma estrutura chamada processo, que vai ter uma área virtual na memória principal.

Na prática, cada programa vai ter seu próprio "0x10000", isolado dos demais.

🔵 Um programa deve sempre terminar

Como o SO aloca recursos de memória (dentre outros) para o processo, nosso programa precisa indicar quando termina.

Desta forma aquele espaço reservado de memória fica livre para ser utilizado por outro processo. Isto evita problemas como vazamento de memória entre outros.

Caso isto não seja feito, o SO vai lançar uma exceção e o programa não pode ser admitido como processo.

Nosso primeiro programa

Vamos trabalhar inicialmente com um exemplo bastante simples. Um programa que não faz nada.

Nossa Leandro, como assim um programa que não faz nada?

Sim, parece estranho para linguagens de mais alto nível. Mas pensando em CPU isto já é alguma coisa, pelo que precisamos de ao menos algumas instruções para um programa que "não faz nada": o programa precisa terminar, lembra?.

🔵 A linguagem das CPU's, o sistema binário

Pensando na CPU como um dispositivo eletrônico, esta só entende pulso elétrico. Mas conseguimos abstrair tais pulsos como 0 ou 1.

Consequentemente, quando falamos em código de máquina para uma CPU estamos falando em instruções que utilizam sistema binário, composto de 0 ou 1.

Nosso programa que não faz nada além de "terminar" pode ser representado então pelo seguinte conjunto de instruções:

Não se preocupe em escrever o programa. Por enquanto são só exemplos de código de máquina para que possamos entender bem os conceitos



10111111 00000001 00000000 00000000 00000000   
10111000 00111100 00000000 00000000 00000000  
00001111 00000101

No sistema binário, cada símbolo é chamado de bit. Este simples programa tem 12 conjuntos de 8 bits cada. Conte você mesmo para confirmar!

O sistema binário tem esse nome porque só fornece dois tipos de símbolos para representar números. Vamos contar:

0
1

Acabou. Com 1 dígito podemos ter 2 combinações apenas. Mas e se quisermos representar mais números? Aí nos resta ficar combinando com mais dígitos.

Para 2 dígitos, conseguimos aumentar para 4 combinações:

Se quisermos continuar, temos que entrar com 3 dígitos, sempre começando com o mais à esquerda possível, o que nos dá 8 combinações:

Com isto, temos um padrão:

1 dígito: 2 combinações
2 dígitos: 4 combinações
3 dígitos: 8 combinações

Repare no padrão de exponenciação. Estamos pegando o número 2 como base e aplicando o número do dígito como expoente:

numero de símbolos ^ número de dígitos

2^1 = 2
2^2 = 4
2^3 = 8

Extrapolando para 4 ou mais dígitos, podemos chegar na seguinte conclusão:

2^4 = 16 combinações
2^5 = 32 combinações
2^6 = 64 combinações
2^7 = 128 combinações
2^8 = 256 combinações

E assim por diante...

Você tá brincando com minha cara, né Leandro? Vim aqui pra ficar escovando bit?

Não exatamente. No programa, cada conjunto ali de 8 bits (chamado de byte) tem um significado para a CPU, o que faz nosso programa ter 12 bytes.

E como não somos uma CPU, estamos nada preocupados em representar instruções em bits, vamos então converter para o sistema decimal para conseguirmos representar nosso mesmo programa de forma mais simples e intuitiva.

🔵 O famoso sistema decimal

Já estamos habituados com o sistema decimal. Muitos números no nosso dia-dia são representados através do sistema decimal.

Falamos de números como "dez", "cento e quinze", "quarenta e dois" sem qualquer problema, pois foi o que aprendemos desde a primeira infância. Nosso cérebro já fixou o aprendizado tão intrinsicamente, que sequer pensamos que se trata de um sistema de numeração como qualquer outro.

Vamos por um momento esquecer que sabemos sistema decimal e aplicar as mesmas regras que aplicamos para o sistema binário.

Repetindo mais uma vez, no sistema binário temos à disposição apenas dois símbolos: 0 e 1.

E no decimal?

Temos dez símbolos à disposição, que são:



0 1 2 3 4 5 6 7 8 9

Tal como no sistema binário, com 1 dígito apenas temos essas 10 possibilidades acima.

Já chegou no nove? Acabaram as combinações? Não tem problema, vamos subir pra dois dígitos sempre começando pelo dígito mais à equerda possível:



00 01 02 03 04 05 06 07 08 09
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
...
...........................99

Olha só, com apenas dois dígitos no sistema decimal, podemos combinar 100 números diferentes!

O padrão é o mesmo no sistema binário, podemos logo aplicar exponenciação da base, sendo:

numero de símbolos ^ número de dígitos

Portanto:

10^2 = 100 combinações
10^3 = 1000 combinações
10^4 = 10000 combinações
etc etc etc

Convertendo binário em decimal

Uma vez que entendendo sistemas de numeração binário e decimal, podemos "compactar" nosso programa inicial de binário para decimal de modo a termos uma leitura mais intuitiva, não?

Aplicando a regra de exponenciação, não fica difícil fazer a conversão:

0 é sempre 0, pois este símbolo está presente em ambos sistemas de numeração
Mesmo vale para 1, pois está presente em ambos

Se quisermos então converter 10 (que é o próximo número depois de 1 em binário) de binário pra decimal, vamos aplicar a seguinte regra:

dígito x 2^posição do dígito

...somando o resultado de cada operação em dígito, onde a posição mais à direita possível começa com zero, pois de acordo com a senhora matemática, qualquer número elevado a zero é UM*.

Com isto:

10 = (1 x 2^1) + (0 x 2^0) = 2 + 0 = 2

Vamos extrapolar um pouquinho?

11 = (1 x 2^1) + (1 x 2^0) = 2 + 1 = 3
100 = (1 x 2^2) + (0 x 2^1) + (0 x 2^0) = 2 + 0 + 0 = 4

Yay! Nice, uh?

Agora vamos converter byte a byte do nosso programa:



10111111 00000001 00000000 00000000 00000000   
10111000 00111100 00000000 00000000 00000000  
00001111 00000101

10111111 = (1 x 2^7) + (0 x 2^6) ... = 191
00000001 = (0 x 2^7) + (0 x 2^6) ... + (1 + 2^0) = 1
etc etc etc até chegar ao 12º byte

Temos então um programa convertido para decimal da seguinte forma:



191 1 0 0 0
184 60 0 0 0
15 5

Entretanto, não é comum representar sistema decimal para instruções de CPU, pois cada byte (8 bits) não seria dividido em partes iguais no sistema decimal, o que poderia causar um desalinhamento, criando buracos desnecessários na memória.

Uma forma de ver este problema é que o sistema decimal composto de 10 símbolos não é divisível por 8 (resto 2), que é a quantidade de bits em um byte

E se tivéssemos um sistema de numeração com uma quantidade de dígitos que fosse divisível por 8?

Sabendo que 16 é divisível por 8 (resto 0) e não causaria desalinhamento entre bits pra representar um programa, será que existe um sistema de numeração de 16 símbolos para podermos compactar ainda mais a representação textual do nosso programa?

Sim, estamos falando do sistema hexadecimal.

🔵 Hexadecimal, o queridinho dos computadores

Certamente você já ouviu falar, viu ou até praticou hexadecimal. Similar ao que fizemos com sistema decimal, vamos esquecer tudo o que sabemos sobre hexadecimal e aplicar algumas regras.

Quantos símbolos temos à disposição? 16.

Daí o nome: hexa, representando 6, e decimal representando 10. DEZ + SEIS!!!!!111

Os primeiros 10 símbolos são exatamente como no decimal:



0 1 2 3 4 5 6 7 8 9

E quanto aos 6 símbolos restantes? Poderíamos representar emojis, gifs animados ou derivados de batata, mas seria muito mais simples representarmos as primeiras 6 letras do alfabeto, não?



0 1 2 3 4 5 6 7 8 9 A B C D E F

As regras pra combinar são as mesmas, sempre do mais à esquerda possível:



0 1 2 3 4 5 6 7 8 9 A B C D E F
10 11 12 13 14 15 16 17 18 19 ?

Qual seria o próximo? 20?

Não, jovem, vamos combinar com as letras restantes



...
19
1A
1B
1C
1D
1E
1F

Agora sim, as combinações com o dígito 2:



20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 
30 31 32 33 34 ............................. 3F 
...........................99................9F
100

Com apenas 2 dígitos no sistema hexadecimal, podemos ter 256 combinações de números diferentes!

em binário, 2 dígitos = 4 combinações
em decimal, 2 dígitos = 100 combinações
em hexa, 2 dígitos = 256 combinações

Por exemplo, para termos 256 combinações com 2 símbolos FF, precisaríamos de 8 símbolos 1111 1111 no sistema binário, obviamente ocupando mais espaço pra representar e visualizar programas.

O céu é o limite 🚀

Aplicando regra de exponenciação para convertermos pra decimal, vamos ter o seguinte:

do 0 ao 9 é tudo igual
A = 10, B = 11, C = 12, D = 13, E = 14, F = 15

Onde:

dígito do sistema * 16^posição do dígito

Com isto, convertendo 1A e FF para decimal, ficaria:

1A = (1 * 16^1) + (10 * 16^0) = 16 + 10 = 26
FF = (15 * 16^1) + (15 * 16^0) = 240 + 15 = 255

Ok, mas precisamos converter de binário para hexa

Com razão, como podemos converter o byte 11111111 para hexadecimal? Dá pra fazer por dedução da conversão decimal, por exemplo:

sabendo que o byte 11111111 representa 255 em decimal, e sabendo que FF em decimal é 255, portanto concluímos que 11111111 = FF
se dividirmos o byte em 2 partes, podemos calcular que 1111 = F, portanto chegamos no mesmo resultado

Geralmente empregamos a técnica de dividir o byte em 2 partes de 4 bits cada. Assim fica mais fácil visualizar.

O simples programa original escrito em binário, fica então convertido em hexadecimal da seguinte forma:



BF 01 00 00 00 
B8 3C 00 00 00 
0F 05

Opa! Já conseguimos ter uma leitura mais intuitiva, certo? Mas que raios significa BF 01, B8 3C ou 0F 05 na CPU?

🔵 Opcodes

Cada CPU possui uma arquitetura específica. Falando de x64 (ou x86_64), esta traz um conjunto de opcodes no manual que representam as instruções disponíveis, registradores entre outras operações de CPU.

De acordo com o manual:

o opcode BF move um valor imediato para o registrador RDI
01 00 00 00: valor imediato hexa que representa 1 em decimal, mas na ordem inversa no formato little-endian (vamos falar de endianness mais a seguir)
o opcode B8 move um valor imediato para o registrador RAX
3C 00 00 00: valor imediato hexa que representa 60 em decimal, mas na ordem inversa no formato little-endian
o opcode 0F 05 entra no modo "kernel" do SO e aguarda a resposta de uma chamada de sistema (syscall)

Mas por quê os bytes são representados na ordem inversa nesta arquitetura de CPU?

🔵 Endianness

O conceito de endianness está relacionado com a forma que CPU's lêem e processam bytes na memória.

Vamos trazer o exemplo de um byte em binário, 10000001, que sabemos que é 129 em decimal. Prestando atenção nos expoentes:

2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0

o bit mais à esquerda, 1 x 2^7 = 128
somado com o bit mais à direita, 1 x 2^0 = 1
o restante dos bits está tudo a zero, não precisam entrar pra soma

Podemos inferir que os bits mais à direita não têm tanto peso no valor final, por isso são chamados bits menos significativos.

O bit da direita incorporou apenas o valor 1 pro resultado final

Da mesma forma, os bits mais à esquerda têm mais peso no valor final, por isso são chamados de bits mais significativos.

O bit da esquerda incorporou 128 pro resultado final, trazendo mais significância

Esta propriedade de definir significância de bits é chamada de endianness. Diferentes arquiteturas de CPU podem decidir ler do mais significativo ao menos significativo (padrão intuitivo de leitura, big-endian) ou do menos significativo ao mais significativo (little-endian).

A decisão passa por fatores históricos ou por facilitar manipulação de ponteiros. Diferentes sistemas podem decidir por inverter a leitura/escrita ou não dos bytes.

Na CPU x86_64, o formato é little-endian, portanto em hexa o valor de 4 bytes 00 0D 00 3C passa a ser 3C 00 0D 00 no formato little-endian.

Concluindo, vamos adicionar comentários ao nosso pseudo-programa:



BF 01 00 00 00  ; MOVE 1 PARA RDI
B8 3C 00 00 00  ; MOVE 60 PARA RAX
0F 05           ; CHAMADA DE SISTEMA (SYSCALL)

Como a CPU sabe qual syscall deve executar? Por padrão, o número da syscall fica no registrador RAX. E como saber qual o número da syscall?

Neste link, temos uma lista completa de todas as syscalls da arquitetura x64, e ali podemos conferir que a syscall exit do kernel representa o número 60 decimal, ou 3C hexa. É exatamente o que a instrução B8 3C está fazendo!

Mais a seguir neste artigo vamos aprofundar no mundo das syscalls e chamadas do kernel.

Nosso segundo programa

Até agora vimos apenas o código de máquina de um programa que não faz nada (apenas termina), mas foi bastante útil para entendermos sistema binário, hexadecimal e outros conceitos.

Continuaremos ainda explorando código de máquina. Não precisa escrever nada, mas pode acompanhar com o código que disponibilizei no início do artigo e rodar os comandos em Linux

Vamos agora elaborar um hipotético programa que imprime "Hello, World" na saída (STDOUT). Para isto, devemos:

alocar memória para a string "Hello, World"

Sim, dados ficam na memória junto com o programa, lembra?

escrever a string na saída STDOUT, que é a saída padrão do programa (em outras palavras, a "tela")

Se quiser mais detalhes do que é STDOUT, standard streams e redirecionamento de streams, sugiro ler outros artigos que escrevi sobre UNIX pipes

terminar o programa

Alocar, imprimir, terminar. Escrever no STDOUT é uma chamada de sistema, e terminar o programa é outra chamada de sistema. Portanto, temos:

uma alocação de dados na memória do programa
2 chamadas de sistema

🔵 Alocando dados na memória do programa

Em linguagem de máquina, fazemos alocação byte a byte, e sabendo que queremos alocar "Hello, World" literalmente, como representar cada letra, o caracter vírgula e o caracter espaço na memória?

Precisamos de uma tradução dos caracteres para representação decimal ou hexadecimal. É isso mesmo que você está lendo, vamos entrar em ASCII.

🔵 ASCII

ASCII (American Standard Code for Information Interchange), é um padrão para codificação de caracteres em comunicação eletrônica, criado nos anos 60.

O padrão ASCII estabeleceu inicialmente 7 bits para cada caracter e foi concebido para suportar caracteres presentes somente na língua inglesa. Por conta desta limitação, tem suporte para um máximo de 128 caracteres (2^7) que abordam os dígitos decimais, caracteres especais e letras do alfabeto, maiúsculas e minúsculas.

Mais tarde veio uma extensão da tabela com um bit a mais portanto suportando mais caracteres como acentuações, porém ainda com limitações para suportar outros idiomas e caracteres especiais.

Tempos depois surgiu o padrão Unicode, que adiciona a capacidade de codificação de tamanho variável, permitindo assim uma multitude de caracteres e alfabetos de diversos idiomas.

Unicode também contempla a mesma tabela ASCII nos primeiros 128 caracteres por questões de retrocompatibilidade em sistemas. Portanto, apesar de sistemas modernos utilizarem esquemas de codificação Unicode tais como UTF-8, neste artigo focaremos na terminologia ASCII por ser suficiente nos nossos exemplos

Podemos verificar na tabela ASCII que os códigos hexa de cada caractere da nossa string são:



H: 0x48     
e: 0x65     
l: 0x6C     
l: 0x6C     
o: 0x6F
,: 0x2C

W: 0x57
o: 0x6F
r: 0x72
l: 0x6C
d: 0x64

0x é uma notação, um prefixo para determinar que o número depois de x é um hexadecimal

Com isto podemos então escrever os primeiros bytes hexa do nosso programa:



48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A

Nice, agora vamos "montar" as instruções para a syscall que escreve no STDOUT. Como o kernel faz isso?

🔵 Syscalls

Syscalls são chamadas de sistema onde o programa sai do modo "user" e entra no modo "kernel". Basicamente, o programa fica à espera que o kernel do sistema operacional execute a função que foi solicitada.

Apesar de neste link estar tudo compilado, temos que entender um fator muito importante sobre o kernel que estamos trabalhando, e se trata do kernel Linux.

O kernel Linux foi escrito em C na virada da década de 80 para 90, e por ser escrito em C, todas as chamadas de sistema são declaradas em C.

Por exemplo, no manual de system calls do kernel podemos pesquisar sobre qualquer chamada de sistema ou comando utilitário.

A chamada que queremos utilizar pra escrever no STDOUT se chama write, e é definida pela função:



ssize_t write(int fd, const void buf[.count], size_t count);

...que está presente na biblioteca padrão C (libc), que o kernel incorpora.

Para distribuições GNU, que é o meu caso utilizando Ubuntu, há um repositório mirror do glibc que é a biblioteca padrão em C para sistemas GNU/Linux.

Repara que a função write espera 3 argumentos:

fd, ou file descriptor, que no nosso caso é o STDOUT, representado pelo valor 1

💡 STDIN representa 0 e STDERR representa 2. Tá lá no nosso outro artigo sobre Bash e UNIX pipes, corre dar uma olhada

buf, ou buffer, que é o ponteiro para o início do buffer de dados. No caso de escrever "Hello, World" com quebra de linha, o buf apontaria para o início da string "Hello, World\n" na memória.
count, que é o tamanho do buffer de dados a ser escrito. Para a string "Hello, World\n", o count seria 13, pois isso inclui os 12 caracteres da string mais 1 byte para a quebra de linha.

🔵 Montando a syscall write

Para montar uma chamada de sistema, é necessário seguir uma interface que determina como um programa deve comunicar com o sistema operacional.

Quem determina isto é a ABI (Application Binary Interface), que define como estruturas de dados ou funções computacionais conversam entre si.

Como precisamos chamar uma função do kernel Linux, vamos utilizar as convenções determinadas por este sistema operacional e a arquitetura da CPU em questão.

Com isto, podemos montar as instruções utilizando registradores para a syscall write. Novamente seguindo esta tabela (que ajuda muito), vamos fazer instrução por instrução:

👉 ARG0
O primeiro argumento da função vai no registrador RDI, e aqui vamos colocar o valor 1 que representa o file descriptor STDOUT. Em hexa, o manual x86 diz que o opcode hexa é BF, seguido do hexa 00 00 00 01 em formato little-endian:



BF 01 00 00 00

👉 ARG1
O segundo argumento é o ponteiro para o buffer onde começa a string na memória, movido para o registrador RSI.

Como a string fica no começo do programa, geralmente este endereço fica em 0x401000. Portanto, o opcode para o move no registrador é 48 BE e o valor do endereço de memoria no formato little-endian em hexa, 00 10 40



48 BE 00 10 40

👉 ARG2
Já o terceiro argumento da função vai para o registrador RDX, que representa o tamanho do buffer em bytes a ser escrito no file descriptor definido no registrador RDI (ARG0).

O opcode é o BA e o valor é 13 em hexa, que é 00 00 00 0D só que no formato little-endian:



BA 0D 00 00 00

Agora, vamos colocar no registrador RAX o número da syscall write, que de acordo com esta tabela (sempre esta tabela, habitue-se a ela), é o número 1, mas em hexa e little-endian:



B8 01 00 00 00

Falei bastante desta tabela, de syscalls e little-endian aqui, nos próximos artigos vou falar cada vez menos. A ideia é focar em outras coisas e estes detalhes estarem já bem fundamentados

Por último, vamos montar a instrução da syscall em si, que é o opcode:



0F 05

Trecho final da syscall write:



48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A ; "Hello, World"

BF 01 00 00 00                 ; MOV 1 para RDI
48 BE 00 10 40                 ; MOV 0x401000 para RSI
BA 0D 00 00 00                 ; MOV 13 para RDX
B8 01 00 00 00                 ; MOV 1 para RAX (write)
0F 05                          ; SYSCALL

A syscall write já tá montada, agora falta terminar o programa.

🔵 Montando a syscall exit

A API da chamada de sistema exit pode ser consultada no manual, e tem a seguinte assinatura no glibc:



void _exit(int status);

👉 ARG0
O primeiro argumento é o status de término, que de acordo com a especificação POSIX, pode ser qualquer inteiro de 0 a 255 mas sendo o 0 indicando que o progama terminou sem erros.



BF 00 00 00 00

Agora, vamos ao trecho final da syscall exit:



BF 00 00 00 00          ; MOV 0 para RDI
B8 3C 00 00 00          ; MOV 60 para RAX (exit)
0F 05                   ; SYSCALL

Programa completo:



48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A
BF 01 00 00 00 
48 BE 00 10 40
BA 0D 00 00 00 
B8 01 00 00 00 
0F 05          
BF 00 00 00 00 
B8 3C 00 00 00 
0F 05

Tomando como exemplo o binário que disponibilizei, ele tem mais bytes por conta de headers necessários para o próprio sistema operacional admitir o programa.

Vamos executar o binário:



$ ./example

Hello, world

Yay! Que dia, hein?

Manipulando o nosso programa

Com o arquivo binário em mãos, e sugiro baixar do repositório, vamos utilizar o utilitário xxd que faz um dump de hexa de qualquer binário, e com ele podemos reparar que o binário vai ter, a partir do byte 4096, a mesma quantidade de bytes que escrevemos aqui neste artigo:



xxd -s 4096 -g1 -c8 -l52 example

00001000: 48 65 6c 6c 6f 2c 20 57  Hello, W
00001008: 6f 72 6c 64 0a bf 01 00  orld....
00001010: 00 00 48 be 00 10 40 00  ..H...@.
00001018: 00 00 00 00 ba 0d 00 00  ........
00001020: 00 b8 01 00 00 00 0f 05  ........
00001028: bf 00 00 00 00 b8 3c 00  ......<.
00001030: 00 00 0f 05              ....

Maravilhoso, não?

E por fim, antes de concluir este artigo que por si só dá quase uma saga, vamos alterar o binário direto em código de máquina utilizando o utilitário hexedit.

Esta dica peguei em vídeos do Blau Araújo. Ele é realmente fantástico e traz conteúdo de primeira. Pra mim é a melhor referência para conteúdo de baixo nível em pt-BR

Para mudar o binário, rodamos o comando:



hexedit --color example

Que vai abrir um editor bastante específico. Com /, podemos buscar por um hexa, por exemplo "48", que vai levar para o início da string.

Vamos trocar o "W" maiúsculo por "w" minúsculo, diretamente em código de máquina, que significa trocar o byte 57 da tabela ASCII por 77:

Então:



48 65 6C 6C  6F 2C 20 57  6F 72 6C 64  0A

Passa a ser:



48 65 6C 6C  6F 2C 20 77  6F 72 6C 64  0A

Gravar o arquivo com ctrl+s e depois ctrl+c para sair. Executar novamente e:



$ ./example

Hello, world

MEO DEOS, impressionante!!!!111

A vida de quem programa é assim?

Leitores mais atentos devem estar se perguntando:

É sempre assim a vida de quem programa? Ficar escovando bits e mudar diretamente código de máquina em hexadecimal?

Para a maioria esmagadora dos casos, não.

E se a gente criasse um programa tradutor que nos permitisse montar as instruções em uma linguagem mais human-friendly e traduzisse para o código de máquina tal o que vimos aqui neste artigo?

Estamos falando de assemblers, que são montadores que permitem escrever em uma linguagem de montagem específica de uma arquitetura (um assembly) e converter para os opcodes, as instruções de CPU.

Reforçando, nesta saga vamos focar no montador NASM para a linguagem Assembly x86 de 64-bits em sistemas GNU/Linux.

Conclusão

Jornada longa essa, hein? Este artigo cobriu diversos conceitos fundamentais, tais como sistema binário, hexadecimal, opcodes, syscalls, libc, ASCII...

Estes conceitos fundamentam o entendimento para escrever código Assembly, que será o tema principal dos próximos artigos.

No próximo artigo, vamos abordar conceitos básicos de Assembly, buscando converter o simples programa que fizemos neste artigo em um asm (atalho pra dizer "assembly") bem organizadinho.

Em seguida, iremos entrar nas syscalls de socket, bind e accept justamente para montarmos o código do nosso web server. Vamos também manipular buffer de arquivos, alocar dados dinamicamente na memória, trabalhar com threads, locks, criar fila na mão, enfim, ainda há muita coisa por vir. Isto aqui é apenas a ponta do iceberg.

Não será um tutorial, mas vamos falar de mnemonics, endereçamento de memória, segmentos de memória, layout de memória de um programa, debugging com gdb entre outras coisas.

Fiquem ligades!

Referências

Blau Araújo, material de curso de Assembly
https://codeberg.org/blau_araujo/assembly-nasm-x86_64/raw/branch/main/pdf/aula01.pdf
Felix Cloutier, "x86 instruction reference"
https://www.felixcloutier.com/x86/
ASCII Table
https://upload.wikimedia.org/wikipedia/commons/thumb/1/1b/ASCII-Table-wide.svg/2560px-ASCII-Table-wide.svg.png
POSIX, Wikipedia
https://en.wikipedia.org/wiki/POSIX
ASM x86 Manual
http://ref.x86asm.net/coder64.html
Syscalls table
https://x64.syscall.sh/
Linux Kernel, Wikipedia
https://en.wikipedia.org/wiki/Linux_kernel
ABI, Wikipedia
https://en.wikipedia.org/wiki/Application_binary_interface
x86 calling conventions
https://en.wikipedia.org/wiki/X86_calling_conventions

Construindo um web server em Assembly x86, parte II, história e arquitetura

Leandro Proença — Thu, 11 Apr 2024 23:26:28 +0000

No artigo anterior demos uma introdução não-técnica sobre o que será esta saga de Assembly x86 conforme avançamos na construção de um web server.

Agora, chegou o momento de começarmos a de fato falar sobre coisas técnicas.

Como de costume, não gosto de esgormitar termos complexos sem a devida explicação. Portanto, vamos iniciar a saga trazendo um pouco de contexto histórico, motivações e porque estamos aqui quando o assunto é computadores.

Okay, agora fui filósofo demais. Mas o que mais importa é que o verdadeiro Assembly são os amigos que fazemos no caminho

Sem mais delongas, vamos ao que interessa.

Agenda

Um pouco de história
Computar informações
- Máquina de Turing
- Arquitetura de von Neumann
- O gargalo de von Neumann
Hierarquia de memória
- Como a CPU executa instruções
- Registradores de CPU
ISA
- CISC
- RISC
Por quê x86?
Conclusão
Referências

Um pouco de história

Ainda muitos milhares de anos a.C, o ser humano precisava realizar cálculos. Um dos instrumentos mais primitivos para esta tarefa era o Ábaco, e certamente você já deve ter visto um:

Não vou entrar em detalhes em como um Ábaco funciona, sugiro que compre um e experimente. É divertido. Eu usei quando estava no ensino primário (cria dos anos 90, cof cof).

Computadores mecânicos

Ainda nesta "pré-história" dos computadores e já avançando para uma Europa iluminista (circa século XVII), podemos ver a seguir invenções mecânicas e projetos como a máquina de calcular de Blaise Pascal, depois a máquina analítica de Charles Babbage e então a máquina de tabulação de Herman Hollerith.

💡 É da máquina de tabulação de Herman Hollerith que vem o nome do seu comprovante de pagamento "holerite"

Estas máquinas eram mecânicas e tinham muitas limitações como não ter uma memória própria para as "instruções", mas foram muito importantes para a evolução, possibilitando mais tarde que Ada Lovelace pudesse escrever o primeiro possível algoritmo para o projeto da máquina de Babbage.

Pra quem quiser uma explicação excelente e mais completa sobre a história dos computadores e como estes funcionam, sugiro o vídeo como reinventar um computador do zero do canal Infinitamente.

Computar informações

Na era moderna dos computadores, que se dá início no século XX, é quando acontece a revolução eletrônica através das válvulas e dos transistores.

Mas não apenas na área da eletrônica. Foi no século XX que vimos a revolução computacional através de um modelo abstrato que abriu portas para muito do que conhecemos hoje em termos de computadores.

Estamos falando da máquina de Turing.

Máquina de Turing

Nos anos 30, o matemático Alan Turing desenvolveu o conceito abstrato de uma máquina que possuía uma fita infinita, dividida em células, e um cabeçote de leitura/escrita que movia para frente e para trás na fita, possiblitando modificar o estado atual na máquina.

Basicamente, este modelo de máquina permitiria que certas classes de problemas pudessem ser resolvidas com operações simples.

Extrapolando, nesta fita, que pode representar um tipo de "memória", é possível armazenar o estado mas também outra máquina, ou seja, temos aqui o conceito de uma máquina de Turing universal, que é capaz de simular outra máquina de Turing.

De forma resumida, podemos colocar na fita tanto o estado (dados) quanto as próprias instruções do programa, mitigando assim o problema de limitação que os computadores primitivos tinham, que era resolver problemas complexos de forma mais simples.

Entretanto, a máquina de Turing era apenas uma abstração. Este conceito de instruções e estado na mesma memória precisava ser concretizado.

É aí que entra von Neumann.

Arquitetura de von Neumann

Von Neumman foi um polímata que propôs um modelo computacional que é utilizado por muitos computadores modernos e dispositivos que usamos hoje em dia.

Neste modelo, temos uma unidade de processamento central, ou CPU, que é responsável por realizar cálculos aritméticos e executar instruções.

Conectada a esta CPU, temos o conceito de memória compartilhada, que vai ser usada para armazenar todas as instruções e estado de um programa de computador.

Esta arquitetura possibilitou que computadores como ENIAC e EDVAC pudessem ser desenvolvidos. O EDVAC, por sua vez, foi um dos precursores na implementação do modelo de von Neumann, com uma CPU que era conectada a uma memória compartilhada e sequencial.

À medida que os componentes computacionais foram ficando mais modernos, os computadores foram ficando menores, mais potentes, versáteis e com utilização de propósito mais geral.

Então, a arquitetura de von Neumann pode ainda contar com dispositivos de entrada e saída de dados (impressora, teclado, mouse, placa de rede, monitor, etc), também conhecidos como dispositivos I/O:

Podemos assumir, então, que quando escrevemos um programa de computador, estamos basicamente manipulando uma memória finita (que tem fim) e dispositivos de entrada e saída de dados, através de instruções que são executadas pela CPU.

Tudo graças ao modelo concreto de von Neumann.

Vale destacar que há arquiteturas computacionais que não seguem este modelo, mas aqui neste guia estamos focando em computadores de propósito geral

O gargalo de von Neumann

Esta arquitetura entretanto traz uma limitação. Como o barramento (caminho) entre a CPU e memória é único, tanto instruções quanto dados trafegam pelo mesmo local, levando a um cenário onde a CPU pode ficar limitada em processamento até que todos os dados sejam lidos do barramento.

Uma forma de mitigar este problema é definir diferentes "níveis" de memória, para que a CPU possa ter uma taxa de processamento maior.

Você acertou, vamos falar agora sobre a hierarquia de memória.

Hierarquia de memória

Nosso programa manipula memória.

Com que frequência?

Todo tempo.

Para mitigar o problema do gargalo de von Neumann, podemos definir uma hierarquia de memória, assim não só a memória principal (RAM) é "enxergada pela CPU" como memória, mas também outros dispositivos de armazenamento no sistema computacional.

Adicionado a isso, com a modernização de computadores no século XX, foi criada a necessidade de orquestrar e controlar todas as interfaces com o hardware. Temos então a concepção de sistemas operacionais para esta tarefa, que começam a surgir em meados dos anos 60/70, dentre eles o UNIX.

Ao tratarmos tudo como memória, podemos introduzir tal hierarquia. Portanto, num sistema computacional tratamos tudo (ou quase tudo) como memória e assim o sistema operacional (SO) pode abstrair de um determinado programa onde aquilo na hierarquia se encontra de fato sendo utilizado, deixando então nosso programa "livre" deste detalhe de implementação física.

Quanto mais pro topo da hierarquia, menor a capacidade de armazenamento e mais caro. Por exemplo, registradores de CPU são memórias voláteis que estão no topo.

Vamos falar sobre registradores mais a seguir na saga

E quanto mais pra base da hierarquia, maior a capacidade e consequentemente mais barato. Exemplo na base são as unidades de armazenamento durável não-voláteis (HD, SSD etc).

No meio temos a memória principal e volátil, tendo como principal exemplo a memória RAM.

A hierarquia de memória desempenha, então, um papel crucial na forma como a CPU gerencia e acessa memória.

Como a CPU executa instruções

Para que uma CPU execute determinada instrução, é necessário ao menos um ciclo de clock, também chamado popularmente como "giro de CPU", ou ciclo de CPU.

Vamos imaginar uma coisa que fica "girando" indefinidamente igual um relógio. De forma simples, é assim que podemos imaginar o clock de uma CPU, como um giro de relógio.

Alguns tipos de instruções podem gastar mais de um ciclo, e determinar quais instruções vão gastar mais ou menos ciclos é algo que é projetado diretamente na construção da CPU.

E onde as instruções ficam armazenadas?

Isso mesmo, na memória.

Portanto, a CPU precisa buscar a instrução na memória, decodificar, executar e armazenar o resultado de volta na memória.

Tudo isto faz gastar imensos ciclos de CPU. Ao gastarmos ciclos, a CPU pode bater num limite e não conseguir atender a tantas operações no mesmo segundo. Pra não mencionar a latência que a CPU gasta pra utilizar o barramento físico e "viajar" até a memória principal.

Tomando como premissa a hierarquia de memória, e se ao invés de armazenar o resultado na memória principal, a CPU resolver armazenar dentro da própria CPU?

Conheça os registradores de CPU.

Registradores de CPU

Você já pode estar pensando em cache de CPU, né? Mas calma lá jovem, cache de CPU é outra seara que não pretendo entrar, não por agora.

Mas que também tem seu lugar na hierarquia de memória

Lembrando (mais uma vez), da hierarquia de memória, de forma muito simplificada:

topo: registradores
depois: cache de CPU
ainda depois: memória principal (RAM)
beeem depois: memória secundária (HD, SSD)

Quanto mais perto do topo, mais rápido a CPU consegue processar, mas em contrapartida é volátil e também tem menor capacidade de armazenamento.

Então, registradores são apenas memórias de hierarquia mais alta que são preferencialmente usadas para computação porque possuem a menor latência do conjunto de memórias disponíveis.

São nos registradores onde a CPU vai armazenar instruções e dados do programa em execução, de modo a manipular sem precisar ficar dando tantos "saltos" na memória principal, economizando assim latência e ciclos de CPU.

Vamos pensar nos registradores como "caixinhas" de tamanho fixo que ficam dentro da CPU.

E como podemos manipular os registradores da CPU? Devemos estabelecer um padrão, que define como controlar o conjunto de instruções da CPU.

Precisamos de uma arquitetura de conjunto de instruções, ou ISA (Instruction Set Architecture).

ISA

ISA serve para definir o conjunto instruções e registradores em uma determinada CPU. O fabricante define a ISA, que pode ser classificada de formas diferentes, determinando quantas operações podem ser feitas por instrução, entre outros aspectos.

Neste artigo vamos destacar 2 abordagens de conjunto de instruções: CISC e RISC.

CISC

CISC, ou Complex Instruction Set Computing, é uma arquitetura onde as instruções podem ser agrupadas em conjuntos mais complexos de instruções, permitindo que uma única instrução execute várias operações complexas.

Aqui, determinadas tarefas podem resultar em apenas um ciclo de CPU, o que aumenta eficiência, mas por outro lado, esta complexidade de instruções pode tornar o tempo de execução menos previsível.

Exemplos de arquiteturas CISC incluem System/360, PDP-11 e Intel 8086.

RISC

Para resolver o problema de instruções muito complexas em CISC, a arquiteura RISC, ou Reduced Instruction Set Computing, determina uma execução mais simples com menos instruções, diminuindo assim o número de circuitos e consequentemente ciclos de CPU. O tamanho das instruções geralmente é fixo, resultando em um desempenho mais rápido e previsível.

Exemplos de arquiteturas RISC são MIPS e ARM, sendo ARM atualmente utilizada nos processadores de MacBook M1 em diante.

Este é um dos motivos de um MacBook ARM consumir menos bateria e fazer menos barulho, por exemplo.

E já que o tema é x86...

Como a saga se trata de x86, especificamente 64-bit (logo mais vamos entender o motivo disso), inicialmente esta arquitetura foi desenvolvida seguindo o padrão CISC, que é o conjunto complexo de instruções.

Entretanto a ISA do x86 foi adaptada para suportar internamente operações simplificadas como encontramos em RISC, portanto pode-se sizer que x86 é um "fake-CISC", que segue um modelo "RISC-ish".

Por quê x86?

Alguns leitores mais atentos devem estar se perguntando: por quê raios x86? O que isto significa?

Bom, pra entender o que é isto, vamos mergulhar um pouco na história dos microprocessadores da Intel.

Anos 70

Os anos 70 foram primordiais. Além da explosão cambriana de sistemas operacionais, vemos também a consolidação da era dos transistores e assim a evolução das CPU's.

Do lado Intel, temos o 8080 de 8-bit lançado em 1974, que além de ser utilizado em sistemas industriais, também foi amplamente encontrado nos primeiros computadores pessoais.

Intel 8086

Esta versão traz consigo conjuntos de instruções de 16-bits e foi um marco na era dos computadores pessoais. É aqui que passa a ser cunhado o termo de família "x86", pois o "x" caracteriza qualquer número que venha antes de "86".

Intuitivo, não?

Anos 80, a década do Intel x86

A partir de então, nesta década vimos a chegada do 80286 (286) que suporta também 16-bit + 8-bit de endereçamento de memória; depois, o famoso 80386 (i386), que trouxe uma grande mudança suportando instruções de 32-bit e os famosos registradores exx (eax, ebx, eip, etc); para então chegarmos ao 80486 (486), que foi uma melhoria do 386 com suporte a instruções mais avançadas.

Pra quem tiver curiosidade em saber a especificação da arquitetura x86, está tudo bem documentado num simples manual de 5000 páginas

Anos 90, Pentium e além

O que vem a seguir é a evolução seguindo com os Pentium 586, 686 e depois, uma simplificação dos termos para x86_32 (32-bit) ou x86_64 (64-bit).

Destaca-se os Pentium II, III e os Core "i AlgumaCoisa" que perduram até hoje.

E os AMD?

Enquanto a Intel dominava o mercado de CPU's, a AMD (Advanced Micro Devices) mexeu os palitinhos e também lançou versões compatíveis com x86, portanto pode-se dizer que, ao desenvolver para arquitetura x86, é possível executar as mesmas instruções em uma CPU fabricada pela AMD.

Conclusão

É isto. Este foi um artigo bastante denso, que cobriu uma breve história dos computadores, passando por modelos computacionais até chegar nas arquiteturas de CPU's e entendermos o que significa aquele "x86" no título do artigo.

No próximo artigo, pretendo trazer brevemente sistema binário e hexadecimal para então começar a apresentar aquilo que estamos todos interessados: linguagem de montagem, ou simplesmente Assembly.

Artigo revisado com carinho por Jeff Quesado, o "Coelho da Bolha", e também por Cadu, o músico frustrado (same thing).

Referências

Ábaco, Wikipedia
https://pt.wikipedia.org/wiki/%C3%81baco
Máquina analítica, Wikipedia
https://pt.wikipedia.org/wiki/M%C3%A1quina_anal%C3%ADtica
Linguagem Assembly, Wikipedia
https://pt.wikipedia.org/wiki/Linguagem_assembly
Cronologia do x86, Wikipedia
https://pt.wikipedia.org/wiki/X86
Arquitetura de Von Neumann, Wikipedia
https://pt.wikipedia.org/wiki/Arquitetura_de_von_Neumann
Blau Araujo, "Fundamentos de Assembly com NASM"
https://codeberg.org/blau_araujo/assembly-nasm-x86_64
História da Computação, Wikipedia
https://pt.wikipedia.org/wiki/Hist%C3%B3ria_da_computa%C3%A7%C3%A3o
Inifitamente, "Como reinventar um computador do zero"
https://www.youtube.com/watch?v=BbnDmeNojFA
Total Phase, "What's a CPU register"
https://www.totalphase.com/blog/2023/05/what-is-register-in-cpu-how-does-it-work/
Turing Machine, Wikipedia
https://en.wikipedia.org/wiki/Turing_machine
Brilliant, "Turing Machines"
https://brilliant.org/wiki/turing-machines/
Instruction Set Architecture, Wikipedia
https://en.wikipedia.org/wiki/Instruction_set_architecture

Construindo um web server em Assembly x86, parte I, introdução

Leandro Proença — Tue, 09 Apr 2024 03:51:43 +0000

Assembly.

Para alguns, um monstrinho. Pra outros, algo antiquado. Mas pra quem tem curiosidade em entender como as coisas funcionam, oportunidade.

Nesta saga que será uma série de artigos, vamos explorar Assembly com NASM para arquitetura x86-64 em GNU/Linux enquanto desenvolvemos um web server multi-thread bastante simples.

O intuito não está nas capacidades do web server em si, pois este irá apenas responder uma mensagem "Hello, world" em formato HTML, mas sim nos conceitos utilizados para construi-lo.

Para quem não tem muita familiaridade com conceitos de mais baixo-nível em computação e concorrência, não se preocupe, pois queremos com este guia fazer com que temas que são vistos como "complexos" possam ser absorvidos com mais facilidade a quem tem curiosidade, podendo então causar aquela boa impressão no churrasco de domingo ou no jantar de Natal.

To brincando gente, tá proibido falar de Assembly nestas ocasiões, por favor não façam isso eu imploro

Conteúdo proposto

Ao longo dos artigos vamos passar por diversos conceitos de computação, sendo alguns de forma superficial e outros com um pouco mais de profundidade, podendo mencionar alguns:

Arquitetura de computadores
Tipos de arquiteturas
Padrões, sistema binário e hexadecimal
Básicos de Assembly x86-64
Debugging com GDB
Filesystem, Sockets
Threads, pool e alocação de memória
Arrays, filas, ponteiros
Concorrência e primitivos de sincronização como spinlocks e futex
Tag h1 do HTML (LOL)

Poderá haver mais conceitos a serem abordados, mas que serão mapeados e detalhados conforme necessidade.

É um tutorial de Assembly?

Definitivamente, não.

A ideia aqui é desenvolver de forma prática um servidor web enquanto passamos por conceitos de Assembly e não só, mas também outros temas importantes sobre concorrência.

Se quer fazer um tutorial rápido para se familiarizar com Assembly x86, há este do tutorials point, mas atenção que ele é para 32-bits, sendo que nosso guia será feito em 64-bits (uma vez entendido os conceitos, fica fácil transportar).

É um curso de Assembly?

Hell no.

Obviamente, vamos aprender diversos conceitos à medida que avançamos na saga, mas se você tem algum interesse em aprender fundamentos de Assembly de forma bastante didática, sugiro acompanhar a playlist de Fundamentos de Assembly x86-64 do Blau Araújo. Ele é referência no assunto em conteúdo pt-BR e já cortou muito mato neste assunto.

Requisitos de ambiente

É esperado que o código seja executado em um sistema UNIX-based, preferencialmente GNU/Linux x86_64 que é onde testamos o código proposto.

Sistema Operacional Ubuntu 22.04.4 LTS (GNU/Linux 6.5.0-17-generic x86_64)
NASM 2.16.01
GNU ld 2.38 (binutils)

E para debugging (claro, nesta casa fazemos debugging, não somos brincalhões):

GNU gdb 12.1
strace 5.16

Para outros ambientes, pode-se optar por rodar o código dentro de um container Docker, seguindo as versões acima apresentadas.

Exemplo de Dockerfile (validar isto plmdds):

FROM ubuntu
RUN apt-get update && apt-get -y install make binutils gdb build-essential wget strace
WORKDIR /app
RUN wget https://www.nasm.us/pub/nasm/releasebuilds/2.16.01/nasm-2.16.01.tar.gz -O nasm.tar.gz && tar -xzvf nasm.tar.gz && cd nasm-2.16.01 && ./configure && make && make install

Será que consigo acompanhar?

Você pode apenas ler e tentar entender os conceitos, ou então ser mais hands-on e escrever código à medida que avança nos artigos.

Recomendo fortemente que experimente o código e rode em seu próprio computador seguindo os requisitos de ambiente, seja em host, virtualizado ou containerizado.

O repositório com o código completo pode ser encontrado em leandronsp/magali.

Este artigo é o primeiro de uma série que vamos explorar sobre Assembly x86-64 enquanto desenvolvemos um web server do zero, sem enrolação e com muita mão na massa.

No próximo artigo já iremos começar com introdução a arquiteturas de computadores e o básico necessário com as terminologias e um pouco de história dos computadores, padrões e linguagens Assembly.

Stay tuned!