GoSudaGo-betingssætninger (if) i AMD64-assemblerkodegenerering og analyse af branch-instruktioner
If-sætninger i Go
Først skal det nævnes, at vi valgte Go, fordi Go blandt moderne sprog har den mest "smukke" assembly, og fordi effektiviteten af dets syntaks endda i visse tilfælde er overvældende i forhold til klassiske sprog.
Nu, hvor vi i den forrige forelæsning har forstået, hvordan et simpelt Go-program fungerer, skal vi straks sammenligne Go og Assembly linje for linje.
Kildekode
Først og fremmest optimerer moderne compilere, herunder GCC, også i Go automatisk forgreninger, der ikke har nogen betydning for udførelsen. Også C-compilere som GCC og Clang udfører meget aggressive optimeringer ved -O2, som er branchestandarden, så den tid, hvor programmører vanskeligt kunne stole fuldt ud på compileren, er i virkeligheden allerede endt for længst, idet den blev afsluttet i slutningen af det 20. århundrede.
Derfor giver det kun mening i det mindste, hvis man stiller betingelser, som compileren har svært ved at forudsige og omskrive til andre konstruktioner.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Hvis man erstatter dette med noget forudsigeligt, der kan fjerne forgreningen, såsom x = 10,
10 // fjerner compileren forgreningen ved optimering.
11 // Hvis man vil se dette direkte i assembly, skal man i C bruge fx -O0 eller
12 // lade compileren bruge en ekstern værdi, som den ikke kan forudsige,
13 // men da dette afsnit handler om moderne programmering, anvendes metoden
14 // med at slå Go's binæroptimering fra ikke.
15 if len(os.Args) < 2 {
16 return
17 }
18 x, _ := strconv.Atoi(os.Args[1])
19
20 if x < 10 {
21 println("X is smaller than 10")
22 } else {
23 println("X is larger or same as 10")
24 }
25}
I dette tilfælde kan compileren ikke forudsige input, så forgreningen oversættes uændret til maskinkode.
Assemblersprog
1TEXT main.main(SB) /home/yjlee/introduction-to-golang/learn-golang/if-and-switch/golang-if/main.go
2 main.go:8 0x47a840 493b6610 CMPQ SP, 0x10(R14)
3 main.go:8 0x47a844 7670 JBE 0x47a8b6
4 main.go:8 0x47a846 55 PUSHQ BP
5 main.go:8 0x47a847 4889e5 MOVQ SP, BP
6 main.go:8 0x47a84a 4883ec10 SUBQ $0x10, SP
7 main.go:15 0x47a84e 48833d12fb0a0002 CMPQ os.Args+8(SB), $0x2
8 main.go:15 0x47a856 7c58 JL 0x47a8b0
9 main.go:15 0x47a858 488b0d01fb0a00 MOVQ os.Args(SB), CX
10 main.go:18 0x47a85f 488b4110 MOVQ 0x10(CX), AX
11 main.go:18 0x47a863 488b5918 MOVQ 0x18(CX), BX
12 main.go:18 0x47a867 e834e8ffff CALL strconv.Atoi(SB)
13 main.go:20 0x47a86c 4883f80a CMPQ AX, $0xa
14 main.go:20 0x47a870 7d1d JGE 0x47a88f
15 main.go:21 0x47a872 e809befbff CALL runtime.printlock(SB)
16 main.go:21 0x47a877 488d0519f50100 LEAQ 0x1f519(IP), AX
17 main.go:21 0x47a87e bb15000000 MOVL $0x15, BX
18 main.go:21 0x47a883 e878c6fbff CALL runtime.printstring(SB)
19 main.go:21 0x47a888 e853befbff CALL runtime.printunlock(SB)
20 main.go:21 0x47a88d eb1b JMP 0x47a8aa
21 main.go:23 0x47a88f e8ecbdfbff CALL runtime.printlock(SB)
22 main.go:23 0x47a894 488d05c8040200 LEAQ 0x204c8(IP), AX
23 main.go:23 0x47a89b bb1a000000 MOVL $0x1a, BX
24 main.go:23 0x47a8a0 e85bc6fbff CALL runtime.printstring(SB)
25 main.go:23 0x47a8a5 e836befbff CALL runtime.printunlock(SB)
26 main.go:25 0x47a8aa 4883c410 ADDQ $0x10, SP
27 main.go:25 0x47a8ae 5d POPQ BP
28 main.go:25 0x47a8af c3 RET
29 main.go:16 0x47a8b0 4883c410 ADDQ $0x10, SP
30 main.go:16 0x47a8b4 5d POPQ BP
31 main.go:16 0x47a8b5 c3 RET
32 main.go:8 0x47a8b6 e845f0feff CALL runtime.morestack_noctxt.abi0(SB)
33 main.go:8 0x47a8bb eb83 JMP main.main(SB)
Ved hjælp af go tool får man den venlige hjælp, at det vises, hvilken syntaks der svarer til hvilken assembly, én for én.
Da det vi skal lære i denne omgang er sammenligningsudtryk og if-forgreninger, er det nok at fokusere på nogle få linjer.
CMPQ-instruktionen og JL-instruktionen
Instruktionen CMPQ er en instruktion til at sammenligne datatyper på 4 byte (4 ord), og dens etymologi er CoMPareQuadword, som er forkortet til CMPQ.
Når man ser på hukommelsesadressen 0x47a84e, findes der sætningen CMPQ os.Args+8(SB), $0x2.
I dette tilfælde sammenlignes antallet af argumenter, som programmet har modtaget, med det hexadecimale tal 0x2 (altså blot 2).
Dernæst undersøges det, om antallet af argumenter er mindre end 2 (altså om programmet kun har sig selv som argument), og et hop udføres efter sammenligningen via JL. Det vil sige, at dette er forkortelsen af Jump, Less than', altså JL.
Hvis argumentantallet var mindre end 2 i den foregående sammenligning, hopper programmet til adressen 0x47a8b0, hvor der findes JGE.
Men da det i denne syntaks er registeret AX, der anvendes, er det nødvendigt at kende identiteten af den værdi, der er gemt i registeret.
MOVQ-instruktionen
Herefter må man forstå, hvordan registeret 'CX' rent faktisk bruges til at gemme startadressen for dataene, og hvordan de faktiske data ekstraheres, efter adressen er læst.
Ser man på intervallet 0x47858-0x47863, udføres denne operation trin for trin.
Først indsættes startadressen for argumentarrayet i CX-registeret med instruktionen MOVQ os.Args(SB), CX. På dette tidspunkt er det nødvendigt at forstå Go's stringtype.
En string i Go er en struktur, og denne struktur er opbygget af to datatyper på 8 byte hver, altså i alt 16 byte.
| struct | 8 byte | 8 byte |
|---|---|---|
| string | hukommelsesadresse | strenglængde |
Visuelt kan det illustreres som ovenfor: de første 8 byte indeholder strengens startadresse, og de næste 8 byte indeholder strengens længde.
Derfor gemmes strengens adresse i registeret AX, og strengens længde gemmes i registeret BX.
CALL
Også i det forrige indlæg, når man så på funktionerne i runtime-familien, var der knyttet en instruktion med navnet CALL.
Den står foran de funktioner, der anvendes i Go, og den betyder bogstaveligt talt, at en given funktion kaldes, altså CALL. Efterfølgende anvendes CALL-funktionen til at konvertere strengen til et heltal, men hvor heltallet gemmes, er ikke synligt, fordi det er abstraheret væk i funktionen.
CMPQ-instruktionen og JGE-instruktionen
Hvis vi vender tilbage til den tidligere adresse 0x47a86c, sammenligner instruktionen strengens adresse med tallet 0xa (decimalt 10)!
Det betyder, at argumentet ikke længere anvendes i programmet, og derfor har man overskrevet strengens placering for at skabe pladsen til den heltalsvariabel x.
Dette er essensen af den aggressive optimering, der udføres i blandt andet Go.
Dernæst optræder instruktionen JGE, som er en forkortelse for Jump, Greater or Equals. Denne syntaks spørger derfor, om værdien er større end eller lig med den værdi, den sammenlignes med.
Således er det ikke direkte udtrykket x < 10, der står, men derimod x < 10 med sammenligningens retning vendt om!
Dette skyldes, at det i maskinkode er mere intuitivt og sparer én instruktion at springe over på forhånd, når betingelsen ikke er opfyldt, end at udføre sammenligningen én gang, når betingelsen er opfyldt, og derefter kontrollere igen, om den ikke er opfyldt.
Denne optimering er meget klassisk, og i modsætning til strconv.Atoi-eksemplet ovenfor er det et mønster, der hyppigt optræder selv i compilere med et betydeligt lavere optimeringsniveau, så det er godt at kende til.
Ved at udnytte dette kan man derfor opnå kildekode, der er forskellig, men som på assemblyniveau stemmer 100% overens.
Eksempel på spejlkode
Ved hjælp af nedenstående script kan man verificere, at et bash-script, efter at have genereret to kilder der er 100% spejlvendte, opnår præcis identisk assembly, når man kun ser på main og ser bort fra metadata, der varierer fra gang til gang.
1#!/usr/bin/env bash
2
3# 1. Fuldstændig nulstilling af eksisterende restfiler og mapper
4echo "[1/6] Cleaning up old artifacts..."
5rm -rf test_dir main_orig main_asm orig.asm asm.asm orig_pure.asm asm_pure.asm
6mkdir -p test_dir
7
8# 2. Skriv kildekoden til den oprindelige version (main.go)
9echo "[2/6] Generating main.go..."
10cat << 'EOF' > main.go
11package main
12
13import (
14 "os"
15 "strconv"
16)
17
18func main() {
19 if len(os.Args) < 2 {
20 return
21 }
22 x, _ := strconv.Atoi(os.Args[1])
23
24 s1 := "X is smaller than 10"
25 s2 := "X is larger or same as 10"
26
27 if x < 10 {
28 println(s1)
29 } else {
30 println(s2)
31 }
32}
33EOF
34
35# 3. Skriv kildekoden til spejlversionen (main_from_asm.go)
36# Operatorstrukturen synkroniseres fuldt symmetrisk, så compileren bruger den samme optimeringsskabelon (JGE) som før
37echo "[3/6] Generating main_from_asm.go..."
38cat << 'EOF' > main_from_asm.go
39package main
40
41import (
42 "os"
43 "strconv"
44)
45
46func main() {
47 if len(os.Args) < 2 {
48 return
49 }
50 x, _ := strconv.Atoi(os.Args[1])
51
52 s1 := "X is smaller than 10"
53 s2 := "X is larger or same as 10"
54
55 // Hvis strukturen x < 10 bevares med 10 som reference, vælger compileren
56 // præcis den samme JGE-mekanisme og blokplacering som i main.go.
57 switch {
58 case x < 10:
59 println(s1)
60 default:
61 println(s2)
62 }
63}
64EOF
65
66# 4. Byg hver version i det samme mappe- og filnavnemiljø
67echo "[4/6] Compiling both sources inside 'test_dir'..."
68cp main.go test_dir/main.go
69cd test_dir && go build -o ../main_orig main.go && cd ..
70rm test_dir/main.go
71
72cp main_from_asm.go test_dir/main.go
73cd test_dir && go build -o ../main_asm main.go && cd ..
74
75# 5. Udtræk den rene main.main-assemblyfunktion ved hjælp af go tool objdump
76echo "[5/6] Extracting main.main assembly sections..."
77go tool objdump -s "main\.main" main_orig > orig.asm
78go tool objdump -s "main\.main" main_asm > asm.asm
79
80# Fjern de virtuelle adresser, offsets og tekstdata for maskinkodebytes
81# og filtrér kun de rene instruktionsfelter (Opcode & Operands), som CPU'en vil udføre
82awk '{print $4, $5, $6, $7}' orig.asm > orig_pure.asm
83awk '{print $4, $5, $6, $7}' asm.asm > asm_pure.asm
84
85# 6. Verificér strukturen af de to maskinkodeinstruktioner via diff
86echo "[6/6] Verifying assembly structural integrity via diff..."
87echo "------------------------------------------------------------"
88if diff orig_pure.asm asm_pure.asm > /dev/null; then
89 echo "===> [성공] 두 바이너리의 main.main 기계어 로직이 100% 일치합니다! <==="
90 echo "컴파일러의 최적화 파이프라인 가이드라인을 완벽하게 동기화하여 동일한 어셈블리를 얻었습니다."
91else
92 echo "===> [실패] 어셈블리 명령어 구조에 차이점이 발견되었습니다. <==="
93 diff -u orig_pure.asm asm_pure.asm
94fi
95echo "------------------------------------------------------------"
Når man faktisk kører kildekoden, får man følgende information.
1[1/6] Cleaning up old artifacts...
2[2/6] Generating main.go...
3[3/6] Generating main_from_asm.go...
4[4/6] Compiling both sources inside 'test_dir'...
5[5/6] Extracting main.main assembly sections...
6[6/6] Verifying assembly structural integrity via diff...
7------------------------------------------------------------
8===> [성공] 두 바이너리의 main.main 기계어 로직이 100% 일치합니다! <===
9컴파일러의 최적화 파이프라인 가이드라인을 완벽하게 동기화하여 동일한 어셈블리를 얻었습니다.
10------------------------------------------------------------
Konklusion
Programmeringssprog tilbyder mange abstraktioner, men bag abstraktionerne gemmer der sig meget interessante og aggressive optimeringer, hvilket vi har set. Ved at udnytte dette omvendt kan man også skabe spejlkode, der har forskellig kildekode men identisk assembly. Hvis man interesserer sig for lavt niveau, og man støder på proprietær software skrevet i Go, er det ikke umuligt at adskille assemblyen og analysere den for at rekonstruere kildekoden.
Næste forelæsning
I næste time skal vi se nærmere på if-sætninger og på den anden spændende konstruktion, select-case-sætningen.