Glen Barber | 24 Jul 20:33 2014
Picon

FreeBSD Quarterly Status Report - Second Quarter 2014


FreeBSD Project Quarterly Status Report: April - June 2014

   This report covers FreeBSD-related projects between April and June
   2014. This is the second of four reports planned for 2014.

   The second quarter of 2014 was a very busy and productive time for the
   FreeBSD Project. A new FreeBSD Core Team was elected, the FreeBSD Ports
   Management Team branched the second quarterly "stable" branch, the
   FreeBSD Release Engineering Team was in the process of finalizing the
   FreeBSD 9.3-RELEASE cycle, and many exciting new features have been
   added to FreeBSD.

   Thanks to all the reporters for the excellent work! This report
   contains 24 entries and we hope you enjoy reading it.

   The deadline for submissions covering the period from July to September
   2014 is October 7th, 2014.
     __________________________________________________________________

FreeBSD Team Reports

     * FreeBSD Core Team
     * FreeBSD Port Management Team
     * FreeBSD Release Engineering Team

Projects

     * Chelsio iSCSI Offload Support
     * CUSE4BSD
(Continue reading)

Bryan Drewery | 22 Jul 23:07 2014
Picon

r268621: panic: shadowed tmpfs v_object

On r268621:

> panic: shadowed tmpfs v_object 0xfffff807a7f96600
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1247d67390
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440
> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480
> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0
> vm_object_deallocate() at vm_object_deallocate+0x236/frame 0xfffffe1247d67550
> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580
> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0
> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0
> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660
> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690
> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0
> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0
> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730
> vputx() at vputx+0x27a/frame 0xfffffe1247d67790
> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860
> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890
> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0
> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0
> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = 0x7fffffffe238, rbp =
0x7fffffffe710 ---
> Uptime: 6d4h0m3s
>
> Dump failed. Partition too small.

(Continue reading)

Nidal Khalil | 22 Jul 23:06 2014
Picon

Re: freebsd-hackers Digest, Vol 588, Issue 1

Still no go

On Tue, Jul 22, 2014 at 5:00 AM, <freebsd-hackers-request <at> freebsd.org>
wrote:

> Send freebsd-hackers mailing list submissions to
>         freebsd-hackers <at> freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> or, via email, send a message with subject or body 'help' to
>         freebsd-hackers-request <at> freebsd.org
>
> You can reach the person managing the list at
>         freebsd-hackers-owner <at> freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-hackers digest..."
>
>
> Today's Topics:
>
>    1. Remote kernel debugging question (Nidal Khalil)
>    2. Re: Remote kernel debugging question (Benjamin Kaduk)
>    3. Re: Remote kernel debugging question (Nidal Khalil)
>    4. Re: Remote kernel debugging question (Navdeep Parhar)
>    5. Re: Remote kernel debugging question (Nidal Khalil)
>    6. Re: Remote kernel debugging question (Navdeep Parhar)
>    7. Re: Remote kernel debugging question (Nidal Khalil)
>
(Continue reading)

Nidal Khalil | 21 Jul 21:22 2014
Picon

Remote kernel debugging question

Hello All,
I am somewhat new to BSD kernel but I am trying to debug a kernel module
using remote debugging.
I am using 9.2 RELEASE.
I setup and compiled the kernel with the following:

makeoptions DEBUG=-g
options          KDB
options          KDB_TRACE
options          DDB_CTF
options          DDB
options          GDB
options          ALT_BREAK_TO_DEBUGGER

I setup the uart for serial1 flags to 0x90 and I can read and write to the
serial from either machine
Both machines have the same kernel booted.
I can enter ddb but I can not launch gdb
The remote GDB backend could not be selected.
sysctl -a | grep debug.kdb

debug.kdb.available: ddb
Is that correct or it should be:
debug.kdb.available: ddb gdb
How do I enable gdb backend. I appreciate the help.

Nidal
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Jan Kokemüller | 18 Jul 18:21 2014
Picon

Fixing fork detection of arc4random by implementing INHERIT_ZERO for minherit?

Hi,
the issue mentioned at 
https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux also 
affects FreeBSDs arc4random implementation as its fork detection relies 
on changing pids only. Under FreeBSD, LibreSSL uses arc4random directly, 
and relies on it to be 100% fork safe. They don't provide a way to stir 
the RNG manually. I've brought this up with the LibreSSL developers, who 
think it's a bug in the OS 
(https://github.com/libressl-portable/portable/issues/17).

I've tried to implement INHERIT_ZERO for minherit to make arc4random 
fork safe (patches attached). It seems to work fine so far, but I'm 
really no expert on FreeBSDs VM system.

Also, the arc4random functions should probably be updated to use 
something more secure like ChaCha20 instead of RC4 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610).

Cheers,
Jan
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Ian Lepore | 16 Jul 23:23 2014
Picon

[CFR] Adding a function to rtld-elf.so, how to handle Symbol.map?

I need to add an ARM-specific function to rtld-elf.so to help locate
exception unwind info in shared objects.  I'm confused about how to add
the function to Symbol.map... do I have to add a 1.4 section because it
was first added in FreeBSD 11, or does it go into an existing section
because it doesn't introduce changes to an existing ABI?

-- Ian

Attachment (find_exidx2.diff): text/x-patch, 4688 bytes
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Prabhpal S. Mavi | 11 Jul 10:32 2014
Picon

Wrong Information From Log Watch Daemon - FreeBSD 9.2 x64

Dear List Members

i did upgrade FreeBSD System From 9.0 T0 9.2 Due to some requirments.
After that i upgraded some packages such as, Apache, MySQL etc..

Problem Statement:
I still receive old package version info from Log Watch, mail that comes
from (Charlie Root) every morning.

How can i fix this behavior ? Kindly advice...

New Version For Upgraded Packages:

[root <at> titan /home/mavi]# apachectl -v
Server version: Apache/2.2.27 (FreeBSD)
Server built:   Jul  9 2014 10:05:55

[root <at> titan /home/mavi]# mysql -uroot -p
Server version: 5.6.19 Source distribution

Package Info From Log Watch Mail:

Checking for packages with security vulnerabilities:
apache-2.2.21  < Previous Version
mysql-server-5.1.60  < Previous Version

automake-1.11.1
ca_root_nss-3.12.11_1
clamav-0.97.3_1
curl-7.21.3_2
(Continue reading)

Picon
Picon

Re: [CFR] Remove texinfo from base

Warner Losh wrote:
> On Jun 25, 2014, at 8:47 AM, Baptiste Daroussin <bapt <at> FreeBSD.org> wrote:
> 
>> On Wed, Jun 25, 2014 at 08:20:41AM -0700, Warner Losh wrote:
>>> On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller <fullermd <at> over-yonder.net> wrote:
>>>
>>>> On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of
>>>> Baptiste Daroussin, and lo! it spake thus:
>>>>> I have just committed the support for this in ports, anyway breakage
>>>>> should be reported, right now it seems fine on my exp-run
>>>> Oh, yes.  Sorry, I did phrase that poorly.  This shouldn't _break_
>>>> anything, but I suspect it will uncover existing-but-hidden breakage.
>>>>
>>>> Which is good.  But does merit awareness that "hey, this will probably
>>>> happen somewhere, so know this is a place to look when a build
>>>> breaks".
>>> I know it will break certain nanobsd configurations that build ports because
>>> dependencies there (at least for the ones I’ve done) aren’t well handled. So
>>> I agree that this patch is missing, at the very least, an UPDATING entry and
>>> a __FreeBSD_version bump.
>> If you build a port that needs texinfo the port framework will do what it needs
> 
> Except in environments that don’t do dependencies quite right, or where only a subset
> of ports tree has been imported and texinfo isn’t part of that…  But people with them
> usually know, which is why UPDATING is needed. That’s all. There’s nothing else for you
> to do.
> 
> Warner

i a few times heard there was and IS a long standing stand-off between 
(Continue reading)

Noel Hunt | 10 Jul 04:09 2014
Picon

FreeBSD/Solaris dual-boot, problems with time (ntpd)

I have a dual-boot machine, running ntpd in both OSes, but when
I switch from one OS to the other the time is wildly out.

Can someone explain what is going on please?

Noel Hunt
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Sean Fagan | 10 Jul 01:33 2014

Expanding on NO_ROOT: Categorizing installed files

We've been looking at some significant changes to how we distribute and update FreeNAS; one of the things
I've done is take the NO_ROOT build changes, and expand upon them to have categories.

I'd like to say I went for minimal changes here, but mostly what I was going for was minimal work on my part. 
However, this seems to mostly work; the METALOG that gets generated has lines such as

	./bin/cat type=file uname=root gname=wheel mode=0555 size=11520 category=base

and I've written a python script that will take that METALOG, and create PKGNG-style packages from it. 
(This may be more useful for things like "category=dev", or "secure".)  I did have to change xinstall a bit
to handle this, and I also changed how it handled hard links for the metalog.

Any comments on this?  More importantly, any interest in it?

(Note that I am not subscribed to the list from this address, so if you respond to the list, I may follow up from
a different address :).)

diff --git a/Makefile.inc1 b/Makefile.inc1
index c0591b6..b9edd0d 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
 <at>  <at>  -14,6 +14,7  <at>  <at> 
 #	-DNO_KERNELOBJ do not run ${MAKE} obj in ${MAKE} buildkernel
 #	-DNO_PORTSUPDATE do not update ports in ${MAKE} update
 #	-DNO_ROOT install without using root privilege
+#	-DLOG_META_INFO Log metadata about installed files
 #	-DNO_DOCUPDATE do not update doc in ${MAKE} update
 #	-DNO_CTF do not run the DTrace CTF conversion tools on built objects
(Continue reading)

Nathan Dautenhahn | 8 Jul 13:45 2014

Re: Kernel Privilege Separation Policy

On Sat, Jul 05, 2014 at 12:24:31PM -0400, George Neville-Neil wrote:
> On 4 Jul 2014, at 16:46, Nathan Dautenhahn wrote:
> 
> >On Fri, Jul 04, 2014 at 10:27:57AM -0400, George Neville-Neil wrote:
> >>On 3 Jul 2014, at 15:23, Julian Elischer wrote:
> >>
> >>>On 7/2/14, 10:52 PM, Dautenhahn, Nathan Daniel wrote:
> >>>>Hi All-
> >>>>
> >>>>I am a graduate student at UIUC and am currently working on a
> >>>>system that
> >>>>isolates the MMU from the rest of the FreeBSD kernel. For the
> >>>>purpose of
> >>>>enabling privilege separtion within the kernel.
> >>>>
> >>>>
> >>>[...]
> >>>
> >>>it does sound interesting.. I think the dearth of answers is that
> >>>everyone is waiting for someone-else to answer, because the topic
> >>>sounds a bit intimidating,
> >>
> >>I also think we'd be interested in seeing the code itself, and what
> >>APIs it exposes.
> >>That would probably focus thinking on what can be done with it.
> >
> >Hi George-
> >
> >I will start working on getting the code available for view on a
> >github
(Continue reading)


Gmane