summaryrefslogtreecommitdiff
path: root/apf_run.c
diff options
context:
space:
mode:
authorBernie Innocenti <codewiz@google.com>2018-04-10 22:52:30 +0900
committerBernie Innocenti <codewiz@google.com>2018-04-20 17:40:36 +0900
commitd2cc2b74f161d88bc0622b03d48ef176fefee03a (patch)
tree5520a802631d8e7295dd370433b3261081d4bd18 /apf_run.c
parent5a1f7799656e73736b9a07ee564b9349c4a1b40f (diff)
downloadapf-d2cc2b74f161d88bc0622b03d48ef176fefee03a.tar.gz
After releasing APFv3, we realized that addressing memory from the top could be simplified by adjusting a few details: 1) The APF interpreter now receives a single unified buffer containing both the program bytecode and the data segment, unambiguously matching the memory layout seen by installApfPacketFilter() and readApfPacketFilter(). 2) Data address zero coincides with the beginning of the APF program, thus decoupling data addresses from the length of the program (which could change between invokations of installApfPacketFilter()). This simplifies the ApfGenerator by not requiring a data relocation step similar to jump relocation. 3) For convenience, the interpreter pre-fills one volatile memory slot with the total size of the APF buffer. The APF program can load this value into a register to efficiently write near the end of the data segment, thus allowing the program-data boundary to shift freely. 4) Negative addresses wrap around the end of the data buffer, such that address -1 coincides with the last byte of the buffer. 5) The immediate offet of LDDW and SDDW are now sign-extended, such that small negative offsets can be encoded as a 1-byte immediate. This, combined with the modular addressing at (4), can be used to address memory cells near the end of the data region with 2-byte opcodes. Overall, the above changes allow building a simple 32bit counter with a sequence more or less like this: 2 li R1, -4 ; R1 = -4 (last 32bit word of data) 1 lddw R0, [R1 + 0] ; R0 = old counter value 2 add R0, 42 ; Increment counter by some value 1 stdw R0, [R1 + 0] ; Write back the new value Total: 6 bytes. Note how the above bytecode is independent of the actual size of the program and data segments. To reduce bytecode size, the counter increment sequence can be moved to an "IncrementAndDrop" trampoline, taking only 2 bytes more than a direct jump to DROP: 2 li R1, -12 ; R0 = counter offset (third to last counter) 3 jmp CountAndDrop ; (could be 2 bytes if jumping nearby) ... CountAndDrop: 1 lddw R0, [R1+0] ; R0 = old counter value 2 add R0, 1 ; Increment counter 1 stdw R0, [R1+0] ; Write back updated value 3 jmp DROP ; cya! Adding a 1-byte INC instruction would make things a little nicer. Change-Id: Ia9b25e49e127a48d7344ddc60b17c93d6421ab7d Bug: 73804303 Test: runtest -x tests/net/java/android/net/apf/ApfTest.java (cherry picked from commit 17c1fbc9e98e380e508fa83d0f927bc742a5161b)
Diffstat (limited to 'apf_run.c')
-rw-r--r--apf_run.c18
1 files changed, 13 insertions, 5 deletions
diff --git a/apf_run.c b/apf_run.c
index 3d654cf..d485b71 100644
--- a/apf_run.c
+++ b/apf_run.c
@@ -74,14 +74,22 @@ int main(int argc, char* argv[]) {
uint8_t* data = NULL;
uint32_t data_len = argc > 3 ? parse_hex(argv[3], &data) : 0;
uint32_t filter_age = argc > 4 ? atoi(argv[4]) : 0;
- int ret = accept_packet(program, program_len, packet, packet_len,
- data, data_len, filter_age);
- printf("Packet %sed\n", ret ? "pass" : "dropp");
+
+ // Combine the program and data into the unified APF buffer.
if (data) {
+ program = realloc(program, program_len + data_len);
+ memcpy(program + program_len, data, data_len);
+ free(data);
+ }
+
+ uint32_t ram_len = program_len + data_len;
+ int ret = accept_packet(program, program_len, ram_len, packet, packet_len,
+ filter_age);
+ printf("Packet %sed\n", ret ? "pass" : "dropp");
+ if (data_len) {
printf("Data: ");
- print_hex(data, data_len);
+ print_hex(program + program_len, data_len);
printf("\n");
- free(data);
}
free(program);
free(packet);