From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 13:58:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76E7E16A4CE for ; Sat, 18 Sep 2004 13:58:15 +0000 (GMT) Received: from vsmtp14.tin.it (vsmtp14.tin.it [212.216.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32FC343D4C for ; Sat, 18 Sep 2004 13:58:15 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp14.tin.it (7.0.027) id 414B1A58000494F2 for freebsd-hackers@freebsd.org; Sat, 18 Sep 2004 15:58:15 +0200 Received: from [192.168.70.227] by ims3a.cp.tin.it with HTTP; Sat, 18 Sep 2004 15:58:15 +0200 Date: Sat, 18 Sep 2004 15:58:15 +0200 Message-ID: <4146316C0000A50A@ims3a.cp.tin.it> In-Reply-To: From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: Avoiding programmer invariant violations (was: Re: FreeBSD Kernel buffer overflow) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 13:58:15 -0000 >I'd suggest that we need to look at this in two ways: > >(1) There's a compile-time INVARIANT that needs to be maintained by > developers in adding new system calls. When building the kernel, it= > would be useful to have a compile-time assertion that causes a kerne= l > compile to fail if an invalid system call is defined. I.e., when > init_sysent.c is generated, it should build in __CTASSERT's that all= > argument counts are consistent with the requirements of the hardware= > architecture being built for. > >(2) There's a run-time INVARIANT issue for loadable modules built by thi= rd > parties who may not understand the limits on arguments on system cal= ls > for various architectures. This can be handled by a check in the > system call registration code, although since that's a non-critical > performance path, I suggest testing the invariant even if INVARIANTS= > isn't compiled in. In some ways, I'd rather handle this at > compile-time for the module, but I think the infrastructure for > hooking up system calls at compile-time for modules will make that > more difficult as compared to statically compiled system calls. > Completely agree >Note that the discussion so far has not addressed the compile-time issue= : > >which is a much better time to perform the tests -- it's something we ca= n >test when the kernel is compiled, so why not?. It also hasn't addressed= >non-i386 systems, such as amd64, which have similar or identical concern= s. I was thinking exactly to it while coding patch, but I'm not so experienc= ed with SPARC and/or other architectures to do that >With all due respect to the submitter, I think bugtraq was not the forum= >to post this issue to, as that forum is typically preferred for >exploitable vulnerabilities. A follow-up post to clarify that the initi= al >post described a possible avenue for programmer error when extending the= >kernel, rather than an immediately exploitable vulnerability, might redu= ce >confusion. You're completely right again. I posted on bugtraq beacause somebody else= could get a good idea to break code, something I not thought...(so I post= this email in hackers@ to let other undestand mine wasn't a exploitable bug report; nobody told "exploitable bug user -> root" or something like that). So what we I have to do? remove INVARIANTS dependency? thanks, rookie