lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Apr 2009 10:59:13 -0700 From: David VomLehn <dvomlehn@...co.com> To: David Miller <davem@...emloft.net> Cc: netdev@...r.kernel.org Subject: Re: [Patch 1/1][RFC] NETDEV: Find network bugs by validating the sk_buff state On Thu, Apr 30, 2009 at 09:46:14AM -0700, David Miller wrote: > From: David VomLehn <dvomlehn@...co.com> > Date: Thu, 30 Apr 2009 09:32:00 -0700 > > > I think the size is very doable. Only two bits are needed to encode > > the state so the ability to check the state isn't an issue. The > > other piece, though, is recording enough information to be able to > > pinpoint the problem. > > It's not my job to design this thing for you, but I guess that's what > I have to do to get you to think out of the box a little bit :-/ Uh, perhaps you missed the rest of the email, where I said I'm thinking of a couple of approaches. The purpose of the email was to let you know briefly that I am looking at approaches that will meet your 16-bit space constraint. > Maintain a table, which is only recorded into when the debugging > feature is enable (via sysctl or whatever) which remembers this stuff. > > That way nobody eats the space or time overhead unless the debugging > feature is enabled. Your description is general enough that I may misunderstand your idea, but it sounds like, if debugging was on, you'd be recording every call to alloc_skb and kfree_skb in your table. This would use a lot of memory. You can't simply have a circular list, because an sk_buff might be allocated for a very long time before being used and you would overwrite its entry. This would reduce the reliability of the information, which is the last thing you want in a debugging tool. So, I'm considering approaches without this drawback. > Wow, I had to use every brain cell I have to come up with that one! David VomLehn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists