Re: ptrace attach in multi-threaded processes

[Konstantin Belousov]

On Tue, Jul 12, 2016 at 09:02:10PM -0700, Mark Johnston wrote:
> Hm, the only SIGSTOP in my scenario is the one generated by PT_ATTACH.
> The problem occurs when this SIGSTOP races with *any* other signal that's
> being delivered to the process and for which the process has registered
> a handler. For instance, SIGHUP after a log rotation.
> 
> If a real SIGSTOP races with PT_ATTACH, then I would indeed expect to
> find the process in a stopped state after the detach. Does this make
> more sense?

I finally see.  Might be something like the patch below is a step in
the desired direction.  Idea is in the proc_next_xthread(): p_xthread
should be set to the next thread with a pending signal.  Do you have a
test case that demonstrates the issue ?

diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c
index 2a5e6de..1106f3a 100644
--- a/sys/kern/kern_sig.c
+++ b/sys/kern/kern_sig.c
@@ -2525,22 +2525,21 @@ ptracestop(struct thread *td, int sig)
PROC_SUNLOCK(p);
return (sig);
}
-   /*
-* Just make wait() to work, the last stopped thread
-* will win.
-*/
-   p->p_xsig = sig;
-   p->p_xthread = td;
-   p->p_flag |= (P_STOPPED_SIG|P_STOPPED_TRACE);
-   sig_suspend_threads(td, p, 0);
-   if ((td->td_dbgflags & TDB_STOPATFORK) != 0) {
-   td->td_dbgflags &= ~TDB_STOPATFORK;
-   cv_broadcast(>p_dbgwait);
+   if (p->p_xthread == NULL)
+   p->p_xthread = td;
+   if (p->p_xthread == td) {
+   p->p_xsig = sig;
+   p->p_flag |= (P_STOPPED_SIG|P_STOPPED_TRACE);
+   sig_suspend_threads(td, p, 0);
+   if ((td->td_dbgflags & TDB_STOPATFORK) != 0) {
+   td->td_dbgflags &= ~TDB_STOPATFORK;
+   cv_broadcast(>p_dbgwait);
+   }
}
 stopme:
thread_suspend_switch(td, p);
if (p->p_xthread == td)
-   p->p_xthread = NULL;
+   proc_next_xthread(p);
if (!(p->p_flag & P_TRACED))
break;
if (td->td_dbgflags & TDB_SUSPEND) {
diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c
index a6037e3..3d9950b 100644
--- a/sys/kern/sys_process.c
+++ b/sys/kern/sys_process.c
@@ -1057,7 +1057,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void 
*addr, int data)
proctree_locked = 0;
}
p->p_xsig = data;
-   p->p_xthread = NULL;
+   proc_next_xthread(p);
if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) != 0) {
/* deliver or queue signal */
td2->td_dbgflags &= ~TDB_XSIG;
@@ -1065,7 +1065,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void 
*addr, int data)
 
if (req == PT_DETACH) {
FOREACH_THREAD_IN_PROC(p, td3)
-   td3->td_dbgflags &= ~TDB_SUSPEND; 
+   td3->td_dbgflags &= ~(TDB_SUSPEND |
+   TDB_XSIG);
}
/*
 * unsuspend all threads, to not let a thread run,
@@ -1376,9 +1377,24 @@ stopevent(struct proc *p, unsigned int event, unsigned 
int val)
do {
if (event != S_EXIT)
p->p_xsig = val;
-   p->p_xthread = NULL;
+   proc_next_xthread(p);
p->p_stype = event; /* Which event caused the stop? */
wakeup(>p_stype);/* Wake up any PIOCWAIT'ing procs */
msleep(>p_step, >p_mtx, PWAIT, "stopevent", 0);
} while (p->p_step);
 }
+
+void
+proc_next_xthread(struct proc *p)
+{
+   struct thread *td;
+
+   PROC_LOCK_ASSERT(p, MA_OWNED);
+   FOREACH_THREAD_IN_PROC(p, td) {
+   if (td == p->p_xthread)
+   continue;
+   if ((td->td_dbgflags & TDB_XSIG) != 0)
+   break;
+   }
+   p->p_xthread = td;
+}
diff --git a/sys/sys/proc.h b/sys/sys/proc.h
index f533db6..a3132d9 100644
--- a/sys/sys/proc.h
+++ b/sys/sys/proc.h
@@ -999,6 +999,7 @@ int proc_getenvv(struct thread *td, struct proc *p, struct 
sbuf *sb);
 void   procinit(void);
 void   proc_linkup0(struct proc *p, struct thread *td);
 void   proc_linkup(struct proc *p, struct thread *td);
+void   proc_next_xthread(struct proc *p);
 struct proc *proc_realparent(struct proc *child);
 void   proc_reap(struct thread *td, struct proc *p, int *status, int options);
 void   proc_reparent(struct proc *child, struct proc *newparent);

Re: ptrace attach in multi-threaded processes

[Mark Johnston]

On Wed, Jul 13, 2016 at 06:30:36AM +0300, Konstantin Belousov wrote:
> On Tue, Jul 12, 2016 at 11:24:14AM -0700, Mark Johnston wrote:
> > On Tue, Jul 12, 2016 at 08:51:50PM +0300, Konstantin Belousov wrote:
> > > On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote:
> > > > On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote:
> > > > I suppose it is not strictly incorrect. I find it surprising that a
> > > > PT_ATTACH followed by a PT_DETACH may leave the process in a different
> > > > state than it was in before the attach. This means that it is not
> > > > possible to gcore a process without potentially leaving it stopped, for
> > > > instance. This result may occur in a single-threaded process
> > > > as well, since a signal may already be queued when the PT_ATTACH handler
> > > > sends SIGSTOP.
> > > I still miss somethine.  Isn't this an expected outcome from sending a
> > > signal with STOP action ?
> > 
> > It is. But I also expect a PT_DETACH operation to resume a stopped
> > process, assuming that a second SIGSTOP was not posted while the
> > process was suspended.
> But as far as the situation was discussed, it seems that real SIGSTOP raced
> with PT_ATTACH. And the offered interpretation that SIGSTOP was delivered
> 'a bit later' than PT_ATTACH would fit into the description.

Hm, the only SIGSTOP in my scenario is the one generated by PT_ATTACH.
The problem occurs when this SIGSTOP races with *any* other signal that's
being delivered to the process and for which the process has registered
a handler. For instance, SIGHUP after a log rotation.

If a real SIGSTOP races with PT_ATTACH, then I would indeed expect to
find the process in a stopped state after the detach. Does this make
more sense?
___
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: ptrace attach in multi-threaded processes

[Konstantin Belousov]

On Tue, Jul 12, 2016 at 11:24:14AM -0700, Mark Johnston wrote:
> On Tue, Jul 12, 2016 at 08:51:50PM +0300, Konstantin Belousov wrote:
> > On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote:
> > > On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote:
> > > I suppose it is not strictly incorrect. I find it surprising that a
> > > PT_ATTACH followed by a PT_DETACH may leave the process in a different
> > > state than it was in before the attach. This means that it is not
> > > possible to gcore a process without potentially leaving it stopped, for
> > > instance. This result may occur in a single-threaded process
> > > as well, since a signal may already be queued when the PT_ATTACH handler
> > > sends SIGSTOP.
> > I still miss somethine.  Isn't this an expected outcome from sending a
> > signal with STOP action ?
> 
> It is. But I also expect a PT_DETACH operation to resume a stopped
> process, assuming that a second SIGSTOP was not posted while the
> process was suspended.
But as far as the situation was discussed, it seems that real SIGSTOP raced
with PT_ATTACH. And the offered interpretation that SIGSTOP was delivered
'a bit later' than PT_ATTACH would fit into the description.

> 
> > 
> > > Indeed, I somehow missed that. I had assumed that the leaked TDB_XSIG
> > > represented a bug in ptracestop().
> > It could, I did not made any statements that deny the bug:
> 
> To be clear, the root of my issue comes from the following: the SIGSTOP
> from PT_ATTACH may be handled concurrently with a second signal
> delivered to a second thread in the same process. Then, the resulting
> behaviour depends on the order in which the recipient threads suspend in
> ptracestop(). If the thread that received SIGSTOP suspends last, its
> td_xsig will be overwritten with the userland-provided value in the
> PT_DETACH handler. If it suspends first, its td_xsig will be preserved,
> and upon PT_DETACH the process will be suspended again in issignal().
> 
> I'm not sure if this is considered a bug. ptracestop() is handling all
> signals (including the SIGSTOP generated by the PT_ATTACH handler) in a
> consistent way, but this results in inconsistent behaviour from the
> perspective of a ptrace(2) consumer.

Still I do not understand what is inconsistent.

Let look at it from the other side (before, we discussed the implementation
in kernel).  Is this happens in gcore(1) ?   If yes, gcore interaction
with ptrace(2) looks like this:
ptrace(PT_ATTACH, g_pid);
waitpid(g_pid, _status, 0);
...
if (sig == SIGSTOP)
sig = 0;
ptrace(PT_DETACH, g_pid, 1, sig);
It sounds as if it is desirable for you to modify gcore(1) to consume
all signals, or at least, all STOP signals before PT_DETACH.  I do not
understand why do you want it, but that would probably give you the
behaviour you want:
ptrace(PT_ATTACH, g_pid);
waitpid(g_pid, _status, 0);
...
/* still consume implicit SIGSTOP from attach */
if (sig == SIGSTOP)
sig = 0;
do {
error = waitpid(g_pid, _status, WNOHANG | WSTOPPED);
} while (error == 0);   
ptrace(PT_DETACH, g_pid, 1, sig);
___
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: dtrace and kernel modules

[Julian Elischer]

On 13/07/2016 1:14 AM, Mark Johnston wrote:

On Thu, Jul 07, 2016 at 12:51:52PM +0800, Julian Elischer wrote:

I'm specifically interested in the case of kernel modules that
instantiate new syscalls.

How much support do we have for that?  In the one example in our
sources of a kld with a syscall (kgssapi.ko) dtrace seems to find
regular function entrypoints but not the syscall.


root@porridge:/usr/src # dtrace -n ":kgssapi::entry {}"
dtrace: description ':kgssapi::entry ' matched 138 probes
^C

root@porridge:/usr/src # dtrace -n "syscall:kgssapi::entry {}"
dtrace: invalid probe specifier syscall:kgssapi::entry {}: probe
description syscall:kgssapi::entry does not match any probes
root@porridge:/usr/src #


Do we have plans to support dynamic syscall support?

I don't know of any plans to add support. It would be fairly
straightforward to dynamically create syscall probes using a hook or
eventhandler in syscall_register(), but getting argument type info would
be more difficult. Right now, argument types are specified by code
generated by makesyscalls.sh using the types in syscalls.master. I'm not
sure how one might obtain these types for dynamically-registered
syscalls.


yes that is the tricky part for sure.

for now function calls is probably enough because every syscall ends 
up calling a function somewhere :-)




___
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: sr-iov's virtual function driver shipped broken?

[Ultima]

Ah, well I posted on the mailing list during Q1 about the issue. Also asked
if it is planned to be fixed for release during Q2? and the response was
that they're is an issues with the current implementation and it is being
worked on, so I never created a bug for it.

https://lists.freebsd.org/pipermail/freebsd-current/2016-March/060350.html

Just opened PR211062 for it.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211062

On Tue, Jul 12, 2016 at 2:24 PM, Ngie Cooper  wrote:

>
> > On Jul 12, 2016, at 11:21, Ultima  wrote:
> >
> > I'v mentioned this in the past, but I just want to verify. Will 11 be
> > released with the virtual function driver unusable? Currently iovctl will
> > only work in pass-through mode.
>
> Hi,
> Is there a bug open for this issue with a repro/more details?
> Thanks,
> -Ngie
>
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[A. Wilcox]

On 12/07/16 15:58, Steven Hartland wrote:
> On 12/07/2016 21:50, Slawa Olhovchenkov wrote:
>> On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
>>
>>> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
>>> be dropped from Tier 2 if they don't support USB and we aren't okay
>>> with dropping disc1 support for all of Tier 2.

That is pretty much all SPARC hardware and a lot of POWER hardware.  Not
to mention newer rack-mount servers that have no USB on front (IBM).

And what of the servers that already have functional CD drives?  Do we
really now have to recommending buying SCSI/SATA slimline or USB DVD
drives just to boot installation media?  That's a heavy cost when you
can fit nearly all other BSDs on a single regular 650 (84 MB for NetBSD
7.0.1 + 223 MB for OpenBSD 5.9 + 385 MB for "TrueOS"/PC-BSD Server 10.3
= 692 MB, all sizes amd64 install iso including sets).

>> Not all BIOS can be boot from USB.
>> I am have Fujitsu notebook not support USB boot.
> From a USB Pen drive I can understand but from a USB DVD Drive that
> would be some seriously antiquated hardware!

I have a Core 2-era Xeon board (Wolfdale-DP, Intel 5000 based) that
cannot under any circumstances boot from a connected USB device.  It
won't boot from a USB DVD, USB CD, USB pen, or USB hard disk (USBMSC).
I hardly consider a server that is 7 years old "antiquated" though I
concede it is not the newest.

Beyond that, there are security issues with allowing servers to boot off
of any random USB device that an admin has lying around.  Most will be
configured by good admins to not do such a thing.

In summary: NAK NAK NAK.  USB is not a solution.  Bringing down the
bloat on disc1 or returning to miniinst is the proper solution.

~arw

-- 
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steven Hartland]

On 12/07/2016 22:20, Ed Schouten wrote:

2016-07-11 23:01 GMT+02:00 Ronald Klop :

Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on
Windows 10. It complained that the ISO is too big for my 700 MB CD-r.

I remember back in the days we also had a 'miniinst' CD, which was
identical to 'bootonly', but at least contained the install sets to
get a minimal system working. What ever happened to that?

Since we found mfsbsd , we've never looked back it 
does just that + a one cmd line install.

___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ed Schouten]

2016-07-11 23:01 GMT+02:00 Ronald Klop :
> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on
> Windows 10. It complained that the ISO is too big for my 700 MB CD-r.

I remember back in the days we also had a 'miniinst' CD, which was
identical to 'bootonly', but at least contained the install sets to
get a minimal system working. What ever happened to that?

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Slawa Olhovchenkov]

On Tue, Jul 12, 2016 at 09:58:08PM +0100, Steven Hartland wrote:

> On 12/07/2016 21:50, Slawa Olhovchenkov wrote:
> > On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
> >
> >> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> >> be dropped from Tier 2 if they don't support USB and we aren't okay
> >> with dropping disc1 support for all of Tier 2.
> >>
> >> There's lots of aging hardware we don't support in modern FreeBSD,
> >> including alpha and ia64.  USB is 20 years young at this point.
> > Not all BIOS can be boot from USB.
> > I am have Fujitsu notebook not support USB boot.
> >
>  From a USB Pen drive I can understand but from a USB DVD Drive that 
> would be some seriously antiquated hardware!

They have CD-ROM. Why I need buy USB DVD Drive?

___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steve Rikli]

I haven't done it in a very long time (circa FreeBSD-6) but PXE installs
were possible back then, so I'd hope that's still a possibility in 11.

Are there mostly current docs for that routine these days?

Cheers,
sr.

On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> be dropped from Tier 2 if they don't support USB and we aren't okay
> with dropping disc1 support for all of Tier 2.
> 
> There's lots of aging hardware we don't support in modern FreeBSD,
> including alpha and ia64.  USB is 20 years young at this point.
> 
> Best,
> Conrad
> 
> On Tue, Jul 12, 2016 at 12:52 PM, Mark Linimon  wrote:
> > On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
> >> +1 on dropping CD images.
> >
> > I have 24U of things that don't have DVD players, including some tier-2
> > machines for which no upgrade is available.
> >
> > mcl
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Chris H]

On Tue, 12 Jul 2016 16:09:10 +0930 Shane Ambler  wrote

> On 12/07/2016 06:54, Conrad Meyer wrote:
> > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > it's time to move on from CD.
> 
> +1 on dropping CD images. I haven't burnt a CD in over 10 years and I
> don't believe I have seen a CD only drive in that time. Even with a CD
> size image I have burnt them to DVD, I first started this because
> transfer speeds of DVD's are faster and nowadays it costs almost the
> same to burn a DVD. So I see zero benefit to using CD's and that's
> before thinking of reusable USB devices.
> 
> I do think there is a benefit to keeping the small boot only image
> available that can be used to start/recover a machine that can then
> download any data to be installed.
> 
> -- 
> FreeBSD - the place to B...Storing Data
> 
> Shane Ambler
> 

-1
There is no *good* reason that FreeBSD can't maintain the CD image.
I think the *real* question here is; *why* is it now so hard to fit
it on a CD?

--Chris


___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steven Hartland]

On 12/07/2016 21:50, Slawa Olhovchenkov wrote:

On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:


Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
be dropped from Tier 2 if they don't support USB and we aren't okay
with dropping disc1 support for all of Tier 2.

There's lots of aging hardware we don't support in modern FreeBSD,
including alpha and ia64.  USB is 20 years young at this point.

Not all BIOS can be boot from USB.
I am have Fujitsu notebook not support USB boot.

From a USB Pen drive I can understand but from a USB DVD Drive that 
would be some seriously antiquated hardware!


Regards
Steve
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Slawa Olhovchenkov]

On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:

> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> be dropped from Tier 2 if they don't support USB and we aren't okay
> with dropping disc1 support for all of Tier 2.
> 
> There's lots of aging hardware we don't support in modern FreeBSD,
> including alpha and ia64.  USB is 20 years young at this point.

Not all BIOS can be boot from USB.
I am have Fujitsu notebook not support USB boot.

> Best,
> Conrad
> 
> On Tue, Jul 12, 2016 at 12:52 PM, Mark Linimon  wrote:
> > On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
> >> +1 on dropping CD images.
> >
> > I have 24U of things that don't have DVD players, including some tier-2
> > machines for which no upgrade is available.
> >
> > mcl
> ___
> 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"
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Conrad Meyer]

Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
be dropped from Tier 2 if they don't support USB and we aren't okay
with dropping disc1 support for all of Tier 2.

There's lots of aging hardware we don't support in modern FreeBSD,
including alpha and ia64.  USB is 20 years young at this point.

Best,
Conrad

On Tue, Jul 12, 2016 at 12:52 PM, Mark Linimon  wrote:
> On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
>> +1 on dropping CD images.
>
> I have 24U of things that don't have DVD players, including some tier-2
> machines for which no upgrade is available.
>
> mcl
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Steven Hartland]

On 12/07/2016 20:52, Mark Linimon wrote:

On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:

+1 on dropping CD images.

I have 24U of things that don't have DVD players, including some tier-2
machines for which no upgrade is available.


Any no USB?
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Mark Linimon]

On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
> +1 on dropping CD images.

I have 24U of things that don't have DVD players, including some tier-2
machines for which no upgrade is available.

mcl
___
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"

Jenkins build is back to normal : FreeBSD_HEAD #420

[jenkins-admin]

See 

___
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: GOST in OPENSSL_BASE

[Kevin Oberman]

On Tue, Jul 12, 2016 at 5:33 AM, Daniel Kalchev  wrote:

>
> > On 12.07.2016 г., at 13:26, Franco Fichtner 
> wrote:
> >
> >
> >> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev  wrote:
> >>
> >> It is trivial to play MTIM with this protocol and in fact, there are
> commercially available “solutions” for “securing one’s corporate network”
> that doe exactly that. Some believe this is with the knowledge and approval
> of the corporation, but who is to say what the black box actually does and
> whose interests it serves?
> >
> > It's also trivial to ignore that pinning certificates and using client
> > certificates can actually help a great deal to prevent all of what you
> > just said.  ;)
>
> I don’t know many users who even know that they can do this —  much less
> actually using it. Pinning the browser vendor’s certificates does not
> protect you from being spied while visiting someone else’s site. This is
> also non-trivial to support.
> In the early days of DANE, Google even had a version of Chrome that
> supported DANE, just to kill it a bit later:
> https://www.ietf.org/mail-archive/web/dane/current/msg06980.html
>
> >
> > The bottom line is not having GOST support readily available could
> alienate
> > a whole lot of businesses.  Not wanting those downstream use cases will
> make
> > those shift elsewhere and the decision will be seen as an overly
> political
> > move that in no possible way reflects the motivation of community growth.
>
>
> Exactly — especially as long as there is no demonstrable proof that GOST
> is actually broken.


I may have been misunderstood, possibly because I was unclear.

I do not object to GOST being readily available as it is legally required
in some places. I do object on its being enabled by default and I do object
to standards endorsing it use, though I do not object to standards for
GOST, itself.

Making the method for enabling GOST simple and clearly documented is a
reasonable thing and, as long as its use is mandated it is really essential.

And, thinks, Andrey, for clarifying the Russian law.  I don't know the
language and have depended on others for the details. In areas of tine
points of laws, this is often inadequate. (As it is when you read the
language fluently. I read and speak American English quite well, but that
does not mean that legalese is covered.)

Reality is that the law is what those charges with formal interpretation of
it say it is. In the US, that is the Supreme Court. Not sure who is in
Russia, but it's not me!)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: sr-iov's virtual function driver shipped broken?

[Ngie Cooper]

> On Jul 12, 2016, at 11:21, Ultima  wrote:
> 
> I'v mentioned this in the past, but I just want to verify. Will 11 be
> released with the virtual function driver unusable? Currently iovctl will
> only work in pass-through mode.

Hi,
Is there a bug open for this issue with a repro/more details?
Thanks,
-Ngie
___
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"

sr-iov's virtual function driver shipped broken?

[Ultima]

I'v mentioned this in the past, but I just want to verify. Will 11 be
released with the virtual function driver unusable? Currently iovctl will
only work in pass-through mode.
___
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: ptrace attach in multi-threaded processes

[Mark Johnston]

On Tue, Jul 12, 2016 at 08:51:50PM +0300, Konstantin Belousov wrote:
> On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote:
> > On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote:
> > I suppose it is not strictly incorrect. I find it surprising that a
> > PT_ATTACH followed by a PT_DETACH may leave the process in a different
> > state than it was in before the attach. This means that it is not
> > possible to gcore a process without potentially leaving it stopped, for
> > instance. This result may occur in a single-threaded process
> > as well, since a signal may already be queued when the PT_ATTACH handler
> > sends SIGSTOP.
> I still miss somethine.  Isn't this an expected outcome from sending a
> signal with STOP action ?

It is. But I also expect a PT_DETACH operation to resume a stopped
process, assuming that a second SIGSTOP was not posted while the
process was suspended.

> 
> > Indeed, I somehow missed that. I had assumed that the leaked TDB_XSIG
> > represented a bug in ptracestop().
> It could, I did not made any statements that deny the bug:

To be clear, the root of my issue comes from the following: the SIGSTOP
from PT_ATTACH may be handled concurrently with a second signal
delivered to a second thread in the same process. Then, the resulting
behaviour depends on the order in which the recipient threads suspend in
ptracestop(). If the thread that received SIGSTOP suspends last, its
td_xsig will be overwritten with the userland-provided value in the
PT_DETACH handler. If it suspends first, its td_xsig will be preserved,
and upon PT_DETACH the process will be suspended again in issignal().

I'm not sure if this is considered a bug. ptracestop() is handling all
signals (including the SIGSTOP generated by the PT_ATTACH handler) in a
consistent way, but this results in inconsistent behaviour from the
perspective of a ptrace(2) consumer.

> 
> > > > Moreover, in my scenario I see a thread with TDB_XSIG set even after
> > > > ptrace(PT_DETACH) was called (P_TRACED is cleared).
> > > This is interesting, we indeed do not clear the flag consistently.
> > > But again, the only consequence seems to be a possible invalid reporting
> > > of events.
___
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: ptrace attach in multi-threaded processes

[Konstantin Belousov]

On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote:
> On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote:
> I suppose it is not strictly incorrect. I find it surprising that a
> PT_ATTACH followed by a PT_DETACH may leave the process in a different
> state than it was in before the attach. This means that it is not
> possible to gcore a process without potentially leaving it stopped, for
> instance. This result may occur in a single-threaded process
> as well, since a signal may already be queued when the PT_ATTACH handler
> sends SIGSTOP.
I still miss somethine.  Isn't this an expected outcome from sending a
signal with STOP action ?

> Indeed, I somehow missed that. I had assumed that the leaked TDB_XSIG
> represented a bug in ptracestop().
It could, I did not made any statements that deny the bug:

> > > Moreover, in my scenario I see a thread with TDB_XSIG set even after
> > > ptrace(PT_DETACH) was called (P_TRACED is cleared).
> > This is interesting, we indeed do not clear the flag consistently.
> > But again, the only consequence seems to be a possible invalid reporting
> > of events.
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Maxim Sobolev]

Another option for the kvm installs and  that we are using for many years
here is to pre-load root UZIP image into RAM. With some easy trimming you
can bring base system down to 30MB or so compressed. Yes, bit of delay to
load, but the kernel alone is around 10MB compressed, so it's not an order
of magnitude increase. Then it runs from the RAM completely, so you are
immune to any disconnects or stalls. If your kvm disconnects in the middle
of the session, you just re-connect and continue.

UZPNAME here is the root UFS compressed with mkuzip. You would just put it
into your ISO as file somewhere and use:

  echo 'image_load="YES"' >> ${CDIR}/boot/loader.conf
  echo "image_name=\"/${UZPNAME}\"" >> ${CDIR}/boot/loader.conf
  echo 'image_type="md_image"' >> ${CDIR}/boot/loader.conf

Also we set mountftom (requires GEOM_LABEL):

  echo vfs.root.mountfrom=\"ufs:ufs/${MD_LABEL}\" >>
${CDIR}/boot/loader.conf

-Maxim

On Tue, Jul 12, 2016 at 9:31 AM, Allan Jude  wrote:

> On 2016-07-12 11:15, Ngie Cooper (yaneurabeya) wrote:
> >
> >> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
> >>
> >> Paweł Tyll wrote on 07/12/2016 01:22:
> >>
> >>> Those 3 things should shave off about 130MB of the 173MB needed to fit
> >>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
> >>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
> >>> CD-R? :)
> >>
> >> It is not only about the target media size. The size matters when you
> need to boot some recovery media from you desktop on remote server via KVM.
> >>
> >> And there is one thing I don't understand - why is the bootonly so
> large? I remember days when this fits to 50MB and now it is almost 235MB
> which renders it almost useless. For recoveries and remote installs I
> always use mfsbsd images (about 45MB).
> >
> > I wholeheartedly agree.
> >
> > It sucks having to transfer more than 50 MB over our work link across a
> few thousand miles with IPMI remote KVM redirection.
> >
> > Thanks,
> > -Ngie
> >
>
> With IPMI virtual media, you usually do not transfer the entire image,
> only read the blocks used by files that you load. Some IPMI clients
> provide stats, usually only about 40mb is read from the bootonly cd.
> More if you do things like invoke an editor to write a custom /etc/fstab
> etc.
>
> --
> Allan Jude
>
>
___
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: dtrace and kernel modules

[Mark Johnston]

On Thu, Jul 07, 2016 at 12:51:52PM +0800, Julian Elischer wrote:
> I'm specifically interested in the case of kernel modules that 
> instantiate new syscalls.
> 
> How much support do we have for that?  In the one example in our 
> sources of a kld with a syscall (kgssapi.ko) dtrace seems to find 
> regular function entrypoints but not the syscall.
> 
> 
> root@porridge:/usr/src # dtrace -n ":kgssapi::entry {}"
> dtrace: description ':kgssapi::entry ' matched 138 probes
> ^C
> 
> root@porridge:/usr/src # dtrace -n "syscall:kgssapi::entry {}"
> dtrace: invalid probe specifier syscall:kgssapi::entry {}: probe 
> description syscall:kgssapi::entry does not match any probes
> root@porridge:/usr/src #
> 
> 
> Do we have plans to support dynamic syscall support?

I don't know of any plans to add support. It would be fairly
straightforward to dynamically create syscall probes using a hook or
eventhandler in syscall_register(), but getting argument type info would
be more difficult. Right now, argument types are specified by code
generated by makesyscalls.sh using the types in syscalls.master. I'm not
sure how one might obtain these types for dynamically-registered
syscalls.
___
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"

Build failed in Jenkins: FreeBSD_HEAD #419

[jenkins-admin]

See 

--
[...truncated 317352 lines...]
===> usr.sbin/praudit (installconfig)
===> usr.sbin/authpf (installconfig)
===> usr.sbin/autofs (installconfig)
===> usr.sbin/blacklistctl (installconfig)
===> usr.sbin/blacklistd (installconfig)
===> usr.sbin/bluetooth (installconfig)
===> usr.sbin/bluetooth/bt3cfw (installconfig)
===> usr.sbin/bluetooth/btpand (installconfig)
===> usr.sbin/bluetooth/hccontrol (installconfig)
===> usr.sbin/bluetooth/hcsecd (installconfig)
===> usr.sbin/bluetooth/hcseriald (installconfig)
===> usr.sbin/bluetooth/l2control (installconfig)
===> usr.sbin/bluetooth/l2ping (installconfig)
===> usr.sbin/bluetooth/rfcomm_pppd (installconfig)
===> usr.sbin/bluetooth/sdpcontrol (installconfig)
===> usr.sbin/bluetooth/sdpd (installconfig)
===> usr.sbin/bluetooth/ath3kfw (installconfig)
===> usr.sbin/bluetooth/bcmfw (installconfig)
===> usr.sbin/bluetooth/bthidcontrol (installconfig)
===> usr.sbin/bluetooth/bthidd (installconfig)
===> usr.sbin/bootparamd (installconfig)
===> usr.sbin/bootparamd/bootparamd (installconfig)
===> usr.sbin/bootparamd/callbootd (installconfig)
===> usr.sbin/bsdinstall (installconfig)
===> usr.sbin/bsdinstall/distextract (installconfig)
===> usr.sbin/bsdinstall/distfetch (installconfig)
===> usr.sbin/bsdinstall/partedit (installconfig)
===> usr.sbin/bsdinstall/scripts (installconfig)
===> usr.sbin/bsnmpd (installconfig)
===> usr.sbin/bsnmpd/gensnmptree (installconfig)
===> usr.sbin/bsnmpd/bsnmpd (installconfig)
===> usr.sbin/bsnmpd/modules (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_atm (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_bridge (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_hast (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_hostres (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_lm75 (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_mibII (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_target (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_usm (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_vacm (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_wlan (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_pf (installconfig)
===> usr.sbin/bsnmpd/modules/snmp_netgraph (installconfig)
===> usr.sbin/bsnmpd/tools (installconfig)
===> usr.sbin/bsnmpd/tools/libbsnmptools (installconfig)
===> usr.sbin/bsnmpd/tools/bsnmptools (installconfig)
===> usr.sbin/ctm (installconfig)
===> usr.sbin/ctm/ctm (installconfig)
===> usr.sbin/ctm/ctm_rmail (installconfig)
===> usr.sbin/ctm/ctm_smail (installconfig)
===> usr.sbin/ctm/ctm_dequeue (installconfig)
===> usr.sbin/fdcontrol (installconfig)
===> usr.sbin/fdformat (installconfig)
===> usr.sbin/fdread (installconfig)
===> usr.sbin/fdwrite (installconfig)
===> usr.sbin/fmtree (installconfig)
===> usr.sbin/freebsd-update (installconfig)
===> usr.sbin/gssd (installconfig)
===> usr.sbin/gpioctl (installconfig)
===> usr.sbin/ip6addrctl (installconfig)
===> usr.sbin/mld6query (installconfig)
===> usr.sbin/ndp (installconfig)
===> usr.sbin/rip6query (installconfig)
===> usr.sbin/route6d (installconfig)
===> usr.sbin/rrenumd (installconfig)
===> usr.sbin/rtadvctl (installconfig)
===> usr.sbin/rtadvd (installconfig)
===> usr.sbin/rtsold (installconfig)
===> usr.sbin/traceroute6 (installconfig)
===> usr.sbin/inetd (installconfig)
===> usr.sbin/ipfwpcap (installconfig)
===> usr.sbin/iscsid (installconfig)
===> usr.sbin/jail (installconfig)
===> usr.sbin/jexec (installconfig)
===> usr.sbin/jls (installconfig)
===> usr.sbin/kbdcontrol (installconfig)
===> usr.sbin/kbdmap (installconfig)
===> usr.sbin/moused (installconfig)
===> usr.sbin/vidcontrol (installconfig)
===> usr.sbin/pppctl (installconfig)
===> usr.sbin/nscd (installconfig)
===> usr.sbin/lpr (installconfig)
===> usr.sbin/lpr/common_source (installconfig)
===> usr.sbin/lpr/chkprintcap (installconfig)
===> usr.sbin/lpr/lp (installconfig)
===> usr.sbin/lpr/lpc (installconfig)
===> usr.sbin/lpr/lpd (installconfig)
===> usr.sbin/lpr/lpq (installconfig)
===> usr.sbin/lpr/lpr (installconfig)
===> usr.sbin/lpr/lprm (installconfig)
===> usr.sbin/lpr/lptest (installconfig)
===> usr.sbin/lpr/pac (installconfig)
===> usr.sbin/lpr/filters (installconfig)
===> usr.sbin/lpr/filters.ru (installconfig)
===> usr.sbin/lpr/filters.ru/koi2alt (installconfig)
===> usr.sbin/lpr/filters.ru/koi2855 (installconfig)
===> usr.sbin/manctl (installconfig)
===> usr.sbin/flowctl (installconfig)
===> usr.sbin/lmcconfig (installconfig)
===> usr.sbin/ngctl (installconfig)
===> usr.sbin/nghook (installconfig)
===> usr.sbin/rpc.yppasswdd (installconfig)
===> usr.sbin/rpc.ypupdated (installconfig)
===> usr.sbin/rpc.ypxfrd (installconfig)
===> usr.sbin/ypbind (installconfig)
===> usr.sbin/ypldap (installconfig)
===> usr.sbin/yp_mkdb (installconfig)
===> usr.sbin/yppoll (installconfig)
===> usr.sbin/yppush (installconfig)
===> usr.sbin/ypserv (installconfig)
===> usr.sbin/ypset (installconfig)
===> 

Re: ptrace attach in multi-threaded processes

[Mark Johnston]

On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote:
> On Mon, Jul 11, 2016 at 06:19:38PM -0700, Mark Johnston wrote:
> > Hi,
> > 
> > It seems to be possible for ptrace(PT_ATTACH) to race with the delivery
> > of a signal to the same process. ptrace(PT_ATTACH) sets P_TRACED and
> > sends SIGSTOP to a thread in the target process. Consider the case where
> > a signal is delivered to a second thread, and both threads are executing
> > ast() concurrently. The two threads will both call issignal() and from
> > there call ptracestop() because P_TRACED is set, though they will be
> > serialized by the proc lock. If the thread receiving SIGSTOP wins the
> > race, it will suspend first and set p->p_xthread. The second thread will
> > also suspend in ptracestop(), overwriting the p_xthread field set by the
> > first thread. Later, ptrace(PT_DETACH) will unsuspend the threads, but
> > it will set td->td_xsig only in the second thread. This means that the
> > first thread will return SIGSTOP from ptracestop() and subsequently
> > suspend the process, which seems rather incorrect.
> Why ?  In particular, why delivering STOP after attach, in the described
> situation, is perceived as incorrect ?  Parallel STOPs, one from attach,
> and other from kill(2), must result in two stops.

I suppose it is not strictly incorrect. I find it surprising that a
PT_ATTACH followed by a PT_DETACH may leave the process in a different
state than it was in before the attach. This means that it is not
possible to gcore a process without potentially leaving it stopped, for
instance. This result may occur in a single-threaded process
as well, since a signal may already be queued when the PT_ATTACH handler
sends SIGSTOP.

To me it just seems a bit strange that ptrace's mechanism for stopping
the target - sending SIGSTOP - interacts this way with ptrace's handling
of signals - ptracestop()). Specifically, PT_ATTACH does not rely on the
SA_STOP property of SIGSTOP to stop the process, but rather on the
special signal handling in ptracestop().

> 
> The bit about overwriting p_xsig/p_xthread indeed initially sound worrysome,
> but probably not too much.  The only consequence of reassigning p_xthread
> is the selection of the 'lead' thread in sys_process.c, it seems.
> 
> > 
> > The above is just a theory to explain an unexpectedly-stopped
> > multi-threaded process that I've observed. Is there some mechanism I'm
> > missing that prevents multiple threads from suspending in ptracestop()
> > at the same time? If not, then I think that's the root of the problem,
> > since p_xthread is pretty clearly not meant to be overwritten this way.
> Again, why ?
> 
> Note the comment 
>* Just make wait() to work, the last stopped thread
>  * will win.
> which seems to point to the situation.

Indeed, I somehow missed that. I had assumed that the leaked TDB_XSIG
represented a bug in ptracestop().

> 
> > Moreover, in my scenario I see a thread with TDB_XSIG set even after
> > ptrace(PT_DETACH) was called (P_TRACED is cleared).
> This is interesting, we indeed do not clear the flag consistently.
> But again, the only consequence seems to be a possible invalid reporting
> of events.
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Allan Jude]

On 2016-07-12 11:15, Ngie Cooper (yaneurabeya) wrote:
> 
>> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> Paweł Tyll wrote on 07/12/2016 01:22:
>>
>>> Those 3 things should shave off about 130MB of the 173MB needed to fit
>>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
>>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
>>> CD-R? :)
>>
>> It is not only about the target media size. The size matters when you need 
>> to boot some recovery media from you desktop on remote server via KVM.
>>
>> And there is one thing I don't understand - why is the bootonly so large? I 
>> remember days when this fits to 50MB and now it is almost 235MB which 
>> renders it almost useless. For recoveries and remote installs I always use 
>> mfsbsd images (about 45MB).
> 
> I wholeheartedly agree.
> 
> It sucks having to transfer more than 50 MB over our work link across a few 
> thousand miles with IPMI remote KVM redirection.
> 
> Thanks,
> -Ngie
> 

With IPMI virtual media, you usually do not transfer the entire image,
only read the blocks used by files that you load. Some IPMI clients
provide stats, usually only about 40mb is read from the bootonly cd.
More if you do things like invoke an editor to write a custom /etc/fstab
etc.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Oversight in /etc/defaults/rc.conf

[Ryan Stone]

On Tue, Jul 12, 2016 at 10:50 AM, RW  wrote:

> Unless I'm misunderstanding the situation. rc.d/iovctl isn't actually
> doing anything by default because of iovctl_files="".
>
> There is an analogy with rc.d/sysctl which runs by default, with a
> an empty sysctl.conf file. This also has no explicit enable entry in
> rc.conf.
>

That is how it is intended to work, and rc.d/sysctl was the inspiration for
that script if memory serves.  I'm not entirely opposed to an iovctl_enable
variable but it seems redundant.
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ngie Cooper (yaneurabeya)]

> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Paweł Tyll wrote on 07/12/2016 01:22:
> 
>> Those 3 things should shave off about 130MB of the 173MB needed to fit
>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
>> CD-R? :)
> 
> It is not only about the target media size. The size matters when you need to 
> boot some recovery media from you desktop on remote server via KVM.
> 
> And there is one thing I don't understand - why is the bootonly so large? I 
> remember days when this fits to 50MB and now it is almost 235MB which renders 
> it almost useless. For recoveries and remote installs I always use mfsbsd 
> images (about 45MB).

I wholeheartedly agree.

It sucks having to transfer more than 50 MB over our work link across a few 
thousand miles with IPMI remote KVM redirection.

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Oversight in /etc/defaults/rc.conf

[Rodney W. Grimes]

> On 07/12/16 13:27, Glen Barber wrote:
> > On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> >> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> >> fine -- however I did notice that the new iovctl rc script is apparently
> >> enabled by default.  That seems like a trivial omission:
> >>
> >> Index: etc/defaults/rc.conf
> >> ===
> >> --- etc/defaults/rc.conf   (revision 302482)
> >> +++ etc/defaults/rc.conf   (working copy)
> >> @@ -695,6 +695,7 @@
> >>  rctl_enable="YES" # Load rctl(8) rules on boot
> >>  rctl_rules="/etc/rctl.conf"   # rctl(8) ruleset. See rctl.conf(5).
> >>
> >> +iovctl_enable="NO"
    Missing explination of knob
> >>  iovctl_files=""   # Config files for iovctl(8)
> >>
> >>  ##
> >>
> > 
> > I'm not sure I understand.  Is there a functional and/or performance
> > impact with it enabled by default?  (Note, I don't disable it in my
> > rc.conf, and there is no /dev/iov/* on my system.)
> 
> I'm not religious about it being turned off per se.  More that it should
> have a clearly defined on/off state shown in the defaults.
> 
> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?
> 
> However, even if it's felt it should be enabled everywhere, then
> shouldn't /etc/defaults/rc.conf have:
> 
> iovctl_enable="YES"

What ever is resolved you also need to add a # comment describing it.

> 
> instead?
> 
>   Cheers,
> 
>   Matthew

-- 
Rod Grimes rgri...@freebsd.org
___
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: panic: bogus refcnt 0 on lle 0xfffff80121a13a00

[Hans Petter Selasky]

On 07/12/16 11:03, Michael Zhilin wrote:

Hi,

I have same issue everyday on my laptop. It happens randomly and I suppose
due to network issues.
I want to test D4507. I've tried to apply patch, it's successful except one
chunk:



I've updated D4605 . It will fix the panic that results of the command 
sequence in the differential revision's comments at least.


--HPS

___
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: Oversight in /etc/defaults/rc.conf

[RW]

On Tue, 12 Jul 2016 15:10:43 +0100
Matthew Seaman wrote:


> I'm not religious about it being turned off per se.  More that it
> should have a clearly defined on/off state shown in the defaults.
> 
> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?

Unless I'm misunderstanding the situation. rc.d/iovctl isn't actually
doing anything by default because of iovctl_files="".

There is an analogy with rc.d/sysctl which runs by default, with a
an empty sysctl.conf file. This also has no explicit enable entry in
rc.conf. 

___
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: Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Olli Hauer]

___
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: Oversight in /etc/defaults/rc.conf

[Glen Barber]

On Tue, Jul 12, 2016 at 03:10:43PM +0100, Matthew Seaman wrote:
> On 07/12/16 13:27, Glen Barber wrote:
> > On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> >> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> >> fine -- however I did notice that the new iovctl rc script is apparently
> >> enabled by default.  That seems like a trivial omission:
> >>
> >> Index: etc/defaults/rc.conf
> >> ===
> >> --- etc/defaults/rc.conf   (revision 302482)
> >> +++ etc/defaults/rc.conf   (working copy)
> >> @@ -695,6 +695,7 @@
> >>  rctl_enable="YES" # Load rctl(8) rules on boot
> >>  rctl_rules="/etc/rctl.conf"   # rctl(8) ruleset. See rctl.conf(5).
> >>
> >> +iovctl_enable="NO"
> >>  iovctl_files=""   # Config files for iovctl(8)
> >>
> >>  ##
> >>
> > 
> > I'm not sure I understand.  Is there a functional and/or performance
> > impact with it enabled by default?  (Note, I don't disable it in my
> > rc.conf, and there is no /dev/iov/* on my system.)
> 
> I'm not religious about it being turned off per se.  More that it should
> have a clearly defined on/off state shown in the defaults.
> 

Ah, this was my confusion.  Thank you for clarifying.

> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?
> 
> However, even if it's felt it should be enabled everywhere, then
> shouldn't /etc/defaults/rc.conf have:
> 
> iovctl_enable="YES"
> 
> instead?
> 

I'm not pro -vs- con either way.  But I think this should be resolved in
head first, and MFC'd to stable/11, as this isn't something I think
should be in the "checklist" when branching.  I think you are really
pointing out a different "bug" here.

Glen



signature.asc
Description: PGP signature

Re: Oversight in /etc/defaults/rc.conf

[Matthew Seaman]

On 07/12/16 13:27, Glen Barber wrote:
> On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
>> I just upgraded my main machine to 11-STABLE.  Things are mostly working
>> fine -- however I did notice that the new iovctl rc script is apparently
>> enabled by default.  That seems like a trivial omission:
>>
>> Index: etc/defaults/rc.conf
>> ===
>> --- etc/defaults/rc.conf (revision 302482)
>> +++ etc/defaults/rc.conf (working copy)
>> @@ -695,6 +695,7 @@
>>  rctl_enable="YES"   # Load rctl(8) rules on boot
>>  rctl_rules="/etc/rctl.conf" # rctl(8) ruleset. See rctl.conf(5).
>>
>> +iovctl_enable="NO"
>>  iovctl_files="" # Config files for iovctl(8)
>>
>>  ##
>>
> 
> I'm not sure I understand.  Is there a functional and/or performance
> impact with it enabled by default?  (Note, I don't disable it in my
> rc.conf, and there is no /dev/iov/* on my system.)

I'm not religious about it being turned off per se.  More that it should
have a clearly defined on/off state shown in the defaults.

I went for 'off' following the general principle that rc.conf items
should mostly be off by default and require specific action to enable.
Yes, there are exceptions to this rule, but I see no particular reason
that iovctl should be one.  What's the advantage to turning it on by
default on every FreeBSD installation?

However, even if it's felt it should be enabled everywhere, then
shouldn't /etc/defaults/rc.conf have:

iovctl_enable="YES"

instead?

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: Oversight in /etc/defaults/rc.conf

[Allan Jude]

On 2016-07-12 08:27, Glen Barber wrote:
> On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
>> I just upgraded my main machine to 11-STABLE.  Things are mostly working
>> fine -- however I did notice that the new iovctl rc script is apparently
>> enabled by default.  That seems like a trivial omission:
>>
>> Index: etc/defaults/rc.conf
>> ===
>> --- etc/defaults/rc.conf (revision 302482)
>> +++ etc/defaults/rc.conf (working copy)
>> @@ -695,6 +695,7 @@
>>  rctl_enable="YES"   # Load rctl(8) rules on boot
>>  rctl_rules="/etc/rctl.conf" # rctl(8) ruleset. See rctl.conf(5).
>>
>> +iovctl_enable="NO"
>>  iovctl_files="" # Config files for iovctl(8)
>>
>>  ##
>>
> 
> I'm not sure I understand.  Is there a functional and/or performance
> impact with it enabled by default?  (Note, I don't disable it in my
> rc.conf, and there is no /dev/iov/* on my system.)
> 
> Glen
> 

If the service should be on by default, then it should have
iovctl_enable="YES" in etc/defaults/rc.conf

One way or the other, a default should be set.

-- 
Allan Jude
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Miroslav Lachman]

Paweł Tyll wrote on 07/12/2016 01:22:


Those 3 things should shave off about 130MB of the 173MB needed to fit
on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
CD-R? :)


It is not only about the target media size. The size matters when you 
need to boot some recovery media from you desktop on remote server via KVM.


And there is one thing I don't understand - why is the bootonly so 
large? I remember days when this fits to 50MB and now it is almost 235MB 
which renders it almost useless. For recoveries and remote installs I 
always use mfsbsd images (about 45MB).


Miroslav Lachman
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Nathan Whitehorn]

On 07/11/16 23:39, Shane Ambler wrote:

On 12/07/2016 06:54, Conrad Meyer wrote:

DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
it's time to move on from CD.


+1 on dropping CD images. I haven't burnt a CD in over 10 years and I
don't believe I have seen a CD only drive in that time. Even with a CD
size image I have burnt them to DVD, I first started this because
transfer speeds of DVD's are faster and nowadays it costs almost the
same to burn a DVD. So I see zero benefit to using CD's and that's
before thinking of reusable USB devices.

I do think there is a benefit to keeping the small boot only image
available that can be used to start/recover a machine that can then
download any data to be installed.



But some people clearly do want that, and this is trivially fixable by 
dropping the toolchain from disc1 and leaving it on the DVD image. So 
let's do that.

-Nathan
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Kurt Jaeger]

Hi!

> On 12/07/2016 06:54, Conrad Meyer wrote:
> > DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
> > it's time to move on from CD.
> 
> +1 on dropping CD images.

CD-ROMs are read-only and pretty much secure, USB flash can be used to
attack systems.

Just sayin' 8-}

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Shane Ambler]

On 12/07/2016 06:54, Conrad Meyer wrote:

DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
it's time to move on from CD.


+1 on dropping CD images. I haven't burnt a CD in over 10 years and I
don't believe I have seen a CD only drive in that time. Even with a CD
size image I have burnt them to DVD, I first started this because
transfer speeds of DVD's are faster and nowadays it costs almost the
same to burn a DVD. So I see zero benefit to using CD's and that's
before thinking of reusable USB devices.

I do think there is a benefit to keeping the small boot only image
available that can be used to start/recover a machine that can then
download any data to be installed.

--
FreeBSD - the place to B...Storing Data

Shane Ambler

___
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"

Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #135

[jenkins-admin]

See 

___
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: GOST in OPENSSL_BASE

[Daniel Kalchev]

> On 12.07.2016 г., at 13:26, Franco Fichtner  wrote:
> 
> 
>> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev  wrote:
>> 
>> It is trivial to play MTIM with this protocol and in fact, there are 
>> commercially available “solutions” for “securing one’s corporate network” 
>> that doe exactly that. Some believe this is with the knowledge and approval 
>> of the corporation, but who is to say what the black box actually does and 
>> whose interests it serves?
> 
> It's also trivial to ignore that pinning certificates and using client
> certificates can actually help a great deal to prevent all of what you
> just said.  ;)

I don’t know many users who even know that they can do this —  much less 
actually using it. Pinning the browser vendor’s certificates does not protect 
you from being spied while visiting someone else’s site. This is also 
non-trivial to support.
In the early days of DANE, Google even had a version of Chrome that supported 
DANE, just to kill it a bit later: 
https://www.ietf.org/mail-archive/web/dane/current/msg06980.html

> 
> The bottom line is not having GOST support readily available could alienate
> a whole lot of businesses.  Not wanting those downstream use cases will make
> those shift elsewhere and the decision will be seen as an overly political
> move that in no possible way reflects the motivation of community growth.


Exactly — especially as long as there is no demonstrable proof that GOST is 
actually broken.

Daniel
___
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: Oversight in /etc/defaults/rc.conf

[Glen Barber]

On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> fine -- however I did notice that the new iovctl rc script is apparently
> enabled by default.  That seems like a trivial omission:
> 
> Index: etc/defaults/rc.conf
> ===
> --- etc/defaults/rc.conf  (revision 302482)
> +++ etc/defaults/rc.conf  (working copy)
> @@ -695,6 +695,7 @@
>  rctl_enable="YES"# Load rctl(8) rules on boot
>  rctl_rules="/etc/rctl.conf"  # rctl(8) ruleset. See rctl.conf(5).
> 
> +iovctl_enable="NO"
>  iovctl_files=""  # Config files for iovctl(8)
> 
>  ##
> 

I'm not sure I understand.  Is there a functional and/or performance
impact with it enabled by default?  (Note, I don't disable it in my
rc.conf, and there is no /dev/iov/* on my system.)

Glen



signature.asc
Description: PGP signature

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Paweł Tyll]

Hello Glen,

> This was actually a known "going to be problem" thing for 11.0.  I'm
> looking into how to fix this for 11.0-RELEASE, but right now, there is
> not much more we can exclude from it. :(
While  the  fact  that  .xz  version  is  roughly 500MB is quite solid
evidence  that  one  can  fit under 700MB with effort, I'm not sure if
this  is  worthwhile. As mentioned earlier, it's 2016, and pretty much
everything  can  be  booted from USB stick for a decade or so, and VMs
usually  emulate DVD drives anyway, which don't care whether the image
is 600MB, 777MB or 3GB.

/usr/bin/clang can be compressed down from 49MB to 14MB by some binary
packer,  if  feasible.  There  are  some  other binaries, not as large
tough.
/boot/kernel/*  -  103MB  -> 38MB - but is there any infrastructure to
load compressed kernel modules, and kernel images?
ports.txz  can  be easily fetched from the net and are useless without
network connection anyway (right?) - saving of another 34MB.

Those 3 things should shave off about 130MB of the 173MB needed to fit
on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
CD-R? :)

And what of FreeBSD 12.0-RELEASE?

Kind regards.

___
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"

[panic] ng_uncallout with NULL callout argument

[Michael Zhilin]

Hi,
I've switched from 10 to head recently. Most of functionalities works
fine except few panics.
The most frequent panic happens when I unplug ethernet cable with
active PPTP VPN connection.

uname -a:
FreeBSD gidrarium 12.0-CURRENT FreeBSD 12.0-CURRENT #1: Sat Jul  9
17:28:38 MSK 2016
jenkins@gidrarium:/builds/FreeBSD-src-head/obj/builds/FreeBSD-src-head/sys/GENERIC
 amd64

Test case:
 - use wired ethernet connection
 - establish PPTP connection using mpd5
 - unplug ethernet cable (=> panic)

db> bt
Tracing pid 902 tid 100675 td 0xf800169a1000
ng_uncallout() at ng_uncallout+0x3d/frame 0xfe04530b3580
ng_pptpgre_disconnect() at ng_pptpgre_disconnect+0xbb/frame 0xf*
ng_destroy_hook() at ng_destroy_hook+0xlfe/frame 8xfe84538b35d8
ng_ranode() at ng_ranode+0x75/frame 0xfe04538b3618
ng_apply_item() at ng_apply_itea+0x4ca/frame 0xfeB4538b36a8
ng_snd_item() at ng_snd_itea+0x3a9/frame 0xfeB4538b36e0
ngc_send() at ngc_send+0x21b/frame 0xfe04530b3790
sosend_generic() at sosend_generic+0x436/frame 0xfe04538b3850
kern_sendit() at kern_sendit+0x21b/frame Bxfe04538b390B
sendit() at sendit+0x19f/frame 0xfeB4530b3950
sys_sendto() at sys_sendto+0x4d/frame 0xfe04530b39a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe04530b3ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfeB4530b3abB
--- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80253906a, rsp -
0x7fffdfffd72B, rbp - 0x7fffdfffd770

Panic happens due to missing check if item (c->c_arg) is NULL in ng_uncallout:

item = c->c_arg;
/* Do an extra check */
if ((rval > 0) && (c->c_func == _callout_trampoline) &&
(NGI_NODE(item) == node)) { /*  NGI_NODE dereferences item,
but it may be NULL */

I suppose that actual root cause may be in upper stack (PPTP?).

Link to bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211031

Best regards,

  Michael
___
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"

Jenkins build is back to normal : FreeBSD_HEAD #418

[jenkins-admin]

See 

___
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: GOST in OPENSSL_BASE

[Andrey Chernov]

On 12.07.2016 12:59, Daniel Kalchev wrote:
> The standard HTTPS implementation is already sufficiently broken, with the 
> door wide open by the concept of “multiple CAs”. The protocol design is 
> flawed, as any CA can issue certificate for any site. Applications are 
> required to trust that certificates, as long as they trust the CA that issued 
> them.
> 
> It is trivial to play MTIM with this protocol and in fact, there are 
> commercially available “solutions” for “securing one’s corporate network” 
> that doe exactly that. Some believe this is with the knowledge and approval 
> of the corporation, but who is to say what the black box actually does and 
> whose interests it serves?
> 
> There is of course an update to the protocol, DANE, that just shuts this door 
> off. But… it faces heavy resistance, as it’s acceptance would mean the end of 
> the lucrative CA business and the ability to intercept “secure” HTTPS 
> communication. Those relying on the HPPTS flaws will never let it become wide 
> spread.
> 
> In summary — anyone can sniff HTTPS traffic. No need for any cipher backdoors 
> here. Nor any need for GOST to be involved.

You forget to mention that CA must already be in the trusted root list
to allow it happens.





signature.asc
Description: OpenPGP digital signature

Re: GOST in OPENSSL_BASE

[Franco Fichtner]

> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev  wrote:
> 
> It is trivial to play MTIM with this protocol and in fact, there are 
> commercially available “solutions” for “securing one’s corporate network” 
> that doe exactly that. Some believe this is with the knowledge and approval 
> of the corporation, but who is to say what the black box actually does and 
> whose interests it serves?

It's also trivial to ignore that pinning certificates and using client
certificates can actually help a great deal to prevent all of what you
just said.  ;)

The bottom line is not having GOST support readily available could alienate
a whole lot of businesses.  Not wanting those downstream use cases will make
those shift elsewhere and the decision will be seen as an overly political
move that in no possible way reflects the motivation of community growth.


Cheers,
Franco
___
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: GOST in OPENSSL_BASE

[Franco Fichtner]

> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev  wrote:
> 
> It is trivial to play MTIM with this protocol and in fact, there are 
> commercially available “solutions” for “securing one’s corporate network” 
> that doe exactly that. Some believe this is with the knowledge and approval 
> of the corporation, but who is to say what the black box actually does and 
> whose interests it serves?

It's also trivial to ignore that pinning certificates and using client
certificates can actually help a great deal to prevent all of what you
just said.  ;)

The bottom line is not having GOST support readily available could alienate
a whole lot of businesses.  Not wanting those downstream use cases will make
those shift elsewhere and the decision will be seen as an overly political
move that in no possible way reflects the motivation of community growth.


Cheers,
Franco
___
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"

FreeBSD_HEAD_i386 - Build #3564 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #3564 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3564/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3564/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3564/console

Change summaries:

302638 by sephe:
hyperv/vmbus: Destroy channel list lock upon attach failure and detach.

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D7003

302637 by sephe:
hyperv/vmbus: Remove needed bits

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D7002

302636 by sephe:
hyperv/vmbus: Move channel map to vmbus_softc

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6982

302635 by royger:
xen: automatically disable MSI-X interrupt migration

If the hypervisor version is smaller than 4.6.0. Xen commits 74fd00 and
70a3cb are required on the hypervisor side for this to be fixed, and those
are only included in 4.6.0, so stay on the safe side and disable MSI-X
interrupt migration on anything older than 4.6.0.

It should not cause major performance degradation unless a lot of MSI-X
interrupts are allocated.

Sponsored by:   Citrix Systems R
MFC after:  3 days
Reviewed by:jhb
Differential revision:  https://reviews.freebsd.org/D7148

302634 by sephe:
hyperv/vmbus: Fix sub-channel re-open support.

For multi-channel devices, once the primary channel is closed,
a set of 'rescind' messages for sub-channels will be delivered
by Hypervisor.  Sub-channel MUST be freed according to these
'rescind' messages; directly re-openning sub-channels in the
same fashion as the primary channel's re-opening does NOT work
at all.

After the primary channel is re-opened, requested # of sub-
channels will be delivered though 'channel offer' messages, and
this set of newly offered channels can be opened along side with
the primary channel.

This unbreaks the MTU setting for hn(4), which requires re-
openning all existsing channels upon MTU change.

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6978

302633 by sephe:
hyperv/vmbus: Free sysctl properly upon channel close.

Prepare for sub-channel re-open.

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6977

302632 by sephe:
hyperv/vmbus: More verbose for GPADL_connect/chan_{rescind,offer}

Reviewed by:Dexuan Cui , Hongjiang Zhang 
MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6976

302631 by sephe:
hyperv/vmbus: Move channel list to vmbus_softc

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6956

302630 by sephe:
hyperv/vmbus: Move GPADL index into vmbus_softc

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6954

302629 by sephe:
hyperv/vmbus: Rework vmbus version accessing.

Instead of global variable, vmbus version is accessed through
a vmbus DEVMETHOD now.

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6953

302628 by ache:
Bump __FreeBSD_version after removing collation from [a-z]-type ranges.

302626 by dchagin:
Fix pc98 LINT build.

MFC after:  4 days

302624 by trasz:
Add some .Xrs to getloginclass(2).

MFC after:  1 month

302623 by sephe:
hyperv/vmbus: Minor renaming

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6919

302622 by sephe:
ntb: Fix LINT

Sponsored by:   Microsoft OSTC

302621 by sephe:
hyperv/vmbus: Don't be oversmart in default cpu selection.

Pin the channel to cpu0 by default.  Drivers having special channel-cpu
mapping requirement should call vmbus_channel_cpu_{set,rr}() themselves.

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6918

302620 by sephe:
hyperv: Nuke unused stuffs

MFC after:  1 week
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6917

___
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: GOST in OPENSSL_BASE

[Daniel Kalchev]

> On 12.07.2016 г., at 12:12, Matthew Seaman  wrote:
> 
> I'm also curious as to how far these regulations are supposed to extend.
> Presumably traffic which is merely transiting Russian territory isn't
> covered, at least in a practical sense.  How about people from Russia
> accessing foreign websites?  I can't see any of the big Internet players
> implementing GOST in any locations outside Russia any time soon.
> Neither would I as a non-Russian have GOST capabilities client-side, so
> what happens if I go and look at say a YandX website over HTTPS?  Putin
> and his advisors aren't stupid, and they'd already have considered all
> this; plus, as you say, the timetable is clearly impossible; so there
> must be something else going on here.

The standard HTTPS implementation is already sufficiently broken, with the door 
wide open by the concept of “multiple CAs”. The protocol design is flawed, as 
any CA can issue certificate for any site. Applications are required to trust 
that certificates, as long as they trust the CA that issued them.

It is trivial to play MTIM with this protocol and in fact, there are 
commercially available “solutions” for “securing one’s corporate network” that 
doe exactly that. Some believe this is with the knowledge and approval of the 
corporation, but who is to say what the black box actually does and whose 
interests it serves?

There is of course an update to the protocol, DANE, that just shuts this door 
off. But… it faces heavy resistance, as it’s acceptance would mean the end of 
the lucrative CA business and the ability to intercept “secure” HTTPS 
communication. Those relying on the HPPTS flaws will never let it become wide 
spread.

In summary — anyone can sniff HTTPS traffic. No need for any cipher backdoors 
here. Nor any need for GOST to be involved.

> 
> Of course, now there's fairly good evidence that there's some sort of
> backdoor in the GOST ciphers, all bets are off on how long it will be
> until they get broken in a very public manner.
> 

One can say the same for any other crypto. Plus, for some ciphers there is 
already evidence.. yet they are still in use.
But, a good show is always worth it. Let’s watch for those heroes. :)

Daniel


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ronald Klop]

On Mon, 11 Jul 2016 23:24:10 +0200, Conrad Meyer  wrote:


DVD-R dates to 1997; cheap USB flash devices are now pervasive.  Maybe
it's time to move on from CD.


Becoming anecdotal now, but my fairly old computer has a (BIOS) bug which  
brakes booting from USB devices. It hangs when it boots with a USB stick  
in it.
With the bootonly ISO I upgraded it from 9.3-PRERELEASE to 11-BETA1. By  
just copying /boot/kernel from the CD to the harddisk. :-) I know I have  
to do more for a proper upgrade, but the ZFS version on disk was to new  
for the 9.3 kernel, by a human mistake. LOL


Regards,
Ronald.





Best,
Conrad

On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop   
wrote:

Hi,

Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on
Windows 10. It complained that the ISO is too big for my 700 MB CD-r.

The bootonly iso (281MB) burns and runs ok.

Regards,
Ronald.
___
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"

___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ronald Klop]

On Mon, 11 Jul 2016 23:32:34 +0200, Alan Somers   
wrote:


On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop   
wrote:

Hi,

Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on
Windows 10. It complained that the ISO is too big for my 700 MB CD-r.

The bootonly iso (281MB) burns and runs ok.

Regards,
Ronald.


Please open a PR.  Those images should be able to fit on a CD.


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211029

Cheers
___
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: panic: bogus refcnt 0 on lle 0xfffff80121a13a00

[Peter Holm]

On Tue, Jul 12, 2016 at 10:55:31AM +0200, Hans Petter Selasky wrote:
> On 07/12/16 10:37, Peter Holm wrote:
> > Exiting from single-user mode triggers this:
> >
> > ifa_maintain_loopback_route: deletion failed for interface igb0: 3
> > panic: bogus refcnt 0 on lle 0xf80121a13a00
> > cpuid = 9
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > 0xfe1048c63470
> > vpanic() at vpanic+0x182/frame 0xfe1048c634f0
> > kassert_panic() at kassert_panic+0x126/frame 0xfe1048c63560
> > llentry_free() at llentry_free+0x136/frame 0xfe1048c63590
> > in_lltable_free_entry() at in_lltable_free_entry+0xb0/frame 
> > 0xfe1048c635c0
> > htable_prefix_free() at htable_prefix_free+0xce/frame 0xfe1048c63620
> > lltable_prefix_free() at lltable_prefix_free+0x5d/frame 0xfe1048c63660
> > in_scrubprefix() at in_scrubprefix+0x290/frame 0xfe1048c63700
> > in_difaddr_ioctl() at in_difaddr_ioctl+0x285/frame 0xfe1048c63750
> > in_control() at in_control+0x96/frame 0xfe1048c637d0
> > ifioctl() at ifioctl+0xda1/frame 0xfe1048c63860
> > kern_ioctl() at kern_ioctl+0x246/frame 0xfe1048c638c0
> > sys_ioctl() at sys_ioctl+0x171/frame 0xfe1048c639a0
> > amd64_syscall() at amd64_syscall+0x2f6/frame 0xfe1048c63ab0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1048c63ab0
> > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fd2eba, rsp = 
> > 0x7fffe468, rbp = 0x7fffe4b0 -
> >
> > Details @ https://people.freebsd.org/~pho/stress/log/bogus_refcnt.txt
> >
> 
> FYI:
> https://reviews.freebsd.org/D4605
> 
> Might be related.
> 
> --HPS

No difference with this patch (- netinet6/nd6.c).

BTW The problem is really easy to reproduce: init 1 followed by
"exit" in the single-user shell.

-- 
Peter
___
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: GOST in OPENSSL_BASE

[Andrey Chernov]

On 12.07.2016 12:16, Andrey Chernov wrote:
> On 12.07.2016 8:48, Kevin Oberman wrote:
>> >> May be need file PR for dns/bind910?
>> >>
>> >> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
>> >> .include http://bsd.port.pre.mk>>
>> >>
>> >> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
>> ${SSL_DEFAULT} == base
>> >> BROKEN= OpenSSL from the base system does not support GOST, add \
>> >> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and
>> rebuild everything \
>> >> that needs SSL.
>> >> .endif
>> >>
>> >
>> > I dislike idea to use GOST in the bind, it is unneeded there, DNSSEC
>> > don't use GOST, so I vote for removing GOST option from there.
>> >
>>
>> I need to note that RFC exists, proposing GOST (old version) for DNSSEC:
>> https://tools.ietf.org/html/rfc5933
>> but nobody really use it.
>>
>> In case people are not aware of it, Russian law now requires ALL
>> encrypted traffic must either be accessible by the FSB or that the
>> private keys must be available to the FSB. 
> 
> It is not quite so. All traffic must be available for 6 months and they
> express intention to ask big companies for their private keys, but later
> is not required by the law (not yet...)
> 
>> I have always assumed that
>> GOST has a hidden vulnerability/backdoor that the FSB is already using,
> 
> I already answer this question elsewhere in this thread with the reference.
> 
>> but this makes it mandatory. Putin gave the FSB 2 weeks to implement the
>> law, which is clearly impossible, but I suspect that there will be a
>> huge effort to pick all low-hanging fruit. As a result, I suspect no one
>> outside of Russia will touch GOST. (Not that they do now, either.) I'd
>> hate to see its support required for any protocol except in Russia as
>> someone will be silly enough to use it.
> 
> I already explain required GOST usage pattern in this thread.
> 

Ah, I see, freebsd-current list was excluded by someone, so I repeat
what I wrote:

Official documents workflow here require using GOST signatures for
authenticity and consistency verification, they are needed or, in some
cases, required for both people and companies. Since it is official in
any case, there is no harm to have FSB backdoor in the algo, unless some
hacker will find it. Just don't use GOST for something else to stay on
safe side.

BTW, latest GOST based on elliptic curves, so from math point of view
probability of having backdoor here is minimal. I don't examine its
implementation.
See
https://ru.wikipedia.org/wiki/%D0%93%D0%9E%D0%A1%D0%A2_%D0%A0_34.10-2012
You can consider GOST goals are the same as FIPS ones with the reason to
have things "domestically produced".

___
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: GOST in OPENSSL_BASE

[Andrey Chernov]

On 12.07.2016 8:48, Kevin Oberman wrote:
> >> May be need file PR for dns/bind910?
> >>
> >> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> >> .include http://bsd.port.pre.mk>>
> >>
> >> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
> ${SSL_DEFAULT} == base
> >> BROKEN= OpenSSL from the base system does not support GOST, add \
> >> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and
> rebuild everything \
> >> that needs SSL.
> >> .endif
> >>
> >
> > I dislike idea to use GOST in the bind, it is unneeded there, DNSSEC
> > don't use GOST, so I vote for removing GOST option from there.
> >
> 
> I need to note that RFC exists, proposing GOST (old version) for DNSSEC:
> https://tools.ietf.org/html/rfc5933
> but nobody really use it.
> 
> In case people are not aware of it, Russian law now requires ALL
> encrypted traffic must either be accessible by the FSB or that the
> private keys must be available to the FSB. 

It is not quite so. All traffic must be available for 6 months and they
express intention to ask big companies for their private keys, but later
is not required by the law (not yet...)

> I have always assumed that
> GOST has a hidden vulnerability/backdoor that the FSB is already using,

I already answer this question elsewhere in this thread with the reference.

> but this makes it mandatory. Putin gave the FSB 2 weeks to implement the
> law, which is clearly impossible, but I suspect that there will be a
> huge effort to pick all low-hanging fruit. As a result, I suspect no one
> outside of Russia will touch GOST. (Not that they do now, either.) I'd
> hate to see its support required for any protocol except in Russia as
> someone will be silly enough to use it.

I already explain required GOST usage pattern in this thread.

___
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: GOST in OPENSSL_BASE

[Matthew Seaman]

On 07/12/16 06:48, Kevin Oberman wrote:
> In case people are not aware of it, Russian law now requires ALL encrypted
> traffic must either be accessible by the FSB or that the private keys must
> be available to the FSB. I have always assumed that GOST has a hidden
> vulnerability/backdoor that the FSB is already using, but this makes it
> mandatory. Putin gave the FSB 2 weeks to implement the law, which is
> clearly impossible, but I suspect that there will be a huge effort to pick
> all low-hanging fruit. As a result, I suspect no one outside of Russia will
> touch GOST. (Not that they do now, either.) I'd hate to see its support
> required for any protocol except in Russia as someone will be silly enough
> to use it.

Agreed that it should be possible to use GOST crypto readily on FreeBSD,
but I dislike the idea of shipping with 'known vulnerable' ciphers
enabled by default.  It should take a positive act to enable them, given
the circumstances.  Whether that should entail installing something from
ports, or recompiling the system with specific settings in src.conf or
it could just be down to tweaking a config file somewhere I wouldn't
care to venture an opinion though.

I'm also curious as to how far these regulations are supposed to extend.
 Presumably traffic which is merely transiting Russian territory isn't
covered, at least in a practical sense.  How about people from Russia
accessing foreign websites?  I can't see any of the big Internet players
implementing GOST in any locations outside Russia any time soon.
Neither would I as a non-Russian have GOST capabilities client-side, so
what happens if I go and look at say a YandX website over HTTPS?  Putin
and his advisors aren't stupid, and they'd already have considered all
this; plus, as you say, the timetable is clearly impossible; so there
must be something else going on here.

Of course, now there's fairly good evidence that there's some sort of
backdoor in the GOST ciphers, all bets are off on how long it will be
until they get broken in a very public manner.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: panic: bogus refcnt 0 on lle 0xfffff80121a13a00

[Michael Zhilin]

Hi,

I have same issue everyday on my laptop. It happens randomly and I suppose
due to network issues.
I want to test D4507. I've tried to apply patch, it's successful except one
chunk:

|Index: sys/netinet6/nd6.c
|===
|--- sys/netinet6/nd6.c
|+++ sys/netinet6/nd6.c
--
Patching file sys/netinet6/nd6.c using Plan A...
Hunk #1 succeeded at 520 (offset 31 lines).
Hunk #2 failed at 739.
Hunk #3 succeeded at 1357 with fuzz 1 (offset 19 lines).
Hunk #4 succeeded at 1446 with fuzz 2 (offset 32 lines).
1 out of 4 hunks failed--saving rejects to sys/netinet6/nd6.c.rej
done

Hans,
Could you please check patch?

Thanks!


On Tue, Jul 12, 2016 at 11:55 AM, Hans Petter Selasky 
wrote:

> On 07/12/16 10:37, Peter Holm wrote:
>
>> Exiting from single-user mode triggers this:
>>
>> ifa_maintain_loopback_route: deletion failed for interface igb0: 3
>> panic: bogus refcnt 0 on lle 0xf80121a13a00
>> cpuid = 9
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe1048c63470
>> vpanic() at vpanic+0x182/frame 0xfe1048c634f0
>> kassert_panic() at kassert_panic+0x126/frame 0xfe1048c63560
>> llentry_free() at llentry_free+0x136/frame 0xfe1048c63590
>> in_lltable_free_entry() at in_lltable_free_entry+0xb0/frame
>> 0xfe1048c635c0
>> htable_prefix_free() at htable_prefix_free+0xce/frame 0xfe1048c63620
>> lltable_prefix_free() at lltable_prefix_free+0x5d/frame 0xfe1048c63660
>> in_scrubprefix() at in_scrubprefix+0x290/frame 0xfe1048c63700
>> in_difaddr_ioctl() at in_difaddr_ioctl+0x285/frame 0xfe1048c63750
>> in_control() at in_control+0x96/frame 0xfe1048c637d0
>> ifioctl() at ifioctl+0xda1/frame 0xfe1048c63860
>> kern_ioctl() at kern_ioctl+0x246/frame 0xfe1048c638c0
>> sys_ioctl() at sys_ioctl+0x171/frame 0xfe1048c639a0
>> amd64_syscall() at amd64_syscall+0x2f6/frame 0xfe1048c63ab0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1048c63ab0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fd2eba, rsp =
>> 0x7fffe468, rbp = 0x7fffe4b0 -
>>
>> Details @ https://people.freebsd.org/~pho/stress/log/bogus_refcnt.txt
>>
>>
> FYI:
> https://reviews.freebsd.org/D4605
>
> Might be related.
>
> --HPS
>
> ___
> 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"
>
___
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"

Build failed in Jenkins: FreeBSD_HEAD_sparc64 #134

[jenkins-admin]

See 

--
Started by upstream project "FreeBSD_HEAD" build number 416
originally caused by:
 Started by an SCM change
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/freebsd/freebsd-ci.git # 
 > timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/freebsd/freebsd-ci.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 2d6143c340cba749b7aac1b27f26bd762555f9a0 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 2d6143c340cba749b7aac1b27f26bd762555f9a0
 > git rev-list 2d6143c340cba749b7aac1b27f26bd762555f9a0 # timeout=10
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on jenkins10a.freebsd.org
Running on jenkins10a.freebsd.org in /builds/workspace/FreeBSD_HEAD_sparc64
[Pipeline] {
[Pipeline] pwd
[Pipeline] stage (Checkout scripts)
Entering stage Checkout scripts
Proceeding
[Pipeline] dir
Running in /builds/workspace/FreeBSD_HEAD_sparc64/freebsd-ci
[Pipeline] {
[Pipeline] git
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/freebsd/freebsd-ci.git # 
 > timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/freebsd/freebsd-ci.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/freebsd/freebsd-ci.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:810)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1066)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1097)
at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83)
at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73)
at 
org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:49)
at hudson.security.ACL.impersonate(ACL.java:213)
at 
org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:47)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true 
fetch --tags --progress https://github.com/freebsd/freebsd-ci.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/freebsd/freebsd-ci.git/': 
Could not resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1719)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1463)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to jenkins10a.freebsd.org(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at 

Re: panic: bogus refcnt 0 on lle 0xfffff80121a13a00

[Hans Petter Selasky]

On 07/12/16 10:37, Peter Holm wrote:

Exiting from single-user mode triggers this:

ifa_maintain_loopback_route: deletion failed for interface igb0: 3
panic: bogus refcnt 0 on lle 0xf80121a13a00
cpuid = 9
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1048c63470
vpanic() at vpanic+0x182/frame 0xfe1048c634f0
kassert_panic() at kassert_panic+0x126/frame 0xfe1048c63560
llentry_free() at llentry_free+0x136/frame 0xfe1048c63590
in_lltable_free_entry() at in_lltable_free_entry+0xb0/frame 0xfe1048c635c0
htable_prefix_free() at htable_prefix_free+0xce/frame 0xfe1048c63620
lltable_prefix_free() at lltable_prefix_free+0x5d/frame 0xfe1048c63660
in_scrubprefix() at in_scrubprefix+0x290/frame 0xfe1048c63700
in_difaddr_ioctl() at in_difaddr_ioctl+0x285/frame 0xfe1048c63750
in_control() at in_control+0x96/frame 0xfe1048c637d0
ifioctl() at ifioctl+0xda1/frame 0xfe1048c63860
kern_ioctl() at kern_ioctl+0x246/frame 0xfe1048c638c0
sys_ioctl() at sys_ioctl+0x171/frame 0xfe1048c639a0
amd64_syscall() at amd64_syscall+0x2f6/frame 0xfe1048c63ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1048c63ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fd2eba, rsp = 
0x7fffe468, rbp = 0x7fffe4b0 -

Details @ https://people.freebsd.org/~pho/stress/log/bogus_refcnt.txt



FYI:
https://reviews.freebsd.org/D4605

Might be related.

--HPS
___
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: GOST in OPENSSL_BASE

[Kevin Oberman]

On Mon, Jul 11, 2016 at 3:51 PM, Andrey Chernov  wrote:

> On 12.07.2016 1:44, Andrey Chernov wrote:
> > On 11.07.2016 21:41, Slawa Olhovchenkov wrote:
> >> On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
> >>
> >>> On 07/10/16 10:10 AM, Andrey Chernov wrote:
>  On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> > I am surprised lack of support GOST in openssl-base.
> > Can be this enabled before 11.0 released?
> 
>  AFAIK openssl maintainers says something like they can't support this
>  code and it will become rotten shortly with new changes, so they drop
> it.
> >>>
> >>> [OpenSSL-maintainer-for-the-base hat on]
> >>>
> >>> GOST is supported on FreeBSD 10.x and 11.x.  We will not drop it on
> >>> these branches unless secteam explicitly ask us to do so.  However, we
> >>> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
> >>>
> >>> [OpenSSL-maintainer-for-the-base hat off]
> >>>
> >>> Jung-uk Kim
> >>>
> >>
> >> Thanks!
> >>
> >> May be need file PR for dns/bind910?
> >>
> >> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> >> .include 
> >>
> >> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
> ${SSL_DEFAULT} == base
> >> BROKEN= OpenSSL from the base system does not support GOST, add \
> >> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and
> rebuild everything \
> >> that needs SSL.
> >> .endif
> >>
> >
> > I dislike idea to use GOST in the bind, it is unneeded there, DNSSEC
> > don't use GOST, so I vote for removing GOST option from there.
> >
>
> I need to note that RFC exists, proposing GOST (old version) for DNSSEC:
> https://tools.ietf.org/html/rfc5933
> but nobody really use it.


In case people are not aware of it, Russian law now requires ALL encrypted
traffic must either be accessible by the FSB or that the private keys must
be available to the FSB. I have always assumed that GOST has a hidden
vulnerability/backdoor that the FSB is already using, but this makes it
mandatory. Putin gave the FSB 2 weeks to implement the law, which is
clearly impossible, but I suspect that there will be a huge effort to pick
all low-hanging fruit. As a result, I suspect no one outside of Russia will
touch GOST. (Not that they do now, either.) I'd hate to see its support
required for any protocol except in Russia as someone will be silly enough
to use it.

(It's not possible because it requires the 6 month storage of all Internet
data and voice communications which will require the immediate installation
of massive amounts of storage, not to mention the floor space, cooling, and
power to support those disks.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

Oversight in /etc/defaults/rc.conf

[Matthew Seaman]

I just upgraded my main machine to 11-STABLE.  Things are mostly working
fine -- however I did notice that the new iovctl rc script is apparently
enabled by default.  That seems like a trivial omission:

Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf(revision 302482)
+++ etc/defaults/rc.conf(working copy)
@@ -695,6 +695,7 @@
 rctl_enable="YES"  # Load rctl(8) rules on boot
 rctl_rules="/etc/rctl.conf"# rctl(8) ruleset. See rctl.conf(5).

+iovctl_enable="NO"
 iovctl_files=""# Config files for iovctl(8)

 ##

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

panic: bogus refcnt 0 on lle 0xfffff80121a13a00

[Peter Holm]

Exiting from single-user mode triggers this:

ifa_maintain_loopback_route: deletion failed for interface igb0: 3
panic: bogus refcnt 0 on lle 0xf80121a13a00
cpuid = 9
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1048c63470
vpanic() at vpanic+0x182/frame 0xfe1048c634f0
kassert_panic() at kassert_panic+0x126/frame 0xfe1048c63560
llentry_free() at llentry_free+0x136/frame 0xfe1048c63590
in_lltable_free_entry() at in_lltable_free_entry+0xb0/frame 0xfe1048c635c0
htable_prefix_free() at htable_prefix_free+0xce/frame 0xfe1048c63620
lltable_prefix_free() at lltable_prefix_free+0x5d/frame 0xfe1048c63660
in_scrubprefix() at in_scrubprefix+0x290/frame 0xfe1048c63700
in_difaddr_ioctl() at in_difaddr_ioctl+0x285/frame 0xfe1048c63750
in_control() at in_control+0x96/frame 0xfe1048c637d0
ifioctl() at ifioctl+0xda1/frame 0xfe1048c63860
kern_ioctl() at kern_ioctl+0x246/frame 0xfe1048c638c0
sys_ioctl() at sys_ioctl+0x171/frame 0xfe1048c639a0
amd64_syscall() at amd64_syscall+0x2f6/frame 0xfe1048c63ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1048c63ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fd2eba, rsp = 
0x7fffe468, rbp = 0x7fffe4b0 -

Details @ https://people.freebsd.org/~pho/stress/log/bogus_refcnt.txt

-- 
Peter
___
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: ptrace attach in multi-threaded processes

[Konstantin Belousov]

On Mon, Jul 11, 2016 at 06:19:38PM -0700, Mark Johnston wrote:
> Hi,
> 
> It seems to be possible for ptrace(PT_ATTACH) to race with the delivery
> of a signal to the same process. ptrace(PT_ATTACH) sets P_TRACED and
> sends SIGSTOP to a thread in the target process. Consider the case where
> a signal is delivered to a second thread, and both threads are executing
> ast() concurrently. The two threads will both call issignal() and from
> there call ptracestop() because P_TRACED is set, though they will be
> serialized by the proc lock. If the thread receiving SIGSTOP wins the
> race, it will suspend first and set p->p_xthread. The second thread will
> also suspend in ptracestop(), overwriting the p_xthread field set by the
> first thread. Later, ptrace(PT_DETACH) will unsuspend the threads, but
> it will set td->td_xsig only in the second thread. This means that the
> first thread will return SIGSTOP from ptracestop() and subsequently
> suspend the process, which seems rather incorrect.
Why ?  In particular, why delivering STOP after attach, in the described
situation, is perceived as incorrect ?  Parallel STOPs, one from attach,
and other from kill(2), must result in two stops.

The bit about overwriting p_xsig/p_xthread indeed initially sound worrysome,
but probably not too much.  The only consequence of reassigning p_xthread
is the selection of the 'lead' thread in sys_process.c, it seems.

> 
> The above is just a theory to explain an unexpectedly-stopped
> multi-threaded process that I've observed. Is there some mechanism I'm
> missing that prevents multiple threads from suspending in ptracestop()
> at the same time? If not, then I think that's the root of the problem,
> since p_xthread is pretty clearly not meant to be overwritten this way.
Again, why ?

Note the comment 
 * Just make wait() to work, the last stopped thread
 * will win.
which seems to point to the situation.

> Moreover, in my scenario I see a thread with TDB_XSIG set even after
> ptrace(PT_DETACH) was called (P_TRACED is cleared).
This is interesting, we indeed do not clear the flag consistently.
But again, the only consequence seems to be a possible invalid reporting
of events.
___
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"