UNIXwork

Extended Attributes Teil 8: macOS Syscalls

10. December 2017

Für den Zugriff auf Extended Attributes hat macOS die Syscalls listxattr, getxattr, setxattr und removexattr. Sie heißen genauso wie die Linux-Syscalls und funktionieren auch fast genauso, nur haben sie ein paar Parameter für Options mehr. Die Syscalls finden sich im Header sys/xattr.h.

Um den Inhalt eines Attributs zu erhalten, benutzen wir den Syscall getxattr:

ssize_t
getxattr(const char *path, const char *name, void *value, size_t size,
        u_int32_t position,
        int options);

Dabei gibt man den Dateipfad, den Namen des Attributs, einen Pointer auf einen Buffer sowie dessen Größe an. Wie im vorherigen Artikel erwähnt, haben macOS Extended Attributes keinen Namespace, daher ist name ein frei wählbarer Name. Mit value und size gibt man einen vorher allozierten Puffer und seine Größe an. Falls value NULL ist, wird von der Funktion nur die Länge des Inhalts zurück gegeben. Der Parameter position funktioniert nicht mit allen Typen von Attributen und sollte daher 0 sein. Der Parameter options kann abgesehn von 0 noch XATTR_NOFOLLOW oder XATTR_SHOWCOMPRESSION sein.

char *buf = malloc(1024);
ssize_t attrlen = ("file.txt", "myattribute", buf, 1024, 0, 0);
if(attrlen > 0) {
    printf("myattribute: %.*s\n", (int)attrlen, buf);
}

Attribute hinzufügen oder verändern geht mit setxattr.

int setxattr(const char *path, const char *name, void *value, size_t size,
        u_int32_t position,
        int options);

position sollte auch hier wieder 0 sein. Bei den options gibt es wieder XATTR_NOFOLLOW und die interessanten Options XATTR_CREATE, um zu erzwingen, dass das Attribut nur gesetzt wird, falls es noch nicht existiert, oder XATTR_REPLACE, um nur den Inhalt eines bereits existierenden Attributs zu ändern.

char *value = "Hello World!";
setxattr("file.txt", "myattribute", value, strlen(value), 0, 0);

Alle existierenden Attribute auflisten geht mit listxattr.

ssize_t listxattr(const char *path, char *namebuf, size_t size, int options);

Dies schreibt in den vorher allozierten Buffer die Namen aller Attribute, getrennt durch ein 0-Byte. Hier findet sich ein Beispielprogramm, welches alle Attribute einer Datei auflistet.

Autor: Olaf | 0 Kommentare | Tags: macos, xattr, c

WTF C Teil 2

17. September 2017

Nach Teil 1 hier die Fortsetzung:

#include <stdio.h>
int main(int argc, const char* argv[printf("Hello, World!\n")]) {}

Gefunden hab ich das Beispiel hier.

Autor: Olaf | 0 Kommentare | Tags: c, wtf

Linkdump

4. April 2017
Autor: Olaf | 0 Kommentare | Tags: links, c, curl, rust

File Descriptor zwischen Prozessen austauschen

5. March 2017

Es ist möglich, dass mehrere Prozesse Zugriff auf die gleichen File-Deskriptoren haben. Beispielsweise werden bei einem Fork alle File-Deskriptoren kopiert. Der Kind-Prozess kann dann auf die selben Dateien oder Sockets zugreifen.

Man kann auch nach einem Fork oder mit nicht-verwandten Prozessen File-Deskriptoren austauschen. Dies geht über Unix Domain Sockets mit den Funktionen sendmsg und recvmsg.

ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);

Die Nachricht vom Typ struct msghdr hat so einige Felder, die man erstmal ausfüllen muss.

struct msghdr {
    void         *msg_name;       /* optional address */
    socklen_t     msg_namelen;    /* size of address */
    struct iovec *msg_iov;        /* scatter/gather array */
    size_t        msg_iovlen;     /* # elements in msg_iov */
    void         *msg_control;    /* ancillary data, see below */
    size_t        msg_controllen; /* ancillary data buffer len */
    int           msg_flags;      /* flags on received message */
 };

Das Feld msg_name wird hier nicht benötigt, daher setzen wir msg_name und msg_namelen auf 0.

struct msghdr msg;
msg.msg_name = NULL;
msg.msg_namelen = 0;

Die eigentlichen Daten überträgt man mit dem Feld msg_iov, ein Array an Buffern, wie man es von writev kennt. Man erstellt ein Array mit struct iovec Elementen und gibt jeweils einen Pointer auf die Daten und die Länge an. Es reicht natürlich, nur einen Buffer anzugeben.

struct iovec iov[1] ;
iov[0].iov_base = (void*)buf;
iov[0].iov_len = len;

msg.msg_iov = iov;
msg.msg_iovlen = 1;

Jetzt wollen wir noch einen Filedescriptor übertragen. Für solche (und andere) Zwecke gibt es das Feld msg_control für folgende struct:

struct cmsghdr {
    size_t cmsg_len;    /* Data byte count, including header
                           (type is socklen_t in POSIX) */
    int    cmsg_level;  /* Originating protocol */
    int    cmsg_type;   /* Protocol-specific type */
    /* followed by
       unsigned char cmsg_data[]; */
};

Nach den Feldern der struct müssen also noch zusätzliche Daten im Speicher liegen. Für den Fall, dass man Filedeskriptoren übertragen möchte, müssen ein oder mehrere Integer folgen. Es empfiehlt sich zunächst einen statischen Buffer mit der entsprechenden Größe anzulegen. Hierfür gibt es das Makro CMSG_SPACE, was die Größe des Buffers liefert.

char cmsg_buf[CMSG_SPACE(sizeof(int))];

Anschließend setzen wir die Felder der struct.

struct cmsghdr *cmsg = (struct cmsghdr*)cmsg_buf;
cmsg->cmsg_len = CMSG_LEN(sizeof(int));
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS; // indicates fd payload data

Jetzt fehlt nur noch der Filedescriptor. Dieser muss, wie schon erwähnt, hinter der struct liegen. Mit dem Makro CMSG_DATA erhält man einen Pointer auf die Payload-Data.

int *data = (int*)CMSG_DATA(cmsg);
*data = fd;

Jetzt setzen wir nur noch msg_control und msg_controllen, sowie msg_flags. Danach kann sendmsg aufgerufen werden.

msg.msg_control = cmsg;
msg.msg_controllen = CMSG_LEN(sizeof(int));

msg.msg_flags = 0;

sendmsg(sock, &msg, 0);

Um einen Filedescriptor zu empfangen nutzt man recvmsg, was in der Benutzung ähnlich ist. Dort kommt die selbe struct für die Message zum Einsatz und man muss die Felder auch genauso setzen.

Ich hab ein kleines Beispielprogramm geschrieben, welches nach einem Fork eine Datei im Elternprozess öffnet und anschließend den Filedescriptor dieser Datei an den Kindprozess sendet. Das Kind empfängt dann den Filedescriptor und schreibt etwas in diese Datei.

Autor: Olaf | 0 Kommentare | Tags: unix, c, socket, ipc

Executable Memory und Intel XED

24. December 2016

Ich hab mich schon öfter gefragt, was man alles tun muss, um einen JIT-Compiler zu schreiben. Oder anders gefragt, wie kann man zur Laufzeit Maschinencode generieren und ausführen.

Zunächst einmal benötigt man Speicher, der es überhaupt erlaubt, dass davon Code ausgeführt werden kann. Wenn man mit malloc Speicher alloziert, ist dieser nicht ausführbar. Intern verwendet malloc mmap und das kann auch einfach direkt genutzt werden. Dabei kann man direkt die Zugriffsrechte für den Speicher festlegen. Man könnte sie allerdings auch im nachhinein mit mprotect ändern. Mit mmap werden auch Dateien in den Speicher gemapped, durch das Flag MAP_ANONYMOUS liefert der Kernel aber ganz ohne Datei den gewünschten Speicher.

void *execmem = mmap(NULL, len, PROT_EXEC | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);

Jetzt haben wir ausführbaren Speicher. Wenn dort Instructions reingeladen werden, können diese ausgeführt werden. Mein erster Versuch war einfach mit memcpy von einem Function-Pointer dort ein paar Bytes rein zu kopieren. Das hat zwar funktioniert, auch wenn ich nicht wusste wie viele Bytes die Funktion eigentlich groß ist und ich einfach eine größere Menge kopiert habe, aber das wäre für diesen ohnehin schon etwas hackigen Blogartikel etwas zu unsauber.

Glücklicherweise hat Intel kürzlich eine Bibliothek für das decoden und encoden von x86-Maschinencode veröffentlicht. Damit ist es mir gelungen nur die Instructions der Funktion zu kopieren.

Um den Maschinencode zu decoden braucht man erstmal einen Pointer auf den Code, in meinem Fall einen Funktions-Pointer.

const xed_uint8_t *inst = (const xed_uint8_t*)func;

Einen Befehl decoden macht folgender Code:

xed_decoded_inst_t dec;
xed_error_enum_t error;

// init xed_decoded_inst_t struct
memset(&dec, '\0', sizeof(xed_decoded_inst_t));
xed_decoded_inst_set_mode(&dec, XED_MACHINE_MODE_LONG_64, XED_ADDRESS_WIDTH_64b);

// decode instruction
error = xed_decode(&dec, inst, 15);

Dies liest 15 Bytes (die Maximalgröße einer Instruction) und dekodiert die Instruction. Wie groß diese dann ist, kann mit xed_decoded_inst_get_length abgefragt werden. Mit der Länge kann man dann zur nächsten Instruction springen.

Man kann diese auch als Assembler-String formatieren:

// print instruction
xed_format_context(XED_SYNTAX_ATT, &dec, buffer, 1024, 0, 0, 0);
printf("%s\n", buffer);

Hier ist das fertige Beispielprogramm. Kompiliere ich das ohne Optimierung und führe es aus ist die Ausgabe:

$ ./x86dec 
copy function code:

pushq  %rbp
mov %rsp, %rbp
movl  %edi, -0x4(%rbp)
movl  %esi, -0x8(%rbp)
movl  -0x8(%rbp), %eax
movl  -0x4(%rbp), %edx
add %edx, %eax
popq  %rbp
retq  

execute new code:

f(10, 50) = 60

Das ganze erfüllt jetzt natürlich keinen Zweck. Spannend wird es erst, wenn man eigenen Code generiert und den dann ausführt.

Was man noch erwähnen sollte ist, dass CPUs separate Data- und Instruction-Caches haben. Glücklicherweise muss man sich bei x86-CPUs keine Sorgen darüber machen, da dort erkannt wird, wenn Speicher modifiziert wird, der gerade auch im Instruction-Cache ist. Hingegen bei RISC-Architekturen, z.B. ARM, muss meistens der Instruction-Cache manuell aktualisiert werden.

Siehe auch: Self-Modifying Code and the Cache on Intel x86

Autor: Olaf | 0 Kommentare | Tags: c, x86, asm, jit
Zurück Weiter