Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

lib: implement subset of getdns API #5

Closed
4 tasks
vavrusa opened this issue Jun 4, 2015 · 1 comment
Closed
4 tasks

lib: implement subset of getdns API #5

vavrusa opened this issue Jun 4, 2015 · 1 comment
Labels
help wanted library question

Comments

@vavrusa
Copy link
Contributor

vavrusa commented Jun 4, 2015

Problem

I'd like the library to be reuseable by clients. getdns is a way to do that.

Expected outcome

  • Download the latest header
  • Implement simple query resolution
  • Implement basic options (TCP, EDNS...)
  • Implement unit tests (some possibly exist in other implementations!)
@pspacek
Copy link
Contributor

pspacek commented Sep 4, 2017

Closing things which rot here for ages now. Feel free to re-open the issue on Gitlab: https://gitlab.labs.nic.cz/knot/knot-resolver/

@pspacek pspacek closed this as completed Sep 4, 2017
CZNIC-GitLab pushed a commit that referenced this issue Sep 7, 2018
@vavrusa
daemon/worker: this fixes connect bug, and error handling from TLS wr…
efd14b4 
…ites

Previously, when the chosen protocol for the next message was SOCK_STREAM,
the TLS upgrade checked next selected address instead of retry address.

The error handling loop for uncorking TLS data was wrong, as the
underlying push function is asynchronous and there's no relationship
between completed DNS packet writes and number of TLS message writes.
In case of the asynchronous function, the buffered data must be valid
until the write is complete, currently this is not guaranteed and
loading the resolver with pipelined requests results in memory errors:

```
$ getdns_query @127.0.0.1#853 -s -a -s -l L -B -F queries -q
...
==47111==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290040a1253 at pc 0x00010da960d3 bp 0x7ffee2628b30 sp 0x7ffee26282e0
READ of size 499 at 0x6290040a1253 thread T0
    #0 0x10da960d2 in wrap_write (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x1f0d2)
    #1 0x10d855971 in uv__write (libuv.1.dylib:x86_64+0xf971)
    #2 0x10d85422e in uv__stream_io (libuv.1.dylib:x86_64+0xe22e)
    #3 0x10d85b35a in uv__io_poll (libuv.1.dylib:x86_64+0x1535a)
    #4 0x10d84c644 in uv_run (libuv.1.dylib:x86_64+0x6644)
    #5 0x10d602ddf in main main.c:422
    #6 0x7fff6a28a014 in start (libdyld.dylib:x86_64+0x1014)

0x6290040a1253 is located 83 bytes inside of 16895-byte region [0x6290040a1200,0x6290040a53ff)
freed by thread T0 here:
    #0 0x10dacdfdd in wrap_free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x56fdd)
    #1 0x10d913c2e in _mbuffer_head_remove_bytes (libgnutls.30.dylib:x86_64+0xbc2e)
    #2 0x10d915080 in _gnutls_io_write_flush (libgnutls.30.dylib:x86_64+0xd080)
    #3 0x10d90ca18 in _gnutls_send_tlen_int (libgnutls.30.dylib:x86_64+0x4a18)
    #4 0x10d90edde in gnutls_record_send2 (libgnutls.30.dylib:x86_64+0x6dde)
    #5 0x10d90f085 in gnutls_record_uncork (libgnutls.30.dylib:x86_64+0x7085)
    #6 0x10d5f6569 in tls_push tls.c:238
    #7 0x10d5e5b2a in qr_task_send worker.c:1002
    #8 0x10d5e2ea6 in qr_task_finalize worker.c:1562
    #9 0x10d5dab99 in qr_task_step worker.c
    #10 0x10d5e12fe in worker_process_tcp worker.c:2410
```

The current implementation adds opportunistic uv_try_write which
either writes the requested data, or returns UV_EAGAIN or an error,
which then falls back to slower asynchronous write that copies the buffered data.

The function signature is changed from simple write to vectorized write.

This also enables TLS False Start to save 1RTT when possible.
CZNIC-GitLab pushed a commit that referenced this issue Sep 7, 2018
@vavrusa
daemon/worker: this fixes connect bug, and error handling from TLS wr…
16d699e 
…ites

Previously, when the chosen protocol for the next message was SOCK_STREAM,
the TLS upgrade checked next selected address instead of retry address.

The error handling loop for uncorking TLS data was wrong, as the
underlying push function is asynchronous and there's no relationship
between completed DNS packet writes and number of TLS message writes.
In case of the asynchronous function, the buffered data must be valid
until the write is complete, currently this is not guaranteed and
loading the resolver with pipelined requests results in memory errors:

```
$ getdns_query @127.0.0.1#853 -s -a -s -l L -B -F queries -q
...
==47111==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290040a1253 at pc 0x00010da960d3 bp 0x7ffee2628b30 sp 0x7ffee26282e0
READ of size 499 at 0x6290040a1253 thread T0
    #0 0x10da960d2 in wrap_write (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x1f0d2)
    #1 0x10d855971 in uv__write (libuv.1.dylib:x86_64+0xf971)
    #2 0x10d85422e in uv__stream_io (libuv.1.dylib:x86_64+0xe22e)
    #3 0x10d85b35a in uv__io_poll (libuv.1.dylib:x86_64+0x1535a)
    #4 0x10d84c644 in uv_run (libuv.1.dylib:x86_64+0x6644)
    #5 0x10d602ddf in main main.c:422
    #6 0x7fff6a28a014 in start (libdyld.dylib:x86_64+0x1014)

0x6290040a1253 is located 83 bytes inside of 16895-byte region [0x6290040a1200,0x6290040a53ff)
freed by thread T0 here:
    #0 0x10dacdfdd in wrap_free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x56fdd)
    #1 0x10d913c2e in _mbuffer_head_remove_bytes (libgnutls.30.dylib:x86_64+0xbc2e)
    #2 0x10d915080 in _gnutls_io_write_flush (libgnutls.30.dylib:x86_64+0xd080)
    #3 0x10d90ca18 in _gnutls_send_tlen_int (libgnutls.30.dylib:x86_64+0x4a18)
    #4 0x10d90edde in gnutls_record_send2 (libgnutls.30.dylib:x86_64+0x6dde)
    #5 0x10d90f085 in gnutls_record_uncork (libgnutls.30.dylib:x86_64+0x7085)
    #6 0x10d5f6569 in tls_push tls.c:238
    #7 0x10d5e5b2a in qr_task_send worker.c:1002
    #8 0x10d5e2ea6 in qr_task_finalize worker.c:1562
    #9 0x10d5dab99 in qr_task_step worker.c
    #10 0x10d5e12fe in worker_process_tcp worker.c:2410
```

The current implementation adds opportunistic uv_try_write which
either writes the requested data, or returns UV_EAGAIN or an error,
which then falls back to slower asynchronous write that copies the buffered data.

The function signature is changed from simple write to vectorized write.

This also enables TLS False Start to save 1RTT when possible.
CZNIC-GitLab pushed a commit that referenced this issue Sep 11, 2018
@vavrusa
daemon/worker: fixes error handling from TLS writes
4a3d747 
The error handling loop for uncorking TLS data was wrong, as the
underlying push function is asynchronous and there's no relationship
between completed DNS packet writes and number of TLS message writes.
In case of the asynchronous function, the buffered data must be valid
until the write is complete, currently this is not guaranteed and
loading the resolver with pipelined requests results in memory errors:

```
$ getdns_query @127.0.0.1#853 -s -a -s -l L -B -F queries -q
...
==47111==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290040a1253 at pc 0x00010da960d3 bp 0x7ffee2628b30 sp 0x7ffee26282e0
READ of size 499 at 0x6290040a1253 thread T0
    #0 0x10da960d2 in wrap_write (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x1f0d2)
    #1 0x10d855971 in uv__write (libuv.1.dylib:x86_64+0xf971)
    #2 0x10d85422e in uv__stream_io (libuv.1.dylib:x86_64+0xe22e)
    #3 0x10d85b35a in uv__io_poll (libuv.1.dylib:x86_64+0x1535a)
    #4 0x10d84c644 in uv_run (libuv.1.dylib:x86_64+0x6644)
    #5 0x10d602ddf in main main.c:422
    #6 0x7fff6a28a014 in start (libdyld.dylib:x86_64+0x1014)

0x6290040a1253 is located 83 bytes inside of 16895-byte region [0x6290040a1200,0x6290040a53ff)
freed by thread T0 here:
    #0 0x10dacdfdd in wrap_free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x56fdd)
    #1 0x10d913c2e in _mbuffer_head_remove_bytes (libgnutls.30.dylib:x86_64+0xbc2e)
    #2 0x10d915080 in _gnutls_io_write_flush (libgnutls.30.dylib:x86_64+0xd080)
    #3 0x10d90ca18 in _gnutls_send_tlen_int (libgnutls.30.dylib:x86_64+0x4a18)
    #4 0x10d90edde in gnutls_record_send2 (libgnutls.30.dylib:x86_64+0x6dde)
    #5 0x10d90f085 in gnutls_record_uncork (libgnutls.30.dylib:x86_64+0x7085)
    #6 0x10d5f6569 in tls_push tls.c:238
    #7 0x10d5e5b2a in qr_task_send worker.c:1002
    #8 0x10d5e2ea6 in qr_task_finalize worker.c:1562
    #9 0x10d5dab99 in qr_task_step worker.c
    #10 0x10d5e12fe in worker_process_tcp worker.c:2410
```

The current implementation adds opportunistic uv_try_write which
either writes the requested data, or returns UV_EAGAIN or an error,
which then falls back to slower asynchronous write that copies the buffered data.

The function signature is changed from simple write to vectorized write.

This also enables TLS False Start to save 1RTT when possible.
CZNIC-GitLab pushed a commit that referenced this issue Sep 14, 2018
@vavrusa
daemon/worker: fixes error handling from TLS writes
f52231b 
The error handling loop for uncorking TLS data was wrong, as the
underlying push function is asynchronous and there's no relationship
between completed DNS packet writes and number of TLS message writes.
In case of the asynchronous function, the buffered data must be valid
until the write is complete, currently this is not guaranteed and
loading the resolver with pipelined requests results in memory errors:

```
$ getdns_query @127.0.0.1#853 -s -a -s -l L -B -F queries -q
...
==47111==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290040a1253 at pc 0x00010da960d3 bp 0x7ffee2628b30 sp 0x7ffee26282e0
READ of size 499 at 0x6290040a1253 thread T0
    #0 0x10da960d2 in wrap_write (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x1f0d2)
    #1 0x10d855971 in uv__write (libuv.1.dylib:x86_64+0xf971)
    #2 0x10d85422e in uv__stream_io (libuv.1.dylib:x86_64+0xe22e)
    #3 0x10d85b35a in uv__io_poll (libuv.1.dylib:x86_64+0x1535a)
    #4 0x10d84c644 in uv_run (libuv.1.dylib:x86_64+0x6644)
    #5 0x10d602ddf in main main.c:422
    #6 0x7fff6a28a014 in start (libdyld.dylib:x86_64+0x1014)

0x6290040a1253 is located 83 bytes inside of 16895-byte region [0x6290040a1200,0x6290040a53ff)
freed by thread T0 here:
    #0 0x10dacdfdd in wrap_free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x56fdd)
    #1 0x10d913c2e in _mbuffer_head_remove_bytes (libgnutls.30.dylib:x86_64+0xbc2e)
    #2 0x10d915080 in _gnutls_io_write_flush (libgnutls.30.dylib:x86_64+0xd080)
    #3 0x10d90ca18 in _gnutls_send_tlen_int (libgnutls.30.dylib:x86_64+0x4a18)
    #4 0x10d90edde in gnutls_record_send2 (libgnutls.30.dylib:x86_64+0x6dde)
    #5 0x10d90f085 in gnutls_record_uncork (libgnutls.30.dylib:x86_64+0x7085)
    #6 0x10d5f6569 in tls_push tls.c:238
    #7 0x10d5e5b2a in qr_task_send worker.c:1002
    #8 0x10d5e2ea6 in qr_task_finalize worker.c:1562
    #9 0x10d5dab99 in qr_task_step worker.c
    #10 0x10d5e12fe in worker_process_tcp worker.c:2410
```

The current implementation adds opportunistic uv_try_write which
either writes the requested data, or returns UV_EAGAIN or an error,
which then falls back to slower asynchronous write that copies the buffered data.

The function signature is changed from simple write to vectorized write.

This also enables TLS False Start to save 1RTT when possible.
CZNIC-GitLab pushed a commit that referenced this issue Mar 30, 2021
@nicki-krizek
daemon/http: fix memleak if http_write_pkt() fails
cc1016e 
This can happen for example when we want to send an answer, but the
http stream (or the connection?) is already closed.

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5ad2445459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55c0db3fc442 in http_write_pkt ../daemon/http.c:610
    #2 0x55c0db3fc882 in http_write ../daemon/http.c:651
    #3 0x55c0db3e9bb1 in qr_task_send ../daemon/worker.c:700
    #4 0x55c0db3ee86c in qr_task_finalize ../daemon/worker.c:1321
    #5 0x55c0db3f0123 in qr_task_step ../daemon/worker.c:1633
    #6 0x55c0db3f0982 in worker_submit ../daemon/worker.c:1755
    #7 0x55c0db3d992a in session_wirebuf_process ../daemon/session.c:759
    #8 0x55c0db3c5f01 in udp_recv ../daemon/io.c:89
    #9 0x7f5ad22b0e0e  (/usr/lib/libuv.so.1+0x20e0e)
CZNIC-GitLab pushed a commit that referenced this issue Mar 30, 2021
@nicki-krizek
daemon/http: fix memleak if http_write_pkt() fails
20c1133 
This can happen for example when we want to send an answer, but the
http stream (or the connection?) is already closed.

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5ad2445459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55c0db3fc442 in http_write_pkt ../daemon/http.c:610
    #2 0x55c0db3fc882 in http_write ../daemon/http.c:651
    #3 0x55c0db3e9bb1 in qr_task_send ../daemon/worker.c:700
    #4 0x55c0db3ee86c in qr_task_finalize ../daemon/worker.c:1321
    #5 0x55c0db3f0123 in qr_task_step ../daemon/worker.c:1633
    #6 0x55c0db3f0982 in worker_submit ../daemon/worker.c:1755
    #7 0x55c0db3d992a in session_wirebuf_process ../daemon/session.c:759
    #8 0x55c0db3c5f01 in udp_recv ../daemon/io.c:89
    #9 0x7f5ad22b0e0e  (/usr/lib/libuv.so.1+0x20e0e)
CZNIC-GitLab pushed a commit that referenced this issue Mar 30, 2021
@nicki-krizek
daemon/http: fix memleak if http_write_pkt() fails
a3a6ba3 
This can happen for example when we want to send an answer, but the
http stream (or the connection?) is already closed.

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5ad2445459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55c0db3fc442 in http_write_pkt ../daemon/http.c:610
    #2 0x55c0db3fc882 in http_write ../daemon/http.c:651
    #3 0x55c0db3e9bb1 in qr_task_send ../daemon/worker.c:700
    #4 0x55c0db3ee86c in qr_task_finalize ../daemon/worker.c:1321
    #5 0x55c0db3f0123 in qr_task_step ../daemon/worker.c:1633
    #6 0x55c0db3f0982 in worker_submit ../daemon/worker.c:1755
    #7 0x55c0db3d992a in session_wirebuf_process ../daemon/session.c:759
    #8 0x55c0db3c5f01 in udp_recv ../daemon/io.c:89
    #9 0x7f5ad22b0e0e  (/usr/lib/libuv.so.1+0x20e0e)
CZNIC-GitLab pushed a commit that referenced this issue Apr 1, 2021
@nicki-krizek
daemon/http: fix memleak if http_write_pkt() fails
f9757a2 
This can happen for example when we want to send an answer, but the
http stream (or the connection?) is already closed.

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5ad2445459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55c0db3fc442 in http_write_pkt ../daemon/http.c:610
    #2 0x55c0db3fc882 in http_write ../daemon/http.c:651
    #3 0x55c0db3e9bb1 in qr_task_send ../daemon/worker.c:700
    #4 0x55c0db3ee86c in qr_task_finalize ../daemon/worker.c:1321
    #5 0x55c0db3f0123 in qr_task_step ../daemon/worker.c:1633
    #6 0x55c0db3f0982 in worker_submit ../daemon/worker.c:1755
    #7 0x55c0db3d992a in session_wirebuf_process ../daemon/session.c:759
    #8 0x55c0db3c5f01 in udp_recv ../daemon/io.c:89
    #9 0x7f5ad22b0e0e  (/usr/lib/libuv.so.1+0x20e0e)
CZNIC-GitLab pushed a commit that referenced this issue Apr 16, 2021
@nicki-krizek
daemon/http: fix memleak if http_write_pkt() fails
7413317 
This can happen for example when we want to send an answer, but the
http stream (or the connection?) is already closed.

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5ad2445459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55c0db3fc442 in http_write_pkt ../daemon/http.c:610
    #2 0x55c0db3fc882 in http_write ../daemon/http.c:651
    #3 0x55c0db3e9bb1 in qr_task_send ../daemon/worker.c:700
    #4 0x55c0db3ee86c in qr_task_finalize ../daemon/worker.c:1321
    #5 0x55c0db3f0123 in qr_task_step ../daemon/worker.c:1633
    #6 0x55c0db3f0982 in worker_submit ../daemon/worker.c:1755
    #7 0x55c0db3d992a in session_wirebuf_process ../daemon/session.c:759
    #8 0x55c0db3c5f01 in udp_recv ../daemon/io.c:89
    #9 0x7f5ad22b0e0e  (/usr/lib/libuv.so.1+0x20e0e)
CZNIC-GitLab pushed a commit that referenced this issue Apr 16, 2021
@nicki-krizek @vcunat
daemon/http: fix memleak if http_write_pkt() fails
5209712 
This can happen for example when we want to send an answer, but the
http stream (or the connection?) is already closed.

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5ad2445459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55c0db3fc442 in http_write_pkt ../daemon/http.c:610
    #2 0x55c0db3fc882 in http_write ../daemon/http.c:651
    #3 0x55c0db3e9bb1 in qr_task_send ../daemon/worker.c:700
    #4 0x55c0db3ee86c in qr_task_finalize ../daemon/worker.c:1321
    #5 0x55c0db3f0123 in qr_task_step ../daemon/worker.c:1633
    #6 0x55c0db3f0982 in worker_submit ../daemon/worker.c:1755
    #7 0x55c0db3d992a in session_wirebuf_process ../daemon/session.c:759
    #8 0x55c0db3c5f01 in udp_recv ../daemon/io.c:89
    #9 0x7f5ad22b0e0e  (/usr/lib/libuv.so.1+0x20e0e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted library question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@vavrusa @pspacek
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy