svn commit: r335437 - in head: share/man/man4 sys/kern
Author: bz
Date: Wed Jun 20 08:34:29 2018
New Revision: 335437
URL: https://svnweb.freebsd.org/changeset/base/335437
Log:
Sometimes it is helpful to get the path for a vnode.
Implement a ddb function walking the namecache to do this.
Reviewed by: jhb, mjg
Inspired by: gdb macro from jhb (old version)
Sponsored by: iXsystems, Inc.
Differential Revision:https://reviews.freebsd.org/D14898
Modified:
head/share/man/man4/ddb.4
head/sys/kern/vfs_cache.c
Modified: head/share/man/man4/ddb.4
==
--- head/share/man/man4/ddb.4 Wed Jun 20 07:02:19 2018(r335436)
+++ head/share/man/man4/ddb.4 Wed Jun 20 08:34:29 2018(r335437)
@@ -60,7 +60,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd August 24, 2017
+.Dd June 20, 2018
.Dt DDB 4
.Os
.Sh NAME
@@ -1121,6 +1121,11 @@ header file.
.Pp
.It Ic show Cm vnodebufs Ar addr
Shows clean/dirty buffer lists of the vnode located at
+.Ar addr .
+.\"
+.Pp
+.It Ic show Cm vpath Ar addr
+Walk the namecache to lookup the pathname of the vnode located at
.Ar addr .
.\"
.Pp
Modified: head/sys/kern/vfs_cache.c
==
--- head/sys/kern/vfs_cache.c Wed Jun 20 07:02:19 2018(r335436)
+++ head/sys/kern/vfs_cache.c Wed Jun 20 08:34:29 2018(r335437)
@@ -37,6 +37,7 @@
#include
__FBSDID("$FreeBSD$");
+#include "opt_ddb.h"
#include "opt_ktrace.h"
#include
@@ -62,6 +63,10 @@ __FBSDID("$FreeBSD$");
#include
#endif
+#ifdef DDB
+#include
+#endif
+
#include
SDT_PROVIDER_DECLARE(vfs);
@@ -2529,3 +2534,54 @@ out:
free(fbuf, M_TEMP);
return (error);
}
+
+#ifdef DDB
+static void
+db_print_vpath(struct vnode *vp)
+{
+
+ while (vp != NULL) {
+ db_printf("%p: ", vp);
+ if (vp == rootvnode) {
+ db_printf("/");
+ vp = NULL;
+ } else {
+ if (vp->v_vflag & VV_ROOT) {
+ db_printf("");
+ vp = vp->v_mount->mnt_vnodecovered;
+ } else {
+ struct namecache *ncp;
+ char *ncn;
+ int i;
+
+ ncp = TAILQ_FIRST(&vp->v_cache_dst);
+ if (ncp != NULL) {
+ ncn = ncp->nc_name;
+ for (i = 0; i < ncp->nc_nlen; i++)
+ db_printf("%c", *ncn++);
+ vp = ncp->nc_dvp;
+ } else {
+ vp = NULL;
+ }
+ }
+ }
+ db_printf("\n");
+ }
+
+ return;
+}
+
+DB_SHOW_COMMAND(vpath, db_show_vpath)
+{
+ struct vnode *vp;
+
+ if (!have_addr) {
+ db_printf("usage: show vpath \n");
+ return;
+ }
+
+ vp = (struct vnode *)addr;
+ db_print_vpath(vp);
+}
+
+#endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > On 2018-06-17 07:32, Eugene Grosbein wrote: > > 17.06.2018 10:18, Allan Jude wrote: > > > >> Author: allanjude > >> Date: Sun Jun 17 03:18:56 2018 > >> New Revision: 335276 > >> URL: https://svnweb.freebsd.org/changeset/base/335276 > >> > >> Log: > >> gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles early > >> > >> Normally the serial console is not enabled until /boot.config is read and > >> we know how the serial console should be configured. Initialize the > >> consoles early in 'dual' mode (serial & keyboard) with a default serial > >> rate of 115200. Then serial is re-initialized once the disk is decrypted > >> and the /boot.config file can be read. > >> > >> This allows the GELIBoot passphrase to be provided via the serial > >> console. > >> > >> PR: 221526 > >> Requested by:many > >> Reviewed by: imp > >> Sponsored by:Klara Systems > >> Differential Revision: https://reviews.freebsd.org/D15862 > > > > I had several cases when booting FreeBSD/amd64 with motherboard having no > > serial ports > > hang hard early at boot unless I rebuilt boot media configuring it to NOT > > try accessing > > missing serial ports. I even could reproduce that with VirtualBox machine > > configured > > with no serial ports (not same as existing bug inactive serial port). > > > > Should there be some way to disable this serial ports configuration at > > compile time? > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > one by default, because it is safer. Then you can just use > 'gptboot-serial' if you want serial support. > > This will likely make Warner a bit sad, since we are just finally > getting around to reducing the number of different bootcode files. I think we should follow the hardware trends there and apply a policy where new features are not added to the CSM boot. All modern machines can be booted in UEFI mode, and if some modern machine cannot, then we need it fixed. We should encourage users to make new installs boot by UEFI. The feature from the commit is only relevant for machines that require CSM boot or do not have UEFI option at all, am I right ? With the policy applied, an additional CSM-boot bootblock would be not shipped. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty wrote: > Conrad Meyer wrote: > > > As a corollary to the above, the name "signature file" is used > > repeatedly in the code, which is misleading. The file contains hashes > > (digests), not signatures (MACs). The file itself is unsigned. > > Nothing about this has signatures. > I think you mean "signature". I belive the only place that says "signature file" is the veriexecctl. And that was in the original sources from NetBSD. For example, see the currentl veriexecctl in NetBSD and it still uses the terminology "signature file". http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/veriexecctl/veriexecctl.c?rev=1.40 But yes, I agree that it's the wrong term that they're using there. > NetBSD refers to the hashes as fingerprints - AFAIK that terminology is > retained. > > If the term signature is used to refer to anything other than the signed > manifests that should be fixed. > That was in the veriexec that was the basis for the MAC conversion. I know I had corrected some before, but probably missed the fact that it was used in some other places. Easy to happen when you've seen the same code for a number of years. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335438 - head/sys/dev/psci
Author: andrew Date: Wed Jun 20 10:02:50 2018 New Revision: 335438 URL: https://svnweb.freebsd.org/changeset/base/335438 Log: Fix the SMCCC signatures, they are all 32-bit calls. This fixes SMCCC version detection. Sponsored by: DARPA, AFRL Modified: head/sys/dev/psci/smccc.h Modified: head/sys/dev/psci/smccc.h == --- head/sys/dev/psci/smccc.h Wed Jun 20 08:34:29 2018(r335437) +++ head/sys/dev/psci/smccc.h Wed Jun 20 10:02:50 2018(r335438) @@ -54,11 +54,11 @@ * These are documented in the document ARM DEN 0070A. */ #defineSMCCC_VERSION \ -SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_64BIT_CALL, 0, 0) +SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_32BIT_CALL, 0, 0) #defineSMCCC_ARCH_FEATURES \ -SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_64BIT_CALL, 0, 1) +SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_32BIT_CALL, 0, 1) #defineSMCCC_ARCH_WORKAROUND_1 \ -SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_64BIT_CALL, 0, 0x8000) +SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_32BIT_CALL, 0, 0x8000) /* The return values from ARM DEN 0070A. */ #defineSMCCC_RET_SUCCESS 0 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335439 - head/sys/dev/psci
Author: andrew Date: Wed Jun 20 10:57:29 2018 New Revision: 335439 URL: https://svnweb.freebsd.org/changeset/base/335439 Log: Move the SMCCC SYSINIT later in the boot so the psci driver has attached. Sponsored by: DARPA, AFRL Modified: head/sys/dev/psci/smccc.c Modified: head/sys/dev/psci/smccc.c == --- head/sys/dev/psci/smccc.c Wed Jun 20 10:02:50 2018(r335438) +++ head/sys/dev/psci/smccc.c Wed Jun 20 10:57:29 2018(r335439) @@ -67,7 +67,7 @@ smccc_init(void *dummy) SMCCC_VERSION_MINOR(smccc_version)); } } -SYSINIT(smccc_start, SI_SUB_DRIVERS, SI_ORDER_ANY, smccc_init, NULL); +SYSINIT(smccc_start, SI_SUB_CONFIGURE, SI_ORDER_ANY, smccc_init, NULL); int32_t smccc_arch_features(uint32_t smccc_func_id) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335440 - head/sys/arm/arm
Author: andrew Date: Wed Jun 20 11:13:10 2018 New Revision: 335440 URL: https://svnweb.freebsd.org/changeset/base/335440 Log: Move the SYSINIT to allow userspace access to the ARM generic timer later in the boot. It doesn't need to be early, so move it to the SI_ORDER_ANY stage of SI_SUB_SMP. Sponsored by: DARPA, AFRL Modified: head/sys/arm/arm/generic_timer.c Modified: head/sys/arm/arm/generic_timer.c == --- head/sys/arm/arm/generic_timer.cWed Jun 20 10:57:29 2018 (r335439) +++ head/sys/arm/arm/generic_timer.cWed Jun 20 11:13:10 2018 (r335440) @@ -243,7 +243,7 @@ tmr_setup_user_access(void *arg __unused) if (arm_tmr_sc != NULL) smp_rendezvous(NULL, setup_user_access, NULL, NULL); } -SYSINIT(tmr_ua, SI_SUB_SMP, SI_ORDER_SECOND, tmr_setup_user_access, NULL); +SYSINIT(tmr_ua, SI_SUB_SMP, SI_ORDER_ANY, tmr_setup_user_access, NULL); static unsigned arm_tmr_get_timecount(struct timecounter *tc) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335441 - head/sys/kern
Author: bz
Date: Wed Jun 20 11:42:06 2018
New Revision: 335441
URL: https://svnweb.freebsd.org/changeset/base/335441
Log:
Instead of using hand-rolled loops where not needed switch them
to FOREACH_PROC_IN_SYSTEM() to have a single pattern to look for.
Reviewed by: kib
MFC after:2 weeks
Sponsored by: iXsystems, Inc.
Differential Revision:https://reviews.freebsd.org/D15916
Modified:
head/sys/kern/kern_jail.c
head/sys/kern/kern_proc.c
head/sys/kern/subr_kdb.c
Modified: head/sys/kern/kern_jail.c
==
--- head/sys/kern/kern_jail.c Wed Jun 20 11:13:10 2018(r335440)
+++ head/sys/kern/kern_jail.c Wed Jun 20 11:42:06 2018(r335441)
@@ -2286,7 +2286,7 @@ prison_remove_one(struct prison *pr)
* Kill all processes unfortunate enough to be attached to this prison.
*/
sx_slock(&allproc_lock);
- LIST_FOREACH(p, &allproc, p_list) {
+ FOREACH_PROC_IN_SYSTEM(p) {
PROC_LOCK(p);
if (p->p_state != PRS_NEW && p->p_ucred &&
p->p_ucred->cr_prison == pr)
Modified: head/sys/kern/kern_proc.c
==
--- head/sys/kern/kern_proc.c Wed Jun 20 11:13:10 2018(r335440)
+++ head/sys/kern/kern_proc.c Wed Jun 20 11:42:06 2018(r335441)
@@ -3176,7 +3176,7 @@ again:
}
}
/* Did the loop above missed any stopped process ? */
- LIST_FOREACH(p, &allproc, p_list) {
+ FOREACH_PROC_IN_SYSTEM(p) {
/* No need for proc lock. */
if ((p->p_flag & P_TOTAL_STOP) != 0)
goto again;
Modified: head/sys/kern/subr_kdb.c
==
--- head/sys/kern/subr_kdb.cWed Jun 20 11:13:10 2018(r335440)
+++ head/sys/kern/subr_kdb.cWed Jun 20 11:42:06 2018(r335441)
@@ -580,14 +580,12 @@ kdb_thr_first(void)
struct proc *p;
struct thread *thr;
- p = LIST_FIRST(&allproc);
- while (p != NULL) {
+ FOREACH_PROC_IN_SYSTEM(p) {
if (p->p_flag & P_INMEM) {
thr = FIRST_THREAD_IN_PROC(p);
if (thr != NULL)
return (thr);
}
- p = LIST_NEXT(p, p_list);
}
return (NULL);
}
@@ -597,11 +595,9 @@ kdb_thr_from_pid(pid_t pid)
{
struct proc *p;
- p = LIST_FIRST(&allproc);
- while (p != NULL) {
+ FOREACH_PROC_IN_SYSTEM(p) {
if (p->p_flag & P_INMEM && p->p_pid == pid)
return (FIRST_THREAD_IN_PROC(p));
- p = LIST_NEXT(p, p_list);
}
return (NULL);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335442 - head/sys/dev/ofw
Author: jhibbits
Date: Wed Jun 20 13:30:35 2018
New Revision: 335442
URL: https://svnweb.freebsd.org/changeset/base/335442
Log:
Attach dev.cpu nodes on powerpc SMT cores, using only the first found thread
Summary: In order to use cpufreq(4), a dev.cpu attachment must be created. If
the IBM property is found denoting SMT, attach only to the first thread setup,
so that a cpufreq device can bind.
Reviewed by: nwhitehorn
Differential Revision: https://reviews.freebsd.org/D15921
Modified:
head/sys/dev/ofw/ofw_cpu.c
Modified: head/sys/dev/ofw/ofw_cpu.c
==
--- head/sys/dev/ofw/ofw_cpu.c Wed Jun 20 11:42:06 2018(r335441)
+++ head/sys/dev/ofw/ofw_cpu.c Wed Jun 20 13:30:35 2018(r335442)
@@ -191,10 +191,6 @@ ofw_cpu_probe(device_t dev)
if (type == NULL || strcmp(type, "cpu") != 0)
return (ENXIO);
- /* Skip SMT CPUs, which we can't reasonably represent with this code */
- if (OF_hasprop(ofw_bus_get_node(dev), "ibm,ppc-interrupt-server#s"))
- return (ENXIO);
-
device_set_desc(dev, "Open Firmware CPU");
return (0);
}
@@ -233,6 +229,43 @@ ofw_cpu_attach(device_t dev)
} else
sc->sc_reg_valid = true;
+#ifdef __powerpc__
+ /*
+* On powerpc, "interrupt-servers" denotes a SMT CPU. Look for any
+* thread on this CPU, and assign that.
+*/
+ if (OF_hasprop(node, "ibm,ppc-interrupt-server#s")) {
+ struct cpuref cpuref;
+ cell_t *servers;
+ int i, nservers, rv;
+
+ if ((nservers = OF_getencprop_alloc(node,
+ "ibm,ppc-interrupt-server#s", (void **)&servers)) < 0)
+ return (ENXIO);
+ nservers /= sizeof(cell_t);
+ for (i = 0; i < nservers; i++) {
+ for (rv = platform_smp_first_cpu(&cpuref); rv == 0;
+ rv = platform_smp_next_cpu(&cpuref)) {
+ if (cpuref.cr_hwref == servers[i]) {
+ sc->sc_cpu_pcpu =
+ pcpu_find(cpuref.cr_cpuid);
+ if (sc->sc_cpu_pcpu == NULL) {
+ OF_prop_free(servers);
+ return (ENXIO);
+ }
+ break;
+ }
+ }
+ if (rv != ENOENT)
+ break;
+ }
+ OF_prop_free(servers);
+ if (sc->sc_cpu_pcpu == NULL) {
+ device_printf(dev, "No CPU found for this device.\n");
+ return (ENXIO);
+ }
+ } else
+#endif
sc->sc_cpu_pcpu = pcpu_find(device_get_unit(dev));
if (OF_getencprop(node, "clock-frequency", &cell, sizeof(cell)) < 0) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Wed, Jun 20, 2018 at 1:21 AM, Simon J. Gerraty wrote: > Conrad Meyer wrote: > > > There's absolutely no reason to use sha1 or ripemd in new designs. > > These should be removed. > > Sorry I disagree - not with ripem (we never supported that or any of the > non-NIST approved hashes), but sha1 is still approved by NIST for > firmware integrity checks - which is what this is, and sha1 is cheaper > than sha256. > > As I mentioned in my talk we've included support for sha256 for 10+ > years, but do not plan to drop sha1 until NIST deprecate it for that > purpose since boot time is a very sensitive subject for us. > With all due respect, NIST is hardly the sole authority on this topic. Over in the IETF, we have the SUIT working group that is even considering hash-based signatures for firmware updates for post-quantum resistance (so that devices can be shipped now that have 20-year lifecycles can have some expectation of retaining the ability to securely take updates over that lifecycle, admittedly). With my IETF Security Area Director hat on, any greenfield proposal coming in to the IESG that included sha1 support would get extremely strong pushback, and I don't expect that "reducing boot time" would be seen as sufficiently compelling. -Ben ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
In message <96021.1529475...@kaos.jnpr.net>, "Simon J. Gerraty" writes: > Conrad Meyer wrote: > > First and foremost: nothing is actually signed, anywhere. The > > The signing of manifests is external. The veriexecctl tool is I assume > a straight copy of what's in NetBSD (I've not looked at it in at least a > decade). If this is correct, should it not be imported into the vendor branches first? What are the criteria to import through the vendor branches v.s. direct import into HEAD? Do I fail to understand a missing piece of information or is there an inconsistency? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
On Tue, Jun 19, 2018 at 6:34 PM, Allan Jude wrote: > On 2018-06-17 07:32, Eugene Grosbein wrote: > > 17.06.2018 10:18, Allan Jude wrote: > > > >> Author: allanjude > >> Date: Sun Jun 17 03:18:56 2018 > >> New Revision: 335276 > >> URL: https://svnweb.freebsd.org/changeset/base/335276 > >> > >> Log: > >> gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles > early > >> > >> Normally the serial console is not enabled until /boot.config is read > and > >> we know how the serial console should be configured. Initialize the > >> consoles early in 'dual' mode (serial & keyboard) with a default > serial > >> rate of 115200. Then serial is re-initialized once the disk is > decrypted > >> and the /boot.config file can be read. > >> > >> This allows the GELIBoot passphrase to be provided via the serial > console. > >> > >> PR:221526 > >> Requested by: many > >> Reviewed by: imp > >> Sponsored by: Klara Systems > >> Differential Revision: https://reviews.freebsd.org/D15862 > > > > I had several cases when booting FreeBSD/amd64 with motherboard having > no serial ports > > hang hard early at boot unless I rebuilt boot media configuring it to > NOT try accessing > > missing serial ports. I even could reproduce that with VirtualBox > machine configured > > with no serial ports (not same as existing bug inactive serial port). > > > > Should there be some way to disable this serial ports configuration at > compile time? > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > one by default, because it is safer. Then you can just use > 'gptboot-serial' if you want serial support. > > This will likely make Warner a bit sad, since we are just finally > getting around to reducing the number of different bootcode files. > I think we should *NOT* do that. There is a niche market for this stuff, and we should support building serial-enabled bootblocks on an opt-in basis. The support is really already there, this just enables it early. I agree with kib@ that the target market here is too small to justify a proliferation of new boot blocks. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335444 - head/sys/arm64/rockchip
Author: manu Date: Wed Jun 20 14:46:07 2018 New Revision: 335444 URL: https://svnweb.freebsd.org/changeset/base/335444 Log: rk_gpio: Read the correct register for gpio read Reported by: jmcneill Modified: head/sys/arm64/rockchip/rk_gpio.c Modified: head/sys/arm64/rockchip/rk_gpio.c == --- head/sys/arm64/rockchip/rk_gpio.c Wed Jun 20 14:45:26 2018 (r335443) +++ head/sys/arm64/rockchip/rk_gpio.c Wed Jun 20 14:46:07 2018 (r335444) @@ -277,7 +277,7 @@ rk_gpio_pin_get(device_t dev, uint32_t pin, unsigned i sc = device_get_softc(dev); RK_GPIO_LOCK(sc); - reg = RK_GPIO_READ(sc, RK_GPIO_SWPORTA_DR); + reg = RK_GPIO_READ(sc, RK_GPIO_EXT_PORTA); RK_GPIO_UNLOCK(sc); *val = reg & (1 << pin) ? 1 : 0; ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335443 - head/sys/arm64/rockchip
Author: manu
Date: Wed Jun 20 14:45:26 2018
New Revision: 335443
URL: https://svnweb.freebsd.org/changeset/base/335443
Log:
if_rk_dwc: Fix delays handling
The property are named {t,r}x_delay and not {t,r}-delay.
The upper bits of the register are a mask of which bits is allowed
to be written, set it otherwise we write nothing.
OF_getencprop returns <0 = for an error.
Pointy Hat: myself
Reported by: jmcneill (delay and mask bits)
Modified:
head/sys/arm64/rockchip/if_dwc_rk.c
Modified: head/sys/arm64/rockchip/if_dwc_rk.c
==
--- head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 13:30:35 2018
(r335442)
+++ head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 14:45:26 2018
(r335443)
@@ -70,16 +70,17 @@ rk3328_set_delays(struct syscon *grf, phandle_t node)
{
uint32_t tx, rx;
- if (OF_getencprop(node, "tx-delay", &tx, sizeof(tx)) >= 0)
+ if (OF_getencprop(node, "tx_delay", &tx, sizeof(tx)) <= 0)
tx = 0x30;
- if (OF_getencprop(node, "rx-delay", &rx, sizeof(rx)) >= 0)
+ if (OF_getencprop(node, "rx_delay", &rx, sizeof(rx)) <= 0)
rx = 0x10;
tx = ((tx & RK3328_GRF_MAC_CON0_TX_MASK) <<
RK3328_GRF_MAC_CON0_TX_SHIFT);
rx = ((rx & RK3328_GRF_MAC_CON0_TX_MASK) <<
RK3328_GRF_MAC_CON0_RX_SHIFT);
- SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx);
+
+ SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx | 0x);
}
static int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335437 - in head: share/man/man4 sys/kern
Hi Bjoern,
It might be nice to be explicit that the vnode was not in the
namecache (in the ddb output) rather than failing silently. The name
of the ddb method does not suggest that only entries in the namecache
may be found, and users (developers :)) do not always read manual
pages thoroughly.
All the best,
Conrad
On Wed, Jun 20, 2018 at 1:34 AM, Bjoern A. Zeeb wrote:
> Author: bz
> Date: Wed Jun 20 08:34:29 2018
> New Revision: 335437
> URL: https://svnweb.freebsd.org/changeset/base/335437
>
> Log:
> Sometimes it is helpful to get the path for a vnode.
> Implement a ddb function walking the namecache to do this.
>
> Reviewed by: jhb, mjg
> Inspired by: gdb macro from jhb (old version)
> Sponsored by: iXsystems, Inc.
> Differential Revision:https://reviews.freebsd.org/D14898
>
> Modified:
> head/share/man/man4/ddb.4
> head/sys/kern/vfs_cache.c
>
> Modified: head/share/man/man4/ddb.4
> ==
> --- head/share/man/man4/ddb.4 Wed Jun 20 07:02:19 2018(r335436)
> +++ head/share/man/man4/ddb.4 Wed Jun 20 08:34:29 2018(r335437)
> @@ -60,7 +60,7 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd August 24, 2017
> +.Dd June 20, 2018
> .Dt DDB 4
> .Os
> .Sh NAME
> @@ -1121,6 +1121,11 @@ header file.
> .Pp
> .It Ic show Cm vnodebufs Ar addr
> Shows clean/dirty buffer lists of the vnode located at
> +.Ar addr .
> +.\"
> +.Pp
> +.It Ic show Cm vpath Ar addr
> +Walk the namecache to lookup the pathname of the vnode located at
> .Ar addr .
> .\"
> .Pp
>
> Modified: head/sys/kern/vfs_cache.c
> ==
> --- head/sys/kern/vfs_cache.c Wed Jun 20 07:02:19 2018(r335436)
> +++ head/sys/kern/vfs_cache.c Wed Jun 20 08:34:29 2018(r335437)
> @@ -37,6 +37,7 @@
> #include
> __FBSDID("$FreeBSD$");
>
> +#include "opt_ddb.h"
> #include "opt_ktrace.h"
>
> #include
> @@ -62,6 +63,10 @@ __FBSDID("$FreeBSD$");
> #include
> #endif
>
> +#ifdef DDB
> +#include
> +#endif
> +
> #include
>
> SDT_PROVIDER_DECLARE(vfs);
> @@ -2529,3 +2534,54 @@ out:
> free(fbuf, M_TEMP);
> return (error);
> }
> +
> +#ifdef DDB
> +static void
> +db_print_vpath(struct vnode *vp)
> +{
> +
> + while (vp != NULL) {
> + db_printf("%p: ", vp);
> + if (vp == rootvnode) {
> + db_printf("/");
> + vp = NULL;
> + } else {
> + if (vp->v_vflag & VV_ROOT) {
> + db_printf("");
> + vp = vp->v_mount->mnt_vnodecovered;
> + } else {
> + struct namecache *ncp;
> + char *ncn;
> + int i;
> +
> + ncp = TAILQ_FIRST(&vp->v_cache_dst);
> + if (ncp != NULL) {
> + ncn = ncp->nc_name;
> + for (i = 0; i < ncp->nc_nlen; i++)
> + db_printf("%c", *ncn++);
> + vp = ncp->nc_dvp;
> + } else {
> + vp = NULL;
> + }
> + }
> + }
> + db_printf("\n");
> + }
> +
> + return;
> +}
> +
> +DB_SHOW_COMMAND(vpath, db_show_vpath)
> +{
> + struct vnode *vp;
> +
> + if (!have_addr) {
> + db_printf("usage: show vpath \n");
> + return;
> + }
> +
> + vp = (struct vnode *)addr;
> + db_print_vpath(vp);
> +}
> +
> +#endif
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
Simon J. Gerraty wrote: > > - Maybe sign the source-of-trust file > > We do. As noted above, we cannot upstream that until FreeBSD has > suitable signing infra. It occurred to me, that since I'll be upstreaming a library that uses BearSSL to do the necessary manifest verification for the loader, the same could be leveraged for the veriexec loader. That may impact where the two libs should go - will discuss with imp. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Wed, Jun 20, 2018, 6:42 AM Cy Schubert wrote: > In message <96021.1529475...@kaos.jnpr.net>, "Simon J. Gerraty" writes: > > Conrad Meyer wrote: > > > First and foremost: nothing is actually signed, anywhere. The > > > > The signing of manifests is external. The veriexecctl tool is I assume > > a straight copy of what's in NetBSD (I've not looked at it in at least a > > decade). > > If this is correct, should it not be imported into the vendor branches > first? > It's not a straight copy. But much of it is from the NetBSD version. > What are the criteria to import through the vendor branches v.s. direct > import into HEAD? Do I fail to understand a missing piece of > information or is there an inconsistency? > I asked about it at BSDCan 3 years ago and pointed people my github branch (before review was created) to get opinions on what to do about it (vendor or directly put it in sbin) and the consensus was to submit it the way I did. -Steve ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335445 - head/sys/arm64/rockchip
Author: manu Date: Wed Jun 20 15:27:09 2018 New Revision: 335445 URL: https://svnweb.freebsd.org/changeset/base/335445 Log: if_rk_dwc: Disable setting delays for now The values for tx/rx delays differs accross the different DTS. Mainline Linux set it to 0x24/0x18 Mostly-Vendor u-boot (the one maintained and developped) to 0x18/0x18 Mostly-Vendor linux (the one maintained and developped) to 0x26/0x11 By experience only 0x18/0x18 works so until the issue is resolved rely on the bootloader settings. Modified: head/sys/arm64/rockchip/if_dwc_rk.c Modified: head/sys/arm64/rockchip/if_dwc_rk.c == --- head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 14:46:07 2018 (r335444) +++ head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 15:27:09 2018 (r335445) @@ -80,7 +80,8 @@ rk3328_set_delays(struct syscon *grf, phandle_t node) rx = ((rx & RK3328_GRF_MAC_CON0_TX_MASK) << RK3328_GRF_MAC_CON0_RX_SHIFT); - SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx | 0x); + /* Disable delays as values conflict between DTS */ + /* SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx | 0x); */ } static int ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
Benjamin Kaduk wrote: > With all due respect, NIST is hardly the sole authority on this topic. True, unless of course you sell to US govt. > With my IETF Security Area Director hat on, any greenfield proposal coming > in > to the IESG that included sha1 support would get extremely strong pushback, > and I don't expect that "reducing boot time" would be seen as sufficiently > compelling. Well that's unfortunate, because reality (and sales teams) can be a pain. The number of customers who would trade boot time for improved security is depressingly small. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
Cy Schubert wrote: > > The signing of manifests is external. The veriexecctl tool is I assume > > a straight copy of what's in NetBSD (I've not looked at it in at least a > > decade). > > If this is correct, should it not be imported into the vendor branches > first? > > What are the criteria to import through the vendor branches v.s. direct > import into HEAD? Do I fail to understand a missing piece of > information or is there an inconsistency? AFAIK the key is whether there is an upstream project that will be tracked, which is not the case here. The ctl tool is the only bit that bears any relationship to the NetBSD code - because we never used it. Once I commit the loader stuff, we can replace the above with something more useful - can leverage the same library to verify manifest signatures. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335437 - in head: share/man/man4 sys/kern
On 20 Jun 2018, at 15:05, Conrad Meyer wrote: > Hi Bjoern, > > It might be nice to be explicit that the vnode was not in the > namecache (in the ddb output) rather than failing silently. The name > of the ddb method does not suggest that only entries in the namecache > may be found, and users (developers :)) do not always read manual > pages thoroughly. It’s not failing silently; it ends with an address w/o name. /bz ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
You can keep these poor security modes in your downstream product if you want, but don't put them in the tree. On Wed, Jun 20, 2018 at 8:28 AM, Simon J. Gerraty wrote: > Benjamin Kaduk wrote: >> With all due respect, NIST is hardly the sole authority on this topic. > > True, unless of course you sell to US govt. > >> With my IETF Security Area Director hat on, any greenfield proposal coming >> in >> to the IESG that included sha1 support would get extremely strong pushback, >> and I don't expect that "reducing boot time" would be seen as sufficiently >> compelling. > > Well that's unfortunate, because reality (and sales teams) can be a > pain. The number of customers who would trade boot time for improved > security is depressingly small. > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335437 - in head: share/man/man4 sys/kern
On Wed, Jun 20, 2018 at 8:36 AM, Bjoern A. Zeeb wrote: > On 20 Jun 2018, at 15:05, Conrad Meyer wrote: > >> Hi Bjoern, >> >> It might be nice to be explicit that the vnode was not in the >> namecache (in the ddb output) rather than failing silently. The name >> of the ddb method does not suggest that only entries in the namecache >> may be found, and users (developers :)) do not always read manual >> pages thoroughly. > > It’s not failing silently; it ends with an address w/o name. Hi, To provide a more concrete proposal, would you object to the following? 0xfoobarbaz: Thanks, Conrad ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Wed, 2018-06-20 at 08:45 -0700, Conrad Meyer wrote: > You can keep these poor security modes in your downstream product if > you want, but don't put them in the tree. > And I request exactly the opposite: reject the complaining of people who think all the world is a 256-core 5ghz server and leave in the option to use faster algorithms on real-world hardware used by real- world vendors who need some option other than "rev your hardware every 18 months to keep up with the software or get out of the business." Stronger algorithm options, yes. Even making stronger options the default, yes. But removing viable options which are endorsed by the people who actually set the standards, no. - Ian > On Wed, Jun 20, 2018 at 8:28 AM, Simon J. Gerraty > wrote: > > > > Benjamin Kaduk wrote: > > > > > > With all due respect, NIST is hardly the sole authority on this > > > topic. > > True, unless of course you sell to US govt. > > > > > > > > With my IETF Security Area Director hat on, any greenfield > > > proposal coming > > > in > > > to the IESG that included sha1 support would get extremely strong > > > pushback, > > > and I don't expect that "reducing boot time" would be seen as > > > sufficiently > > > compelling. > > Well that's unfortunate, because reality (and sales teams) can be a > > pain. The number of customers who would trade boot time for > > improved > > security is depressingly small. > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote: > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > > > > On 2018-06-17 07:32, Eugene Grosbein wrote: > > > > > > 17.06.2018 10:18, Allan Jude wrote: > > > > > > > > > > > Author: allanjude > > > > Date: Sun Jun 17 03:18:56 2018 > > > > New Revision: 335276 > > > > URL: https://svnweb.freebsd.org/changeset/base/335276 > > > > > > > > Log: > > > > gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles > > > > early > > > > > > > > Normally the serial console is not enabled until /boot.config is read > > > > and > > > > we know how the serial console should be configured. Initialize the > > > > consoles early in 'dual' mode (serial & keyboard) with a default > > > > serial > > > > rate of 115200. Then serial is re-initialized once the disk is > > > > decrypted > > > > and the /boot.config file can be read. > > > > > > > > This allows the GELIBoot passphrase to be provided via the serial > > > > console. > > > > > > > > PR: 221526 > > > > Requested by: many > > > > Reviewed by: imp > > > > Sponsored by: Klara Systems > > > > Differential Revision:https://reviews.freebsd.org/D15862 > > > I had several cases when booting FreeBSD/amd64 with motherboard having no > > > serial ports > > > hang hard early at boot unless I rebuilt boot media configuring it to NOT > > > try accessing > > > missing serial ports. I even could reproduce that with VirtualBox machine > > > configured > > > with no serial ports (not same as existing bug inactive serial port). > > > > > > Should there be some way to disable this serial ports configuration at > > > compile time? > > > > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > > one by default, because it is safer. Then you can just use > > 'gptboot-serial' if you want serial support. > > > > This will likely make Warner a bit sad, since we are just finally > > getting around to reducing the number of different bootcode files. > I think we should follow the hardware trends there and apply a policy > where new features are not added to the CSM boot. All modern machines > can be booted in UEFI mode, and if some modern machine cannot, then we > need it fixed. We should encourage users to make new installs boot by > UEFI. > > The feature from the commit is only relevant for machines that require > CSM boot or do not have UEFI option at all, am I right ? With the policy > applied, an additional CSM-boot bootblock would be not shipped. > I think it is far too early to say that the code for booting without efi is abandonware. I have half a dozen x86 boxes in use here, and only one of them is even able to boot efi, and its default resolution in efi mode confuses the kvm switch it's connected to, so even on that I have to use legacy bios boot. However, I'm not sure we need to make a prepackaged gptboot binary that has serial prompting for geli passwords. That's a pretty specialized need that can be handled by people building WITH_GPTBOOT_SERIAL or some similar option and installing it themselves. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote: > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > > > > On 2018-06-17 07:32, Eugene Grosbein wrote: > > > > > > 17.06.2018 10:18, Allan Jude wrote: > > > > > > > > > > > Author: allanjude > > > > Date: Sun Jun 17 03:18:56 2018 > > > > New Revision: 335276 > > > > URL: https://svnweb.freebsd.org/changeset/base/335276 > > > > > > > > Log: > > > > gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles > > > > early > > > > > > > > Normally the serial console is not enabled until /boot.config is read > > > > and > > > > we know how the serial console should be configured. Initialize the > > > > consoles early in 'dual' mode (serial & keyboard) with a default > > > > serial > > > > rate of 115200. Then serial is re-initialized once the disk is > > > > decrypted > > > > and the /boot.config file can be read. > > > > > > > > This allows the GELIBoot passphrase to be provided via the serial > > > > console. > > > > > > > > PR: 221526 > > > > Requested by: many > > > > Reviewed by: imp > > > > Sponsored by: Klara Systems > > > > Differential Revision:https://reviews.freebsd.org/D15862 > > > I had several cases when booting FreeBSD/amd64 with motherboard having no > > > serial ports > > > hang hard early at boot unless I rebuilt boot media configuring it to NOT > > > try accessing > > > missing serial ports. I even could reproduce that with VirtualBox machine > > > configured > > > with no serial ports (not same as existing bug inactive serial port). > > > > > > Should there be some way to disable this serial ports configuration at > > > compile time? > > > > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > > one by default, because it is safer. Then you can just use > > 'gptboot-serial' if you want serial support. > > > > This will likely make Warner a bit sad, since we are just finally > > getting around to reducing the number of different bootcode files. > I think we should follow the hardware trends there and apply a policy > where new features are not added to the CSM boot. All modern machines > can be booted in UEFI mode, and if some modern machine cannot, then we > need it fixed. We should encourage users to make new installs boot by > UEFI. > > The feature from the commit is only relevant for machines that require > CSM boot or do not have UEFI option at all, am I right ? With the policy > applied, an additional CSM-boot bootblock would be not shipped. > I think it is far too early to say that the code for booting without efi is abandonware. I have half a dozen x86 boxes in use here, and only one of them is even able to boot efi, and its default resolution in efi mode confuses the kvm switch it's connected to, so even on that I have to use legacy bios boot. However, I'm not sure we need to make a prepackaged gptboot binary that has serial prompting for geli passwords. That's a pretty specialized need that can be handled by people building WITH_GPTBOOT_SERIAL or some similar option and installing it themselves. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote: > On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote: > > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > > > > > > On 2018-06-17 07:32, Eugene Grosbein wrote: > > > > > > > > 17.06.2018 10:18, Allan Jude wrote: > > > > > > > > > > > > > > Author: allanjude > > > > > Date: Sun Jun 17 03:18:56 2018 > > > > > New Revision: 335276 > > > > > URL: https://svnweb.freebsd.org/changeset/base/335276 > > > > > > > > > > Log: > > > > > gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles > > > > > early > > > > > > > > > > Normally the serial console is not enabled until /boot.config is > > > > > read and > > > > > we know how the serial console should be configured. Initialize the > > > > > consoles early in 'dual' mode (serial & keyboard) with a default > > > > > serial > > > > > rate of 115200. Then serial is re-initialized once the disk is > > > > > decrypted > > > > > and the /boot.config file can be read. > > > > > > > > > > This allows the GELIBoot passphrase to be provided via the serial > > > > > console. > > > > > > > > > > PR: 221526 > > > > > Requested by: many > > > > > Reviewed by:imp > > > > > Sponsored by: Klara Systems > > > > > Differential Revision: https://reviews.freebsd.org/D15862 > > > > I had several cases when booting FreeBSD/amd64 with motherboard having > > > > no serial ports > > > > hang hard early at boot unless I rebuilt boot media configuring it to > > > > NOT try accessing > > > > missing serial ports. I even could reproduce that with VirtualBox > > > > machine configured > > > > with no serial ports (not same as existing bug inactive serial port). > > > > > > > > Should there be some way to disable this serial ports configuration at > > > > compile time? > > > > > > > > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > > > one by default, because it is safer. Then you can just use > > > 'gptboot-serial' if you want serial support. > > > > > > This will likely make Warner a bit sad, since we are just finally > > > getting around to reducing the number of different bootcode files. > > I think we should follow the hardware trends there and apply a policy > > where new features are not added to the CSM boot. All modern machines > > can be booted in UEFI mode, and if some modern machine cannot, then we > > need it fixed. We should encourage users to make new installs boot by > > UEFI. > > > > The feature from the commit is only relevant for machines that require > > CSM boot or do not have UEFI option at all, am I right ? With the policy > > applied, an additional CSM-boot bootblock would be not shipped. > > > > I think it is far too early to say that the code for booting without > efi is abandonware. I have half a dozen x86 boxes in use here, and only > one of them is even able to boot efi, and its default resolution in efi > mode confuses the kvm switch it's connected to, so even on that I have > to use legacy bios boot. I do not propose to abandon bios boot, or even to declare it legacy with the proper meaning. I mean that CSM is disappearing on the newest platforms, and should become only used on old machines or i386. With that attitude, adding a features for it, esp. by the cost of the user confusion, is not worth the efforts. It still should be maintained for the foreseable future. If the machines where you get the trouble is newer than say 5 years, then they should boot with UEFI. If not, the problem in loader.efi needs to be fixed. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
On Wed, Jun 20, 2018 at 10:03 AM, Konstantin Belousov wrote: > On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote: > > On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote: > > > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > > > > > > > > On 2018-06-17 07:32, Eugene Grosbein wrote: > > > > > > > > > > 17.06.2018 10:18, Allan Jude wrote: > > > > > > > > > > > > > > > > > Author: allanjude > > > > > > Date: Sun Jun 17 03:18:56 2018 > > > > > > New Revision: 335276 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/335276 > > > > > > > > > > > > Log: > > > > > > gptboot, zfsboot, gptzfsboot: Enable the video and serial > consoles early > > > > > > > > > > > > Normally the serial console is not enabled until /boot.config > is read and > > > > > > we know how the serial console should be > configured. Initialize the > > > > > > consoles early in 'dual' mode (serial & keyboard) with a > default serial > > > > > > rate of 115200. Then serial is re-initialized once the disk is > decrypted > > > > > > and the /boot.config file can be read. > > > > > > > > > > > > This allows the GELIBoot passphrase to be provided via the > serial console. > > > > > > > > > > > > PR: 221526 > > > > > > Requested by: many > > > > > > Reviewed by:imp > > > > > > Sponsored by: Klara Systems > > > > > > Differential Revision: https://reviews.freebsd.org/D15862 > > > > > I had several cases when booting FreeBSD/amd64 with motherboard > having no serial ports > > > > > hang hard early at boot unless I rebuilt boot media configuring it > to NOT try accessing > > > > > missing serial ports. I even could reproduce that with VirtualBox > machine configured > > > > > with no serial ports (not same as existing bug inactive serial > port). > > > > > > > > > > Should there be some way to disable this serial ports > configuration at compile time? > > > > > > > > > > > > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > > > > one by default, because it is safer. Then you can just use > > > > 'gptboot-serial' if you want serial support. > > > > > > > > This will likely make Warner a bit sad, since we are just finally > > > > getting around to reducing the number of different bootcode files. > > > I think we should follow the hardware trends there and apply a policy > > > where new features are not added to the CSM boot. All modern machines > > > can be booted in UEFI mode, and if some modern machine cannot, then we > > > need it fixed. We should encourage users to make new installs boot by > > > UEFI. > > > > > > The feature from the commit is only relevant for machines that require > > > CSM boot or do not have UEFI option at all, am I right ? With the > policy > > > applied, an additional CSM-boot bootblock would be not shipped. > > > > > > > I think it is far too early to say that the code for booting without > > efi is abandonware. I have half a dozen x86 boxes in use here, and only > > one of them is even able to boot efi, and its default resolution in efi > > mode confuses the kvm switch it's connected to, so even on that I have > > to use legacy bios boot. > I do not propose to abandon bios boot, or even to declare it legacy > with the proper meaning. I mean that CSM is disappearing on the newest > platforms, and should become only used on old machines or i386. With that > attitude, adding a features for it, esp. by the cost of the user confusion, > is not worth the efforts. It still should be maintained for the foreseable > future. > > If the machines where you get the trouble is newer than say 5 years, > then they should boot with UEFI. If not, the problem in loader.efi > needs to be fixed. > There is no problem in loader.efi that's specific to geli. It already uses the UEFI boot loader config. While there's some issues downstream (eg kernel messages), this specific issue is a non-issue for loader.efi. Warer ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335446 - in head/sys: arm64/arm64 arm64/include kern
Author: manu
Date: Wed Jun 20 16:07:35 2018
New Revision: 335446
URL: https://svnweb.freebsd.org/changeset/base/335446
Log:
Add pmap_mapdev_attr for arm64
This is needed for efifb.
arm and ricv pmap (the two arch with arm64 that uses subr_devmap) have very
different implementation so for now only add this for arm64.
Tested with efifb on Pine64 with a few other patches.
Reviewed by: cognet
Differential Revision:https://reviews.freebsd.org/D15294
Modified:
head/sys/arm64/arm64/pmap.c
head/sys/arm64/include/pmap.h
head/sys/kern/subr_devmap.c
Modified: head/sys/arm64/arm64/pmap.c
==
--- head/sys/arm64/arm64/pmap.c Wed Jun 20 15:27:09 2018(r335445)
+++ head/sys/arm64/arm64/pmap.c Wed Jun 20 16:07:35 2018(r335446)
@@ -1142,7 +1142,7 @@ pmap_kextract(vm_offset_t va)
* Low level mapping routines.
***/
-static void
+void
pmap_kenter(vm_offset_t sva, vm_size_t size, vm_paddr_t pa, int mode)
{
pd_entry_t *pde;
Modified: head/sys/arm64/include/pmap.h
==
--- head/sys/arm64/include/pmap.h Wed Jun 20 15:27:09 2018
(r335445)
+++ head/sys/arm64/include/pmap.h Wed Jun 20 16:07:35 2018
(r335446)
@@ -140,10 +140,12 @@ extern vm_offset_t virtual_end;
va) | (pa)) & L1_OFFSET) == 0 && (size) >= L1_SIZE)
void pmap_bootstrap(vm_offset_t, vm_offset_t, vm_paddr_t, vm_size_t);
+void pmap_kenter(vm_offset_t sva, vm_size_t size, vm_paddr_t pa, int mode);
void pmap_kenter_device(vm_offset_t, vm_size_t, vm_paddr_t);
vm_paddr_t pmap_kextract(vm_offset_t va);
void pmap_kremove(vm_offset_t);
void pmap_kremove_device(vm_offset_t, vm_size_t);
+void *pmap_mapdev_attr(vm_offset_t pa, vm_size_t size, vm_memattr_t ma);
void *pmap_mapdev(vm_offset_t, vm_size_t);
void *pmap_mapbios(vm_paddr_t, vm_size_t);
Modified: head/sys/kern/subr_devmap.c
==
--- head/sys/kern/subr_devmap.c Wed Jun 20 15:27:09 2018(r335445)
+++ head/sys/kern/subr_devmap.c Wed Jun 20 16:07:35 2018(r335446)
@@ -287,6 +287,37 @@ pmap_mapdev(vm_offset_t pa, vm_size_t size)
return ((void *)(va + offset));
}
+#if defined(__aarch64__)
+void *
+pmap_mapdev_attr(vm_offset_t pa, vm_size_t size, vm_memattr_t ma)
+{
+ vm_offset_t va, offset;
+ void * rva;
+
+ /* First look in the static mapping table. */
+ if ((rva = devmap_ptov(pa, size)) != NULL)
+ return (rva);
+
+ offset = pa & PAGE_MASK;
+ pa = trunc_page(pa);
+ size = round_page(size + offset);
+
+ if (early_boot) {
+ akva_devmap_vaddr = trunc_page(akva_devmap_vaddr - size);
+ va = akva_devmap_vaddr;
+ KASSERT(va >= VM_MAX_KERNEL_ADDRESS - L2_SIZE,
+ ("Too many early devmap mappings"));
+ } else
+ va = kva_alloc(size);
+ if (!va)
+ panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
+
+ pmap_kenter(va, size, pa, ma);
+
+ return ((void *)(va + offset));
+}
+#endif
+
/*
* Unmap device memory and free the kva space.
*/
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335447 - in head: . gnu/usr.bin/binutils/ld usr.bin/clang/lld
Author: bdrewery
Date: Wed Jun 20 16:10:02 2018
New Revision: 335447
URL: https://svnweb.freebsd.org/changeset/base/335447
Log:
Rework how the ld link is handled in WORLDTMP from r322811.
LLD_BOOTSTRAP (build) is independent of LLD_IS_LD (installed) so they
should not be based on each other.
This is related to upcoming WITH_SYSTEM_LINKER work.
Reviewed by: emaste
Sponsored by: Dell EMC
Differential Revision:https://reviews.freebsd.org/D15836
Modified:
head/Makefile.inc1
head/gnu/usr.bin/binutils/ld/Makefile
head/usr.bin/clang/lld/Makefile
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Jun 20 16:07:35 2018(r335446)
+++ head/Makefile.inc1 Wed Jun 20 16:10:02 2018(r335447)
@@ -586,7 +586,7 @@ TMAKE= \
# TOOLS_PREFIX set in BMAKE
XMAKE= ${BMAKE} \
TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \
- MK_GDB=no MK_LLD_IS_LD=${MK_LLD_BOOTSTRAP} MK_TESTS=no
+ MK_GDB=no MK_TESTS=no
# kernel-tools stage
KTMAKEENV= INSTALL="sh ${.CURDIR}/tools/install.sh" \
Modified: head/gnu/usr.bin/binutils/ld/Makefile
==
--- head/gnu/usr.bin/binutils/ld/Makefile Wed Jun 20 16:07:35 2018
(r335446)
+++ head/gnu/usr.bin/binutils/ld/Makefile Wed Jun 20 16:10:02 2018
(r335447)
@@ -7,8 +7,10 @@ ELF_SCR_EXT= x xbn xc xd xdc xdw xn xr xs xsc xsw xu x
.PATH: ${SRCDIR}/ld
PROG= ld.bfd
-.if ${MK_LLD_IS_LD} == "no"
+.if (!defined(TOOLS_PREFIX) && ${MK_LLD_IS_LD} == "no") || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} == "no")
MAN= ld.1
+LINKS= ${BINDIR}/ld.bfd ${BINDIR}/ld
.else
MAN= ld.bfd.1
CLEANFILES+= ld.bfd.1
@@ -57,9 +59,6 @@ CLEANFILES+= ldemul-list.h stringify.sed
FILES= ${LDSCRIPTS:S|^|ldscripts/|}
FILESDIR= ${SCRIPTDIR}
-.if ${MK_LLD_IS_LD} == "no"
-LINKS= ${BINDIR}/ld.bfd ${BINDIR}/ld
-.endif
HOST= ${TARGET_TUPLE}
LIBSEARCHPATH= \"=/lib\":\"=/usr/lib\"
Modified: head/usr.bin/clang/lld/Makefile
==
--- head/usr.bin/clang/lld/Makefile Wed Jun 20 16:07:35 2018
(r335446)
+++ head/usr.bin/clang/lld/Makefile Wed Jun 20 16:10:02 2018
(r335447)
@@ -8,7 +8,8 @@ LLD_SRCS= ${LLVM_SRCS}/tools/lld
PACKAGE= lld
PROG_CXX= ld.lld
-.if ${MK_LLD_IS_LD} != "no"
+.if (!defined(TOOLS_PREFIX) && ${MK_LLD_IS_LD} != "no") || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
SYMLINKS= ${PROG_CXX} ${BINDIR}/ld
MLINKS=ld.lld.1 ld.1
.endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335449 - head/lib/clang/libllvm
Author: bdrewery
Date: Wed Jun 20 16:10:10 2018
New Revision: 335449
URL: https://svnweb.freebsd.org/changeset/base/335449
Log:
Fix sources needed for lld.
lld always needs these DWARF sources, as well as other default and extra
tools. XDL seems to be the best fit list.
Remove MK_LLD_IS_LD check from SRCS_MIW which is now reduced to just a
few files for llvm-objdump.
Sponsored by: Dell EMC
Differential Revision:https://reviews.freebsd.org/D15915
Modified:
head/lib/clang/libllvm/Makefile
Modified: head/lib/clang/libllvm/Makefile
==
--- head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:07 2018
(r335448)
+++ head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:10 2018
(r335449)
@@ -371,30 +371,30 @@ SRCS_MIN+=
DebugInfo/CodeView/TypeIndexDiscovery.cpp
SRCS_MIN+= DebugInfo/CodeView/TypeRecordMapping.cpp
SRCS_MIN+= DebugInfo/CodeView/TypeStreamMerger.cpp
SRCS_MIN+= DebugInfo/CodeView/TypeTableCollection.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFAbbreviationDeclaration.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFAcceleratorTable.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFCompileUnit.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFContext.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDataExtractor.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugAbbrev.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugArangeSet.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugAranges.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugFrame.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugInfoEntry.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugLine.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugLoc.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugMacro.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugPubTable.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugRangeList.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDie.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFExpression.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFFormValue.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFGdbIndex.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFTypeUnit.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFUnit.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFUnitIndex.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFVerifier.cpp
-SRCS_MIW+= DebugInfo/DWARF/SyntaxHighlighting.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFAbbreviationDeclaration.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFAcceleratorTable.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFCompileUnit.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFContext.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDataExtractor.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugAbbrev.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugArangeSet.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugAranges.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugFrame.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugInfoEntry.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugLine.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugLoc.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugMacro.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugPubTable.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugRangeList.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDie.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFExpression.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFFormValue.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFGdbIndex.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFTypeUnit.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFUnit.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFUnitIndex.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFVerifier.cpp
+SRCS_XDL+= DebugInfo/DWARF/SyntaxHighlighting.cpp
SRCS_MIN+= DebugInfo/MSF/MSFBuilder.cpp
SRCS_MIN+= DebugInfo/MSF/MSFCommon.cpp
SRCS_MIN+= DebugInfo/MSF/MSFError.cpp
@@ -1275,7 +1275,7 @@ SRCS_EXT+=Transforms/Vectorize/Vectorize.cpp
SRCS_EXT+= XRay/InstrumentationMap.cpp
SRCS_ALL+= ${SRCS_MIN}
-.if !defined(TOOLS_PREFIX) || ${MK_LLD_IS_LD} != "no"
+.if !defined(TOOLS_PREFIX)
SRCS_ALL+= ${SRCS_MIW}
.endif
.if ${MK_CLANG_EXTRAS} != "no"
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335448 - in head: . lib/clang/libllvm
Author: bdrewery
Date: Wed Jun 20 16:10:07 2018
New Revision: 335448
URL: https://svnweb.freebsd.org/changeset/base/335448
Log:
Rework WITHOUT_LLD/TOOLCHAIN fix from r327892 for cross-tools.
MK_LLD is for the installed lld while MK_LLD_BOOTSTRAP is for the build
tool. For WITH_SYSTEM_LINKER it is necesarry to separate the logic of
these two. When building libllvm TOOLS_PREFIX will be defined and
MK_LLD_BOOTSTRAP should be checked instead.
Sponsored by: Dell EMC
Differential Revision:https://reviews.freebsd.org/D15837
Modified:
head/Makefile.inc1
head/lib/clang/libllvm/Makefile
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Jun 20 16:10:02 2018(r335447)
+++ head/Makefile.inc1 Wed Jun 20 16:10:07 2018(r335448)
@@ -562,7 +562,6 @@ BSARGS= DESTDIR= \
-DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no \
MK_CLANG_EXTRAS=no MK_CLANG_FULL=no \
MK_LLDB=no MK_TESTS=no \
- MK_LLD=${MK_LLD_BOOTSTRAP} \
MK_INCLUDES=yes
BMAKE= \
Modified: head/lib/clang/libllvm/Makefile
==
--- head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:02 2018
(r335447)
+++ head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:07 2018
(r335448)
@@ -1284,16 +1284,19 @@ SRCS_ALL+= ${SRCS_EXT}
.if ${MK_CLANG_FULL} != "no"
SRCS_ALL+= ${SRCS_FUL}
.endif
-.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLD} != "no"
+.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLD} != "no" || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
SRCS_ALL+= ${SRCS_EXL}
.endif
-.if ${MK_LLD} != "no"
+.if ${MK_LLD} != "no" || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
SRCS_ALL+= ${SRCS_LLD}
.endif
.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no"
SRCS_ALL+= ${SRCS_XDB}
.endif
-.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no" || ${MK_LLD} != "no"
+.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no" || ${MK_LLD} != "no" || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
SRCS_ALL+= ${SRCS_XDL}
.endif
.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no" || !defined(TOOLS_PREFIX)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335450 - in head: . share/mk tools/build/options
Author: bdrewery
Date: Wed Jun 20 16:10:14 2018
New Revision: 335450
URL: https://svnweb.freebsd.org/changeset/base/335450
Log:
Add WITH_SYSTEM_LINKER, on by default, that avoids building lld when possible.
This works similar to WITH_SYSTEM_COMPILER added in r300354. It only
supports lld via WITH_LLD_BOOTSTRAP.
When both SYSTEM_COMPILER and SYSTEM_LINKER logic passes then libclang
will not build in cross-tools. If either check fails though then
libclang is built.
The .info is reworked to notify when libclang will be built since if
either clang or lld needs to be rebuilt, but not the other, the
notification can lead to confusion on why "clang is building".
-fuse-ld= is not used with this method so some combinations of compiler
and linker are expected to fail.
A new 'make test-system-linker' target is added to see the logic results.
Makefile.inc1:
CROSS_BINUTILS_PREFIX support had to be moved higher up so that XLD
could be set and MK_LLD_BOOTSTRAP disabled before checking SYSTEM_LINKER
logic as done with SYSTEM_COMPILER. This also required moving where
bsd.linker.mk was read since XLD needs to be set before parsing it. This
creates a situation where src.opts.mk can not test LINKER_FEATURES or
add LLD_BOOTSTAP to BROKEN_OPTIONS.
Reviewed by: emaste (earlier version)
Sponsored by: Dell EMC
Differential Revision:https://reviews.freebsd.org/D15894
Added:
head/tools/build/options/WITHOUT_SYSTEM_LINKER (contents, props changed)
head/tools/build/options/WITH_SYSTEM_LINKER (contents, props changed)
Modified:
head/Makefile
head/Makefile.inc1
head/share/mk/bsd.compiler.mk
head/share/mk/bsd.linker.mk
head/share/mk/src.opts.mk
Modified: head/Makefile
==
--- head/Makefile Wed Jun 20 16:10:10 2018(r335449)
+++ head/Makefile Wed Jun 20 16:10:14 2018(r335450)
@@ -143,7 +143,7 @@ TGTS= all all-man buildenv buildenvvars buildkernel bu
stage-packages \
create-packages-world create-packages-kernel create-packages \
packages installconfig real-packages sign-packages package-pkg \
- print-dir test-system-compiler
+ print-dir test-system-compiler test-system-linker
# These targets require a TARGET and TARGET_ARCH be defined.
XTGTS= native-xtools native-xtools-install xdev xdev-build xdev-install \
@@ -168,7 +168,7 @@ META_TGT_WHITELIST+= \
_* build32 buildfiles buildincludes buildkernel buildsoft \
buildworld everything kernel-toolchain kernel-toolchains kernel \
kernels libraries native-xtools showconfig test-system-compiler \
- tinderbox toolchain \
+ test-system-linker tinderbox toolchain \
toolchains universe world worlds xdev xdev-build
.ORDER: buildworld installworld
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Jun 20 16:10:10 2018(r335449)
+++ head/Makefile.inc1 Wed Jun 20 16:10:14 2018(r335450)
@@ -97,9 +97,74 @@ MK_GCC_BOOTSTRAP=no
# Pull in COMPILER_TYPE and COMPILER_FREEBSD_VERSION early. Pull it from the
# tree to be friendlier to foreign OS builds. It's safe to do so
unconditionally
# here since we will always have the right make, unlike in src/Makefile
+# Don't include bsd.linker.mk yet until XBINUTILS is handled (after
src.opts.mk)
+_NO_INCLUDE_LINKERMK= t
.include "share/mk/bsd.compiler.mk"
+.undef _NO_INCLUDE_LINKERMK
+# src.opts.mk depends on COMPILER_FEATURES
.include "share/mk/src.opts.mk"
+.if ${TARGET} == ${MACHINE}
+TARGET_CPUTYPE?=${CPUTYPE}
+.else
+TARGET_CPUTYPE?=
+.endif
+.if !empty(TARGET_CPUTYPE)
+_TARGET_CPUTYPE=${TARGET_CPUTYPE}
+.else
+_TARGET_CPUTYPE=dummy
+.endif
+.if ${TARGET} == "arm"
+.if ${TARGET_ARCH:Marmv[67]*} != "" && ${TARGET_CPUTYPE:M*soft*} == ""
+TARGET_ABI=gnueabihf
+.else
+TARGET_ABI=gnueabi
+.endif
+.endif
+MACHINE_ABI?= unknown
+MACHINE_TRIPLE?=${MACHINE_ARCH:S/amd64/x86_64/:C/hf$//:S/mipsn32/mips64/}-${MACHINE_ABI}-freebsd12.0
+TARGET_ABI?= unknown
+TARGET_TRIPLE?=
${TARGET_ARCH:S/amd64/x86_64/:C/hf$//:S/mipsn32/mips64/}-${TARGET_ABI}-freebsd12.0
+
+# Handle external binutils.
+.if defined(CROSS_TOOLCHAIN_PREFIX)
+CROSS_BINUTILS_PREFIX?=${CROSS_TOOLCHAIN_PREFIX}
+.endif
+# If we do not have a bootstrap binutils (because the in-tree one does not
+# support the target architecture), provide a default cross-binutils prefix.
+# This allows riscv64 builds, for example, to automatically use the
+# riscv64-binutils port or package.
+.if !make(showconfig)
+.if !empty(BROKEN_OPTIONS:MBINUTILS_BOOTSTRAP) && \
+${MK_LLD_BOOTSTRAP} == "no" && \
+!defined(CROSS_BINUTILS_PREFIX)
+CROSS_BINUTILS_PREFIX=/usr/local/${TARGET_TRIPLE}/bin/
+.if !exists(${CROSS_BINUTILS_PREFIX})
+.error In-tree binutils does not support the ${TARGET_ARCH} architecture.
Re: svn commit: r335402 - head/sbin/veriexecctl
I want to preface this by saying: this discussion should be happening
in either arch@ or phabricator, after the patch series was temporarily
reverted pending necessary improvements. I have asked for the series
to be reverted and am still waiting on that.
I am happy to promise to respond promptly to updates on this
particular series so you are not waiting for two years again.
I think it's quite close to something reasonably general, but as-is,
it is worse than useless — it promises a security feature but _does
not deliver it_, which is the "emperor's new clothes" of security.
On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty wrote:
> Conrad Meyer wrote:
>> First and foremost: nothing is actually signed, anywhere. The
>
> The signing of manifests is external. The veriexecctl tool is I assume
> a straight copy of what's in NetBSD (I've not looked at it in at least a
> decade).
The signing of manifests does not exist in the patch series committed.
(If NetBSD does something broken, that is not an excuse to copy it.)
> A veriexec loader that leverages signed manifests requires some signing
> infra. That's a big topic all by itself.
It *may* require that. However, even without that, admins could
reasonably manage their own PKI in some fashion, independent of
FreeBSD's infra. But it requires the support code to verify
signatures, as in the "verify" part of veriexec, which is wholly
absent.
> As I mentioned in my talk at BSDCan,
(FWIW, I was not at your talk, and it is not a justification for bad
design or implementation anyway.)
> the signing server we use is open
> source and handles pretty much anything OpenSSL can, as well as OpenPGP
> (and others).
It doesn't really matter if there's a signing server, because nothing
in the patch series *verifies* signatures.
> Tweaking the veriexec loader to only process manifests after
> verification is not hard
Then I even more do not understand why it was not done prior to commit.
> - one of the first things I did when pulling
> veriexec into Junos almost 15 years ago.
>
>> As a corollary to the above, the name "signature file" is used
>> repeatedly in the code, which is misleading. The file contains hashes
>> (digests), not signatures (MACs). The file itself is unsigned.
>> Nothing about this has signatures.
>
> NetBSD refers to the hashes as fingerprints - AFAIK that terminology is
> retained.
Fingerprints is fine, "signatures" is not. "Signatures file" is used
to refer to the manifest file, which only contains fingerprints, in
multiple locations in the code.
> If the term signature is used to refer to anything other than the signed
> manifests that should be fixed.
Should have been fixed prior to commit, yes.
>> There's absolutely no reason to use sha1 or ripemd in new designs.
>> These should be removed.
>
> Sorry I disagree - not with ripem (we never supported that or any of the
> non-NIST approved hashes), but sha1 is still approved by NIST for
> firmware integrity checks - which is what this is, and sha1 is cheaper
> than sha256.
Again — this is a discussion for arch or phabricator, with the series
reverted first.
I reckon you're wrong. If you're unwilling to trust me, I believe you
should get and accept input from a 3rd party vaguely familiar with
cryptography (maybe cperciva@ or gordon@ or delphij@) before
introducing SHA1 or Ripe-MD in a novel integrity-protection design.
(Some modern Intel and AMD CPUs have intrinsics support for SHA-2, and
on those machines SHA-2 256 is about the same performance as SHA-1.)
Performance is absolutely not a reason to use a known weak hash
algorithm in 2018, especially when the feature as-committed has so
many other glaring performance problems. If you care about MAC
performance in a secure algorithm in 2018, perhaps look at any of
these great options:
* SHA-3 (Keccak)
* Blake2-b
* Poly1305-{AES,Salsa,ChaCha}
All have highly efficient software implementations that smoke SHA-2
and don't have SHA-1's known weakness. Blake2 is even in-tree
already.
> As I mentioned in my talk we've included support for sha256 for 10+
> years,
FreeBSD has had this code for 0 years. It's a novel feature here.
There is no reason to introduce SHA-1 in novel security features in
2018.
> but do not plan to drop sha1 until NIST deprecate it for that
> purpose since boot time is a very sensitive subject for us.
See above. There are lots of secure hashes faster than SHA-1 without
its known weaknesses.
>> The patchset is littered with style issues. One fairly obvious issue
>> is mixed indentation styles — some files vary between space and tab
>> indentation from line to line.
>
> You can probably blame me for some of that.
> I only recently found a style9.el that does a half decent job of
> formatting per style(9).
To commit to the tree, you are supposed to be able to get it right, or
at least close to right.
>> Please revert this patchset. It's not ready.
>> - Maybe use HMACs instead of raw hashes
>
> Why?
A
svn commit: r335451 - head/share/man/man5
Author: bdrewery Date: Wed Jun 20 16:15:03 2018 New Revision: 335451 URL: https://svnweb.freebsd.org/changeset/base/335451 Log: Regenerate for SYSTEM_LINKER Modified: head/share/man/man5/src.conf.5 Modified: head/share/man/man5/src.conf.5 == --- head/share/man/man5/src.conf.5 Wed Jun 20 16:10:14 2018 (r335450) +++ head/share/man/man5/src.conf.5 Wed Jun 20 16:15:03 2018 (r335451) @@ -1,6 +1,6 @@ .\" DO NOT EDIT-- this file is @generated by tools/build/options/makeman. .\" $FreeBSD$ -.Dd June 15, 2018 +.Dd June 20, 2018 .Dt SRC.CONF 5 .Os .Sh NAME @@ -1481,6 +1481,22 @@ The and .Va WITHOUT_GCC options control those. +.It Va WITHOUT_SYSTEM_LINKER +Set to not opportunistically skip building a cross-linker during the +bootstrap phase of the build. +Normally, if the currently installed linker matches the planned bootstrap +linker type and revision, then it will not be built. +This does not prevent a linker from being built for installation though, +only for building one for the build itself. +The +.Va WITHOUT_LLD +and +.Va WITHOUT_BINUTILS +options control those. +.Pp +This option is only relevant when +.Va WITH_LLD_BOOTSTRAP +is set. .It Va WITHOUT_TALK Set to not build or install .Xr talk 1 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
Ian,
On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore wrote:
> And I request exactly the opposite: reject the complaining of people
> who think all the world is a 256-core 5ghz server
First: no need to be so rude to other committers. The hyperbole
doesn't help anyone and doesn't help communicate your point clearly.
It's just verbal diarrhea. Please try to be excellent to each other.
> and leave in the
> option to use faster algorithms on real-world hardware used by real-
> world vendors who need some option other than "rev your hardware every
> 18 months to keep up with the software or get out of the business."
Second: You have very much misread my complaints and very much
misunderstand the cryptographic algorithm landscape if that is your
conclusion.
See my earlier email,
https://lists.freebsd.org/pipermail/svn-src-all/2018-June/166107.html
; in particular I would quote:
> Performance is absolutely not a reason to use a known weak hash
> algorithm in 2018, especially when the feature as-committed has so
> many other glaring performance problems. If you care about MAC
> performance in a secure algorithm in 2018, perhaps look at any of
> these great options:
>
> * Blake2-b
> * Poly1305-{AES,Salsa,ChaCha}
>
> They have highly efficient software implementations *that smoke SHA-2
> and don't have SHA-1's known weakness*. Blake2 is even in-tree
> already.
(Removing Keccak, which I had forgotten has crap performance in
software — mea culpa.)
> Stronger algorithm options, yes. Even making stronger options the
> default, yes.
"More secure than SHA1" and "faster than SHA1" are *not* mutually exclusive.
> But removing viable options which are endorsed by the
> people who actually set the standards, no.
No one actually endorses SHA1 in new designs. No one endorses RIPEMD at all.
Please look at the actual code size and layout of the sha1 support
module and tell me that is a burden for Juniper to maintain in their
downstream tree, rather than just getting angry about the suggestion
we don't introduce novel, insecurity cryptographic designs.
Thank you,
Conrad
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
On Wed, Jun 20, 2018 at 10:05:16AM -0600, Warner Losh wrote: > On Wed, Jun 20, 2018 at 10:03 AM, Konstantin Belousov > wrote: > > > On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote: > > > On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote: > > > > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > > > > > > > > > > On 2018-06-17 07:32, Eugene Grosbein wrote: > > > > > > > > > > > > 17.06.2018 10:18, Allan Jude wrote: > > > > > > > > > > > > > > > > > > > > Author: allanjude > > > > > > > Date: Sun Jun 17 03:18:56 2018 > > > > > > > New Revision: 335276 > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/335276 > > > > > > > > > > > > > > Log: > > > > > > > gptboot, zfsboot, gptzfsboot: Enable the video and serial > > consoles early > > > > > > > > > > > > > > Normally the serial console is not enabled until /boot.config > > is read and > > > > > > > we know how the serial console should be > > configured. Initialize the > > > > > > > consoles early in 'dual' mode (serial & keyboard) with a > > default serial > > > > > > > rate of 115200. Then serial is re-initialized once the disk is > > decrypted > > > > > > > and the /boot.config file can be read. > > > > > > > > > > > > > > This allows the GELIBoot passphrase to be provided via the > > serial console. > > > > > > > > > > > > > > PR: 221526 > > > > > > > Requested by: many > > > > > > > Reviewed by:imp > > > > > > > Sponsored by: Klara Systems > > > > > > > Differential Revision: https://reviews.freebsd.org/D15862 > > > > > > I had several cases when booting FreeBSD/amd64 with motherboard > > having no serial ports > > > > > > hang hard early at boot unless I rebuilt boot media configuring it > > to NOT try accessing > > > > > > missing serial ports. I even could reproduce that with VirtualBox > > machine configured > > > > > > with no serial ports (not same as existing bug inactive serial > > port). > > > > > > > > > > > > Should there be some way to disable this serial ports > > configuration at compile time? > > > > > > > > > > > > > > > > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > > > > > one by default, because it is safer. Then you can just use > > > > > 'gptboot-serial' if you want serial support. > > > > > > > > > > This will likely make Warner a bit sad, since we are just finally > > > > > getting around to reducing the number of different bootcode files. > > > > I think we should follow the hardware trends there and apply a policy > > > > where new features are not added to the CSM boot. All modern machines > > > > can be booted in UEFI mode, and if some modern machine cannot, then we > > > > need it fixed. We should encourage users to make new installs boot by > > > > UEFI. > > > > > > > > The feature from the commit is only relevant for machines that require > > > > CSM boot or do not have UEFI option at all, am I right ? With the > > policy > > > > applied, an additional CSM-boot bootblock would be not shipped. > > > > > > > > > > I think it is far too early to say that the code for booting without > > > efi is abandonware. I have half a dozen x86 boxes in use here, and only > > > one of them is even able to boot efi, and its default resolution in efi > > > mode confuses the kvm switch it's connected to, so even on that I have > > > to use legacy bios boot. > > I do not propose to abandon bios boot, or even to declare it legacy > > with the proper meaning. I mean that CSM is disappearing on the newest > > platforms, and should become only used on old machines or i386. With that > > attitude, adding a features for it, esp. by the cost of the user confusion, > > is not worth the efforts. It still should be maintained for the foreseable > > future. > > > > If the machines where you get the trouble is newer than say 5 years, > > then they should boot with UEFI. If not, the problem in loader.efi > > needs to be fixed. > > > > There is no problem in loader.efi that's specific to geli. It already uses > the UEFI boot loader config. While there's some issues downstream (eg > kernel messages), this specific issue is a non-issue for loader.efi. I referenced the problems that Ian has with UEFI boot on his machines, not the serial console and geli change above. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Wed, 2018-06-20 at 09:30 -0700, Conrad Meyer wrote:
> Ian,
>
> On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore wrote:
> >
> > And I request exactly the opposite: reject the complaining of people
> > who think all the world is a 256-core 5ghz server
> First: no need to be so rude to other committers. The hyperbole
> doesn't help anyone and doesn't help communicate your point clearly.
> It's just verbal diarrhea. Please try to be excellent to each other.
>
> >
> > and leave in the
> > option to use faster algorithms on real-world hardware used by real-
> > world vendors who need some option other than "rev your hardware every
> > 18 months to keep up with the software or get out of the business."
> Second: You have very much misread my complaints and very much
> misunderstand the cryptographic algorithm landscape if that is your
> conclusion.
>
> See my earlier email,
> https://lists.freebsd.org/pipermail/svn-src-all/2018-June/166107.html
> ; in particular I would quote:
>
> >
> > Performance is absolutely not a reason to use a known weak hash
> > algorithm in 2018, especially when the feature as-committed has so
> > many other glaring performance problems. If you care about MAC
> > performance in a secure algorithm in 2018, perhaps look at any of
> > these great options:
> >
> > * Blake2-b
> > * Poly1305-{AES,Salsa,ChaCha}
> >
> > They have highly efficient software implementations *that smoke SHA-2
> > and don't have SHA-1's known weakness*. Blake2 is even in-tree
> > already.
> (Removing Keccak, which I had forgotten has crap performance in
> software — mea culpa.)
>
> >
> > Stronger algorithm options, yes. Even making stronger options the
> > default, yes.
> "More secure than SHA1" and "faster than SHA1" are *not* mutually exclusive.
>
> >
> > But removing viable options which are endorsed by the
> > people who actually set the standards, no.
> No one actually endorses SHA1 in new designs. No one endorses RIPEMD at all.
>
> Please look at the actual code size and layout of the sha1 support
> module and tell me that is a burden for Juniper to maintain in their
> downstream tree, rather than just getting angry about the suggestion
> we don't introduce novel, insecurity cryptographic designs.
>
> Thank you,
> Conrad
>
I have zero interest in arguing with you (or anybody) about this. I've
expessed my opinion on the subject and have nothing more to say.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Wed, Jun 20, 2018 at 9:30 AM, Conrad Meyer wrote: > > Please look at the actual code size and layout of the sha1 support > module and tell me that is a burden for Juniper to maintain in their > downstream tree, rather than just getting angry about the suggestion > we don't introduce novel, insecurity cryptographic designs. > I have no problem removing the SHA1 and RIPEMD implementations. It's a minor change and very little code for others to have to maintain if needed. That was the intention of fingerprint module implementation, to try to make it easy to add/remote different algorithms. It could even potentially be done as a port, if people are keen to having to pre-load a module to get the support (I know that that's a bit of a grey area without a verified loader and secureboot or similar functionality to protect integrity.) I think some of the issue was this code has been looking for eyes to give a good look for over 2 years (even before the review was posted, it was available in my GitHub branch for at least 1 year prior, if not longer.) As for some of the other issues, note my comment in the review https://reviews.freebsd.org/D8554: "Note I have some updates that I have been working on to handle the meta-data store better in SMP environments. So there will be updates to these reviews, hopefully in the near future, time permitting." And I was working on those sets of changes, when work and family didn't steal away time. I was told that some discussion happened at BSDCan this year in such that veriexec should go in as-is so it would be there, which is why the commit happened (given the review was approved to land back in January.) I suppose I should have just kept with my original intention to fix the issues and update the review(s). Hopefully now it will mean it will get the right eyes on it. I don't believe I need to dig up all the e-mail threads and chat logs for IRC where I asked for help and was given pointers to folks to contact and we ended up here. It's a better use of everyone's time to just cool down, back things out, get new reviews updated and provide constructive feedback. So far this experience (I am not pointing at you here) has been a mixed set of constructive comments and outright flaming. The latter of which is never going to help get the right results and could be one of the reasons that a number of folks give up contributing to FreeBSD. -Steve ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335394 - head
On 6/19/18 4:40 PM, Bryan Drewery wrote: > Author: bdrewery > Date: Tue Jun 19 23:40:42 2018 > New Revision: 335394 > URL: https://svnweb.freebsd.org/changeset/base/335394 > > Log: > Fix detection for binutils bootstrap package. > > The path was changed recently in the port to be the full target triple. Except this doesn't work either. The TARGET_TRIPLE the package uses is based on the build _host_ machine, so if you are building a current MIPS world on an 11.2 host (for example), TARGET_TRIPLE will use '12.0' but won't work because the package installed on the host will be using '11.2'. I want to revert the cross binutils packages back to the old naming scheme as that makes more sense (and it is what configure scripts keep looking for, I have to create symlinks for gdb's ./configure script to DTRT when cross-building for example.) -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335394 - head
On 6/20/2018 10:00 AM, John Baldwin wrote: > On 6/19/18 4:40 PM, Bryan Drewery wrote: >> Author: bdrewery >> Date: Tue Jun 19 23:40:42 2018 >> New Revision: 335394 >> URL: https://svnweb.freebsd.org/changeset/base/335394 >> >> Log: >> Fix detection for binutils bootstrap package. >> >> The path was changed recently in the port to be the full target triple. > > Except this doesn't work either. The TARGET_TRIPLE the package uses is based > on the build _host_ machine, so if you are building a current MIPS world > on an 11.2 host (for example), TARGET_TRIPLE will use '12.0' but won't work > because the package installed on the host will be using '11.2'. > Oops... > I want to revert the cross binutils packages back to the old naming scheme > as that makes more sense (and it is what configure scripts keep looking for, > I have to create symlinks for gdb's ./configure script to DTRT when > cross-building > for example.) > I'm all for reverting that. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
svn commit: r335452 - in head: . share/mk
Author: bdrewery
Date: Wed Jun 20 17:20:39 2018
New Revision: 335452
URL: https://svnweb.freebsd.org/changeset/base/335452
Log:
Reduce exec and fstat overhead for non-build targets.
This is mostly targetting 'make showconfig' and 'make test-system-*' for
the benefit of makeman and universe-one-clang work.
Sponsored by: Dell EMC
Modified:
head/Makefile.inc1
head/Makefile.libcompat
head/share/mk/bsd.compiler.mk
head/share/mk/bsd.init.mk
head/share/mk/local.meta.sys.mk
head/share/mk/src.sys.obj.mk
head/share/mk/sys.mk
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Jun 20 16:15:03 2018(r335451)
+++ head/Makefile.inc1 Wed Jun 20 17:20:39 2018(r335452)
@@ -50,6 +50,10 @@
.error "Both TARGET and TARGET_ARCH must be defined."
.endif
+.if make(showconfig) || make(test-system-*)
+_MKSHOWCONFIG= t
+.endif
+
SRCDIR?= ${.CURDIR}
LOCALBASE?=/usr/local
@@ -175,7 +179,8 @@ WANT_COMPILER_TYPE= gcc
WANT_COMPILER_TYPE=
.endif
-.if !defined(WANT_COMPILER_FREEBSD_VERSION)
+.if !defined(WANT_COMPILER_FREEBSD_VERSION) && !make(showconfig) && \
+!make(test-system-linker)
.if ${WANT_COMPILER_TYPE} == "clang"
WANT_COMPILER_FREEBSD_VERSION_FILE= lib/clang/freebsd_cc_version.h
WANT_COMPILER_FREEBSD_VERSION!= \
@@ -203,8 +208,9 @@ WANT_COMPILER_VERSION!= \
# GCC cannot be used for cross-arch yet. For clang we pass -target later if
# TARGET_ARCH!=MACHINE_ARCH.
.if ${MK_SYSTEM_COMPILER} == "yes" && \
+defined(WANT_COMPILER_FREEBSD_VERSION) && \
(${MK_CLANG_BOOTSTRAP} == "yes" || ${MK_GCC_BOOTSTRAP} == "yes") && \
-!make(showconfig) && !make(xdev*) && \
+!make(xdev*) && \
${X_COMPILER_TYPE} == ${WANT_COMPILER_TYPE} && \
(${X_COMPILER_TYPE} == "clang" || ${TARGET_ARCH} == ${MACHINE_ARCH}) && \
${X_COMPILER_VERSION} == ${WANT_COMPILER_VERSION} && \
@@ -228,7 +234,8 @@ WANT_LINKER_TYPE= bfd
WANT_LINKER_TYPE=
.endif
-.if !defined(WANT_LINKER_FREEBSD_VERSION)
+.if !defined(WANT_LINKER_FREEBSD_VERSION) && !make(showconfig) && \
+!make(test-system-compiler)
.if ${WANT_LINKER_TYPE} == "lld"
WANT_LINKER_FREEBSD_VERSION_FILE= lib/clang/include/lld/Common/Version.inc
WANT_LINKER_FREEBSD_VERSION!= \
@@ -246,8 +253,9 @@ WANT_LINKER_FREEBSD_VERSION=
.endif # !defined(WANT_LINKER_FREEBSD_VERSION)
.if ${MK_SYSTEM_LINKER} == "yes" && \
+defined(WANT_LINKER_FREEBSD_VERSION) && \
(${MK_LLD_BOOTSTRAP} == "yes") && \
-!make(showconfig) && !make(xdev*) && \
+!make(xdev*) && \
${X_LINKER_TYPE} == ${WANT_LINKER_TYPE} && \
${X_LINKER_VERSION} == ${WANT_LINKER_VERSION} && \
${X_LINKER_FREEBSD_VERSION} == ${WANT_LINKER_FREEBSD_VERSION}
@@ -437,6 +445,7 @@ BUILDENV_SHELL?=${SHELL}
BUILDENV_SHELL?=/bin/sh
.endif
+.if !defined(_MKSHOWCONFIG)
.if !defined(SVN_CMD) || empty(SVN_CMD)
. for _P in /usr/bin /usr/local/bin
. for _S in svn svnlite
@@ -505,6 +514,7 @@ EXTRA_REVISION= _${_BRANCH:C/.*-p([0-9]+$)/\1/}
.endif
PKG_VERSION= ${_REVISION}${EXTRA_REVISION}
.endif
+.endif # !defined(_MKSHOWCONFIG)
KNOWN_ARCHES?= aarch64/arm64 \
amd64 \
@@ -541,11 +551,13 @@ _t= ${TARGET_ARCH}/${TARGET}
.endif
.endfor
+.if !defined(_MKSHOWCONFIG)
_CPUTYPE!= MAKEFLAGS= CPUTYPE=${_TARGET_CPUTYPE} ${MAKE} -f /dev/null \
-m ${.CURDIR}/share/mk MK_AUTO_OBJ=no -V CPUTYPE
.if ${_CPUTYPE} != ${_TARGET_CPUTYPE}
.error CPUTYPE global should be set with ?=.
.endif
+.endif
.if make(buildworld)
BUILD_ARCH!= uname -p
.if ${MACHINE_ARCH} != ${BUILD_ARCH}
@@ -763,7 +775,7 @@ LIBCOMPAT= SOFT
# to get updated host tools.
.if ${MK_META_MODE} == "yes" && defined(NO_CLEAN) && \
!defined(NO_META_IGNORE_HOST) && !defined(NO_META_IGNORE_HOST_HEADERS) && \
-!make(showconfig)
+!defined(_MKSHOWCONFIG)
# r318736 - ino64 major ABI breakage
META_MODE_BAD_ABI_VERS+= 1200031
@@ -881,37 +893,33 @@ _cleanobj_fast_depend_hack: .PHONY
# 20180525 r334224 vadvise
# 20180604 r334626 brk sbrk
.for f in brk exect fstat fstatat fstatfs getdirentries getfsstat sbrk
setlogin shmat sigreturn statfs vadvise
-.if exists(${OBJTOP}/lib/libc/.depend.${f}.o)
- @if egrep -qw '${f}\.[sS]' \
- ${OBJTOP}/lib/libc/.depend.${f}.o; then \
- echo Removing stale dependencies for ${f} syscall wrappers; \
+ @if [ -e "${OBJTOP}/lib/libc/.depend.${f}.o" ] && \
+ egrep -qw '${f}\.[sS]' ${OBJTOP}/lib/libc/.depend.${f}.o; then \
+ echo "Removing stale dependencies for ${f} syscall wrappers"; \
rm -f ${OBJTOP}/lib/libc/.depend.${f}.* \
${LIBCOMPAT:D${LIBCOMPAT_OBJTOP}/lib/libc/.depend.${f}.*}; \
fi
-.endif
.endfor
# 20170607 remove stale dependencies for utimens* wrappers removed in r319663
.for f in futimens utimensat
-.if exists(${OBJTOP}/lib/libc/.depend.${f}.o)
- @if egrep -q '/$
Re: svn commit: r335402 - head/sbin/veriexecctl
Hi Simon, Jonathan points out some of my comments were more acerbic than necessary. I apologize for that. I'd like to try to rephrase them in a more clear way. On Wed, Jun 20, 2018 at 8:43 AM, Conrad Meyer wrote: > On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty wrote: >> As I mentioned in my talk at BSDCan, > > (FWIW, I was not at your talk, and it is not a justification for bad > design or implementation anyway.) I said before and I'll repeat: I think this design is pretty close to a reasonable security feature. I think it currently has a number of serious — but addressable — flaws, some of which I have tried to outline. > ... > Why is this either necessary or helpful to be in the FreeBSD tree > as-is? I don't think it is, and you should revert it. Please. I > don't know if there's a maintainer timeout on this kind of thing, but, > you are forewarned. Sorry, this was a poor choice of words. I mean to say something like: I asked for a revert in an earlier email, and this reply did not address the primary reason for the revert, so I am still asking for a revert. I can do it myself, but I would like to give the committer the opportunity to do it themselves. (In private, Stephen has let me know he will do so when he gets back to his FreeBSD machines, so there's no need for that anyway.) All the best, Conrad ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Tue, Jun 19, 2018 at 8:34 PM Conrad Meyer wrote: > Please revert this patchset. It's not ready. > I'm not sure I understand the need to revert the patches. They may need some refinement, but they also do provide some functionality upon which you can build the tooling that Simon discussed. Unless I missed something, this feature only impacts the system when it is specifically compiled in. In cases like that, I think its reasonable to give the committer some time to refine them in place prior to the code slush/freeze, at which point we can decide what to do. Jonathan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan wrote: > And I was working on those sets of changes, when work and family didn't > steal away time. I was told that some discussion happened at BSDCan this > year in such that veriexec should go in as-is so it would be there, which is why > the commit happened (given the review was approved to land back in January.) I will readily admit that I was probably the source of this. My reasoning was fairly simple: when a review has been open for over a year with no action, it seems like the submitter should be able to commit it without waiting for more review, if they are confident in their change. I stand by that (and, in fact, would substitute something shorter for "over a year"). (Of course, if the submitter has other reasons for delaying the commit, that's their prerogative, and I wasn't intending to push Steve to commit this before he was ready.) Jonathan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On Wed, Jun 20, 2018 at 10:58 AM Jonathan T. Looney wrote: > > On Tue, Jun 19, 2018 at 8:34 PM Conrad Meyer wrote: >> >> Please revert this patchset. It's not ready. > > > I'm not sure I understand the need to revert the patches. They may need some > refinement, but they also do provide some functionality upon which you can > build the tooling that Simon discussed. > > Unless I missed something, this feature only impacts the system when it is > specifically compiled in. In cases like that, I think its reasonable to give > the committer some time to refine them in place prior to the code > slush/freeze, at which point we can decide what to do. +1 for all points. I do agree with others that SHA-1 support should not be included (unless I have missed something, but I think firmware integrity check counts as a "Digital signature" verification, according to SP 800-131A "9 Hash algorithms", SHA-1 verification should only be used for legacy usage, which does not apply on FreeBSD because this is new feature). But even that, given the code only impacts systems that have it explicitly compiled in, it's reasonable to give the committer more time to make further improvements rather than reverting it as a whole as this would give the code more exposure. Cheers, ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335278 - head/bin/pwd
On 6/18/18 10:26 PM, Eitan Adler wrote: > On 18 June 2018 at 10:57, John Baldwin wrote: >> On 6/16/18 10:14 PM, Eitan Adler wrote: >>> Author: eadler >>> Date: Sun Jun 17 05:14:50 2018 >>> New Revision: 335278 >>> URL: https://svnweb.freebsd.org/changeset/base/335278 >>> >>> Log: >>> pwd: mark usage as dead >> >> You keep committing changes like this and ignoring e-mails about them. > > I replied both the first time and this time. I may have > (accidentally?) ignored similar emails though. The question I have is > other than the mild code churn what's the harm? > >> What broken compiler are you using that doesn't properly inherit __dead2 >> from the call to exit()? > > In this case, scan-build50 was getting annoyed. In this case, someone in a private reply suggested that marking usage 'static' is probably the better fix than marking it __dead2. If that change satisfies scan-build then I think that is a better approach. Also, the proper place for __dead2 if you were going to use it would be on the prototype, not the definition. That is, if usage() were intended to be an exported function like abort() or exit(), then you want to mark the prototype in the header as __dead2 so that the compiler will understand that those functions don't return. However, that annotation is only useful on the prototype, not the definition. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Wed, 20 Jun 2018 19:03:15 +0300 Konstantin Belousov schrieb: > On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote: > > On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote: > > > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote: > > > > > > > > On 2018-06-17 07:32, Eugene Grosbein wrote: > > > > > > > > > > 17.06.2018 10:18, Allan Jude wrote: > > > > > > > > > > > > > > > > > Author: allanjude > > > > > > Date: Sun Jun 17 03:18:56 2018 > > > > > > New Revision: 335276 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/335276 > > > > > > > > > > > > Log: > > > > > > gptboot, zfsboot, gptzfsboot: Enable the video and serial > > > > > > consoles early > > > > > > > > > > > > Normally the serial console is not enabled until /boot.config is > > > > > > read and > > > > > > we know how the serial console should be configured. Initialize > > > > > > the > > > > > > consoles early in 'dual' mode (serial & keyboard) with a default > > > > > > serial > > > > > > rate of 115200. Then serial is re-initialized once the disk is > > > > > > decrypted > > > > > > and the /boot.config file can be read. > > > > > > > > > > > > This allows the GELIBoot passphrase to be provided via the serial > > > > > > console. > > > > > > > > > > > > PR: 221526 > > > > > > Requested by: many > > > > > > Reviewed by: imp > > > > > > Sponsored by: Klara Systems > > > > > > Differential Revision:https://reviews.freebsd.org/D15862 > > > > > I had several cases when booting FreeBSD/amd64 with motherboard > > > > > having no > > > > > serial ports hang hard early at boot unless I rebuilt boot media > > > > > configuring it > > > > > to NOT try accessing missing serial ports. I even could reproduce > > > > > that with > > > > > VirtualBox machine configured with no serial ports (not same as > > > > > existing bug > > > > > inactive serial port). > > > > > > > > > > Should there be some way to disable this serial ports configuration > > > > > at compile > > > > > time? > > > > > > > > > > > > > > > > > > > I think what we'll do it compile it both ways, and use the non-serial > > > > one by default, because it is safer. Then you can just use > > > > 'gptboot-serial' if you want serial support. > > > > > > > > This will likely make Warner a bit sad, since we are just finally > > > > getting around to reducing the number of different bootcode files. > > > I think we should follow the hardware trends there and apply a policy > > > where new features are not added to the CSM boot. All modern machines > > > can be booted in UEFI mode, and if some modern machine cannot, then we > > > need it fixed. We should encourage users to make new installs boot by > > > UEFI. > > > > > > The feature from the commit is only relevant for machines that require > > > CSM boot or do not have UEFI option at all, am I right ? With the policy > > > applied, an additional CSM-boot bootblock would be not shipped. > > > > > > > I think it is far too early to say that the code for booting without > > efi is abandonware. I have half a dozen x86 boxes in use here, and only > > one of them is even able to boot efi, and its default resolution in efi > > mode confuses the kvm switch it's connected to, so even on that I have > > to use legacy bios boot. > I do not propose to abandon bios boot, or even to declare it legacy > with the proper meaning. I mean that CSM is disappearing on the newest > platforms, and should become only used on old machines or i386. With that > attitude, adding a features for it, esp. by the cost of the user confusion, > is not worth the efforts. It still should be maintained for the foreseable > future. > > If the machines where you get the trouble is newer than say 5 years, > then they should boot with UEFI. If not, the problem in loader.efi > needs to be fixed. > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" I'm a bit confused right now. I lived under the impression that the PCengines APU 2C is a very common piece of hardware amongst FreeBSD users and developers: https://www.pcengines.ch/apu2c4.htm This piece of hardware is still non-UEFI, although coreboot seems to support UEFI. So, in the "opensource market", there is still pretty recent hadware around with non-UEFI capabilities. I was wondering why the APU wasn't able to boot with an early enabled serial console, although this piece of hardware is serial-console only and we use "tip" to connect. The kernel I use is is customised - so if there is a prerequisite to have compiled in, please let me know. Regards, Oliver - -- O. Hartmann Ich widerspreche der Nutzung oder "Ubermittlung meiner Daten f"ur Werbezwecke oder f
svn commit: r335454 - head/usr.bin/ar
Author: emaste Date: Wed Jun 20 18:43:17 2018 New Revision: 335454 URL: https://svnweb.freebsd.org/changeset/base/335454 Log: usr.bin/ar: use standard 2-Clause FreeBSD license Many licenses on ar files contained small variations from the standard FreeBSD license text. To avoid license proliferation switch to the usual 2-clause FreeBSD license after obtaining permission from all copyright holders. Approved by: jkoshy, kaiw, kientzle Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D14561 Modified: head/usr.bin/ar/ar.c head/usr.bin/ar/read.c head/usr.bin/ar/util.c Modified: head/usr.bin/ar/ar.c == --- head/usr.bin/ar/ar.cWed Jun 20 17:37:55 2018(r335453) +++ head/usr.bin/ar/ar.cWed Jun 20 18:43:17 2018(r335454) @@ -1,4 +1,6 @@ /*- + * SPDX-License-Identifier: BSD-3-Clause + * * Copyright (c) 2007 Kai Wang * Copyright (c) 2007 Tim Kientzle * Copyright (c) 2007 Joseph Koshy @@ -8,22 +10,22 @@ * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer - *in this position and unchanged. + *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. */ /*- Modified: head/usr.bin/ar/read.c == --- head/usr.bin/ar/read.c Wed Jun 20 17:37:55 2018(r335453) +++ head/usr.bin/ar/read.c Wed Jun 20 18:43:17 2018(r335454) @@ -1,4 +1,6 @@ /*- + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD + * * Copyright (c) 2007 Kai Wang * Copyright (c) 2007 Tim Kientzle * All rights reserved. @@ -7,22 +9,22 @@ * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer - *in this position and unchanged. + *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND
Re: svn commit: r335402 - head/sbin/veriexecctl
On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan
wrote:
And I was working on those sets of changes, when work and family
didn't
steal away time. I was told that some discussion happened at BSDCan
this
year in such that veriexec should go in as-is so it would be there,
which
is why
the commit happened (given the review was approved to land back in
January.)
I will readily admit that I was probably the source of this. My
reasoning
was fairly simple: when a review has been open for over a year with no
action, it seems like the submitter should be able to commit it
without
waiting for more review, if they are confident in their change. I
stand by
that (and, in fact, would substitute something shorter for "over a
year").
([...] I wasn't intending to push Steve to commit
this before he was ready.)
I suspect I was part of that push, and while it's provoked some
discussion I still think it was the right course of action. Simon and I
chatted about these changes at BSDCan (starting with my apologies for
not doing the asked-for review two years ago!) and I suggested that,
since the changes had been accepted in Phabricator in January and nobody
had raised any objections since then (see: D85{61,62,75}), it would
probably be better to commit and iterate than to continue waiting for an
unspecified number of additional reviews that might never come. Now that
the code has landed it's sparked some lively discussion about potential
improvements, but that's a much better situation than the silence Steve
heard for a long time in Phabricator.
So: is there a strong reason why a backout-and-re-commit approach is
superior to iterating on the code in-tree? SHA-1 doesn't give me the
warm fuzzies either, but I don't see why the whole framework has to be
backed out rather than just receive incremental improvements, e.g.,
disabling or removing SHA-1 while keeping it easy for downstream
consumers to re-enable/re-add whatever algorithms their customers want.
Jon
--
jonat...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335456 - head/share/man/man7
Author: trasz Date: Wed Jun 20 19:16:51 2018 New Revision: 335456 URL: https://svnweb.freebsd.org/changeset/base/335456 Log: Improve wording. MFC after:2 weeks Modified: head/share/man/man7/development.7 Modified: head/share/man/man7/development.7 == --- head/share/man/man7/development.7 Wed Jun 20 18:51:38 2018 (r335455) +++ head/share/man/man7/development.7 Wed Jun 20 19:16:51 2018 (r335456) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 11, 2018 +.Dd June 20, 2018 .Dt DEVELOPMENT 7 .Os .Sh NAME @@ -81,7 +81,7 @@ Build instructions can be found in .Xr build 7 and .Xr release 7 . -Kernel APIs are usually documented, use +Kernel APIs are documented in section 9 manual pages; use .Ql "apropos -s 9 ''" for a list. Regression test suite is described in ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335457 - head
Author: jhb Date: Wed Jun 20 19:22:33 2018 New Revision: 335457 URL: https://svnweb.freebsd.org/changeset/base/335457 Log: Correct path to removed asf(8) binary. Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Wed Jun 20 19:16:51 2018(r335456) +++ head/ObsoleteFiles.inc Wed Jun 20 19:22:33 2018(r335457) @@ -39,7 +39,7 @@ # done # 20180615: asf(8) removed -OLD_FILES+=usr/bin/asf +OLD_FILES+=usr/sbin/asf OLD_FILES+=usr/share/man/man8/asf.8.gz # 20180609: obsolete libc++ files missed from the 5.0.0 import OLD_FILES+=usr/include/c++/v1/__refstring ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335458 - head/sys/kern
Author: kevans
Date: Wed Jun 20 19:23:56 2018
New Revision: 335458
URL: https://svnweb.freebsd.org/changeset/base/335458
Log:
Add debug.verbose_sysinit tunable for VERBOSE_SYSINIT
VERBOSE_SYSINIT is currently an all-or-nothing option. debug.verbose_sysinit
adds an option to have the code compiled in but quiet by default so that
getting this information from a device in the field doesn't necessarily
require distributing a recompiled kernel.
Its default is VERBOSE_SYSINIT's value as defined in the kernconf. As such,
the default behavior for simply omitting or including this option is
unchanged.
MFC after:1 week
Modified:
head/sys/kern/init_main.c
Modified: head/sys/kern/init_main.c
==
--- head/sys/kern/init_main.c Wed Jun 20 19:22:33 2018(r335457)
+++ head/sys/kern/init_main.c Wed Jun 20 19:23:56 2018(r335458)
@@ -119,6 +119,18 @@ intbootverbose = BOOTVERBOSE;
SYSCTL_INT(_debug, OID_AUTO, bootverbose, CTLFLAG_RW, &bootverbose, 0,
"Control the output of verbose kernel messages");
+#ifdef VERBOSE_SYSINIT
+/*
+ * We'll use the defined value of VERBOSE_SYSINIT from the kernel config to
+ * dictate the default VERBOSE_SYSINIT behavior. Significant values for this
+ * option and associated tunable are:
+ * - 0, 'compiled in but silent by default'
+ * - 1, 'compiled in but verbose by default' (default)
+ */
+intverbose_sysinit = VERBOSE_SYSINIT;
+TUNABLE_INT("debug.verbose_sysinit", &verbose_sysinit);
+#endif
+
#ifdef INVARIANTS
FEATURE(invariants, "Kernel compiled with INVARIANTS, may affect performance");
#endif
@@ -268,7 +280,7 @@ restart:
continue;
#if defined(VERBOSE_SYSINIT)
- if ((*sipp)->subsystem > last) {
+ if ((*sipp)->subsystem > last && verbose_sysinit != 0) {
verbose = 1;
last = (*sipp)->subsystem;
printf("subsystem %x\n", last);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335459 - head/usr.sbin/acpi/acpidump
Author: emaste Date: Wed Jun 20 19:40:54 2018 New Revision: 335459 URL: https://svnweb.freebsd.org/changeset/base/335459 Log: acpidump.8: include NFIT in the man page list of tables Was missed in r321298. Reported by: Ben Widawsky (in review D15931) MFC after:1 week Modified: head/usr.sbin/acpi/acpidump/acpidump.8 Modified: head/usr.sbin/acpi/acpidump/acpidump.8 == --- head/usr.sbin/acpi/acpidump/acpidump.8 Wed Jun 20 19:23:56 2018 (r335458) +++ head/usr.sbin/acpi/acpidump/acpidump.8 Wed Jun 20 19:40:54 2018 (r335459) @@ -29,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 14, 2005 +.Dd June 20, 2018 .Dt ACPIDUMP 8 .Os .Sh NAME @@ -105,6 +105,7 @@ utility dumps contents of the following tables: .It HPET .It MADT .It MCFG +.It NFIT .It RSD PTR .It RSDT .It WDDT ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335460 - head
Author: bdrewery
Date: Wed Jun 20 19:45:04 2018
New Revision: 335460
URL: https://svnweb.freebsd.org/changeset/base/335460
Log:
Only look for NOTES as needed.
Sponsored by: Dell EMC
Modified:
head/Makefile
Modified: head/Makefile
==
--- head/Makefile Wed Jun 20 19:40:54 2018(r335459)
+++ head/Makefile Wed Jun 20 19:45:04 2018(r335460)
@@ -573,13 +573,13 @@ universe_${target}_${target_arch}: universe_${target}_
universe_${target}_done: universe_${target}_kernels .PHONY
universe_${target}_kernels: universe_${target}_worlds .PHONY
universe_${target}_kernels: universe_${target}_prologue .MAKE .PHONY
-.if exists(${KERNSRCDIR}/${target}/conf/NOTES)
- @(cd ${KERNSRCDIR}/${target}/conf && env __MAKE_CONF=/dev/null \
+ @if [ -e "${KERNSRCDIR}/${target}/conf/NOTES" ]; then \
+ (cd ${KERNSRCDIR}/${target}/conf && env __MAKE_CONF=/dev/null \
${SUB_MAKE} LINT \
> ${.CURDIR}/_.${target}.makeLINT 2>&1 || \
(echo "${target} 'make LINT' failed," \
- "check _.${target}.makeLINT for details"| ${MAKEFAIL}))
-.endif
+ "check _.${target}.makeLINT for details"| ${MAKEFAIL})); \
+ fi
@cd ${.CURDIR}; ${SUB_MAKE} ${.MAKEFLAGS} TARGET=${target} \
universe_kernels
.endif # !MAKE_JUST_WORLDS
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335456 - head/share/man/man7
On Wed, Jun 20, 2018 at 07:16:51PM +, Edward Tomasz Napierala wrote: > Author: trasz > Date: Wed Jun 20 19:16:51 2018 > New Revision: 335456 > URL: https://svnweb.freebsd.org/changeset/base/335456 > > Log: > Improve wording. > > MFC after: 2 weeks > > Modified: > head/share/man/man7/development.7 > > Modified: head/share/man/man7/development.7 > == > --- head/share/man/man7/development.7 Wed Jun 20 18:51:38 2018 > (r335455) > +++ head/share/man/man7/development.7 Wed Jun 20 19:16:51 2018 > (r335456) > @@ -24,7 +24,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd May 11, 2018 > +.Dd June 20, 2018 > .Dt DEVELOPMENT 7 > .Os > .Sh NAME > @@ -81,7 +81,7 @@ Build instructions can be found in > .Xr build 7 > and > .Xr release 7 . > -Kernel APIs are usually documented, use > +Kernel APIs are documented in section 9 manual pages; use Kernel API is an oxymoron. Section 9 describes Kernel Programming Interfaces, the A from Application is not needed. We usually abbreviate it as KPI. Kernel API are syscalls, if anything. > .Ql "apropos -s 9 ''" > for a list. > Regression test suite is described in ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335461 - in head/sys: kern sys
Author: hselasky
Date: Wed Jun 20 20:04:20 2018
New Revision: 335461
URL: https://svnweb.freebsd.org/changeset/base/335461
Log:
Permit the kernel environment to set an array of numeric values for a single
sysctl(9) node.
Reviewed by: kib@, imp@, jhb@
Differential Revision:https://reviews.freebsd.org/D15802
MFC after:1 week
Sponsored by: Mellanox Technologies
Modified:
head/sys/kern/kern_environment.c
head/sys/kern/kern_sysctl.c
head/sys/sys/systm.h
Modified: head/sys/kern/kern_environment.c
==
--- head/sys/kern/kern_environment.cWed Jun 20 19:45:04 2018
(r335460)
+++ head/sys/kern/kern_environment.cWed Jun 20 20:04:20 2018
(r335461)
@@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
@@ -514,6 +515,141 @@ getenv_string(const char *name, char *data, int size)
strlcpy(data, cp, size);
}
return (cp != NULL);
+}
+
+/*
+ * Return an array of integers at the given type size and signedness.
+ */
+int
+getenv_array(const char *name, void *pdata, int size, int *psize,
+int type_size, bool allow_signed)
+{
+ char buf[KENV_MNAMELEN + 1 + KENV_MVALLEN + 1];
+ uint8_t shift;
+ int64_t value;
+ int64_t old;
+ char *end;
+ char *ptr;
+ int n;
+
+ if (getenv_string(name, buf, sizeof(buf)) == 0)
+ return (0);
+
+ /* get maximum number of elements */
+ size /= type_size;
+
+ n = 0;
+
+ for (ptr = buf; *ptr != 0; ) {
+
+ value = strtoq(ptr, &end, 0);
+
+ /* check if signed numbers are allowed */
+ if (value < 0 && !allow_signed)
+ goto error;
+
+ /* check for invalid value */
+ if (ptr == end)
+ goto error;
+
+ /* check for valid suffix */
+ switch (*end) {
+ case 't':
+ case 'T':
+ shift = 40;
+ end++;
+ break;
+ case 'g':
+ case 'G':
+ shift = 30;
+ end++;
+ break;
+ case 'm':
+ case 'M':
+ shift = 20;
+ end++;
+ break;
+ case 'k':
+ case 'K':
+ shift = 10;
+ end++;
+ break;
+ case ' ':
+ case '\t':
+ case ',':
+ case 0:
+ shift = 0;
+ break;
+ default:
+ /* garbage after numeric value */
+ goto error;
+ }
+
+ /* skip till next value, if any */
+ while (*end == '\t' || *end == ',' || *end == ' ')
+ end++;
+
+ /* update pointer */
+ ptr = end;
+
+ /* apply shift */
+ old = value;
+ value <<= shift;
+
+ /* overflow check */
+ if ((value >> shift) != old)
+ goto error;
+
+ /* check for buffer overflow */
+ if (n >= size)
+ goto error;
+
+ /* store value according to type size */
+ switch (type_size) {
+ case 1:
+ if (allow_signed) {
+ if (value < SCHAR_MIN || value > SCHAR_MAX)
+ goto error;
+ } else {
+ if (value < 0 || value > UCHAR_MAX)
+ goto error;
+ }
+ ((uint8_t *)pdata)[n] = (uint8_t)value;
+ break;
+ case 2:
+ if (allow_signed) {
+ if (value < SHRT_MIN || value > SHRT_MAX)
+ goto error;
+ } else {
+ if (value < 0 || value > USHRT_MAX)
+ goto error;
+ }
+ ((uint16_t *)pdata)[n] = (uint16_t)value;
+ break;
+ case 4:
+ if (allow_signed) {
+ if (value < INT_MIN || value > INT_MAX)
+ goto error;
+ } else {
+ if (value > UINT_MAX)
+ goto error;
+ }
+ ((uint32_t *)pdata)[n] = (uint32_t)value;
+
Re: svn commit: r335402 - head/sbin/veriexecctl
Hi Jon, On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson wrote: > On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote: >> My reasoning >> was fairly simple: when a review has been open for over a year with no >> action, it seems like the submitter should be able to commit it without >> waiting for more review, if they are confident in their change. I stand by >> that (and, in fact, would substitute something shorter for "over a year"). For this as a question of general process, I think "it depends." For minor fixes? Of course! Less than one year. For minor improvements or enhancements? Also yes, also probably less than 1yr. For large features like this, I think the answer is more nuanced. Sometimes being in a review for a year means the reviewers are overloaded and don't have time. In that case, maybe they shouldn't block progress. Sometimes being in review for a year just means the right reviewers haven't been found. I think that was more the case here. I would suggest anyone submitting a large feature and not getting feedback in a reasonable timeframe to solicit feedback from a wider audience much sooner than one year, and also indicate intention to merge the unreviewed change with some time window (1-2 weeks?) on giving feedback or at least asking for more time to review. > So: is there a strong reason why a backout-and-re-commit approach is > superior to iterating on the code in-tree? Yeah: > Any disputed change must be backed out pending resolution of the dispute > if requested by a maintainer. Security related changes may override a > maintainer's wishes at the Security Officer's discretion. > > This may be hard to swallow in times of conflict (when each side is > convinced that they are in the right, of course) but a version control > system makes it unnecessary to have an ongoing dispute raging when it is > far easier to simply reverse the disputed change, get everyone calmed > down again and then try to figure out what is the best way to proceed. > If the change turns out to be the best thing after all, it can be easily > brought back. If it turns out not to be, then the users did not have to > live with the bogus change in the tree while everyone was busily > debating its merits. People very rarely call for back-outs in the > repository since discussion generally exposes bad or controversial > changes before the commit even happens, but on such rare occasions the > back-out should be done without argument so that we can get immediately > on to the topic of figuring out whether it was bogus or not. In particular, SHA1 was never the primary reason the backout was requested, just one design smell in the aggregate. This change introduces a security feature that doesn't provide the security guarantees it claims to. That should be a major red flag. All the best, Conrad ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335456 - head/share/man/man7
On Wed, 2018-06-20 at 22:54 +0300, Konstantin Belousov wrote: > On Wed, Jun 20, 2018 at 07:16:51PM +, Edward Tomasz Napierala wrote: > > > > Author: trasz > > Date: Wed Jun 20 19:16:51 2018 > > New Revision: 335456 > > URL: https://svnweb.freebsd.org/changeset/base/335456 > > > > Log: > > Improve wording. > > > > MFC after:2 weeks > > > > Modified: > > head/share/man/man7/development.7 > > > > Modified: head/share/man/man7/development.7 > > == > > --- head/share/man/man7/development.7 Wed Jun 20 18:51:38 2018 > > (r335455) > > +++ head/share/man/man7/development.7 Wed Jun 20 19:16:51 2018 > > (r335456) > > @@ -24,7 +24,7 @@ > > .\" > > .\" $FreeBSD$ > > .\" > > -.Dd May 11, 2018 > > +.Dd June 20, 2018 > > .Dt DEVELOPMENT 7 > > .Os > > .Sh NAME > > @@ -81,7 +81,7 @@ Build instructions can be found in > > .Xr build 7 > > and > > .Xr release 7 . > > -Kernel APIs are usually documented, use > > +Kernel APIs are documented in section 9 manual pages; use > Kernel API is an oxymoron. Section 9 describes Kernel Programming > Interfaces, the A from Application is not needed. We usually abbreviate > it as KPI. This is the manpage a new developer is going to look at, and if you throw an abbreviation like KPI at them and they search for what it means, they're going to find "Key Performance Indicator" and nothing about kernels. This might be a good place to introduce and define that acronym, maybe something like "Kernel programming interfaces (KPIs) are documented...". -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
Xin LI wrote: > I do agree with others that SHA-1 support should not be included It can certainly be disabled by default. > (unless I have missed something, but I think firmware integrity check > counts as a "Digital signature" verification, according to SP 800-131A A "Digital signature" verification is an accepted form of firmware integrity check, but a simple hash (inlcuding SHA-1) is also acceptible. We of course perform both - and the Digital signature does *not* use SHA-1, it has been deprecated for that purpose for some years now. > "9 Hash algorithms", SHA-1 verification should only be used for legacy > usage, which does not apply on FreeBSD because this is new feature). I've managed to get out of having to memorize all those SP's, so will check with one of the pour souls who still does - as to whether we are claiming "legacy" status... > But even that, given the code only impacts systems that have it > explicitly compiled in, it's reasonable to give the committer more > time to make further improvements rather than reverting it as a whole > as this would give the code more exposure. Indeed - thanks --sjg ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
Conrad Meyer wrote:
> The signing of manifests does not exist in the patch series committed.
Nor will it, the singing of manifests is a build thing.
But as I mentioned earlier I think the loader verification code can be
leveraged for a verifying userland veriexec tool similar to that in
Junos.
> (If NetBSD does something broken, that is not an excuse to copy it.)
How about we backout the veriexecctl tool - which is the only bit your
comments apply to - and which we do not use.
All the signing etc discussion is orthogonal to the kernel part.
> > A veriexec loader that leverages signed manifests requires some signing
> > infra. That's a big topic all by itself.
>
> It *may* require that. However, even without that, admins could
> reasonably manage their own PKI in some fashion, independent of
There still needs to be a tool that they can use.
The work I've done on the loader should make this simple since it
provides for OpenPGP signatures as well as X.509 based certs.
> FreeBSD's infra. But it requires the support code to verify
> signatures, as in the "verify" part of veriexec, which is wholly
> absent.
Yes. As above, reverting the veriexecctl tool would be fine,
I'll commit a proper verifying tool along with the loader bits.
I have to do some tweaking of one of my libs first.
> Again — this is a discussion for arch or phabricator, with the series
> reverted first.
For code that's off by default why is reverting a requirement?
> many other glaring performance problems. If you care about MAC
> performance in a secure algorithm in 2018, perhaps look at any of
> these great options:
>
> * SHA-3 (Keccak)
> * Blake2-b
> * Poly1305-{AES,Salsa,ChaCha}
The framework allows folk to add any hashes they like.
For us, anything which is not NIST approved is of little interest.
Obviously many people have the luxury of not haveing to bow to NIST,
so again the framework provides.
> FreeBSD has had this code for 0 years. It's a novel feature here.
> There is no reason to introduce SHA-1 in novel security features in
> 2018.
As mentioned earlier (in this thread? hard to say), no reason it needs
to be enabled by default.
FreeBSD.org if they are going to sign the packages they ship, need to
make a decision about the hashes they want to support.
> And no, upstreaming the signature verification code is completely
> orthogonal to implementing signing infrastructure.
Not really since one dictates the other.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
(Apologies to cem@ for the duplicate in his inbox, Gmail decided to not reply-all in my reply.) On Wed, Jun 20, 2018 at 1:07 PM, Conrad Meyer wrote: > Hi Jon, > > On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson > wrote: > > On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote: > >> My reasoning > >> was fairly simple: when a review has been open for over a year with no > >> action, it seems like the submitter should be able to commit it without > >> waiting for more review, if they are confident in their change. I stand > by > >> that (and, in fact, would substitute something shorter for "over a > year"). > > For this as a question of general process, I think "it depends." For > minor fixes? Of course! Less than one year. For minor improvements > or enhancements? Also yes, also probably less than 1yr. For large > features like this, I think the answer is more nuanced. > > Sometimes being in a review for a year means the reviewers are > overloaded and don't have time. In that case, maybe they shouldn't > block progress. Sometimes being in review for a year just means the > right reviewers haven't been found. I think that was more the case > here. > > I would suggest anyone submitting a large feature and not getting > feedback in a reasonable timeframe to solicit feedback from a wider > audience much sooner than one year, and also indicate intention to > merge the unreviewed change with some time window (1-2 weeks?) on > giving feedback or at least asking for more time to review. > That was the problem. I soliticted feedback many times over at least 3 years. The first set was in my GitHub branch and I had discussed with various people starting at BSDCan 3 or 4 years ago. I had even sent an early version of the changes to rwatson (whom I had previously worked with at TIS/NAI/McAfee) and was provided some feedback based on a cursory look over of the code, which was integrated into the branch. At MeetBSD 2016, I also discussed the code with some people and that was when it was suggested that I create an account of Phabricator and put the code up for review. Some members of core and/or the Foundation had suggested who to talk to get reviews and I had also spoken with rwatson again to see if he had any suggestions. Once the code had landed in review, I also talked with people during vBSDcon last year in an effort to try to find out who else should put eyes on it. I even talked about it during one of the BoF sessions and pointed out both my GitHub branch and the set of reviews on Phabricator, which is when there started to get some additional feedback and/or watchers on the review. Also, after I had received my commit bit and the reviews were still collecting dust in Phabricator, on numberous occassions I solicited feedback or suggestions on who to contact on the IRC channel. I'm guessing that people had not looked at the reviews before suggesting who to talk to or they did not realize the areas of interest that the changes might cover. I think this experience illustrates the need for some better way for someone contributing to be able to find out who the correct parties are that need to be contacted. It was 3+ year struggle for me to find people to put eyes on the code and it was not just a fire it off and wait forever thing. One can only listen to crickets in response for requests for help for so long. -Steve ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335462 - head/sys/dev/ixl
Author: erj Date: Wed Jun 20 22:16:46 2018 New Revision: 335462 URL: https://svnweb.freebsd.org/changeset/base/335462 Log: ixl(4): Fix gcc build errors By removing redundant function declarations. Reported by: ci.freebsd.org via Mark Millard MFC after:1 month Modified: head/sys/dev/ixl/ixl.h head/sys/dev/ixl/ixl_pf.h Modified: head/sys/dev/ixl/ixl.h == --- head/sys/dev/ixl/ixl.h Wed Jun 20 20:04:20 2018(r335461) +++ head/sys/dev/ixl/ixl.h Wed Jun 20 22:16:46 2018(r335462) @@ -542,7 +542,6 @@ extern const uint8_t ixl_bcast_addr[ETHER_ADDR_LEN]; /* Common function prototypes between PF/VF driver */ voidixl_init_tx_ring(struct ixl_vsi *vsi, struct ixl_tx_queue *que); -voidixl_set_queue_rx_itr(struct ixl_rx_queue *que); voidixl_get_default_rss_key(u32 *); const char * i40e_vc_stat_str(struct i40e_hw *hw, enum virtchnl_status_code stat_err); Modified: head/sys/dev/ixl/ixl_pf.h == --- head/sys/dev/ixl/ixl_pf.h Wed Jun 20 20:04:20 2018(r335461) +++ head/sys/dev/ixl/ixl_pf.h Wed Jun 20 22:16:46 2018(r335462) @@ -401,7 +401,5 @@ s32 ixl_write_i2c_byte_aq(struct ixl_pf *pf, u8 byte_o intixl_get_fw_lldp_status(struct ixl_pf *pf); intixl_attach_get_link_status(struct ixl_pf *); -u64ixl_max_aq_speed_to_value(u8); -void ixl_handle_vflr(void *, int); #endif /* _IXL_PF_H_ */ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335454 - head/usr.bin/ar
> Author: emaste > Date: Wed Jun 20 18:43:17 2018 > New Revision: 335454 > URL: https://svnweb.freebsd.org/changeset/base/335454 > > Log: > usr.bin/ar: use standard 2-Clause FreeBSD license > > Many licenses on ar files contained small variations from the standard > FreeBSD license text. To avoid license proliferation switch to the usual > 2-clause FreeBSD license after obtaining permission from all copyright > holders. > > Approved by:jkoshy, kaiw, kientzle > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D14561 > > Modified: > head/usr.bin/ar/ar.c > head/usr.bin/ar/read.c > head/usr.bin/ar/util.c > > Modified: head/usr.bin/ar/ar.c > == > --- head/usr.bin/ar/ar.c Wed Jun 20 17:37:55 2018(r335453) > +++ head/usr.bin/ar/ar.c Wed Jun 20 18:43:17 2018(r335454) > @@ -1,4 +1,6 @@ > /*- > + * SPDX-License-Identifier: BSD-3-Clause > + * I think there may be an error above, commit message says 2 clause, license below appears to be 2 clause, yet above we have 3? > * Copyright (c) 2007 Kai Wang > * Copyright (c) 2007 Tim Kientzle > * Copyright (c) 2007 Joseph Koshy > @@ -8,22 +10,22 @@ > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > - *notice, this list of conditions and the following disclaimer > - *in this position and unchanged. > + *notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > *notice, this list of conditions and the following disclaimer in the > *documentation and/or other materials provided with the distribution. > * > - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR > - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > - * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, > - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > */ > > /*- > > Modified: head/usr.bin/ar/read.c > == > --- head/usr.bin/ar/read.cWed Jun 20 17:37:55 2018(r335453) > +++ head/usr.bin/ar/read.cWed Jun 20 18:43:17 2018(r335454) > @@ -1,4 +1,6 @@ > /*- > + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD > + * > * Copyright (c) 2007 Kai Wang > * Copyright (c) 2007 Tim Kientzle > * All rights reserved. > @@ -7,22 +9,22 @@ > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > - *notice, this list of conditions and the following disclaimer > - *in this position and unchanged. > + *notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > *notice, this list of conditions and the following disclaimer in the > *documentation and/or other materials provided with the distribution. > * > - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR > - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > - * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, > - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > - * DATA, OR P
Re: svn commit: r335454 - head/usr.bin/ar
On 20/06/2018 17:42, Rodney W. Grimes wrote: Author: emaste Date: Wed Jun 20 18:43:17 2018 New Revision: 335454 URL: https://svnweb.freebsd.org/changeset/base/335454 Log: usr.bin/ar: use standard 2-Clause FreeBSD license Many licenses on ar files contained small variations from the standard FreeBSD license text. To avoid license proliferation switch to the usual 2-clause FreeBSD license after obtaining permission from all copyright holders. Approved by: jkoshy, kaiw, kientzle Sponsored by:The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D14561 Modified: head/usr.bin/ar/ar.c head/usr.bin/ar/read.c head/usr.bin/ar/util.c Modified: head/usr.bin/ar/ar.c == --- head/usr.bin/ar/ar.cWed Jun 20 17:37:55 2018(r335453) +++ head/usr.bin/ar/ar.cWed Jun 20 18:43:17 2018(r335454) @@ -1,4 +1,6 @@ /*- + * SPDX-License-Identifier: BSD-3-Clause + * I think there may be an error above, commit message says 2 clause, license below appears to be 2 clause, yet above we have 3? Look at all the file: there are two licenses there. Pedro. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335454 - head/usr.bin/ar
> On 20/06/2018 17:42, Rodney W. Grimes wrote: > >> Author: emaste > >> Date: Wed Jun 20 18:43:17 2018 > >> New Revision: 335454 > >> URL: https://svnweb.freebsd.org/changeset/base/335454 > >> > >> Log: > >>usr.bin/ar: use standard 2-Clause FreeBSD license > >> > >>Many licenses on ar files contained small variations from the standard > >>FreeBSD license text. To avoid license proliferation switch to the usual > >>2-clause FreeBSD license after obtaining permission from all copyright > >>holders. > >> > >>Approved by:jkoshy, kaiw, kientzle > >>Sponsored by: The FreeBSD Foundation > >>Differential Revision: https://reviews.freebsd.org/D14561 > >> > >> Modified: > >>head/usr.bin/ar/ar.c > >>head/usr.bin/ar/read.c > >>head/usr.bin/ar/util.c > >> > >> Modified: head/usr.bin/ar/ar.c > >> == > >> --- head/usr.bin/ar/ar.c Wed Jun 20 17:37:55 2018(r335453) > >> +++ head/usr.bin/ar/ar.c Wed Jun 20 18:43:17 2018(r335454) > >> @@ -1,4 +1,6 @@ > >> /*- > >> + * SPDX-License-Identifier: BSD-3-Clause > >> + * > > I think there may be an error above, commit message says 2 clause, > > license below appears to be 2 clause, yet above we have 3? > Look at all the file: there are two licenses there. My claim still stands, the commit message and reality do not match, Ed claimed that he was switching to 2-clause FreeBSD license, yet it does not appear to actually do that. It further claims that he obtained permission from ALL copyright holders, which also appears to not be true, or he could of removed the 3 clause. The dual license is an even bigger can of worms, as then technically this file is neither BSD-2-Clause nor BSD-3-Clause, but some hybrid that has to be treated specially. Does SPDX have rules for dual tagging a file? I seem to recall that there was some way to do that at least. I am unclear as to it even be legal or valid to have added the 2 clause license on top of the BSD 3 clause license. > Pedro. -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335464 - head
Author: emaste
Date: Thu Jun 21 02:15:50 2018
New Revision: 335464
URL: https://svnweb.freebsd.org/changeset/base/335464
Log:
Makefile.inc1: rename build metadata file to toolchain-metadata.mk
The metadata file contains more than just compiler metadata.
Discussed with: bdrewery
Modified:
head/Makefile.inc1
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Thu Jun 21 01:22:35 2018(r335463)
+++ head/Makefile.inc1 Thu Jun 21 02:15:50 2018(r335464)
@@ -92,8 +92,8 @@ MK_GCC_BOOTSTRAP= no
# running CC from bsd.compiler.mk.
.if make(installworld) || make(install) || make(distributeworld) || \
make(stageworld)
-.-include "${OBJTOP}/compiler-metadata.mk"
-.if !defined(_LOADED_COMPILER_METADATA)
+.-include "${OBJTOP}/toolchain-metadata.mk"
+.if !defined(_LOADED_TOOLCHAIN_METADATA)
.error A build is required first. You may have the wrong MAKEOBJDIRPREFIX set.
.endif
.endif
@@ -311,7 +311,7 @@ test-system-${_t}: .PHONY
# Store some compiler metadata for use in installworld where we don't
# want to invoke CC at all.
-_COMPILER_METADATA_VARS= COMPILER_VERSION \
+_TOOLCHAIN_METADATA_VARS= COMPILER_VERSION \
COMPILER_TYPE \
COMPILER_FEATURES \
COMPILER_FREEBSD_VERSION \
@@ -319,17 +319,17 @@ _COMPILER_METADATA_VARS= COMPILER_VERSION \
LINKER_FEATURES \
LINKER_TYPE \
LINKER_FREEBSD_VERSION
-compiler-metadata.mk: .PHONY .META
+toolchain-metadata.mk: .PHONY .META
@: > ${.TARGET}
- @echo ".info Using cached compiler metadata from build at $$(hostname)
on $$(date)" \
+ @echo ".info Using cached toolchain metadata from build at $$(hostname)
on $$(date)" \
> ${.TARGET}
- @echo "_LOADED_COMPILER_METADATA=t" >> ${.TARGET}
-.for v in ${_COMPILER_METADATA_VARS}
+ @echo "_LOADED_TOOLCHAIN_METADATA=t" >> ${.TARGET}
+.for v in ${_TOOLCHAIN_METADATA_VARS}
@echo "${v}=${${v}}" >> ${.TARGET}
@echo "X_${v}=${X_${v}}" >> ${.TARGET}
.endfor
- @echo ".export ${_COMPILER_METADATA_VARS}" >> ${.TARGET}
- @echo ".export ${_COMPILER_METADATA_VARS:C,^,X_,}" >> ${.TARGET}
+ @echo ".export ${_TOOLCHAIN_METADATA_VARS}" >> ${.TARGET}
+ @echo ".export ${_TOOLCHAIN_METADATA_VARS:C,^,X_,}" >> ${.TARGET}
# We must do lib/ and libexec/ before bin/ in case of a mid-install error to
@@ -1015,7 +1015,7 @@ _cross-tools:
@echo "--"
@echo ">>> stage 3: cross tools"
@echo "--"
- @rm -f ${OBJTOP}/compiler-metadata.mk
+ @rm -f ${OBJTOP}/toolchain-metadata.mk
${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools
${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools
_build-metadata:
@@ -1023,7 +1023,7 @@ _build-metadata:
@echo "--"
@echo ">>> stage 3.1: recording build metadata"
@echo "--"
- ${_+_}cd ${.CURDIR}; ${WMAKE} compiler-metadata.mk
+ ${_+_}cd ${.CURDIR}; ${WMAKE} toolchain-metadata.mk
${_+_}cd ${.CURDIR}; ${WMAKE} host-osreldate.h
_includes:
@echo
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335454 - head/usr.bin/ar
On 20 June 2018 at 20:48, Rodney W. Grimes wrote: > > My claim still stands, the commit message and reality do not match, > Ed claimed that he was switching to 2-clause FreeBSD license, yet > it does not appear to actually do that. The commit message could have been more clear indeed. > Does SPDX have rules for dual tagging a file? I seem to recall that > there was some way to do that at least. It does (using license1 AND/OR license2), but in this case one of the licenses is a subset of the other. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335402 - head/sbin/veriexecctl
On 19 June 2018 at 20:08, Eitan Adler wrote: > On 19 June 2018 at 18:08, Stephen J. Kiernan wrote: >> Added: head/sbin/veriexecctl/Makefile >> == >> --- /dev/null 00:00:00 1970 (empty, because file is newly added) >> +++ head/sbin/veriexecctl/Makefile Wed Jun 20 01:08:54 2018 >> (r335402) >> @@ -0,0 +1,11 @@ >> +# $FreeBSD$ >> + >> +PROG= veriexecctl >> +MAN= veriexecctl.8 >> +SRCS= veriexecctl_parse.y veriexecctl_conf.l veriexecctl.c >> + >> +WARNS?=3 > > Why are we introducing new code with lower-than-6 warnings ? In all the commotion about the more important issues this fell through. Also its argument parsing appears to not be using getopt[_long] ? -- Eitan Adler ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335467 - head/tools/build/mk
Author: kevans
Date: Thu Jun 21 05:28:00 2018
New Revision: 335467
URL: https://svnweb.freebsd.org/changeset/base/335467
Log:
Don't remove loader.conf(5) when built WITHOUT_FORTH
The new stand/ structure installs loader.conf(5) and defaults/loader.conf
regardless of interpreter. The only thing gating installation now is
MK_BOOT.
Reported by: eadler
Modified:
head/tools/build/mk/OptionalObsoleteFiles.inc
Modified: head/tools/build/mk/OptionalObsoleteFiles.inc
==
--- head/tools/build/mk/OptionalObsoleteFiles.inc Thu Jun 21 05:18:08
2018(r335466)
+++ head/tools/build/mk/OptionalObsoleteFiles.inc Thu Jun 21 05:28:00
2018(r335467)
@@ -2335,7 +2335,6 @@ OLD_FILES+=usr/share/man/man8/fdcontrol.8.gz
.endif
.if ${MK_FORTH} == no
-OLD_FILES+=usr/share/man/man5/loader.conf.5.gz
OLD_FILES+=usr/share/man/man8/beastie.4th.8.gz
OLD_FILES+=usr/share/man/man8/brand.4th.8.gz
OLD_FILES+=usr/share/man/man8/check-password.4th.8.gz
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r335468 - head/sys/netinet
Author: mmacy
Date: Thu Jun 21 06:10:52 2018
New Revision: 335468
URL: https://svnweb.freebsd.org/changeset/base/335468
Log:
udp_ctlinput: don't refer to unpcb after we drop the lock
Reported by: pho@
Modified:
head/sys/netinet/udp_usrreq.c
Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c Thu Jun 21 05:28:00 2018
(r335467)
+++ head/sys/netinet/udp_usrreq.c Thu Jun 21 06:10:52 2018
(r335468)
@@ -802,14 +802,15 @@ udp_common_ctlinput(int cmd, struct sockaddr *sa, void
INPLOOKUP_WILDCARD |
INPLOOKUP_RLOCKPCB, NULL);
if (inp != NULL) {
struct udpcb *up;
+ void *ctx;
+ udp_tun_icmp_t func;
up = intoudpcb(inp);
- if (up->u_icmp_func != NULL) {
- INP_RUNLOCK(inp);
- (*up->u_icmp_func)(cmd, sa, vip,
up->u_tun_ctx);
- } else {
- INP_RUNLOCK(inp);
- }
+ ctx = up->u_tun_ctx;
+ func = up->u_icmp_func;
+ INP_RUNLOCK(inp);
+ if (func != NULL)
+ (*func)(cmd, sa, vip, ctx);
}
}
} else
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
