re: CVS commit: src/share/man/man4
On Sat, May 09, 2009 at 07:51:41AM -0700, Paul Goyette wrote: > So really should simply document the option DRM_NO_AGP rather than > telling folks to include unnecessary drivers! Just because it compiles doesn't mean it works properly. For most drivers at least, you really need the AGP support for the GART. what about systems that don't have AGP? .mrg.
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Mon, May 11, 2009 at 12:11:03PM +1000, Daniel Carosone wrote: > On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote: > > On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote: > > > On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: > > > > > > > [...] since there's no way of changing a PGP passphrase > > > > short of generating a new key. > > > > > > Huh? Sure, you have a need to deal with keyring copies from before > > > the change, maybe with some more rm -P and its limtations, but > > > otherwise, I don't understand this. > > > > Sorry, I must be missing something then (perfectly possible, now I'm > > old and grey) - how do you change the passphrase on a PGP key? > > For gpg, the passwd sub-command under edit-key. For other > implementations, special sigils created by waving the magic > wand^Wpointer. > > If the corresponding feature is missing from this implementation, > that's a deficiency, but not a limitation of the format. Someone > might implement the feature, or you might combine tools since the > keyring format is standardised and (I hope) therefore the tools are > interoperable. Cool, thanks, that's exactly the information I was looking for. I'll look into providing that somehow (I've been of the opinion that we need one binary for key management, and one binary for signing/verification and encrypting/decrypting for a while now - it's the way that the old nbpg SoC project was going too), and that definitely gives me an incentive to do that kind of split. Thanks once again, Al
Re: CVS commit: src/sbin/fsck_ffs
In message: <20090511015855.gd16...@britannica.bec.de> Joerg Sonnenberger writes: : On Sun, May 10, 2009 at 07:51:41PM -0600, M. Warner Losh wrote: : > I've missed much of the discussion, can someone recap exactly what : > you'd like to see changed? That would be the starting point for any : > user-visisble changes to FreeBSD... : : There is currently a mixed naming convention when refering to FFS : filesystems (v1 and v2). Sometimes, it is FFS, FFS2, UFS, UFS2 etc. : The consensus in NetBSD was to consistently use FFS and FFSv2. : UFS2 is bad, as it changes the underlaying inode format, but still has : FFS on top. Right, I gleaned that from the discussion. What I didn't glean from the discussion is what, exactly, you were going to do about it and what, exactly, you'd like to harmonize with FreeBSD on. It may have been there, but I just missed it. Warner
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote: > On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote: > > On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: > > > > > [...] since there's no way of changing a PGP passphrase > > > short of generating a new key. > > > > Huh? Sure, you have a need to deal with keyring copies from before > > the change, maybe with some more rm -P and its limtations, but > > otherwise, I don't understand this. > > Sorry, I must be missing something then (perfectly possible, now I'm > old and grey) - how do you change the passphrase on a PGP key? For gpg, the passwd sub-command under edit-key. For other implementations, special sigils created by waving the magic wand^Wpointer. If the corresponding feature is missing from this implementation, that's a deficiency, but not a limitation of the format. Someone might implement the feature, or you might combine tools since the keyring format is standardised and (I hope) therefore the tools are interoperable. -- Dan. pgpab5DcKPMca.pgp Description: PGP signature
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote: > On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote: > > On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: > > > > > [...] since there's no way of changing a PGP passphrase > > > short of generating a new key. > > > > Huh? Sure, you have a need to deal with keyring copies from before > > the change, maybe with some more rm -P and its limtations, but > > otherwise, I don't understand this. > > Sorry, I must be missing something then (perfectly possible, now I'm > old and grey) - how do you change the passphrase on a PGP key? gpg --edit-key keyid passwd Joerg
Re: CVS commit: src/sbin/fsck_ffs
On Sun, May 10, 2009 at 07:51:41PM -0600, M. Warner Losh wrote: > I've missed much of the discussion, can someone recap exactly what > you'd like to see changed? That would be the starting point for any > user-visisble changes to FreeBSD... There is currently a mixed naming convention when refering to FFS filesystems (v1 and v2). Sometimes, it is FFS, FFS2, UFS, UFS2 etc. The consensus in NetBSD was to consistently use FFS and FFSv2. UFS2 is bad, as it changes the underlaying inode format, but still has FFS on top. Joerg
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote: > On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: > > > [...] since there's no way of changing a PGP passphrase > > short of generating a new key. > > Huh? Sure, you have a need to deal with keyring copies from before > the change, maybe with some more rm -P and its limtations, but > otherwise, I don't understand this. Sorry, I must be missing something then (perfectly possible, now I'm old and grey) - how do you change the passphrase on a PGP key? Thanks, Al
Re: CVS commit: src/sbin/fsck_ffs
In message: <20090510220227.gd16...@britannica.bec.de> Joerg Sonnenberger writes: : On Sun, May 10, 2009 at 04:31:34AM +, YAMAMOTO Takashi wrote: : > have you tried to convince freebsd guys to use your preferred name? : > being different creates another layer of confusion. : : We had a short discussion about this during BSDCan. Kirk didn't mind and : if it should be reasonable to get consistent. I think that this sort of decision can't be made by just Kirk since FreeBSD has deployed ufs2 for several releases now. I've missed much of the discussion, can someone recap exactly what you'd like to see changed? That would be the starting point for any user-visisble changes to FreeBSD... Warner
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: > [...] since there's no way of changing a PGP passphrase > short of generating a new key. Huh? Sure, you have a need to deal with keyring copies from before the change, maybe with some more rm -P and its limtations, but otherwise, I don't understand this. -- Dan. pgpNspqO3Rna0.pgp Description: PGP signature
Re: CVS commit: src/sbin/fsck_ffs
On Sun, May 10, 2009 at 04:31:34AM +, YAMAMOTO Takashi wrote: > have you tried to convince freebsd guys to use your preferred name? > being different creates another layer of confusion. We had a short discussion about this during BSDCan. Kirk didn't mind and if it should be reasonable to get consistent. Joerg
Re: CVS commit: src/sys/dist/ipf/netinet
Mihai Chelaru wrote: Module Name:src Committed By: kefren Date: Fri May 8 05:18:34 UTC 2009 Modified Files: src/sys/dist/ipf/netinet: ip_fil_netbsd.c Log Message: Don't call callout_stop() without callout_init() Fixes PR/41364 To generate a diff of this commit: cvs rdiff -u -r1.49 -r1.50 src/sys/dist/ipf/netinet/ip_fil_netbsd.c Will this be pulled up to NetBSD 5.0? Thanks, -e.
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
Simon Burge writes: > "Perry E. Metzger" wrote: > >> [ ... ] Encrypted swap should >> be the default -- either using cgd or by simply encrypting the blocks as >> they go in and out without using the cgd layer. > > You've benchmarked the effect of this, especially on older hardware? No, but others have, and it is generally negligible. Why is this the case? Well, think about it for a moment -- the time to encrypt a disk block is a tiny fraction of the time needed to write it to disk. It is true that on older machines there is less processor, but there is also even less disk bandwidth. The situation is a lot worse if you're thrashing, but of course the situation is always a lot worse if you're thrashing. In any case: there would clearly be a knob to this on and off, and it can even be left off by default, at least on older ports. The problem is this: it is a significant effort to set this up at all, so no one does it. If it was trivial to set up, even something listed in sysinst, it would be widely used, unlike the situation now where it is barely if ever done. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/sys/nfs
hi, > On Sun, May 10, 2009 at 05:18:26AM +, YAMAMOTO Takashi wrote: > > Module Name: src > > Committed By: yamt > > Date: Sun May 10 05:18:26 UTC 2009 > > > > Modified Files: > >src/sys/nfs: nfs_vnops.c > > > > Log Message: > > nfs_lookup: vn_lock the vnode returned by cache_lookup_raw > > before feeding it to VOP_GETATTR. it's necessary because the vnode might > > be being cleaned by getcleanvnode. > > > > it's an instance of more general races between vnode reclaim and > > unlocked VOPs. however, this one happens somewhat often because it can be > > triggered by getnewvnode rather than revoke. > > This seems a bit odd; cache_lookup_raw returns a reference to the > vnode, so the vnode shouldn't *be* getting reclaimed after that. > > Or so I'd think. (?) there is a race. see PR/41374. besides that, a vnode reference does not prevent revoke(2). YAMAMOTO Takashi > > -- > David A. Holland > dholl...@netbsd.org
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Sat, 9 May 2009 03:46:28 +0100 Alistair Crooks wrote: > On Fri, May 08, 2009 at 01:18:38PM -0400, Perry E. Metzger wrote: > > > > "Alistair G. Crooks" writes: > > > > > Module Name: src > > > Committed By: agc > > > Date: Fri May 8 06:06:39 UTC 2009 > > > > > > Modified Files: > > > src/crypto/external/bsd/netpgp/dist: TODO configure configure.ac > > > src/crypto/external/bsd/netpgp/dist/src/bin: netpgp.c > > > src/crypto/external/bsd/netpgp/dist/src/lib: config.h config.h.in > > > crypto.c misc.c netpgp.c openssl_crypto.c reader.c signature.c > > > signature.h version.h > > > > > > Log Message: > > [...] > > > + if setrlimit exists, set the core dump size to be 0 > > > (with thanks to mrg for the reference implementation) > > [...] > > > > What's the threat model this is protecting against? Presumably, if a > > user can execute the program, and the program can read his keys, the > > uesr can already read his own keys, so having a core dump doesn't give > > the user information he didn't already have. > > Heh, yeah, it's not really to do with keys, much more the passphrase, > which is dynamically allocated in a number of places in the library, > and I haven't finished auditing all of the places just yet. I've > added code to zero out that memory after use when I can - some more > are still needed. > > The threat that I'm protecting against here is that of information > disclosure coming from committing the passphrase to disk in a core > dump. Having to remember to rm -P the core dump file is a pain, you > don't get a second chance at it, and after that there is still the > problem of any spared sectors. I suspect you don't want a re-run of > the tls vs. agc wars from a month ago. Whilst most people will use > an encrypted block device of some description, others are prevented > from doing that for various reasons. I'm especially sensitive about > passphrases here, since there's no way of changing a PGP passphrase > short of generating a new key. > > I'd really recommend source-changes-full for reviewing the changes > that are made - the setrlimit(2) call is only made in the driver > program, not the library. > > Regards, > Alistair I recall reading a paper about storing sensitive data in shared memory blocks, I just can seem to find it. -- Adam Hoka
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
Simon Burge wrote: "Perry E. Metzger" wrote: [ ... ] Encrypted swap should be the default -- either using cgd or by simply encrypting the blocks as they go in and out without using the cgd layer. You've benchmarked the effect of this, especially on older hardware? Let's first have it as an option that is very easy to enable/disable, ie., /etc/rc.d/cgd_swap start. Once that's in current, I'm sure people with various hardware configurations will be happy to switch it on just for benchmarking and then back off. I doubt Perry alone, or anyone for that matter, can cover as much ground... -e.
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Sat, May 09, 2009 at 12:44:27PM -0400, Perry E. Metzger wrote: > By that token, it would be of use for NetBSD to port over the encrypted > swap features other OSes have (it should be essentially no performance > hit), Writing even an encrypted copy of a passphrase to disk is still a hazard compared to not writing it at all. Programs that deal with such things should lock themselves in memory. :-/ > and I think it would also be nice if NetBSD could zeroize or > randomize RAM on voluntary shutdowns. That seems like a good idea. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/nfs
On Sun, May 10, 2009 at 05:18:26AM +, YAMAMOTO Takashi wrote: > Module Name: src > Committed By:yamt > Date:Sun May 10 05:18:26 UTC 2009 > > Modified Files: > src/sys/nfs: nfs_vnops.c > > Log Message: > nfs_lookup: vn_lock the vnode returned by cache_lookup_raw > before feeding it to VOP_GETATTR. it's necessary because the vnode might > be being cleaned by getcleanvnode. > > it's an instance of more general races between vnode reclaim and > unlocked VOPs. however, this one happens somewhat often because it can be > triggered by getnewvnode rather than revoke. This seems a bit odd; cache_lookup_raw returns a reference to the vnode, so the vnode shouldn't *be* getting reclaimed after that. Or so I'd think. (?) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sbin/fsck_ffs
On Sun, May 10, 2009 at 04:31:34AM +, YAMAMOTO Takashi wrote: | have you tried to convince freebsd guys to use your preferred name? | being different creates another layer of confusion. As I explained in my original thread about this issue [1], it is the inconsistency in use of "ffs" versus "ufs" without own own software and documentation that is confusing to end users, not our difference in naming with other UNIX distributions. For that matter, FreeBSD is not a paragon of consistency here -- the tools have "ffs" in the name, and the manual page on FreeBSD describing the file system is ffs(7) (not ufs(7)) -- so using it It is not an issue of `confusing kernel hackers who know it as UFS' or confusing `confusing people who use both NetBSD and FreeBSD', it is an issue of confusing our end users. What we had before was confusing, especially when it led to people resulting in unbootable systems because the documentation was unclear. I have no objection to Izumi Tsutsui's recent suggestion of updating the documentation to indicate that UFS is another name for FFS in our system. E.g, "FFSv2 (UFS2)". [1] http://mail-index.netbsd.org/tech-userlevel/2009/03/31/msg002003.html pgpaSaAaKJL6D.pgp Description: PGP signature
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
"Perry E. Metzger" wrote: > [ ... ] Encrypted swap should > be the default -- either using cgd or by simply encrypting the blocks as > they go in and out without using the cgd layer. You've benchmarked the effect of this, especially on older hardware? Simon.
Re: CVS commit: src/sys/netinet6
On Sun, May 10, 2009 at 1:12 PM, YAMAMOTO Takashi
wrote:
>> That said, where we now return EPERM is where in the future we'll
>> return the error value returned by kauth(9), like many many other
>> places in the kernel. Other parts of the networking stacks (say,
>> opening a raw socket) now return EPERM instead of EACCES
>
> ip(4) and ip6(4) seem to document EACCES.
Right. Do you think we need to fix the code or the documentation?
IMHO - documentation. I like being able to tell when an error comes
from kauth(9), and EPERM is a nice way to paint those.
>> -- if we're
>> interested in checking whether this is a problem or not we should do
>> so on a much larger scale, and not as a response to a specific change.
>
> i'm not sure what you mean.
> how can we check breakage without looking at each specific changes?
Ideally, regression tests and documentation on what parts of the
system affect other parts and how, including documentation.
Examples:
- IPKDB doesn't compile and not included in ALL (I think we need to
use x86_{read,write}_flags() on i386, but don't take my word for it)
- errno(2) says, for EMFILE, that "[a]s released, the limit on the
number of open files per process is 64" -- is this still correct?
But I guess looking at each specific change is good enough for now. ;)
Thanks,
-e.
Re: CVS commit: src/sys
On Sun, May 10, 2009 at 1:16 PM, YAMAMOTO Takashi wrote: > isn't KAUTH_REQ_NETWORK_SOCKET_RAWSOCK being deprecated in favor of _OPEN? I'm still trying to decide, that's why I used this one (so removing it causes errors). On one hand, it would be nice to centralize everything like we planned. On the other hand, it requires the secmodel to understand kernel internals until things are done right (ie., we get rid of the nasty things like the routing socket) and I don't want to have to put the same logic in every secmodel just so that the system "works". I have plans on fixing the bluetooth socket for this (based on socket credentials), and might add an "open routing socket" request or something. At the moment it's at a lower priority. -e.
Re: CVS commit: src/sys
hi, > Module Name: src > Committed By: elad > Date: Wed May 6 21:41:59 UTC 2009 > > Modified Files: > src/sys/netinet: ip_output.c > src/sys/netinet6: ip6_output.c ip6_var.h ipsec.c ipsec.h raw_ip6.c > udp6_output.c > > Log Message: > Remove some usage of "priv" and "privileged" variables and instead pass > around credentials. Also push down kauth(9) calls closer to where the > operation is done. > > Mailing list reference: > > http://mail-index.netbsd.org/tech-net/2009/04/30/msg001270.html > > > To generate a diff of this commit: > cvs rdiff -u -r1.201 -r1.202 src/sys/netinet/ip_output.c > cvs rdiff -u -r1.137 -r1.138 src/sys/netinet6/ip6_output.c > cvs rdiff -u -r1.52 -r1.53 src/sys/netinet6/ip6_var.h > cvs rdiff -u -r1.140 -r1.141 src/sys/netinet6/ipsec.c > cvs rdiff -u -r1.50 -r1.51 src/sys/netinet6/ipsec.h > cvs rdiff -u -r1.103 -r1.104 src/sys/netinet6/raw_ip6.c isn't KAUTH_REQ_NETWORK_SOCKET_RAWSOCK being deprecated in favor of _OPEN? YAMAMOTO Takashi > cvs rdiff -u -r1.38 -r1.39 src/sys/netinet6/udp6_output.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files.
Re: CVS commit: src/sys/netinet6
hi, > On Sun, May 10, 2009 at 8:44 AM, YAMAMOTO Takashi > wrote: > have you checked callers and ensure that the change from EACCES to EPERM won't be a problem? >>> >>> Only ipsec_set_policy() returns EPERM instead of EACCES now, and I >>> don't think it should be a problem. >> >> "don't think"? why not? >> i asked if you checked what the callers of ipsec_set_policy do with >> the error number. do you mean "yes, of course"? >> >>> As for calling context -- I did look at the callers and mostly I just >>> moved the call inside instead of at the top. That's also why I didn't >>> remove the last one in in6.c, where is obvious that it's done before >>> splnet(), and still need to take care of it. :) >> >> i'm not sure what you mean. >> my question was about the ipsec.c change. sorry if it was not clear. >> >>> It's possible though that I've missed something. Do you see any problems? >> >> i don't know if there are problems or not. >> i'm not familiar with the code in question. >> i was just wondering about the implications of the error number change. > > Okay, I misunderstood you. I thought you were asking about the calling > context *and* the error value. > > Anyway, the error value is just returned. The caller returns it if > it's not zero. I could not find a place that checks specifically for > EACCES, or documentation that says the user should check for it. > Ioctl(4) doesn't mention it at all. ok. > That said, where we now return EPERM is where in the future we'll > return the error value returned by kauth(9), like many many other > places in the kernel. Other parts of the networking stacks (say, > opening a raw socket) now return EPERM instead of EACCES ip(4) and ip6(4) seem to document EACCES. > -- if we're > interested in checking whether this is a problem or not we should do > so on a much larger scale, and not as a response to a specific change. i'm not sure what you mean. how can we check breakage without looking at each specific changes? YAMAMOTO Takashi > > Thanks, > > -e.
Re: CVS commit: src/sys/netinet6
On Sun, May 10, 2009 at 8:44 AM, YAMAMOTO Takashi wrote: >>> have you checked callers and ensure that the change from EACCES to EPERM >>> won't be a problem? >> >> Only ipsec_set_policy() returns EPERM instead of EACCES now, and I >> don't think it should be a problem. > > "don't think"? why not? > i asked if you checked what the callers of ipsec_set_policy do with > the error number. do you mean "yes, of course"? > >> As for calling context -- I did look at the callers and mostly I just >> moved the call inside instead of at the top. That's also why I didn't >> remove the last one in in6.c, where is obvious that it's done before >> splnet(), and still need to take care of it. :) > > i'm not sure what you mean. > my question was about the ipsec.c change. sorry if it was not clear. > >> It's possible though that I've missed something. Do you see any problems? > > i don't know if there are problems or not. > i'm not familiar with the code in question. > i was just wondering about the implications of the error number change. Okay, I misunderstood you. I thought you were asking about the calling context *and* the error value. Anyway, the error value is just returned. The caller returns it if it's not zero. I could not find a place that checks specifically for EACCES, or documentation that says the user should check for it. Ioctl(4) doesn't mention it at all. That said, where we now return EPERM is where in the future we'll return the error value returned by kauth(9), like many many other places in the kernel. Other parts of the networking stacks (say, opening a raw socket) now return EPERM instead of EACCES -- if we're interested in checking whether this is a problem or not we should do so on a much larger scale, and not as a response to a specific change. Thanks, -e.
