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, 16 Nov 2016 10:24:14 +0100 From: Greg KH <gregkh@...uxfoundation.org> To: Ingo Molnar <mingo@...nel.org> Cc: Kees Cook <keescook@...omium.org>, Peter Zijlstra <peterz@...radead.org>, Will Deacon <will.deacon@....com>, "Reshetova, Elena" <elena.reshetova@...el.com>, Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, David Windsor <dave@...gbits.org>, Linus Torvalds <torvalds@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t On Wed, Nov 16, 2016 at 10:07:37AM +0100, Ingo Molnar wrote: > > * Greg KH <gregkh@...uxfoundation.org> wrote: > > > On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote: > > > So what I'd love to see is to have a kernel option that re-introduces some > > > historic root (and other) holes that can be exploited deterministically - > > > obviously default disabled. > > > > Ick, I don't want to have to support nasty #ifdefs for > > "CONFIG_TOTALLY_INSECURE" type options in code logic for the next 20+ > > years, do you? > > I'd write it in C, not CPP, so it would be an 'if', but yeah, it would be extra > code otherwise. > > So I'd restrict this strictly to cases: > > - Where the maintainer absolutely agrees to carry it. > > - Where it's still easy to do technically - for example a single unobtrusive > 'if' condition or so, in cases where the current upstream code still has a > similar structure conductive to the re-introducion of the bug. Such testcases > can be dropped the moment they interfere with active development. > > - Plus an additional approach could be that some of the typical holes can be > reproduced in completely separate code that is not seen by anyone who doesn't > want to see it. Ok, but in looking at a number of "security" fixes over the past year or so, I don't think that many of them would really work well for this. Just look at all of the "don't reference a NULL pointer" bugs for an example of that. > I doubt many bugs have 20 years life times in face of frequent code reorganization > - and if code is static for 20 years then there won't be much extra maintenance > overhead, right? Hah, you obviously are not in charge of maintaining the tty layer :) Anyway, if you want to try this for the next type of security "issue" in your area of the kernel, be my guest, but I think it's going to be a lot harder than you think. thanks, greg k-h
Powered by blists - more mailing lists