jail2 patchset 14
Have tried Jail2 patchset #14 on 6.2-PRERELEASE, everything compiles and
works ok, but resolve.
gethostbyname always returns NULL, but host/dig works ok.
here's an example:
virtual# host mail.ru
mail.ru has address 194.67.57.26
mail.ru mail is handled by 10 mxs.mail.ru.
virtual# ping mail.ru
ping: cannot resolve mail.ru: Host name lookup failure
here is some truss output of 'ping mail.ru':
kqueue() = 4 (0x4)
socket(PF_INET,SOCK_DGRAM,0) = 5 (0x5)
connect(5,{ AF_INET ***.62.171.***:53 },16) ERR#22 'Invalid argument'
close(5) = 0 (0x0)
socket(PF_INET,SOCK_DGRAM,0) = 5 (0x5)
connect(5,{ AF_INET ***.62.171.***:53 },16) ERR#22 'Invalid argument'
close(5) = 0 (0x0)
close(4) = 0 (0x0)
where
***.62.171.***:53 is nameserver;
*** is masked ip nodes;
may be I've forgotten something?
thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Unable to stop a jail
We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to stop a jail
On Fri, 1 Dec 2006, 10:43-, Steven Hartland wrote: We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? Known bug, discussed several times. IIRC leaked struct ucred. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to stop a jail
On Fri, 1 Dec 2006, Steven Hartland wrote: Hi, We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? no the jails should really be gone (you should not find any sockets or processes for them after some seconds) - at least it should be that way... See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to stop a jail
On Fri, 1 Dec 2006, Bjoern A. Zeeb wrote: On Fri, 1 Dec 2006, Steven Hartland wrote: We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? no the jails should really be gone (you should not find any sockets or processes for them after some seconds) - at least it should be that way... See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 Not all cases of straggling jails are leaks -- does netstat -n show that all the TIME_WAIT TCP connections in the jail have been GC'd? Because security state may be used in the network stack for TCP packet transmission/reception, the ucred remains referenced until the last socket/pcb associated with it are free'd. I've been wondering if we should add a jail process counter, and hide jails in jls if the counter is zero (with a -a argument or such to show them). One idea I've been kicking around is adding a zombie state for jails, in which some straggling references exist, but (a) there are no processes in the jail, and (b) no new processes are allowed to enter the jail. The significance of (b) is that we could vrele() the vnode reference hung off the jail; there's been at least one report that this vnode reference causes issues, as the file system it's from can't be unmounted until the last jail reference evaporates. In essence, this would move to having two reference counts on the prison: a strong reference that has to do with having process members, and a weak reference that has to do with ucreds pointing at the prison. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to stop a jail
Robert Watson wrote: Not all cases of straggling jails are leaks -- does netstat -n show that all the TIME_WAIT TCP connections in the jail have been GC'd? Because security state may be used in the network stack for TCP packet transmission/reception, the ucred remains referenced until the last socket/pcb associated with it are free'd. I've been wondering if we should add a jail process counter, and hide jails in jls if the counter is zero (with a -a argument or such to show them). One idea I've been kicking around is adding a zombie state for jails, in which some straggling references exist, but (a) there are no processes in the jail, and (b) no new processes are allowed to enter the jail. The significance of (b) is that we could vrele() the vnode reference hung off the jail; there's been at least one report that this vnode reference causes issues, as the file system it's from can't be unmounted until the last jail reference evaporates. This appears to not be the case here as there where no references to the address in netstat and no processes remaining. So it does seem there is some sort of leak still remaining there someone where. At one point I did have two zombie jails ( of the same jail ) but the second one was due to a socket reference which then just disappeared a minute or so later. In essence, this would move to having two reference counts on the prison: a strong reference that has to do with having process members, and a weak reference that has to do with ucreds pointing at the prison. The proposal sounds like a good idea but I'm sure there's an argument that would say thats just hiding the real underlieing issue? Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to stop a jail
On Fri, 1 Dec 2006, Steven Hartland wrote: In essence, this would move to having two reference counts on the prison: a strong reference that has to do with having process members, and a weak reference that has to do with ucreds pointing at the prison. The proposal sounds like a good idea but I'm sure there's an argument that would say thats just hiding the real underlieing issue? Well, there are two things going on here: (1) Jails that last a long time due to being referenced by data structures that last a long time. I.e., time-wait TCP connections. (2) Leaks in credentials or jails resulting in jails that never go away. What I describe is intended to address the former issue, which is one that exists for a reason. The latter issues are clearly bugs and just need to be fixed. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jail2 patchset 14
Eldar T. Zaitov wrote:
Have tried Jail2 patchset #14 on 6.2-PRERELEASE, everything compiles and
works ok, but resolve.
gethostbyname always returns NULL, but host/dig works ok.
here's an example:
virtual# host mail.ru
mail.ru has address 194.67.57.26
mail.ru mail is handled by 10 mxs.mail.ru.
virtual# ping mail.ru
ping: cannot resolve mail.ru: Host name lookup failure
here is some truss output of 'ping mail.ru':
kqueue() = 4 (0x4)
socket(PF_INET,SOCK_DGRAM,0) = 5 (0x5)
connect(5,{ AF_INET ***.62.171.***:53 },16) ERR#22 'Invalid argument'
close(5) = 0 (0x0)
socket(PF_INET,SOCK_DGRAM,0) = 5 (0x5)
connect(5,{ AF_INET ***.62.171.***:53 },16) ERR#22 'Invalid argument'
close(5) = 0 (0x0)
close(4) = 0 (0x0)
where
***.62.171.***:53 is nameserver;
*** is masked ip nodes;
may be I've forgotten something?
thank you.
Hope this would help you:
sysctl security.jail.allow_raw_sockets=1
man 8 jail
GL
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
[ANN] unionfs patchset-17 release, lock mechanism changed for robust working
Hi Guys! It is my pleasure and honor to announce the availability of the unionfs patchset-17. p17 have some significant improvements around the lock mechanism for robust and stable working. Patchset-17: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p17.diff For 6.x sorry, it is for current only. Changes in unionfs-p17.diff - Fs takes illegal access without lock of lower layer vnode if the both upper/lower layers have both vnode. To fix this problem, we change the lock mechanism to get locks for both upper/lower layer always. - Kernel gets a dead-lock easily within above upper/lower-layer-always-lock-mechanism. To avoide above dead-lock, we changed vfs_lookup.c. By that change, it always locks vnodes parent first and children second. You could see the same lock-order-control implementation around cache_lookup. - It takes the both open/close operations per kernel thread. - It takes readdir-treat-status-management per kernel thread. - It reopens vnode if needed when coping to upper layer on advlock. - mount_unionfs(8) changes option style fitting for fstab(5) style. (by rodrigc) - manual of mount_unionfs(8) was changed. (by rodrigc) The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) After release of p16, some folks gave us some panic reports that indicate our implementations has a critical problem around the lock mechanism. After our long researches and discussions, we have tried to re-implement our unionfs lock mechanism. And it is done :) For unionfs lovers (including FreeSBIE developers, ports cluster managers, heavy memory-fs users, or folks use unionfs), could you try p17 please? If p17 solves that panics, we guess it is unionfs merge time for current branch. Thanks P.S. Current English document of web has some Japanese contents. We need a translator ;-) -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Nvidia on amd64
Hello, A while ago there was a post about features missing in FreeBSD in order to allow for the Nvidia driver to work correctly on the amd64 platform. I'm curious if anyone has any information about the progress in this area? Regards, Ralph. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardening FreeBSD, does anyone have any documentation that may help?
On Tue, 21 Nov 2006, Joerg Sonnenberger wrote: The code is integrated in GCC 4.1, patching if needed at all is quite contained. But we're still running gcc 3.4.6, and won't be moving to gcc 4.1 on 6.x. The gcc 3.4.6 patch is the one we're reluctant to have to support. The ABI impact is limited to the stack guard cookie, the initialisation function and the failure handler. Three different solutions can be used: (1) The code can be part of a separate library (libssp). (2) The code can be part of libc (DragonFly, OpenBSD and glibc do this). (3) Like (2), but the cookie is part of the Thread Control Block, e.g. accessible via %gs. This is done on newer glibc systems and has the advantage of avoiding PIC references. Can you point me to more information on which systems implement #3? The original benchmarks done with Propolice by IBM suggest typical degrations in the area of 2%-5%, depending on how many functions are called and not inlined and how many of them need to get the protection. The site of Etoh has more details. One specific question about performance that came up was how much compiling libc with SSP enabled would impact the performance of applications. I also brought up the topic of whether we might consider using the flag to enable SSP for all functions, rather than just the ones which use strings. We need to gather more empirical data on how many recent buffer overflows have been on non-string arrays. Or is the default SSP option to protect all functions using arrays of any type rather than just arrays of strings? Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
unsubscribing from freebsd lists (was Re: contiguous memory allocation problem)
Kamal R. Prasad wrote: Hello, I would like to unsubscribe myself from all freebsd mailing lists. I have sent an unsubscribe to freebsd-hackers-unsubscribe, but did not get any response to verify. Since the admin is on the mailing list, I would appreciate if you can delete my name and/or email me the procedure to follow. thanks -kamal On 7/3/06, Julian Elischer [EMAIL PROTECTED] wrote: Ian Dowse wrote: In message [EMAIL PROTECTED], Hans Petter Selasky writes: But there is one problem, that has been overlooked, and that is High speed isochronous transfers, which are not supported by the existing USB system. I don't think that the EHCI specification was designed for scatter and gather, when you consider this: 8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, and I am right, one page has to contain two transfers. (see page 43 of ehci-r10.pdf) I haven't looked into the details, but the text in section 3.3.3 seems to suggest that EHCI is designed to not require physically contiguous allocations here either, so the same approach of using bus_dmamap_load() should work: This data structure requires the associated data buffer to be contiguous (relative to virtual memory), but allows the physical memory pages to be non-contiguous. Seven page pointers are provided to support the expression of 8 isochronous transfers. The seven pointers allow for 3 (transactions) * 1024 (maximum packet size) * 8 (transaction records) (24576 bytes) to be moved with this data structure, regardless of the alignment offset of the first page. yes, as long as the beffers are contiguous in some virtual space then the maximum number of pages they can need is 7. (they actually fit into 6 but they may start part way through the first page and may therefore overflow into a 7th). Ian Go to: http://lists.freebsd.org/mailman/listinfo. Open up each list, enter in your email address near the bottom, press unsubscribe, and you should get an unsubscribe confirmation email-unless your spam blocker or something similar is deleting the confirmation emails. Either that, or you could login with your username and password and delete your subscription that way as well. Again, this has to be done for each mailing list you're subscribed to (or maybe there was a general method from the web interface, but I forget..). Best of luck, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
