From owner-freebsd-arch Tue Jun 20 10:50: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by hub.freebsd.org (Postfix) with ESMTP id 5054D37C1CB for ; Tue, 20 Jun 2000 10:48:15 -0700 (PDT) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (exchange.maxwell.syr.edu [128.230.129.241]) by maxwell.syr.edu (8.9.3/8.9.1) with ESMTP id NAA05912 for ; Tue, 20 Jun 2000 13:48:18 -0400 (EDT) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 13:48:14 -0400 Message-ID: From: Christopher Sedore To: "'arch@freebsd.org'" Subject: RE: MORE: Re: kblob discussion. Date: Tue, 20 Jun 2000 13:48:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >* Christopher Sedore [000620 09:43] wrote: >> >> [...] >> >> >Last night I started thinking about making kblob more flexible, >> >here's the problem I came across: >> > >> >All the papers that have been given to me make sure that once a >> >0 copy buffer is shared across subsystems it is immutable until >> >the data it's loaned has gone back to no references except by >> >the user process. >> > >> >Not following the above system is _wrong_. >> >> I'm not sure I would put that level of emphasis on _wrong_. > It deserves >> that level of emphasis if it can cause kernel state (or other system) >> corruption (which should be reason for _wrong_, though I'd >call this a >> problem with implementation more than anything else). If the >> user/application can only screw up its own data/connections >(in the sense of >> undefined, possibly random data being sent/written), then >why not state that >> modifying the data causes undefined results (including TCP >checksum errors, >> whatever else) and let the programmer beware. > >Because it puts undue burden on the rest of the kernel to cope with >a user's access to internals. What happens if we are using some >sort of checksum offloading chipset or encryption/compression system >that can't stand the data being ripped out from under it. What's >the point of recalculating the checksum of a packet when we know >it shouldn't have changed? > >It's wrong. :) The only access is to data that the user passed in already, so harm should be limited to incorrect checksums. I guess I have to agree that ultimately it would be harder to make sure the kernel could deal with changes in this area than just to prevent them in the first place. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message