Date: Tue, 12 Dec 2000 17:47:52 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Julian Elischer <julian@elischer.org>, Matt Dillon <dillon@earth.backplane.com>, kris@citusc.usc.edu, arch@FreeBSD.ORG Subject: Re: Safe string formatting in the kernel Message-ID: <49405.976639672@critter> In-Reply-To: Your message of "12 Dec 2000 17:33:01 %2B0100." <xzpitop4n2a.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <xzpitop4n2a.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
>Julian Elischer <julian@elischer.org> writes:
>> Poul-Henning Kamp wrote:
>> > There are several places where this new API would make the code
>> > simpler and less prone to overflowable errors. procfs and various
>> > netgraph nodes spring to mind immediately.
>> hmmm such as?
>
>In procfs: portions of procfs_{map,rlimit,status,vnops}.c
>In linprocfs: most of linprocfs_misc.c
>
>Poul-Henning also mentioned the mn(4) and musycc(4) drivers.
>
>Any part of the kernel that exports string sysctls will also benefit.
>Most of the magic that's necessary for writeable string sysctls can be
>eliminated by using sbufs in such a way that you'll be able to declare
>string sysctls just as easily as integer sysctls (currently, each
>writeable string sysctl requires ~20 lines of code).
>
>Empirical tests show that the sbuf API adds less than 2 kB of code to
>the kernel, and I believe (though I can't prove) that the amount of
>duplicated code and static buffers that can be replaced with judicious
>use of sbufs will more than outweigh that cost. In some cases (procfs
>and linprocfs at least, but probably others too) using sbufs also
>saves large amounts of syscall stack space.
The main thing, however, is providing a trivial string api so that
we can get less overflow bugs in the future.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49405.976639672>