Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Jul 2019 21:43:10 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        =?UTF-8?B?546L5piK54S2?= <msl0000023508@gmail.com>
Cc:        bugs@freebsd.org
Subject:   Re: [Bug 238837] init: Remove P_SYSTEM flag from PID 1 to allow easier debugging of init(8)
Message-ID:  <20190715205420.H1092@besplex.bde.org>
In-Reply-To: <CAPge7yeumUb6FwT9O3Cd=gqbaavCD-d2HZPua1chwjXQW_t7hA@mail.gmail.com>
References:  <bug-238837-227@https.bugs.freebsd.org/bugzilla/> <bug-238837-227-hBlTfh5AxA@https.bugs.freebsd.org/bugzilla/> <20190713190837.E899@besplex.bde.org> <CAPge7yeumUb6FwT9O3Cd=gqbaavCD-d2HZPua1chwjXQW_t7hA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Jul 2019, [UTF-8] =E7~N~K=E6~X~J=E7~D=B6 wrote:

> Thanks for share this. The followings are my suggestions.
>
>
>> But debugging also
>> requires normal signal handling, perhaps including core dumps, so
>> my replacements for the bogus pid tests may be too strong.
> I think this could be fixed by allowing default actions be taken during
> debugging of init(8), in kern/kern_sig.c:

I now prefer a more conservative change at first:
- keep P_SYSTEM for init
- check that P_SYSTEM is set for all pids <=3D 1, and remove the redundant
   pid tests in places that now check both pid <=3D 1 and P_SYSTEM
- open small holes in P_SYSTEM checks allow useful things that are believed
   to be safe.  Mainly ptrace on init.
- add P_SYSTEM checks for p_candebug() and p_cansignal()...
- open small hoes in the new P_SYSTEM checks.

In kern, p_candebug() is currently required for ktr, pget() and ptrace().
I think ktr doesn't operate on init, and we want to allow pget() and
ptrace(), except at higher securelevels.  This gets complicated.
securelevels used to be documented only in init(8), and init is still
responsible for managing them in some cases.  init can also be run in
jails, and there is a per-jail securelevel.  I don't really understand
jails, but think that we don't want to make it too easy to run ptrace
on init in jails.  Hopefully the per-jail securelevel is enough to
control this.

p_candebug() actually has always had a check that disallows tracing of
specifically initproc at securelevel > 0.  This check was not in 4.4BSD.
It was added to sys_process.c in 1997 (r25200) and had no effect there
until 2000 (r65237 (p_can* reorganization)) when it was have no effect
in kern_prot.c.  So nothing new needs to be done for securelevels provided
this code is correct.

>> Don't take default actions on system processes.
> Change to something like:
>
> /*
> * Don't take default actions on system processes.
> */
> if ((p =3D=3D initproc && !(p->p_flag & P_TRACED)) ||
>    p->p_flag & P_SYSTEM) {

This is essentially the method of opening a hole for init (we open the
hole which allows P_TRACED to be set for init elsewhere, and here we trust
P_TRACED to only be set if default signal actions are allowed).  This is
a bit too strong.  I don't want P_TRACED to allow default SIGKILL actions.
ptrace() can't control those.  It can control some other signals whose
default is to kill the process.

>> - kern_proc.c:stop_all_proc(): to disallow stopping system processes.
>>    This seems right for init, and the change breaks it.
> Add an additional check for init(8) seems needed, along with the 'P_SYSTE=
M'
> checking.

Keeping P_SYSTEM for init preserves existing behaviour here and in any othe=
r
cases that we haven't noticed.

Bruce
From owner-freebsd-bugs@freebsd.org  Mon Jul 15 13:25:56 2019
Return-Path: <owner-freebsd-bugs@freebsd.org>
Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id C77F6B9D7A
 for <freebsd-bugs@mailman.nyi.freebsd.org>;
 Mon, 15 Jul 2019 13:25:56 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org
 [IPv6:2610:1c1:1:606c::50:13])
 by mx1.freebsd.org (Postfix) with ESMTP id A9935903CA
 for <freebsd-bugs@freebsd.org>; Mon, 15 Jul 2019 13:25:56 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: by mailman.nyi.freebsd.org (Postfix)
 id A9292B9D79; Mon, 15 Jul 2019 13:25:56 +0000 (UTC)
Delivered-To: bugs@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id A8E63B9D78
 for <bugs@mailman.nyi.freebsd.org>; Mon, 15 Jul 2019 13:25:56 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org
 [IPv6:2610:1c1:1:606c::19:3])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 server-signature RSA-PSS (4096 bits)
 client-signature RSA-PSS (4096 bits) client-digest SHA256)
 (Client CN "mxrelay.nyi.freebsd.org",
 Issuer "Let's Encrypt Authority X3" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 8B69A903C9
 for <bugs@FreeBSD.org>; Mon, 15 Jul 2019 13:25:56 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
 [IPv6:2610:1c1:1:606c::50:1d])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5E7991E343
 for <bugs@FreeBSD.org>; Mon, 15 Jul 2019 13:25:56 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org ([127.0.1.5])
 by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6FDPuDm002769
 for <bugs@FreeBSD.org>; Mon, 15 Jul 2019 13:25:56 GMT
 (envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
 by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6FDPue2002768
 for bugs@FreeBSD.org; Mon, 15 Jul 2019 13:25:56 GMT
 (envelope-from bugzilla-noreply@freebsd.org)
X-Authentication-Warning: kenobi.freebsd.org: www set sender to
 bugzilla-noreply@freebsd.org using -f
From: bugzilla-noreply@freebsd.org
To: bugs@FreeBSD.org
Subject: [Bug 239224] Virtual Interface: Not Working in Netmap Mode on 11.3
 STABLE
Date: Mon, 15 Jul 2019 13:25:55 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.3-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: halfling@halfling.com.br
X-Bugzilla-Status: New
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: bugs@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform
 op_sys bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-239224-227@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-Rspamd-Queue-Id: A9935903CA
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org
X-Spamd-Result: default: False [-2.99 / 15.00];
 local_wl_from(0.00)[freebsd.org];
 NEURAL_HAM_MEDIUM(-1.00)[-1.000,0];
 NEURAL_HAM_SHORT(-0.99)[-0.990,0];
 ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US];
 NEURAL_HAM_LONG(-1.00)[-1.000,0]
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-bugs>,
 <mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs/>;
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
 <mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 13:25:56 -0000

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

            Bug ID: 239224
           Summary: Virtual Interface: Not Working in Netmap Mode on 11.3
                    STABLE
           Product: Base System
           Version: 11.3-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: halfling@halfling.com.br

Hello!

I was trying to update my servers from FreeBSD 11.2-STABLE to 11.3-STABLE a=
nd
first a tested Netmap on top of 11.3-STABLE. My application did a Kernel Pa=
nic
on my first try.

First I thought my application was wrong so I tried netmap/apps in Virtual
Interfaces like(VLAN/TAP/TUN):

pkt-gen -f rx -i vlan5 (Kernel Panic. Server reboot)
pkt-gen -f rx -i tap5 (Kernel Panic. Server reboot)
pkt-gen -f rx -i tun5 (Kernel Panic. Server reboot)

vale-ctl -h vale0:vlan5 (Kernal Panic. Server reboot)
vale-ctl -h vale0:tap5 (Kernal Panic. Server reboot)
vale-ctl -h vale0:tun5 (Kernal Panic. Server reboot)

So I tried with tcpdump:
tcpdump -eni netmap:vlan5 (Kernal Panic. Server reboot)
tcpdump -eni netmap:tap5 (Kernal Panic. Server reboot)
tcpdump -eni netmap:tun5 (Kernal Panic. Server reboot)

This tests is full working in my FreeBSD 11.2-STABLE, but is not working in
FreeBSD 11.3-STABLE

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190715205420.H1092>