DelphinusDNS Blog
(the latest about delphinusdnsd)||
|
Previous Page
March 24th, 2023
In this commit (github) I have changed the TCP
structure a little bit. I now fork an extra child that is an "accept engine".
All it does is select on the listening descriptors and accept(2)'s the socket.
Once it has this it passes the socket off to the main TCP engine that used to
do this task. I was able to lose the "inet" pledge in the main TCP engine and
this made it worth it. However now the setup is a bit weird because the main
tcp engine passes this descriptor to the parsing engine which now has comparable pledges. That's what's weird about it. But the UDP main process still needs
the parser process in order to do safe parsing, why not give the tcp process
it's own parser too right? It's just a bit more overhead but is acceptable to
me. On my test workstation the latency of a lookup was around 1 ms on tcp.
What's next? The acceptloop() will likely see adoption in the AXFR engine as
well so that it can lose it's inet pledge too. But I'm gonna take it easy for
the rest of the day. I did mostly programming today.
For some eye-candy this is what a box with delphinusdnsd looks like in a
process listing:
root@stern# ps ax|grep delphin
45039 ?? Spc 0:00.42 delphinusdnsd: cortex [] (delphinusdnsd)
21925 ?? Spc 0:00.64 delphinusdnsd -f /var/delphinusdnsd/etc/delphinusdns
54020 ?? Spc 0:00.02 delphinusdnsd: cortex [] (delphinusdnsd)
26945 ?? SpU 0:00.05 delphinusdnsd: primary [] (delphinusdnsd)
64451 ?? SpUc 0:00.02 delphinusdnsd: unix controlling socket [] (delphinus
40668 ?? Spc 0:00.03 delphinusdnsd: AXFR engine on port 10053 [] (delphin
81060 ?? SpUc 0:00.03 delphinusdnsd: Replicant engine [] (delphinusdnsd)
97802 ?? Spc 0:00.30 delphinusdnsd: FORWARD engine [] (delphinusdnsd)
53973 ?? Sp 0:00.13 delphinusdnsd: TCP engine 0 [] (delphinusdnsd)
78173 ?? Sp 0:00.03 delphinusdnsd: TCP parse engine 0 [] (delphinusdnsd)
60256 ?? Sp 0:00.04 delphinusdnsd: TCP accept engine 0 [] (delphinusdnsd
13609 ?? Sp 0:00.04 delphinusdnsd: udp parse engine 0 [] (delphinusdnsd)
13864 ?? Sp 0:00.04 delphinusdnsd: forward parse engine [] (delphinusdns
86423 p0 R+/1 0:00.01 grep delphin
Lots of processes...
0 comments
March 23rd, 2023
I likely found the culprit. It was wrongly added on March 19th.
Here is the
fix to this. Whew! Thanks to Otto for some great hints!
0 comments
March 22nd, 2023
After I wrote this the forwarding delphinusdnsd crashed again. I guess I'm
bug hunting when I find the time. This is weird! I'll get to the bottom of
it one day though.
0 comments
March 22nd, 2023
I've found a bug with my memory allocation code, it has been stalling efforts
to get some things encrypted in the shared memory. There is several factors
involved but I think unwind(8) plays a major role in this.
-
I recently turned
unwind on at home on my workstation and it unearthed another bug. I'm glad
it does this, delphinusdnsd gets better. Anyhow I'm theorizing that unwind
does a lot of lookups for the root zone for validation purposes ('.').
- In
the majority of crashes that I saw were in an area where rapid allocations and
frees happened, this was due to the code that I used for the encryption. I'm
wondering if I can save on the context allocations and frees in the future.
So I mailed Otto who gave me some helpful hints and having looked at his
malloc code I was able to piece together what could have happened. If another
network looks up for '.' it causes a 1 byte allocation to occur, the length is
saved in a struct and a NUL byte is put in that 1 byte. This is the represent
ation of the root zone. It's a hack because it really is 0 length. So then
I have a second allocation for the human readable representation of the root
zone which will be 2 bytes for the '.' and the NUL terminator (it's a string).
The problem I found in the function convert_name() which is supposed to
short circuit the root zone and return a length of 2. Unfortunately I had a
wrong check in this function that checked for a NUL byte on the 1st element
(starting at zeroth), which was a bug, it should check the zeroth element.
I was able to track down this commit
done in 2020
. So what is there to know? And how does this bug occur? I suspect
that build_question() built the root question name with one byte and one byte
length and then freed it. Whenever a free occurs Otto's malloc writes a magic
called deadfree's (0xdfdfdfdfdfdfdfdf) which account for 8 bytes over the freed
area. The actual freeing is delayed until next free actually which gives the
code a chance to detect 'write after free\'s'. Once the chunk is freed another
one byte allocation comes along and sets NUL byte, but the adjacent bytes are
still from the freeing so 0x00dfdfdfdfdfdfdf. At this point when the
convert_name() is called the bug is that the short circuit fails and the rest
falls through due to passing 0 to memcpy (which too is erroneous). The 2 byte
allocation will then be zero filled (2 NUL's) makeing the human representation
flawed. This would reflect on the logs most likely. There is a cascading
effect taking off for this NUL, NUL in fact turning into just a NUL in the
(so-called) engine process.
If this isn't the bug, then it's one of many. I also made sure I 8 byte
aligned the shared memory slot for struct parsequestion. So far looking at it
the code has held up longer than other times. I'll be backporting the fixes
for this into the 1.7.3 release. Good night!
0 comments
March 22nd, 2023
Today I finished the code to the new txt parsing, and backported it to the
STABLE_1_7 branch. This addresses the problems I identified on this blog
on December 25th, 2022 and explained it a little more on January 3rd.
I'm happy I found time to do this as this month I had lots of appointments
for non-coding related things. Please enjoy this change!
0 comments
March 08th, 2023
I made a mistake there was no buffer overflow. There was 5 variables to watch
and a buffer which was 0xffff + 3 bytes big. The one variable I did not watch
close enough was tcpnp->bytes_expected, which limits how much can be read and
is decreased. I'm sorry for the heartthrob, I won't backport the refactored
code just yet.
0 comments
March 8th, 2023
I have found a potential buffer overflow in the TCP and TLS code. I think the
TCP code was around for a number of years. Since June 2019 at least. The best
way to go about this is to upgrade to the master branch with git and recompile.
Then wait for a 1.7.2 patch release, the code hasn't changed much since 1.7.1
and thus this is OK.
0 comments
January 31st, 2023
The quest to give the source of a notify packet a bound IP had me going off
on a trail to fix it. However..., I have realised I need to rewrite this
code partially. It was first implemented in the predecessor of delphinusdnsd
under the wildcarddnsd name. This was in 2011 and before I moved into this
nice apartment. I don't really know what I was on (self admittance). So
I'm going to adjust the TODO file accordingly and plan out this code.
Important to me is, that this code is readable, and not jammed. As in that
you cannot really move it forwards or backwards and gain what you want from
it. This takes time out of my day unfortunately that I would otherwise use
to relax. Maybe a bit of work is good for me though.
0 comments
January 30th, 2023
The TODO's for this year will likely not be achieved. The usage of
delphinusdnsd will have to be watched by me and some parts will have to be
rewritten as they are just impossible to maintain. This means that this year
there will likely not be a dns update functionality. I'm not saying this in
spite but rather want to prevent a burn out of myself. I deserve a break and
if anyone wants to contribute the best way is to send me patches first before
we both consider adding you to the commit list.
Also there have been some breakthroughs with the got (game of trees) program
that I might make use of. This may mean that I'm possibly taking development
from github back to a got repo. However. Since we're on version 1.7.1 now
and the last release will be before 2.0.0 for me this may not happen. It's
something to consider though. Eventually I'll have to let go graciously.
0 comments
January 28th, 2023
I found another issue with delphinusdnsd as an AXFR primary. When on a host
with IP aliases it will sometimes pick the wrong IP (IPv6). I have a patch
but it does wrong things which I have to debug first before I commit it.
The TXT RR problem is also by now on the back burner, the emotional blockage
that I have hasn't fully healed and I lack the concentration to sit down and
do this right now. If anyone wants to step up and help that would be grand.
If not, it will take its natural time.
0 comments
Next Page
|
Search
RSS Feed
 Click here for RSS
On this day in
Other links
Have feedback?
By clicking on the header of an article you will be
served a cookie. If you do not agree to this do not
click on the header. Thanks!
Using a text-based webbrowser?
... such as lynx? Welcome back it's working again for the time being.
Older Blog Entries
May, 2023
April, 2023
March, 2023
January, 2023
December, 2022
November, 2022
October, 2022
September, 2022
August, 2022
July, 2022
June, 2022
May, 2022
April, 2022
March, 2022
February, 2022
January, 2022
December, 2021
November, 2021
March, 2021
February, 2021
January, 2021
December, 2020
November, 2020
October, 2020
September, 2020
August, 2020
July, 2020
June, 2020
May, 2020
April, 2020
March, 2020
February, 2020
January, 2020
December, 2019
November, 2019
October, 2019
September, 2019
Powered by BCHS
|