dpkg-buildflags

future

Several compile-time options (detailed below) can be used to enable features that should be enabled by default, but cannot due to backwards compatibility reasons.

lfs

This setting (disabled by default) enables Large File Support on 32-bit architectures where their ABI does not include LFS by default, by adding -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to CPPFLAGS.

QS

Mehrere Optionen zur Kompilierung (Details weiter unten) können verwandt werden, um dabei zu helfen, Probleme im Quellcode oder im Bausystem zu erkennen.

bug

Diese Einstellung (standardmäßig deaktiviert) fügt Warnoptionen hinzu, die zuverlässig problematischen Quellcode erkennen. Diese Warnungen sind fatal. Die einzigen derzeit unterstützten Schalter sind CFLAGS und CXXFLAGS, wobei die Schalter auf -Werror=array-bounds, -Werror=clobbered, -Werror=implicit-function-declaration und -Werror=volatile-register-var gesetzt werden.

canary

Diese Einstellung (standardmäßig deaktiviert) fügt Pseudo-Kanarienvögel-Optionen zu den Bauschaltern hinzu, so dass die Bauprotokolle überprüft werden können, wie die Bauschalter sich fortpflanzen. Dies erlaubt, Auslassungen in den normalen Bauschaltereinstellungen zu finden. Derzeit werden nur die Schalter CPPFLAGS, CFLAGS, OBJCFLAGS, CXXFLAGS und OBJCXXFLAGS unterstützt, wobei die Schalter auf -D__DEB_CANARY_Schalter_Zufallskennung__ gesetzt werden, und LDFLAGS, das auf -Wl,-z,deb-canary-Zufallskennung gesetzt wird.

Bereinigung

Mehrere Kompilierzeit-Optionen (weiter unten beschrieben) können dazu verwandt werden, ein erstelltes Programm vor Speicherverfälschungsangriffen Speicherlecks, Verwendung nach Freigabe, Daten-Zugriffswettläufen (»races«) in Threads und Fehlern durch undefiniertes Verhalten zu bereinigen. Hinweis: Diese Optionen sollten nicht beim Bauen im Produktivbetrieb benutzt werden, da sie die Zuverlässigkeit von spezifikationsgetreuem Code, die Sicherheit oder sogar die Funktionalität reduzieren können.

address

Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=address zu LDFLAGS und -fsanitize=address -fno-omit-frame-pointer zu CFLAGS und CXXFLAGS hinzu.

thread

Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=thread zu CFLAGS, CXXFLAGS und LDFLAGS hinzu.

leak

Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=leak zu LDFLAGS hinzu. Sie wird automatisch deaktiviert, falls entweder die Funktionalitäten address oder thread aktiviert werden, da diese sie einschließen.

undefined

Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=undefined zu CFLAGS, CXXFLAGS und LDFLAGS hinzu.

Härtung

Mehrere Kompilierzeit-Optionen (weiter unten beschrieben) können dazu verwandt werden, ein erstelltes Programm gegen Speicherverfälschungsangriffe zu härten, oder zusätzliche Warnungsmeldungen während der Übersetzung auszugeben. Sie werden für Architekturen, die diese unterstützen, standardmäßig aktiviert; die Ausnahmen sind unten angegeben.

format

Diese Einstellung (standardmäßig aktiviert) fügt -Wformat -Werror=format-security zu CFLAGS, CXXFLAGS CXXFLAGS, OBJCFLAGS und OBJCXXFLAGS hinzu. Damit wird über inkorrekte Formatzeichenkettenverwendungen gewarnt und zu einem Fehler führen, wenn Formatfunktionen deart verwandt werden, dass daraus ein mögliches Sicherheitsproblem werden könnte. Derzeit warnt dies über Aufrufe auf printf- und scanf-Funktionen, bei denen die Formatzeichenkette nicht eine reine Zeichenkette ist und es keine Formatargumente gibt, wie in printf(foo); statt printf("%s", foo);. Dies könnte ein Sicherheitsproblem sein, falls die Formatzeichenkette aus einer unvertrauenswürdigen Eingabe stammt und ‚%n’ enthält.

fortify

Diese Einstellung (standardmäßig aktiviert) fügt -D_FORTIFY_SOURCE=2 zu CPPFLAGS hinzu. Während der Code-Erstellung hat der Compiler umfangreiche Informationen über Puffergrößen (wo möglich) und versucht, unsichere unbegrenzte Pufferfunktionsaufrufe durch längenbegrenzte zu ersetzen. Das ist besonders für alten, verkramten Code nützlich. Zusätzlich werden Formatzeichenketten in schreibbarem Speicher, die ‚%n’ enthalten, blockiert. Falls eine Anwendung von solchen Formatzeichenketten abhängt, müssen dafür andere Lösungsmöglichkeiten gefunden werden.

Beachten Sie, dass die Quellen auch mit -O1 oder höher übersetzt werden müssen, damit diese Option einen Effekt hat. Falls die Umgebungsvariable DEB_BUILD_OPTIONS noopt enthält, dann wird die Unterstützung von fortify aufgrund neuer Warnungen von Glibc 2.16 und neuer deaktiviert.

stackprotector

Diese Einstellung (standardmäßig aktiviert falls stackprotectorstrong nicht verwandt wird) fügt -fstack-protector --param=ssp-buffer-size=4 zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS hinzu. Dies fügt Sicherheitsprüfungen gegen die Überschreibung des Stapelspeichers (Stacks) hinzu. Damit werden viele mögliche Code-Einfügeangriffe zu Abbruchsituationen. Im besten Fall werden damit Code-Einfügungsangriffe zu Diensteverweigerungsangriffen oder zu keinen Problemen (abhängig von der Anwendung).

Diese Funktionalität benötigt das Linken mit Glibc (oder einem anderen Anbieter von __stack_chk_fail). Sie muss daher deaktiviert werden, wenn mit -nostdlib oder -ffreestanding oder Ähnlichem gebaut wird.

stackprotectorstrong

Diese Einstellung (standardmäßig aktiviert) fügt -fstack-protector-strong zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS hinzu. Dies ist eine stärkere Variante von stackprotector allerdings ohne signifikante Einbußen bei der Leistung.

Deaktivierung von stackprotector deaktiviert auch diese Einstellung.

Diese Funktionalität stellt die gleichen Anforderungen wie stackprotector und benötigt zusätzlich Gcc 4.9 oder neuer.

relro

Diese Einstellung (standardmäßig aktiviert) fügt -Wl,-z,relro zu LDFLAGS hinzu. Während des Ladens des Programms müssen mehrere ELF-Speicherabschnitte vom Binder (Linker) geschrieben werden. Diese Einstellung signalisiert dem Ladeprogramm, diese Abschnitte in nur-Lese-Zugriff zu ändern, bevor die Steuerung an das Programm übergeben wird. Insbesondere verhindert dies GOT-Überschreibeangriffe. Falls diese Option deaktiviert ist, wird auch bindnow deaktiviert.

bindnow

Diese Einstellung (standardmäßig deaktiviert) fügt -Wl,-z,now zu LDFLAGS hinzu. Während des Ladens des Programms werden alle dynamischen Symbole aufgelöst, womit das gesamte PLT nur-lesend markiert werden kann (aufgrund von relro oben). Diese Option kann nicht aktiviert werden, falls relro nicht aktiviert ist.

pie

Diese Einstellung (seit Dpkg 1.18.13 ohne Vorgabe und standardmäßig von GCC auf den Debian-Architekturen Amd64, Arm64, Armel, Armhf, I386, Kfreebsd-amd64, Kfreebsd-i386, Mips, Mipsel, Mips64el, PPC64el, S390x, Sparc und Sparc64 hinzugefügt) fügt die benötigten Optionen mittels GCC-Spec-Dateien hinzu, falls sie zum Aktivieren oder Deaktivieren von PIE benötigt werden. Falls aktiviert und von GCC hinzugefügt, ergänzt nichts. Wenn aktiviert und nicht von GCC hinzugefügt, fügt -fPIE zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS hinzu und -fPIE -pie zu LDFLAGS. Wenn deaktiviert und von GCC hinzugefügt, fügt -fno-PIE zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS hinzu und -fno-PIE -no-pie zu LDFLAGS.

»Position Independent Executable« (positionsunabhängige Programme) werden benötigt, um »Address Space Layout Randomization« (Bereitstellung eines zufälligen Adressbereichlayouts) auszunutzen, der von einigen Kernelversionen bereitgestellt wird. Während ASLR bereits für Datenbereiche auf dem Stapel (Stack) und Heap erzwungen werden kann (brk und mmap), müssen die Codebereiche positionsunabhängig übersetzt werden. Laufzeitbibliotheken machen dies bereits (-fPIC), so dass sie ASLR automatisch erhalten, aber Programm-.text-Regionen müssen mit PIE gebaut werden, um ASLR zu erhalten. Wenn dies passiert, sind ROP- (Return Oriented Programming) Angriffe sehr viel schwerer durchzuführen, da es keine statischen Orte mehr gibt, zu denen während eines Speicherverfälschungsangriffs hingesprungen werden könnte.

PIE ist nicht mit -fPIC kompatibel, daher muss im Allgemeinen Vorsicht beim Bau von Laufzeitbibliotheksobjekten walten gelassen werden. Da aber der ausgegebene PIE-Schalter mittels GCC-Spezifikationsdateien hinzugefügt wird, sollte es immer sicher sein, sie bedingungslos zu setzen, unabhängig von dem Objekttyp, der übersetzt oder gelinkt wird.

Statische Bibliotheken können von jedem Programm und anderen statischen Bibliotheken benutzt werden. Abhängig von den zum Kompilieren aller Objekte innerhalb einer statischen Bibliothek verwandten Schaltern können diese Bibliotheken von verschiedenen Gruppen von Objekten verwandt werden:

Falls es notwendig ist, diese Schalter manuell zu setzen und die GGC-Spezifikations-Hinzufügung zu umgehen, müssen mehrere Dinge beachtet werden. Die bedingungslose und explizite Übergabe von -fPIE, -fpie oder -pie an das Bausystem mit Libtool ist sicher, da diese Schalter entfernt werden, wenn Laufzeit-Bibliotheken gebaut werden. Andernfalls könnte es bei Projekten, die sowohl Programme wie auch Laufzeit-Bibliotheken bauen, notwendig sein, dass Sie beim Bau der Laufzeit-Bibliotheken sicherstellen, dass -fPIC immer als letztes an die Kompilierungsschalter wie CFLAGS übergeben wird (so dass es jedes frühere -PIE außer Kraft setzen kann) und -shared als letztes an Link-Schalter wie LDFLAGS übergeben wird (so dass es jedes frühere -pie außer Kraft setzen kann). Hinweis: Das sollte mit der Vorgabe-GCC-Spezifikationsmaschinerie nicht notwendig sein.

Zusätzlich können auf einigen Architekturen mit sehr wenigen Registern (dazu gehört aber i386 nicht mehr, seitdem in GCC >= 5 Optimierungen erfolgten) Leistungsverluste von bis zu 15% in sehr text-Segment-lastigen Anwendungsfällen auftreten, da PIE über allgemeine Register implementiert ist; in den meisten Anwendungsfällen sind dies weniger als 1%. Architekturen mit mehr allgemeinen Registern (z.B. Amd64) erfahren nicht diese Schlimmstfall-Strafe.

Reproduzierbarkeit

Die Kompilierzeit-Optionen (weiter unten beschrieben) können dazu verwandt werden, die Reproduzierbarkeit zu verbessern oder zusätzliche Warnungsmeldungen während der Übersetzung auszugeben. Sie werden für Architekturen, die diese unterstützen, standardmäßig aktiviert; die Ausnahmen sind unten angegeben.

timeless

Diese (standardmäßig aktivierte) Einstellung fügt -Wdate-time zu CPPFLAGS hinzu. Dies führt zu Warnungen, wenn die Makros __TIME__, __DATE__ und __TIMESTAMP__ verwandt werden.

fixdebugpath

Diese Einstellung (standardmäßig aktiviert) fügt -fdebug-prefix-map=BUILDPATH=. zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS hinzu, wobei BUILDPATH auf das oberste Verzeichnis des bauenden Pakets gesetzt wird. Dies führt dazu, dass der Baupfad aus allen erstellten Debug-Symbolen entfernt wird.

Konfigurationsdateien

/etc/dpkg/buildflags.conf

Systemweite Konfigurationsdatei

$XDG_CONFIG_HOME/dpkg/buildflags.conf oder

$HOME/.config/dpkg/buildflags.conf

Benutzer-Konfigurationsdatei

Paketierungsunterstützung

/usr/share/dpkg/buildflags.mk

Makefile-Schnipsel, das alle von dpkg-buildflags unterstützten Schalter in Variablen laden (und optional exportieren) wird. (seit Dpkg 1.16.1)

Verwendung in debian/rules

Sie sollten dpkg-buildflags aufrufen oder buildflags.mk in die Datei debian/rules einbinden, um die benötigten Bauschalter, die an das Bausystem weitergegeben werden sollen, abzufragen. Beachten Sie, dass ältere Versionen von dpkg-buildpackage (vor Dpkg 1.16.1) diese Variablen automatisch exportierten. Allerdings sollten Sie sich nicht darauf verlassen, da dies den manuellen Aufruf von debian/rules nicht korrekt ermöglicht.

Für Pakete mit Autoconf-artigen Bausystemen können Sie die relevanten Optionen direkt wie oben gezeigt an Configure oder make(1) übergeben.

Für andere Bausysteme oder wenn Sie feingranularere Steuerung benötigen (welcher Schalter wo weitergegeben wird), können Sie --get verwenden. Oder Sie können stattdessen buildflags.mk einbinden, das sich um den Aufruf von dpkg-buildflags kümmert und die Bauschalter in Make-Variablen speichert.

Falls Sie alle Bauschalter in die Umgebung exportieren möchten (wo sie dann vom Baussystem eingelesen werden können):

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk

Für zusätzliche Steuerung was exportiert wird, können Sie die Variablen manuell exportieren (da keine standardmäßig exportiert werden):

include /usr/share/dpkg/buildflags.mk
export CPPFLAGS CFLAGS LDFLAGS

Und natürlich können Sie die Schalter manuell an Befehle weitergeben:

include /usr/share/dpkg/buildflags.mk
build-arch:
	$(CC) -o hello hello.c $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)