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: Wed, 23 Sep 2015 23:06:09 -0400 From: Tejun Heo <tj@...nel.org> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: David Miller <davem@...emloft.net>, cwang@...pensource.com, tom@...bertland.com, kafai@...com, kernel-team@...com, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, torvalds@...ux-foundation.org, jiri@...nulli.us, nicolas.dichtel@...nd.com, tgraf@...g.ch, sfeldma@...il.com Subject: Re: [PATCH v2] netlink: Replace rhash_portid with bound Hello, On Thu, Sep 24, 2015 at 10:54:36AM +0800, Herbert Xu wrote: > What I am concerned about is the next guy who comes along and > does a rewrite like the one that introduced the netlink_bind > bug. That person needs to fully understand what each primitive > is protecting against. > > Using primitives where they're not needed can lead to misunderstandings > which may end up causing bugs. I think this is where we're not agreeing. My point is that better understanding and lower likelihood of bug doesn't equate specializing each usage site. That's a lot more likely to lead to unnecessary cognition overhead and naturally errors. There's no reason to require such error-prone and specific understanding of each usage site when we can have agreed-upon abstractions which yield invariants which are a lot easier for people to wrap their heads around. This isn't an isolated one-off barrier hack. This is a well-established pattern and sure there are cases we wanna deconstruct that and make exceptions but that needs to be justifiable. The overhead gotta buy us something. Here it just doesn't. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists