[Dnsmasq-discuss] Partial denial of service with dnsmasq on resource constrained systems

marcus marcus at jaeger-company.de
Thu Apr 1 08:00:25 UTC 2021


Fuck youVon meinem/meiner Galaxy gesendet
-------- Ursprüngliche Nachricht --------Von: Dominik <dl6er at dl6er.de> Datum: 01.04.21  09:52  (GMT+01:00) An: Tony Ambardar <tony.ambardar at gmail.com>, dnsmasq-discuss at lists.thekelleys.org.uk Betreff: Re: [Dnsmasq-discuss] Partial denial of service with dnsmasq on
  resource constrained systems Hey Tony,On Wed, 2021-03-31 at 19:43 -0700, Tony Ambardar wrote:> You're right that text segments are fairly small and shared; memory usage> was dominated by storage for blocklists read from file. This makes the> problem more general than just tiny systems, since people tend to size> their blocklists proportional to system memory size.I wounldn't say this. Users try to squeeze too-large files also when theydo not have enough memory for them...On Wed, 2021-03-31 at 19:43 -0700, Tony Ambardar wrote:> You're also right that actual memory footprint increases only minimally> with each fork() thanks to copy-on-write; I'm certain these OOM systems> aren't really exhausting memory. But I do think there's confusion around> memory usage optimizations like COW vs. memory accounting used for OOM.OOM is just severely broken IMO. As a concept. Linux should likely notallow overcommitment at all, there is just no way at all for software toaccount for memory not being available it successfully allocated some timeago.On Wed, 2021-03-31 at 19:43 -0700, Tony Ambardar wrote:> I recall looking at dnsmasq process statistics on OOM invocation, and> noticed their VM set sizes were usually close to total system memory,> i.e.> COW wasn't relevant. And from a dnsmasq proc memory map, the large> segment> storing the blocklist was marked read-write. I suspect that despite COW,> since that memory is *potentially* writable it's being accounted for at> fork() time.The fork technically needs to allocate as much memory as the program iscurrently using but /proc/[pid]/maps won't tell you if the memory is copy-on-write or not. It is for sure read-write as, otherwise, when the forkwould write to it, it would be sent SIGSEGV. Instead, when trying to writeto a copy-on-write page, you will trigger a page-fault, the page will beduplicated and you can continue happily as if nothing would have happened.Also the "p" (private) doesn't help much here because it is justdistinguishing from "s" (shared) at this point.It *should* be possible to extract the relevant information from/proc/[pid]/pagemap and then check the details of the page(s) in/proc/kpageflags for KPF_SWAPBACKED (page is backed by swap/RAM). This isthe only way I'm aware of to check if this is a copy-on-write page existingin multiple places.If you know a simpler way to do this, I'd be happy to learn.On Wed, 2021-03-31 at 19:43 -0700, Tony Ambardar wrote:> A possible fix I'd suggest is to update dnsmasq's memory handling. IIRC,> we use the same cache structure and memory allocation for both DNS cache> and storing static server lists read from file. Perhaps use a separate,> page-aligned memory pool to store these lists, then after initialization> (and before forking) use mprotect() to set the region as read-only.> > Assuming it works, this would have the advantage of being a no-knobs> solution vs. setting kludgey process or connection limits.I like the idea of splitting the cache in two parts. Say a static and adynamic cache. Using mprotect() shouldn't even be necessary but helps toensure we're not writing to the static part of the cache anywhere in thecode.KSM (kernel samepage merging) comes to my mind as well, but this seems tobe the wrong tool for the job. Figured I should mention it nonetheless.On Wed, 2021-03-31 at 19:43 -0700, Tony Ambardar wrote:> One other thing I saw while testing with large blocklists was a> noticeable> latency increase, likely related to lookup times. I recall some> discussion> on the ML where you mentioned work on a hash/tree solution was in> progress. Were those changes completed?Yes, dnsmasq uses hash buckets to minimize the amount of memory it has toloop over when trying to find a name.Best,Dominik_______________________________________________Dnsmasq-discuss mailing listDnsmasq-discuss at lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210401/0bacc98c/attachment.htm>


More information about the Dnsmasq-discuss mailing list