Re: type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

[Konstantin Belousov]

On Sun, Jul 09, 2017 at 11:15:18PM -0300, Otac??lio wrote:
> Dears
> 
> I'm the maintainer of xosview and I'm debugging rather weird behavior 
> from it in the latest FreeBSD 12 revisions (12.0-CURRENT #0 r320730 
> AMD64) . The problem is occurring on the lines responsible for 
> collecting statistics about paging. These lines follow:
> 
> If (pageinfo) {
> Pageinfo [0] = (uint64_t) vm.v_vnodepgsin + (uint64_t) vm.v_swappgsin;
Why these casts are needed ?  What is the type of vm.v_vnodepgsin ?

> Pageinfo [1] = (uint64_t) vm.v_vnodepgsout + (uint64_t) vm.v_swappgsout;
> }
> 
> This code works on FreeBSD 11 and until a short time ago it works at 12. 
> But now it returns extremely large values ??when interpreted as 64-bit 
> values. A debugging has shown that for this sysctl call the following 
> values ??are returned in the terminal:
> sysctl vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin 
> vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout
> Vm.stats.vm.v_vnodepgsin: 47432
> Vm.stats.vm.v_swappgsin: 0
> Vm.stats.vm.v_vnodepgsout: 19
> Vm.stats.vm.v_swappgsout: 0
> 
> While the code returns things like:
> 
> Pageinf [0] = 34359785800; Pageinfo [1] = 140733193388051
> Pageinf [0] = 34359785800; Pageinfo [1] = 2678138638516092947
> 
> After some tests I found that if I change the code to use a typecast to 
> (uint32_t) then Xosview works correctly.:
> If (pageinfo) {
> Pageinfo [0] = (uint32_t) ((uint64_t) vm.v_vnodepgsin + (uint64_t) 
> vm.v_swappgsin);
> Pageinfo [1] = (uint32_t) ((uint64_t) vm.v_vnodepgsout + (uint64_t) 
> vm.v_swappgsout);
> }
> 
> For me, it seems that some code in the kernel is storing values ??as 32 
> bits where it should be 64 bits. Is this behavior correct?

Show the _exact_ code fragment that reads the MIBs values.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

[Otacílio]

Dears

I'm the maintainer of xosview and I'm debugging rather weird behavior 
from it in the latest FreeBSD 12 revisions (12.0-CURRENT #0 r320730 
AMD64) . The problem is occurring on the lines responsible for 
collecting statistics about paging. These lines follow:


If (pageinfo) {
Pageinfo [0] = (uint64_t) vm.v_vnodepgsin + (uint64_t) vm.v_swappgsin;
Pageinfo [1] = (uint64_t) vm.v_vnodepgsout + (uint64_t) vm.v_swappgsout;
}

This code works on FreeBSD 11 and until a short time ago it works at 12. 
But now it returns extremely large values ​​when interpreted as 64-bit 
values. A debugging has shown that for this sysctl call the following 
values ​​are returned in the terminal:
sysctl vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin 
vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout

Vm.stats.vm.v_vnodepgsin: 47432
Vm.stats.vm.v_swappgsin: 0
Vm.stats.vm.v_vnodepgsout: 19
Vm.stats.vm.v_swappgsout: 0

While the code returns things like:

Pageinf [0] = 34359785800; Pageinfo [1] = 140733193388051
Pageinf [0] = 34359785800; Pageinfo [1] = 2678138638516092947

After some tests I found that if I change the code to use a typecast to 
(uint32_t) then Xosview works correctly.:

If (pageinfo) {
Pageinfo [0] = (uint32_t) ((uint64_t) vm.v_vnodepgsin + (uint64_t) 
vm.v_swappgsin);
Pageinfo [1] = (uint32_t) ((uint64_t) vm.v_vnodepgsout + (uint64_t) 
vm.v_swappgsout);

}

For me, it seems that some code in the kernel is storing values ​​as 32 
bits where it should be 64 bits. Is this behavior correct?


[]'s

-Otacílio
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Jilles Tjoelker]

On Sun, Jul 09, 2017 at 02:07:06PM +, Johannes Lundberg wrote:
> That code gets the child's pid from the fork command. That's is not
> available in my case (Wayland client connects to Wayland server via unix
> socket).

> I can understand the security issue.. hmm will dig further tomorrow..

It seems like what Wayland wants is not a security feature, but a
feature to prevent people from building things that will not work in a
future more secure world. In this future world, operations like making a
screenshot would be privileged.

Even if the PID race is solved, it remains trivial to fake the check
(for example, fork a process that sends the initial message and then
immediately execs a "privileged" binary, or use ptrace to attach to a
"privileged" binary or launch a new copy of a "privileged" binary).

With regard to security, it would be equivalent to have the client send
the name of its binary to the server. Putting this into a low-level
Wayland library would deter people from faking the check to do things
that will not work in the future more secure world. I don't know how
invasive this would be, though.

One possible implementation of the future more secure world would be
per-application UIDs a la Android. Another one would be
Capsicum-sandboxed applications where applications receive their Wayland
sockets pre-connected by code that tells the Wayland server the
application identity.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Jilles Tjoelker]

On Sun, Jul 09, 2017 at 05:43:22PM +0100, David Chisnall wrote:
> On 9 Jul 2017, at 14:25, Stefan Ehmann  wrote:

> > Don't why the structs are not compatible, maybe because:
> > "The process ID cmcred_pid should not be looked up (such as via the
> > KERN_PROC_PID sysctl) for making security decisions.  The sending
> > process could have exited and its process ID already been reused for
> > a new process."

> Note that having the kernel provide a process descriptor instead of a
> PID would allow the userspace process to have race-free access to the
> PID.

This is an interesting idea, but would require quite a few changes.

First, current process descriptors act as an artificial parent process,
suppressing the normal SIGCHLD to the parent and not being matched by a
wildcard waitpid() or similar function. A new kind of process descriptor
would have to be added which leaves this behaviour unchanged and could
exist in parallel with a process descriptor from pdfork().

Second, pdgetpid() makes no guarantees whether the process ID still
exists. It should not make them either for this case, since this would
allow another user to hold onto process slots for RLIMIT_NPROC. The only
solution would be to add variants of the necessary calls that take a
process descriptor instead of a process ID.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Cy Schubert]

In message , Rick Macklem writes:
> --_002_YTXPR01MB0189F5614497D4FA96A7579ADDA80YTXPR01MB0189CANP_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,
> 
> The attached one line patch to /etc/rc.d/nfsd modifies the script so that i=
> t
> does not force the nfsuserd to be run when nfsv4_server_enable is set.
> (nfsuserd can still be enabled via nfsuserd_enable=3D"YES" is /etc/rc.conf.=
> )
> 
> Here's why I think this patch might be appropriate...
> (a) - The original RFC for NFSv4 (RFC3530) essentially required Owners and
>Owner_groups to be specified as @ and this required
>the nfsuserd daemon to be running.
> (b) - RFC7530, which replace RFC3530, allows a Owner/Owner_group string to =
> be
>   the uid/gid number in a string when using AUTH_SYS. This simplifies confi=
> guration
>   for an all AUTH_SYS/POSIX environment (most NFS uses, I suspect?).
> 
> To make the server do (b), two things need to be done:
> 1 - set vfs.nfsd.enable_stringtouid=3D1
> 2 - set vfs.nfsd.enable_uidtostring=3D1 (for head, I don't know if it will =
> be MFC'd?)
> OR
>   - never run nfsuserd after booting (killing it off after it has been runn=
> ing is not
> sufficient)
>  =20
> Given the above, it would seem that /etc/rc.d/nfsd should not force running=
>  of
> the nfsuserd daemon, due to changes in the protocol.
> 
> However, this will result in a POLA violation, in that after the patch, nfs=
> userd won't
> start when booting, unless nfsuserd_enable=3D"YES" is added to /etc/rc.conf=
> .
> 
> So, what do people think about this patch? rick=

How about a warning message + an UPDATING entry + no MFC? And, relnotes = 
yes to say we now support RFC7530 in 12.0?

-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Rick Macklem]

Hi,

The attached one line patch to /etc/rc.d/nfsd modifies the script so that it
does not force the nfsuserd to be run when nfsv4_server_enable is set.
(nfsuserd can still be enabled via nfsuserd_enable="YES" is /etc/rc.conf.)

Here's why I think this patch might be appropriate...
(a) - The original RFC for NFSv4 (RFC3530) essentially required Owners and
   Owner_groups to be specified as @ and this required
   the nfsuserd daemon to be running.
(b) - RFC7530, which replace RFC3530, allows a Owner/Owner_group string to be
  the uid/gid number in a string when using AUTH_SYS. This simplifies 
configuration
  for an all AUTH_SYS/POSIX environment (most NFS uses, I suspect?).

To make the server do (b), two things need to be done:
1 - set vfs.nfsd.enable_stringtouid=1
2 - set vfs.nfsd.enable_uidtostring=1 (for head, I don't know if it will be 
MFC'd?)
OR
  - never run nfsuserd after booting (killing it off after it has been running 
is not
sufficient)
  
Given the above, it would seem that /etc/rc.d/nfsd should not force running of
the nfsuserd daemon, due to changes in the protocol.

However, this will result in a POLA violation, in that after the patch, 
nfsuserd won't
start when booting, unless nfsuserd_enable="YES" is added to /etc/rc.conf.

So, what do people think about this patch? rick

nfsd-rcd.patch
Description: nfsd-rcd.patch
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 19:08, Benjamin Kaduk пишет:

> (BTW, I think there is not agreement as to whether vmrun.sh should
> be used in general use, or alternate solutions for VM managemnet.)

As a side note: I used the process written at TH...

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[SOLVED] [memstick install] auto-zfs error

[Boris Samorodov]

08.07.2017 18:56, Boris Samorodov пишет:
> Hi All,
> 
> I tied to install a new FreeBSD-amd-12 system from official USB
> installation memstick.img. Auto-UFS (GPT) installs fine and the system
> boots fine. However, ZFS-Auto install succeeds, but is not loaded.
> At the very beginning it gives something like "gpt sector  error,
> gpt sector 1 error, can't find zroot..."
> 
> Is it a known error / should I give more (precise) errors?
> 
> I tried two recent images with the same result:
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img

It turned out GPT and zfs are not usable at this machine.
MBR / ZFS works fine.

I'll stick with that.

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[David Chisnall]

On 9 Jul 2017, at 14:25, Stefan Ehmann  wrote:
> 
> Don't why the structs are not compatible, maybe because:
> "The process ID cmcred_pid should not be looked up (such as via the
> KERN_PROC_PID sysctl) for making security decisions.  The sending process 
> could have exited and its process ID already been reused for a new process."

Note that having the kernel provide a process descriptor instead of a PID would 
allow the userspace process to have race-free access to the PID.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 19:08, Benjamin Kaduk пишет:
> On Sun, Jul 09, 2017 at 06:58:09PM +0300, Boris Samorodov wrote:
>> 09.07.2017 18:48, Boris Samorodov пишет:
>>> 09.07.2017 18:37, Benjamin Kaduk пишет:

 Documentation looks okay, as -I  is documented during
 the install stage, and is not supposed to be needed during
 normal operation.

 The quoted error message from vmrun.sh happens when it thinks you
 need to install on the given filesystem image
 (if [ $force_install -eq 1 -o $need_install -eq 1 ];)
 so it might be worth checking that your guest.img contains a valid
 FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
 prepared to handle that?)
>>>
>>> Yes, I used AutoZFS installer function to install FreeBSD.
>>
>> -
>> % sudo mdconfig -f quest.img
>> mdo0
>>
>> % gpart show md0
>> =>  40  16777136  md0  GPT  (8.0G)
>> 40  10241  freebsd-boot  (512K)
>>   1064   984   - free -  (492K)
>>   2048   41943042  freebsd-swap  (2.0G)
>>4196352  125788163  freebsd-zfs  (6.0G)
>>   16775168  2008   - free -  (1.0M)
>> -
>>
>> So, that seems the same bug as at my previous email:
>> https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066514.html
> 
> Is it?  I refer to this part of vmrun.sh:
> 
>   file -s ${first_diskdev} | grep "boot sector" > /dev/null
>   rc=$?
>   if [ $rc -ne 0 ]; then
>   file -s ${first_diskdev} | grep ": Unix Fast File sys" > 
> /dev/null
>   rc=$?
>   fi
>   if [ $rc -ne 0 ]; then
>   need_install=1
>   else
>   need_install=0
>   fi
> 
> Which is not expected to be particularly robust.
> (BTW, I think there is not agreement as to whether vmrun.sh should
> be used in general use, or alternate solutions for VM managemnet.)

OK, normal bhyveload/bhyve ended up at a successful boot.
Benjamin, thank you for your comments and help!

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Benjamin Kaduk]

On Sun, Jul 09, 2017 at 06:58:09PM +0300, Boris Samorodov wrote:
> 09.07.2017 18:48, Boris Samorodov пишет:
> > 09.07.2017 18:37, Benjamin Kaduk пишет:
> >>
> >> Documentation looks okay, as -I  is documented during
> >> the install stage, and is not supposed to be needed during
> >> normal operation.
> >>
> >> The quoted error message from vmrun.sh happens when it thinks you
> >> need to install on the given filesystem image
> >> (if [ $force_install -eq 1 -o $need_install -eq 1 ];)
> >> so it might be worth checking that your guest.img contains a valid
> >> FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
> >> prepared to handle that?)
> > 
> > Yes, I used AutoZFS installer function to install FreeBSD.
> 
> -
> % sudo mdconfig -f quest.img
> mdo0
> 
> % gpart show md0
> =>  40  16777136  md0  GPT  (8.0G)
> 40  10241  freebsd-boot  (512K)
>   1064   984   - free -  (492K)
>   2048   41943042  freebsd-swap  (2.0G)
>4196352  125788163  freebsd-zfs  (6.0G)
>   16775168  2008   - free -  (1.0M)
> -
> 
> So, that seems the same bug as at my previous email:
> https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066514.html

Is it?  I refer to this part of vmrun.sh:

file -s ${first_diskdev} | grep "boot sector" > /dev/null
rc=$?
if [ $rc -ne 0 ]; then
file -s ${first_diskdev} | grep ": Unix Fast File sys" > 
/dev/null
rc=$?
fi
if [ $rc -ne 0 ]; then
need_install=1
else
need_install=0
fi

Which is not expected to be particularly robust.
(BTW, I think there is not agreement as to whether vmrun.sh should
be used in general use, or alternate solutions for VM managemnet.)

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 18:48, Boris Samorodov пишет:
> 09.07.2017 18:37, Benjamin Kaduk пишет:
>> On Sun, Jul 09, 2017 at 01:02:26PM +0300, Boris Samorodov wrote:
>>> Hi All,
>>>
>>> I try to create a FreeBSD guest as per TH, section "21.7.2. Creating
>>> a FreeBSD Guest". All is good up until the last command at the section.
>>> When I try to launch the installed client, I get:
>>> -
>>> # sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d
>>> guest.img guestname
>>> Launching virtual machine "guestname" ...
>>> Installation CDROM image "./release.iso" is not readable
>>>
>>> % uname -a
>>> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r320821: Sun
>>> Jul  9 07:10:56 MSK 2017
>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64
>>> -
>>>
>>> Is it a bug at vmrun.sh or documentation?
>>
>> Documentation looks okay, as -I  is documented during
>> the install stage, and is not supposed to be needed during
>> normal operation.
>>
>> The quoted error message from vmrun.sh happens when it thinks you
>> need to install on the given filesystem image
>> (if [ $force_install -eq 1 -o $need_install -eq 1 ];)
>> so it might be worth checking that your guest.img contains a valid
>> FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
>> prepared to handle that?)
> 
> Yes, I used AutoZFS installer function to install FreeBSD.

-
% sudo mdconfig -f quest.img
mdo0

% gpart show md0
=>  40  16777136  md0  GPT  (8.0G)
40  10241  freebsd-boot  (512K)
  1064   984   - free -  (492K)
  2048   41943042  freebsd-swap  (2.0G)
   4196352  125788163  freebsd-zfs  (6.0G)
  16775168  2008   - free -  (1.0M)
-

So, that seems the same bug as at my previous email:
https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066514.html

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 18:37, Benjamin Kaduk пишет:
> On Sun, Jul 09, 2017 at 01:02:26PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> I try to create a FreeBSD guest as per TH, section "21.7.2. Creating
>> a FreeBSD Guest". All is good up until the last command at the section.
>> When I try to launch the installed client, I get:
>> -
>> # sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d
>> guest.img guestname
>> Launching virtual machine "guestname" ...
>> Installation CDROM image "./release.iso" is not readable
>>
>> % uname -a
>> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r320821: Sun
>> Jul  9 07:10:56 MSK 2017
>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64
>> -
>>
>> Is it a bug at vmrun.sh or documentation?
> 
> Documentation looks okay, as -I  is documented during
> the install stage, and is not supposed to be needed during
> normal operation.
> 
> The quoted error message from vmrun.sh happens when it thinks you
> need to install on the given filesystem image
> (if [ $force_install -eq 1 -o $need_install -eq 1 ];)
> so it might be worth checking that your guest.img contains a valid
> FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
> prepared to handle that?)

Yes, I used AutoZFS installer function to install FreeBSD.

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Benjamin Kaduk]

On Sun, Jul 09, 2017 at 01:02:26PM +0300, Boris Samorodov wrote:
> Hi All,
> 
> I try to create a FreeBSD guest as per TH, section "21.7.2. Creating
> a FreeBSD Guest". All is good up until the last command at the section.
> When I try to launch the installed client, I get:
> -
> # sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d
> guest.img guestname
> Launching virtual machine "guestname" ...
> Installation CDROM image "./release.iso" is not readable
> 
> % uname -a
> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r320821: Sun
> Jul  9 07:10:56 MSK 2017
> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64
> -
> 
> Is it a bug at vmrun.sh or documentation?

Documentation looks okay, as -I  is documented during
the install stage, and is not supposed to be needed during
normal operation.

The quoted error message from vmrun.sh happens when it thinks you
need to install on the given filesystem image
(if [ $force_install -eq 1 -o $need_install -eq 1 ];)
so it might be worth checking that your guest.img contains a valid
FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
prepared to handle that?)

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Problem with make installworld et alii

[Michael Butler]

You need to a build newer than SVN r320652 to fix this ..

On 07/09/17 10:43, Filippo Moretti wrote:

FreeBSD sting 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320360: Mon Jun 26 15:49:29 
UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  
i386After compiling world and kernel I cannot make install world with the 
following error:Fatal error cannot allocate read line in initial thread at line 
392 in file /use/src/lib/libthr/thread/thr_init.c (errorno=12)PID 42315 (cc) 
uid 0: exited on signal 6 (core dumped)
make:  "/usr/src/share/mk/bsd.compiler.mk" line 145 : Unable to determine 
compiler type for CC=cc . Consider settingCOMPILER_TYPE





This is the report of the crash I experienced with my custom kernel while 
running xinit (all the operations in console mode worked).I can succesfully 
start X using GENERIC.My kernel Worked fine until I reinstalled this snapshot.


Jul  8 08:41:53 sting kernel:
Jul  8 08:41:53 sting kernel:
Jul  8 08:41:53 sting kernel: Fatal trap 12: page fault while in kernel mode
Jul  8 08:41:53 sting kernel: cpuid = 1; apic id = 01
Jul  8 08:41:53 sting kernel: fault virtual address = 0xa4c8c67d
Jul  8 08:41:53 sting kernel: fault code= supervisor read, page 
not present
Jul  8 08:41:53 sting kernel: instruction pointer   = 0x20:0xc7f86218
Jul  8 08:41:53 sting kernel: stack pointer = 0x28:0xf0b828e0
Jul  8 08:41:53 sting kernel: frame pointer = 0x28:0xf0b8290c
Jul  8 08:41:53 sting kernel: code segment  = base 0x0, limit 
0xf, type 0x1b
Jul  8 08:41:53 sting kernel: = DPL 0, pres 1, def32 1, gran 1
Jul  8 08:41:53 sting kernel: processor eflags  = interrupt enabled, resume, 
IOPL = 0
Jul  8 08:41:53 sting kernel: current process   = 798 (Xorg)
Jul  8 08:41:53 sting kernel: trap number   = 12
Jul  8 08:41:53 sting kernel: panic: page fault
Jul  8 08:41:53 sting kernel: cpuid = 1
Jul  8 08:41:53 sting kernel: time = 1499495998
Jul  8 08:41:53 sting kernel: KDB: stack backtrace:
Jul  8 08:41:53 sting kernel: #0 0xc07d92df at kdb_backtrace+0x4f
Jul  8 08:41:53 sting kernel: #1 0xc079ad33 at vpanic+0x133
Jul  8 08:41:53 sting kernel: #2 0xc079abfb at panic+0x1b
Jul  8 08:41:53 sting kernel: #3 0xc0a7a73e at trap_fatal+0x31e
Jul  8 08:41:53 sting kernel: #4 0xc0a7a783 at trap_pfault+0x33
Jul  8 08:41:53 sting kernel: #5 0xc0a79e8e at trap+0x2be
Jul  8 08:41:53 sting kernel: #6 0xc0a68d6a at calltrap+0x6
Jul  8 08:41:53 sting kernel: #7 0xc0823df8 at unp_connect2+0x88
Jul  8 08:41:53 sting kernel: #8 0xc0823a9b at unp_connectat+0x40b
Jul  8 08:41:53 sting kernel: #9 0xc0821000 at uipc_connect+0x40
Jul  8 08:41:53 sting kernel: #10 0xc081dac6 at kern_connectat+0x116
Jul  8 08:41:53 sting kernel: #11 0xc081d999 at sys_connect+0x99
Jul  8 08:41:53 sting kernel: #12 0xc0a7b104 at syscall+0x5b4
Jul  8 08:41:53 sting kernel: #13 0xc0a68dee at Xint0x80_syscall+0x2e
Jul  8 08:41:53 sting kernel: Uptime: 2m10s
Jul  8 08:41:53 sting kernel: Physical memory: 2929 MB
Jul  8 08:41:53 sting kernel: Dumping 109 MB: 94 78 62 46 30 14
Jul  8 08:41:53 sting kernel: Dump complete
Jul  8 08:41:53 sting kernel: Automatic reboot in 15 seconds - press a key on 
the console to abort
Jul  8 08:41:53 sting kernel: --> Press a key on the console to reboot,
Jul  8 08:41:53 sting kernel: --> or switch off the system now.
Jul  8 08:41:53 sting kernel: Rebooting...
Jul  8 08:41:53 sting kernel: cpu_reset: Restarting BSP
Jul  8 08:41:53 sting kernel: cpu_reset_proxy: Stopped CPU 1
I also get these messages in console

Jul  8 08:45:31 sting kernel: 1st 0xc6114bb8 bufwait (bufwait) @ 
/usr/src/sys/kern/vfs_bio.c:3539
Jul  8 08:45:31 sting kernel: 2nd 0xd0391800 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
Jul  8 08:45:31 sting kernel: stack backtrace:
Jul  8 08:45:31 sting kernel: #0 0xc0cbbbd1 at witness_debugger+0x81
Jul  8 08:45:31 sting kernel: #1 0xc0cbbaf1 at witness_checkorder+0xd11
Jul  8 08:45:31 sting kernel: #2 0xc0c60154 at _sx_xlock+0x64
Jul  8 08:45:31 sting kernel: #3 0xc0f5d3b0 at ufsdirhash_add+0x40
Jul  8 08:45:31 sting kernel: #4 0xc0f6010a at ufs_direnter+0x47a
Jul  8 08:45:31 sting kernel: #5 0xc0f6a07f at ufs_makeinode+0x5af
Jul  8 08:45:31 sting kernel: #6 0xc0f695a6 at ufs_symlink+0x36
Jul  8 08:45:31 sting kernel: #7 0xc123be43 at VOP_SYMLINK_APV+0xd3
Jul  8 08:45:31 sting kernel: #8 0xc0d301a4 at kern_symlinkat+0x274
Jul  8 08:45:31 sting kernel: #9 0xc0d2ff21 at sys_symlink+0x31
Jul  8 08:45:31 sting kernel: #10 0xc120719e at syscall+0x6de
Jul  8 08:45:31 sting kernel: #11 0xc11f2bee at Xint0x80_syscall+0x2e
Jul  8 08:46:07 sting kernel: lock order reversal:
Jul  8 08:46:07 sting kernel: 1st 0xd18c9914 ufs (ufs) @ 
/usr/src/sys/kern/vfs_syscalls.c:3362
Jul  8 08:46:07 sting kernel: 2nd 0xc6114bb8 bufwait (bufwait) @ 
/usr/src/sys/ufs/ffs/ffs_vnops.c:280
Jul  8 08:46:07 sting kernel: 3rd 0xd1af3c68 ufs (ufs) @ 
/usr/src/sys/kern/vfs_subr.c:2602
Jul  8 08:46:07 sting kernel: stack 

Problem with make installworld et alii

[Filippo Moretti]

FreeBSD sting 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320360: Mon Jun 26 15:49:29 
UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  
i386After compiling world and kernel I cannot make install world with the 
following error:Fatal error cannot allocate read line in initial thread at line 
392 in file /use/src/lib/libthr/thread/thr_init.c (errorno=12)PID 42315 (cc) 
uid 0: exited on signal 6 (core dumped)
make:  "/usr/src/share/mk/bsd.compiler.mk" line 145 : Unable to determine 
compiler type for CC=cc . Consider settingCOMPILER_TYPE





This is the report of the crash I experienced with my custom kernel while 
running xinit (all the operations in console mode worked).I can succesfully 
start X using GENERIC.My kernel Worked fine until I reinstalled this snapshot.


Jul  8 08:41:53 sting kernel: 
Jul  8 08:41:53 sting kernel: 
Jul  8 08:41:53 sting kernel: Fatal trap 12: page fault while in kernel mode
Jul  8 08:41:53 sting kernel: cpuid = 1; apic id = 01
Jul  8 08:41:53 sting kernel: fault virtual address = 0xa4c8c67d
Jul  8 08:41:53 sting kernel: fault code= supervisor read, page 
not present
Jul  8 08:41:53 sting kernel: instruction pointer   = 0x20:0xc7f86218
Jul  8 08:41:53 sting kernel: stack pointer = 0x28:0xf0b828e0
Jul  8 08:41:53 sting kernel: frame pointer = 0x28:0xf0b8290c
Jul  8 08:41:53 sting kernel: code segment  = base 0x0, limit 
0xf, type 0x1b
Jul  8 08:41:53 sting kernel: = DPL 0, pres 1, def32 1, gran 1
Jul  8 08:41:53 sting kernel: processor eflags  = interrupt enabled, resume, 
IOPL = 0
Jul  8 08:41:53 sting kernel: current process   = 798 (Xorg)
Jul  8 08:41:53 sting kernel: trap number   = 12
Jul  8 08:41:53 sting kernel: panic: page fault
Jul  8 08:41:53 sting kernel: cpuid = 1
Jul  8 08:41:53 sting kernel: time = 1499495998
Jul  8 08:41:53 sting kernel: KDB: stack backtrace:
Jul  8 08:41:53 sting kernel: #0 0xc07d92df at kdb_backtrace+0x4f
Jul  8 08:41:53 sting kernel: #1 0xc079ad33 at vpanic+0x133
Jul  8 08:41:53 sting kernel: #2 0xc079abfb at panic+0x1b
Jul  8 08:41:53 sting kernel: #3 0xc0a7a73e at trap_fatal+0x31e
Jul  8 08:41:53 sting kernel: #4 0xc0a7a783 at trap_pfault+0x33
Jul  8 08:41:53 sting kernel: #5 0xc0a79e8e at trap+0x2be
Jul  8 08:41:53 sting kernel: #6 0xc0a68d6a at calltrap+0x6
Jul  8 08:41:53 sting kernel: #7 0xc0823df8 at unp_connect2+0x88
Jul  8 08:41:53 sting kernel: #8 0xc0823a9b at unp_connectat+0x40b
Jul  8 08:41:53 sting kernel: #9 0xc0821000 at uipc_connect+0x40
Jul  8 08:41:53 sting kernel: #10 0xc081dac6 at kern_connectat+0x116
Jul  8 08:41:53 sting kernel: #11 0xc081d999 at sys_connect+0x99
Jul  8 08:41:53 sting kernel: #12 0xc0a7b104 at syscall+0x5b4
Jul  8 08:41:53 sting kernel: #13 0xc0a68dee at Xint0x80_syscall+0x2e
Jul  8 08:41:53 sting kernel: Uptime: 2m10s
Jul  8 08:41:53 sting kernel: Physical memory: 2929 MB
Jul  8 08:41:53 sting kernel: Dumping 109 MB: 94 78 62 46 30 14
Jul  8 08:41:53 sting kernel: Dump complete
Jul  8 08:41:53 sting kernel: Automatic reboot in 15 seconds - press a key on 
the console to abort
Jul  8 08:41:53 sting kernel: --> Press a key on the console to reboot,
Jul  8 08:41:53 sting kernel: --> or switch off the system now.
Jul  8 08:41:53 sting kernel: Rebooting...
Jul  8 08:41:53 sting kernel: cpu_reset: Restarting BSP
Jul  8 08:41:53 sting kernel: cpu_reset_proxy: Stopped CPU 1
I also get these messages in console

Jul  8 08:45:31 sting kernel: 1st 0xc6114bb8 bufwait (bufwait) @ 
/usr/src/sys/kern/vfs_bio.c:3539
Jul  8 08:45:31 sting kernel: 2nd 0xd0391800 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
Jul  8 08:45:31 sting kernel: stack backtrace:
Jul  8 08:45:31 sting kernel: #0 0xc0cbbbd1 at witness_debugger+0x81
Jul  8 08:45:31 sting kernel: #1 0xc0cbbaf1 at witness_checkorder+0xd11
Jul  8 08:45:31 sting kernel: #2 0xc0c60154 at _sx_xlock+0x64
Jul  8 08:45:31 sting kernel: #3 0xc0f5d3b0 at ufsdirhash_add+0x40
Jul  8 08:45:31 sting kernel: #4 0xc0f6010a at ufs_direnter+0x47a
Jul  8 08:45:31 sting kernel: #5 0xc0f6a07f at ufs_makeinode+0x5af
Jul  8 08:45:31 sting kernel: #6 0xc0f695a6 at ufs_symlink+0x36
Jul  8 08:45:31 sting kernel: #7 0xc123be43 at VOP_SYMLINK_APV+0xd3
Jul  8 08:45:31 sting kernel: #8 0xc0d301a4 at kern_symlinkat+0x274
Jul  8 08:45:31 sting kernel: #9 0xc0d2ff21 at sys_symlink+0x31
Jul  8 08:45:31 sting kernel: #10 0xc120719e at syscall+0x6de
Jul  8 08:45:31 sting kernel: #11 0xc11f2bee at Xint0x80_syscall+0x2e
Jul  8 08:46:07 sting kernel: lock order reversal:
Jul  8 08:46:07 sting kernel: 1st 0xd18c9914 ufs (ufs) @ 
/usr/src/sys/kern/vfs_syscalls.c:3362
Jul  8 08:46:07 sting kernel: 2nd 0xc6114bb8 bufwait (bufwait) @ 
/usr/src/sys/ufs/ffs/ffs_vnops.c:280
Jul  8 08:46:07 sting kernel: 3rd 0xd1af3c68 ufs (ufs) @ 
/usr/src/sys/kern/vfs_subr.c:2602
Jul  8 08:46:07 sting kernel: stack backtrace:
Jul  8 08:46:07 sting kernel: #0 0xc0cbbbd1 at witness_debugger+0x81
Jul  8 08:46:07 

Re: Getting PID of socket client

[Johannes Lundberg]

That code gets the child's pid from the fork command. That's is not
available in my case (Wayland client connects to Wayland server via unix
socket).

I can understand the security issue.. hmm will dig further tomorrow..

Thanks for the info!


On Sun, 9 Jul 2017 at 15:26, Stefan Ehmann  wrote:

> On 09.07.2017 11:52, Johannes Lundberg wrote:
> > Hi
> >
> > Yeah I forgot to mention the LOCAL_CREDS.
> > It does not return the PID of the client process but i guess it could be
> > expanded to include that instead of adding another option for that.
>
> I was only skimming the man page. Didn't see that cmsgcred contains the
> PID, but sockcred does not. Of course the PID in my sample output is
> also wrong (the UID is printed instead of the PID):
>
> > $ ./unixstrserv02
> > PID of sender = 1001
>
> Don't why the structs are not compatible, maybe because:
> "The process ID cmcred_pid should not be looked up (such as via the
> KERN_PROC_PID sysctl) for making security decisions.  The sending
> process could have exited and its process ID already been reused for a
> new process."
>
> According to the commit log LOCAL_CREDS was obtained from NetBSD but I
> didn't investigate further.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Stefan Ehmann]

On 09.07.2017 11:52, Johannes Lundberg wrote:

Hi

Yeah I forgot to mention the LOCAL_CREDS.
It does not return the PID of the client process but i guess it could be 
expanded to include that instead of adding another option for that.


I was only skimming the man page. Didn't see that cmsgcred contains the 
PID, but sockcred does not. Of course the PID in my sample output is 
also wrong (the UID is printed instead of the PID):



$ ./unixstrserv02
PID of sender = 1001


Don't why the structs are not compatible, maybe because:
"The process ID cmcred_pid should not be looked up (such as via the
KERN_PROC_PID sysctl) for making security decisions.  The sending 
process could have exited and its process ID already been reused for a 
new process."


According to the commit log LOCAL_CREDS was obtained from NetBSD but I 
didn't investigate further.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

Hi All,

I try to create a FreeBSD guest as per TH, section "21.7.2. Creating
a FreeBSD Guest". All is good up until the last command at the section.
When I try to launch the installed client, I get:
-
# sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d
guest.img guestname
Launching virtual machine "guestname" ...
Installation CDROM image "./release.iso" is not readable

% uname -a
FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r320821: Sun
Jul  9 07:10:56 MSK 2017
bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64
-

Is it a bug at vmrun.sh or documentation?

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Johannes Lundberg]

Hi

Yeah I forgot to mention the LOCAL_CREDS.
It does not return the PID of the client process but i guess it could be
expanded to include that instead of adding another option for that.


On Sun, Jul 9, 2017 at 11:47 AM, Stefan Ehmann  wrote:

> On 09.07.2017 10:03, Johannes Lundberg wrote:
>
>> Hi
>>
>> Without altering the client code (i.e. adding sendmsg(credentials)), is
>> there anyway of getting the client PID (or path to binary) using the file
>> descriptor returned by accept() on the server side?
>>
>> Similar to Linux's getsockopt with SO_PEERCRED option.
>>
>
> You want the LOCAL_CREDS socket option from unix(4).
>
> There's also a FreeBSD sample in the UNIX network programming book. Source
> is available from http://unpbook.com/src.html
>
> With the following two changes it seems to work for me:
> unixstrserv02.c: set LOCAL_CREDS
> readcred.c: disable CONTROL_LEN check
>
> $ ./unixstrserv02
> PID of sender = 1001
> real user ID = 1001
> real group ID = 1001
> effective user ID = 1001
> 3 groups: 0 5 920
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Stefan Ehmann]

On 09.07.2017 10:03, Johannes Lundberg wrote:

Hi

Without altering the client code (i.e. adding sendmsg(credentials)), is
there anyway of getting the client PID (or path to binary) using the file
descriptor returned by accept() on the server side?

Similar to Linux's getsockopt with SO_PEERCRED option.


You want the LOCAL_CREDS socket option from unix(4).

There's also a FreeBSD sample in the UNIX network programming book. 
Source is available from http://unpbook.com/src.html


With the following two changes it seems to work for me:
unixstrserv02.c: set LOCAL_CREDS
readcred.c: disable CONTROL_LEN check

$ ./unixstrserv02
PID of sender = 1001
real user ID = 1001
real group ID = 1001
effective user ID = 1001
3 groups: 0 5 920
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Johannes Lundberg]

follow-up

Seems like at least OpenBSD implemented SO_PEERCRED which returns a struct
sockpeercred.

/* Read using getsockopt() with SOL_SOCKET, SO_PEERCRED */
struct sockpeercred {
uid_t uid; /* effective user id */
gid_t gid; /* effective group id */
pid_t pid;
};

If not anyone is oppose to this or know some other secret API that provides
similar functionality, I can see if I can put together a patch for this
very useful API.



On Sun, Jul 9, 2017 at 10:03 AM, Johannes Lundberg 
wrote:

> Hi
>
> Without altering the client code (i.e. adding sendmsg(credentials)), is
> there anyway of getting the client PID (or path to binary) using the file
> descriptor returned by accept() on the server side?
>
> Similar to Linux's getsockopt with SO_PEERCRED option.
>
> Thanks!
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Getting PID of socket client

[Johannes Lundberg]

Hi

Without altering the client code (i.e. adding sendmsg(credentials)), is
there anyway of getting the client PID (or path to binary) using the file
descriptor returned by accept() on the server side?

Similar to Linux's getsockopt with SO_PEERCRED option.

Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"