Re: Possible issue with linux xattr support?
On Wed, Aug 30, 2023 at 06:55:14AM +0200, Alexander Leidinger wrote: > Am 2023-08-29 21:02, schrieb Shawn Webb: > > > Back in 2019, I had a similar issue: I needed access to be able to > > read/write to the system extended attribute namespace from within a > > jailed context. I wrote a rather simple patch that provides that > > support on a per-jail basis: > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3 > > You enabled it by default. I would assume you had a thought about the > implications... any memories about it? I hope you don't mind if I quote a response I wrote to another person on the list about the feature: === begin quote === In HardenedBSD's case, since we use filesystem extended attributes to toggle exploit mitigations on a per-application basis, there's now a conceptual security boundary between the host and the jail. Should the jail and the host share resources, like executables, a jailed process could toggle an exploit mitigation, and the toggle would bubble up to the host. So the next time the host executed /shared/app/executable/here, the security posture of the host would be affected. FreeBSD uses ELF header tagging, not filesystem extended attributes, to toggle exploit mitigations. So my description above is moot for FreeBSD users. I'm just hoping to share a unique perspective. === end quote === The main reason for enabling it by default in HardenedBSD is so that exploit mitigation toggles get applied to the application on `pkg install` (or `make install` in ports.) We have patches to our ports tree and have forked pkg to support the way we toggle exploit mitigations. So, I wanted to make sure that applications would behave the same in a jailed environment and the host... to avoid a POLA violation. > > What I'm after is: > - What can go wrong if we enable it by default? I don't know if there's anything that could go wrong if FreeBSD was to enable it by default. I think it might be more of a downstream issue: those who have developed custom behavior backed by filesystem extended attributes. > - Why would we like to disable it (or any ideas why it is disabled by > default in FreeBSD)? I wouldn't want to dictate what approach FreeBSD takes, if any. I think the approach I've taken works well for HardenedBSD. But the FreeBSD community might prefer an entirely different approach altogether. > > Depending in the answers we may even use a simpler patch and have it allowed > in jails even without the possibility to configure it. I also wonder if extended attributes could be taught to (optionally?) scope extended attributes to each jail. That might be a topic worth exploring some day for someone. Just a random thought. :-) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Possible issue with linux xattr support?
On Tue, Aug 29, 2023 at 09:31:46PM +0200, Felix Palmen wrote: > * Shawn Webb [20230829 15:25]: > > On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote: > > > * Kyle Evans [20230829 14:07]: > > > > On 8/29/23 14:02, Shawn Webb wrote: > > > > > Back in 2019, I had a similar issue: I needed access to be able to > > > > > read/write to the system extended attribute namespace from within a > > > > > jailed context. I wrote a rather simple patch that provides that > > > > > support on a per-jail basis: > > > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3 > > > > > > > > > > Hopefully that's useful to someone. > > > > > > > > > > Thanks, > > > > > > > > > > > > > FWIW (which likely isn't much), I like this approach much better; it > > > > makes > > > > more sense to me that it's a feature controlled by the creator of the > > > > jail > > > > and not one allowed just by using a compat ABI within a jail. > > > > > > Well, a typical GNU userland won't work in a jail without this, that's > > > what I know now. But I'm certainly with you, it doesn't feel logical > > > that a Linux binary can do something in a jail a FreeBSD binary can't. > > > > > > So, indeed, making it a jail option sounds better. > > > > > > Unless, bringing back a question raised earlier in this thread: What's > > > the reason to restrict this in a jailed context in the first place? IOW, > > > could it just be allowed unconditionally? > > > > In HardenedBSD's case, since we use filesystem extended attributes to > > toggle exploit mitigations on a per-application basis, there's now a > > conceptual security boundary between the host and the jail. > > > > Should the jail and the host share resources, like executables, a > > jailed process could toggle an exploit mitigation, and the toggle > > would bubble up to the host. So the next time the host executed > > /shared/app/executable/here, the security posture of the host would be > > affected. > > Isn't the sane approach here *not* to share any executables with a jail > other than via a read-only nullfs mount? I thought about that, too, but nullfs is not guaranteed to be available or applicable in all environments. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Possible issue with linux xattr support?
On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote: > * Kyle Evans [20230829 14:07]: > > On 8/29/23 14:02, Shawn Webb wrote: > > > Back in 2019, I had a similar issue: I needed access to be able to > > > read/write to the system extended attribute namespace from within a > > > jailed context. I wrote a rather simple patch that provides that > > > support on a per-jail basis: > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3 > > > > > > Hopefully that's useful to someone. > > > > > > Thanks, > > > > > > > FWIW (which likely isn't much), I like this approach much better; it makes > > more sense to me that it's a feature controlled by the creator of the jail > > and not one allowed just by using a compat ABI within a jail. > > Well, a typical GNU userland won't work in a jail without this, that's > what I know now. But I'm certainly with you, it doesn't feel logical > that a Linux binary can do something in a jail a FreeBSD binary can't. > > So, indeed, making it a jail option sounds better. > > Unless, bringing back a question raised earlier in this thread: What's > the reason to restrict this in a jailed context in the first place? IOW, > could it just be allowed unconditionally? In HardenedBSD's case, since we use filesystem extended attributes to toggle exploit mitigations on a per-application basis, there's now a conceptual security boundary between the host and the jail. Should the jail and the host share resources, like executables, a jailed process could toggle an exploit mitigation, and the toggle would bubble up to the host. So the next time the host executed /shared/app/executable/here, the security posture of the host would be affected. FreeBSD uses ELF header tagging, not filesystem extended attributes, to toggle exploit mitigations. So my description above is moot for FreeBSD users. I'm just hoping to share a unique perspective. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Possible issue with linux xattr support?
On Tue, Aug 29, 2023 at 05:45:51PM +0300, Dmitry Chagin wrote: > On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote: > > * Dmitry Chagin [20230828 18:57]: > > > On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote: > > > > * Cy Schubert [20230827 16:59]: > > > > > > > > > > If we are to break it to fix a problem, maybe a sysctl to > > > > > enable/disable then? > > > > > > > > IMHO depends on the exact nature of the problem. If it's confirmed that > > > > it (always and only) breaks for jailed processes, just disabling it for > > > > them would be the better workaround. "No-op" calls won't break anything. > > > > > > > > > > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch > > > > Thanks, I can confirm this avoids the issue in both cases I experienced > > (install from GNU coreutils and python). > > > thanks, this is the first half of the fix, it works for you due to you > are running tools under unprivileged user, afaiu. The second I have > tested by myself :) > > > If I understand this patch correctly, it completely avoids EPERM, > > masking it as not supported, so callers should consider it non-fatal, > > allowing to silently ignore writing of "system" attributes while still > > keeping other functionality? > > > system namespace is accessible only for privileged user, for others Linux > returns ENOTSUP. So many tools ignores this error, eg ls. > > the second: https://people.freebsd.org/~dchagin/sea_jailed.patch > > Try this under privileged user, please. Back in 2019, I had a similar issue: I needed access to be able to read/write to the system extended attribute namespace from within a jailed context. I wrote a rather simple patch that provides that support on a per-jail basis: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3 Hopefully that's useful to someone. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
On Thu, Apr 13, 2023 at 06:48:14PM -0400, Charlie Li wrote: > Shawn Webb wrote: > > Does the ZFS project have some sort of automated testing to catch > > data-gobbling, pool killing bugs? It seems like this would have been > > caught with some CI/CD stress testing automation scripts. > > > I can't speak about how the OpenZFS project does things, but this particular > corruption does not have any deterministic characteristics both pre- and > post-condition, so would be hard to automate testing. My approach would be to have a policy by which any new feature scheduled to land in the main branch must also not show any regressions when running `poudriere bulk -ac`. Such a policy could be enforced via server-side git commit hook. One problem, though, is that implementing that policy isn't just a matter of code, but also infrastructure, so there's a tangible monetary cost. I should mention that I appreciate the selfless hard work of those involved in the FreeBSD and OpenZFS projects. I hope for continued incremental improvements. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
0 > > >> >>>>>> =3D20 > > >> >>>>>> errors: No known data errors > > >> >>>>>> =3D20 > > >> >>>>>> =3D20 > > >> >>>>>> =3D3D3D=3D3D3D=3D3D3D > > >> >>>>>> Mark Millard > > >> >>>>>> marklmi at yahoo.com > > >> >>>>>> =3D20 > > >> >>>>> =3D20 > > >> >>>>> Let's try this again. Claws-mail didn't include the list address i= > > n > > >> >>>>> =3D > > >> >>>>> the=3D20 > > >> >>>> header. Trying to reply, again, using exmh instead. > > >> >>>>> =3D20 > > >> >>>>> =3D20 > > >> >>>>> Did your pools suffer the EXDEV problem? The EXDEV also corrupted = > > =3D > > >> >>>>> files. > > >> >>>> > > >> >>>> As I reported, this was a jump from before the import > > >> >>>> to as things are tonight (here). So: NO, unless the > > >> >>>> existing code as of tonight still has the EXDEV problem! > > >> >>>> > > >> >>>> Prior to this experiment I'd not progressed any media > > >> >>>> beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > > >> >>>> > > >> >>>> I think, without sufficient investigation we risk jumping to > > >> >>>>> conclusions. I've taken an extremely cautious approach, rolling > > >> >>>>> back > > >> >>>>> snapshots (as much as possible, i.e. poudriere datasets) when EXDE= > > V > > >> >>>>> corruption was encountered. > > >> >>>>> > > >> >>>> Again: nothing between main-n261544-cee09bda03c8-dirty and > > >> >>>> main-n262122-2ef2c26f3f13-dirty was involved at any stage. > > >> >>>> > > >> >>>> =3D20 > > >> >>>>> I did not rollback any snapshots in my MH mail directory. Rolling > > >> >>>>> back > > >> >>>>> snapshots of my MH maildir would result in loss of email. I have t= > > o > > >> >>>>> live with that corruption. Corrupted files in my outgoing sent > > >> >>>>> email > > >> >>>>> directory remain: > > >> >>>>> =3D20 > > >> >>>>> slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=3D20 > > >> >>>>> 53 > > >> >>>>> slippy$=3D20 > > >> >>>>> =3D20 > > >> >>>>> There are 53 corrupted files in my note log of 9913 emails. Those = > > =3D > > >> >>>>> files > > >> >>>> will never be fixed. They were corrupted by the EXDEV bug. Any new > > >> >>>> ZFS > > >> >>>>> or ZFS patches cannot retroactively remove the corruption from > > >> >>>>> those > > >> >>>>> files. > > >> >>>>> =3D20 > > >> >>>>> But my poudriere files, because the snapshots were rolled back, > > >> >>>>> were > > >> >>>>> "repaired" by the rolled back snapshots. > > >> >>>>> =3D20 > > >> >>>>> I'm not convinced that there is presently active corruption since > > >> >>>>> the problem has been fixed. I am convinced that whatever corruptio= > > n > > >> >>>>> that was written at the time will remain forever or until those > > >> >>>>> files > > >> >>>>> are deleted or replaced -- just like my email files written to dis= > > k > > >> >>>>> at > > >> >>>>> the time. > > >> >>>>> > > >> >>>> My test results and procedure just do not fit your conclusion > > >> >>>> that things are okay now if block_clonging is completely avoided. > > >> >>>> > > >> >>> Admitting I'm wrong: sending copies of my last reply to you back to > > >> >>> myself, > > >> >>> > > >> >> again and again, three times, I've managed to reproduce the corruptio= > > n > > >> >> you > > >> >>> are talking about. > > >> >>> > > >> >> This email itself was also corrupted. Below is what was sent. Good > > >> >> thing > > >> >> multiple copies are saved by exmh. > > >> >> > > >> >> Admitting I'm wrong: sending copies of my last reply to you back to > > >> >> myself, > > >> >> again and again, three times, I've managed to reproduce the corruptio= > > n > > >> >> you > > >> >> are talking about. > > >> >> > > >> > This email itself was also corrupted. Below is what was sent. Good > > >> > thing > > >> > multiple copies are saved by exmh. > > >> > > > >> > Admitting I'm wrong: sending copies of my last reply to you back to > > >> > myself, > > >> > again and again, three times, I've managed to reproduce the corruption > > >> > you > > >> > are talking about. > > >> > > > >> > From my previous email to you. > > >> > > > >> > header. Trying to reply:, again, using exmh instead. > > >> > ^ > > >> > Here it is, nine additional bytes of garbage. I've replaced the garbag= > > e > > >> > with colons because nulls mess up a lot of things, including cut= > > . > > >> > > > >> > In another instance about 500 bytes were removed. I can reproduce the > > >> > corruption at will now. > > >> > > > >> > The EXDEV patch is applied. Block_cloning is disabled. > > >> > > > >> > Somehow nulls and other garbage are inserted in the middle of emails > > >> > after > > >> > the ZFS upgrade. > > >> > > > >> Can you please try this patch: > > >> > > >> github.com > > > > > > The patch was applied yesterday at noon (PDT). > > > > > >> > > >> > > >> > > >> Unfortunately I don=E2=80=99t see how this can happen with block cloning > > >> disabled. > > > > > > It does and it's reproducible. > > > > > > > There is corruption with the recent import, with the > > https://github.com/openzfs/zfs/pull/14739/files patch applied and > > block cloning disabled on the pool. > > Same here. > > > > > There is no corruption with top of main with zfs merge reverted altogether. > > I'm in the process of building a branch reverting the merge altogether and > will test it on my sandbox machine later today. > > > > > Which commit results in said corruption remains to be seen, a variant > > of the tree with just block cloning support reverted just for testing > > purposes is about to be evaluated. I've learned over the years downstream that it's not really my place to tell upstream what to do or how to do it. However, I think given the seriousness of this, upstream might do well to revert the commit until a solid fix is in place. Upstream might want to consider the impacts this is having not just with downstream projects, but also regular users. Really bad timing to have a lot of new tax documentation that I really don't want to lose. I'd really like to have an up-to-date, security patched OS, but I guess I'll stay behind so that I don't risk losing critical financial documentation. Does the ZFS project have some sort of automated testing to catch data-gobbling, pool killing bugs? It seems like this would have been caught with some CI/CD stress testing automation scripts. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Mon, Feb 27, 2023 at 03:40:41PM -0500, Shawn Webb wrote: > On Mon, Feb 27, 2023 at 08:57:19PM +0100, Dimitry Andric wrote: > > On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > > > > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > > > main-n261147-b8bb73ab724b: Sun Feb 26 > > > 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). > > > > > > Building an appliance based on 13-STABLE sources, a customized kernel via > > > nanoBSD, since a > > > couple of weeks for now building the sources fails in kernel sources: > > > > > > [...] > > > --- modules-all --- > > > --- all_subdir_an --- > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > > > error: a > > > function definition without a prototype is deprecated in all versions of > > > C and is not > > > supported in C2x [-Werror,-Wdeprecated-non-prototype] > > > [..] > > > > > > Disabling all wireless options in the kernel config starts dropping > > > errors of a similar kind > > > on other kernel places. > > > > > > Compiling on FBSD 13-STABLE seems to be all right. > > > > > > Can this be fixed. please? What causes the error and how can this be > > > resolved if the subtree > > > of FreeBSD's sources is a submodule? > > > > Not sure what you mean with "subtree is a submodule", but this is likely > > caused by skipping the cross-tools stage somehow. Do you have any > > specific make.conf or src.conf settings for that? > > FWIW, HardenedBSD is also impacted by this. We set > WITH_SYSTEM_COMPILER and WITH_SYSTEM_LINKER by default, which I think > might be a contributing factor. The reason for not hitting the error in that particular file in 14-CURRENT is because the an(4) driver was removed by FreeBSD in commit 663b174b5b5387948bfa94131a08f6259d2926cc from 07 June 2021. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Mon, Feb 27, 2023 at 08:57:19PM +0100, Dimitry Andric wrote: > On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > > main-n261147-b8bb73ab724b: Sun Feb 26 > > 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). > > > > Building an appliance based on 13-STABLE sources, a customized kernel via > > nanoBSD, since a > > couple of weeks for now building the sources fails in kernel sources: > > > > [...] > > --- modules-all --- > > --- all_subdir_an --- > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > > error: a > > function definition without a prototype is deprecated in all versions of C > > and is not > > supported in C2x [-Werror,-Wdeprecated-non-prototype] > > [..] > > > > Disabling all wireless options in the kernel config starts dropping errors > > of a similar kind > > on other kernel places. > > > > Compiling on FBSD 13-STABLE seems to be all right. > > > > Can this be fixed. please? What causes the error and how can this be > > resolved if the subtree > > of FreeBSD's sources is a submodule? > > Not sure what you mean with "subtree is a submodule", but this is likely > caused by skipping the cross-tools stage somehow. Do you have any > specific make.conf or src.conf settings for that? FWIW, HardenedBSD is also impacted by this. We set WITH_SYSTEM_COMPILER and WITH_SYSTEM_LINKER by default, which I think might be a contributing factor. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Lots of port failures today?
On Thu, Aug 18, 2022 at 02:28:58PM -0700, Mark Millard wrote: > Larry Rosenman wrote on > Date: Thu, 18 Aug 2022 19:45:10 UTC : > > > https://home.lerctr.org:/build.html?mastername=live-host_ports=2022-08-18_13h12m51s > > > > circa 97ecdc00ac5 on main > > Ideas? > > Unsure but . . . > > A bunch of your errors start with text looking like: > > QUOTE > CMake Error: > The detected version of Ninja () is less than the version of Ninja required > by CMake (1.3). > END QUOTE > The 14-CURRENT/amd64 package build I kicked off yesterday for HardenedBSD is experiencing the same exact failure. Nearly 12,000 ports skipped: http://ci-08.md.hardenedbsd.org/build.html?mastername=hardenedbsd-current_amd64-local=2022-08-17_20h01m01s Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: [iwlwifi] ipv6 connection problem
I should have mentioned that my wireless AP isn't your typical AP. It's running HardenedBSD 13-STABLE on a PC-Engines APU2 with an Atheros WNIC. Here's the relevant configs on the WAP: begin rc.conf ifconfig_igb0="DHCP" ifconfig_igb0_ipv6="inet6 accept_rtadv" wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap mode 11a up" ifconfig_wlan0="HOSTAP" cloned_interfaces="bridge0" ifconfig_bridge0="addm igb0 addm wlan0 span igb1 up" end rc.conf begin hostapd-wlan0.conf interface=wlan0 ctrl_interface=/var/run/hostapd-wlan0 ctrl_interface_group=wheel ssid=[redacted] wpa=2 wpa_passphrase=[redacted] wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP end hostapd-wlan0.conf On Sat, Aug 13, 2022 at 09:49:34PM +0100, Nuno Teixeira wrote: > Hello Shawn! > > I've tested your config: > --- > wlans_iwlwifi0="wlan0" > create_args_wlan0="wlanmode sta regdomain ETSI country PT" > ifconfig_wlan0_ipv6="inet6 accept_rtadv" > ifconfig_wlan0="WPA DHCP" > rtsold_enable="YES" > --- > and no carrier. > > Think we have to wait a little more and see if people that use ifwwifi > driver do some tests on ipv6. > > Thanks, > > Shawn Webb escreveu no dia sábado, 13/08/2022 > à(s) 21:21: > > > On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote: > > > Hello, > > > > > > Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can > > > have a funcional internet. > > > > > > Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf: > > > --- > > > wlans_iwlwifi0="wlan0" > > > create_args_wlan0="wlanmode sta regdomain ETSI country PT" > > > ifconfig_wlan0_ipv6="inet6 accept_rtadv" > > > ifconfig_wlan0="WPA SYNCDHCP" > > > rtsold_enable="YES" > > > --- > > > but wpa_supplicant doesn't connect after trying for some seconds. > > > > > > How do I obtain more details to help showing my problem? > > > I've tried "wpa_supplicant_flags="-f /var/log/wpa.log" without success. > > > > Caveat: the last time I used the iwlwifi driver was somewhere between > > one and two months ago, during which time there have been several > > changes in src related to wifi/linuxkpi stuff. > > > > Hardware: Dell Precision 7550, BIOS revision 1.13.0 > > > > Dual stack IPv4+IPv6 worked for me that last time I used iwlwifi. > > Here's my relevant configs: > > > > begin rc.conf > > ifconfig_em0_ipv6="inet6 accept_rtadv" > > ifconfig_em0="DHCP" > > > > #wlans_iwlwifi0="wlan0" > > create_args_wlan0="wlanmode sta" > > wlandebug_wlan0="+state +crypto +node +auth +assoc +dot1xsm +wpa" > > ifconfig_wlan0="WPA DHCP" > > ifconfig_wlan0_ipv6="inet6 accept_rtadv" > > end rc.conf > > > > begin `pciconf -lv` > > iwlwifi0@pci0:0:20:3: class=0x028000 rev=0x00 hdr=0x00 vendor=0x8086 > > device=0x06f0 subvendor=0x8086 subdevice=0x4070 > > vendor = 'Intel Corporation' > > device = 'Comet Lake PCH CNVi WiFi' > > end `pciconf -lv` > > > > begin dmesg.boot > > 27] iwlwifi0: successfully loaded firmware image > > 'iwlwifi-QuZ-a0-hr-b0-71.ucode' > > [27] iwlwifi0: api flags index 2 larger than supported by driver > > [27] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37 > > [27] iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode > > op_mode iwlmvm > > [27] iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x351 > > [28] iwlwifi0: Detected RF HR B3, rfid=0x10a100 > > [28] iwlwifi0: base HW address: [redacted] > > end dmesg.boot > > > > Hopefully this helps. But this is all the info I've got. Please let me > > know if you have any questions or comments. > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > -- > Nuno Teixeira > FreeBSD Committer (ports) -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: [iwlwifi] ipv6 connection problem
On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote: > Hello, > > Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can > have a funcional internet. > > Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf: > --- > wlans_iwlwifi0="wlan0" > create_args_wlan0="wlanmode sta regdomain ETSI country PT" > ifconfig_wlan0_ipv6="inet6 accept_rtadv" > ifconfig_wlan0="WPA SYNCDHCP" > rtsold_enable="YES" > --- > but wpa_supplicant doesn't connect after trying for some seconds. > > How do I obtain more details to help showing my problem? > I've tried "wpa_supplicant_flags="-f /var/log/wpa.log" without success. Caveat: the last time I used the iwlwifi driver was somewhere between one and two months ago, during which time there have been several changes in src related to wifi/linuxkpi stuff. Hardware: Dell Precision 7550, BIOS revision 1.13.0 Dual stack IPv4+IPv6 worked for me that last time I used iwlwifi. Here's my relevant configs: begin rc.conf ifconfig_em0_ipv6="inet6 accept_rtadv" ifconfig_em0="DHCP" #wlans_iwlwifi0="wlan0" create_args_wlan0="wlanmode sta" wlandebug_wlan0="+state +crypto +node +auth +assoc +dot1xsm +wpa" ifconfig_wlan0="WPA DHCP" ifconfig_wlan0_ipv6="inet6 accept_rtadv" end rc.conf begin `pciconf -lv` iwlwifi0@pci0:0:20:3: class=0x028000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x06f0 subvendor=0x8086 subdevice=0x4070 vendor = 'Intel Corporation' device = 'Comet Lake PCH CNVi WiFi' end `pciconf -lv` begin dmesg.boot 27] iwlwifi0: successfully loaded firmware image 'iwlwifi-QuZ-a0-hr-b0-71.ucode' [27] iwlwifi0: api flags index 2 larger than supported by driver [27] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37 [27] iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode op_mode iwlmvm [27] iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x351 [28] iwlwifi0: Detected RF HR B3, rfid=0x10a100 [28] iwlwifi0: base HW address: [redacted] end dmesg.boot Hopefully this helps. But this is all the info I've got. Please let me know if you have any questions or comments. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Failover Mode between ether/wlan panics
On Mon, Aug 01, 2022 at 01:05:07AM +0100, Nuno Teixeira wrote: > Hello, > > I'm trying to setup a failover mode ethernet/wireless as shown in > https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-and-wireless > and I got a panic. > > /etc/rc.conf: > --- > ifconfig_re0="ether " > wlans_iwlwifi0="wlan0" > ifconfig_wlan0="WPA" > create_args_wlan0="country PT" > cloned_interfaces="lagg0" > ifconfig_lagg0="up laggproto failover laggport re0 laggport wlan0 DHCP" > --- > > Any ideas of what's wrong? > BTW, no kernel dump and I have dumpdev="AUTO" in /etc/rc.conf... When I last talked to bz@, the combination of iwlwifi and lagg was reported as not supported. bz@ might need/want some help in that area. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Kernel panic in networking code
On Thu, Dec 09, 2021 at 12:05:30PM -0500, Mark Johnston wrote: > On Thu, Dec 09, 2021 at 10:20:10AM -0500, Shawn Webb wrote: > > Hey all, > > > > It looks like there's a potential deadlock in some networking code, > > specifically with ipv4 jails. I can reproduce by running Poudriere on > > 14-CURRENT. > > > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to > > any point in the code paths that would trigger/cause this kind of > > kernel panic. > > > > I've uploaded the crash.txt file here: > > https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt > > There is some WIP to address this in https://reviews.freebsd.org/D9 > and its followup revision. Awesome. Thanks for the response! I'll follow along. I'm happy to test out the patch before it lands if needed/wanted. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Kernel panic in networking code
Hey all, It looks like there's a potential deadlock in some networking code, specifically with ipv4 jails. I can reproduce by running Poudriere on 14-CURRENT. I am using HardenedBSD 14-CURRENT, but we don't have any changes to any point in the code paths that would trigger/cause this kind of kernel panic. I've uploaded the crash.txt file here: https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt `uname -a`: FreeBSD ci-08 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD #0 hardened/current/master-n191216-7474f245a83: Wed Dec 8 22:44:04 EST 2021 shawn@ci-08:/usr/obj/usr/src/amd64.amd64/sys/HARDENEDBSD amd64 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: [REVIEW] Hide BIT_* macros from userland code
On Fri, Dec 03, 2021 at 11:03:54AM +0100, Stefan Esser wrote: > Am 02.12.21 um 17:46 schrieb Shawn Webb: > > Hey Stefan, > > > > On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: > >> I have created > >> > >>https://reviews.freebsd.org/D33235 > >> > >> to remove the BIT_* macros used in the kernel from the userland API. > >> > >> They conflict with differing definitions in some 3rd party code and > >> lead to compile issues in a number of ports (via CPU_* macros based > >> on the BIT_* macros). > >> > >> See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787 > >> for an example of such a problem. > > > > I recently was in a position to evaluate BIT_* macros for userland > > use. It was around the time when the conversation regarding hiding > > BIT_* from userland, which conversation caused me to find another > > solution. > > > > I think such an API is incredibly useful, so I wonder if there's a way > > to satisfy both. For example, maybe prefix the userland side with a > > USERLAND_ or something similar? Kernel would use BIT_* and userland > > would use USERLAND_BIT_* (just spitballing, not actually advocating > > for "USERLAND_BIT_*" but rather just the idea of it.) > > Hi Shawn, > > I have updated the patch set in review D33235 and have added you to > the reviewer list. > > IMHO the approach proposed by Konstantin Belousov is better than the > introduction of prefixed macro names for the userland. > > A simple #define _WANT_FREEBSD_BITSET makes the __BIT* macros available > by their traditional names, no other changes are required in the code. > > This does not solve the potential case of a program that wants to use > both the BSD and GLIBC variants of the macros in a single source file. > But I think that such a case is constructed and does not occur in > actual code. > > And in any case, the IMHO __BIT* names are as good as the USERLAND_BIT* > names you suggest (and I understand that you did not want that specific > name - therefore a prefix of __ might be considered to match what you > proposed ;-) ). > > And you are of course free to map __BIT* to any other prefixed name in > a header file in your code ... > > An update of the bitset(9) man page might be a good idea, explaining > the visibility rules and _WANT_FREEBSD_BITSET for system utilities that > need to work with kernel style bitsets. Awesome. kib's suggestion makes sense here. And thanks for adding me to the review. I'll make sure to pay attention as it progresses. :-) Thanks again, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: [REVIEW] Hide BIT_* macros from userland code
Hey Stefan, On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: > I have created > > https://reviews.freebsd.org/D33235 > > to remove the BIT_* macros used in the kernel from the userland API. > > They conflict with differing definitions in some 3rd party code and > lead to compile issues in a number of ports (via CPU_* macros based > on the BIT_* macros). > > See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787 > for an example of such a problem. I recently was in a position to evaluate BIT_* macros for userland use. It was around the time when the conversation regarding hiding BIT_* from userland, which conversation caused me to find another solution. I think such an API is incredibly useful, so I wonder if there's a way to satisfy both. For example, maybe prefix the userland side with a USERLAND_ or something similar? Kernel would use BIT_* and userland would use USERLAND_BIT_* (just spitballing, not actually advocating for "USERLAND_BIT_*" but rather just the idea of it.) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: VDSO on amd64
On Thu, Nov 25, 2021 at 09:53:19PM +0200, Konstantin Belousov wrote: > On Thu, Nov 25, 2021 at 09:35:53AM +, David Chisnall wrote: > > Great news! > > > > Note that your example of throwing an exception from a signal handler works > > because the signal is delivered during a system call. The compiler > > generates correct unwind tables for calls because any call may throw. > The syscalls itself are not annotated, I consider fixing this after vdso > lands. > > > > > If you did something like a division by zero to get a SIGFPE or a > > null-pointer dereference to get a SIGSEGV then the throw would probably not > > work (or, rather, would be delivered to the right place but might corrupt > > some register state). Neither clang nor GCC currently supports non-call > > exceptions by default. > Well, yes, the part of it was that the signal was synchronous. I was always > curious, how good are unwind tables generated by -fasynchronous-unwind-tables > with this regard. > > But still, the fact that unwinder stepped over the signal frame amused me. > > > > > This mechanism is more useful for Java VMs and similar. Some Linux-based > > implementations (including Android) use this to avoid null-pointer checks in > > Java. > > > > The VDSO mechanism in Linux is also used for providing some syscall > > implementations. In particular, getting the current approximate time and > > getting the current CPU (either by reading from the VDSO's data section or > > by doing a real syscall, without userspace knowing which). It also provides > > the syscall stub that is used for the kernel transition for all 'real' > > syscalls. This doesn't matter so much on amd64, but on i386 it lets them > > select between int 80h, syscall or sysenter, depending on what the hardware > > supports. > > > > > > A few questions about future plans: > > > > - Do you have plans to extend the VDSO to provide system call entry points > > and fast-path syscalls? It would be really nice if we could move all of the > > libsyscalls bits into the VDSO so that any compartmentalisation mechanism > > that wanted to interpose on syscalls just needed to provide a replacement > > for the VDSO. > No. > > Moving syscall entry point to VDSO is pointless: > - it would add one more level of indirection before SYSCALL, > - we do not have slow syscall entry point on amd64 so there is nothing to > choose. > > And optimizing 32bit binaries (where we could implement slightly faster > syscall entry) is past its importance. > > Basically, we do not have to split libc into libc proper and VDSO, as > Linux has. We can implement features for syscall boundary from both > sides of kernel, because libc and kernel are developed under the same > project. Usermode timehands, fast signal blocks, upcoming rseq support, > just to name a few of them, all benefit from this model. > > VDSO is only needed for us to provide the unwind annotations on the signal > trampoline, in a way expected by unwinders. > > > > > - It looks as if the Linux VDSO mechanism isn't yet using this. Do you > > plan on moving it over? > No. > > > > > - I can't quite tell from kern_sharedpage.c (this file has almost no > > comments) - is the userspace mapping of the VDSO randomised? This has been > > done on Linux for a while because the VDSO is an incredibly high-value > > target for code reuse attacks (it can do system calls and it can restore the > > entire register state from the contents of an on-stack buffer if you can > > jump into it). > Not now. Randomizing shared page location is not too hard, but there are > some ABI issues to sort out. We live with fixed-mapped shared page for > more than 10 years. As a point of reference, HardenedBSD's PaX-inspired ASLR implementation has randomized the shared page for more than half a decade now without issue. I suspect FreeBSD will find, if applied properly, randomization of the shared page (now VDSO) likely won't break anything. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Fri, Oct 29, 2021 at 11:59:40AM +0100, David Chisnall wrote: > On 28/10/2021 16:26, Shawn Webb wrote: > > I wonder if providing a 9pfs client would be > > a good step in helping deprecate smbfs. > > Note: WSL2 uses 9p-over-VMBus, but most of the Linux world is moving away > from 9p-over-VirtIO to FUSE-over-VirtIO. This has a few big advantages: > > - The kernel already has solid FUSE support so this isn't a completely new > code path. > > - FUSE is designed around POSIX filesystem semantics, 9p isn't and this > mismatch causes problems in places. > > - FUSE filesystems can be exposed almost directly to the guest. For > example, if you have a networked filesystem you can run the FUSE FS in an > unprivileged userspace process and remove the entire host kernel storage > stack from the attack surface for the guest. > > - FUSE allows exposing buffer cache pages. The FUSE-over-VirtIO mechanism > makes it fairly easy to expose read-only root filesystem images to guests. > > The last point is especially important for container workloads where you may > have hundreds of containers in lightweight VMs on a single node all using > the same base layer. That's really cool. I hadn't heard about FUSE-over-VirtIO before. Thanks for the info! -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Thu, Oct 28, 2021 at 10:44:56AM -0400, Ed Maste wrote: > The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and > I propose removing it for FreeBSD 14. I know the CHERI folks have been > using it but they plan to migrate away from it. It was broken for > months before they fixed it, so I suspect nobody is using it on > contemporary releases. > > I have review D32707 (https://reviews.freebsd.org/D32707) open to add > this deprecation notice to the man page: > The smbfs filesystem driver supports only the obsolete SMBv1 protocol. > smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not > present in FreeBSD 14 and above. Users are advised to evaluate the > sysutils/fusefs-smbnetfs port instead. > > A similar notice would be added to the smbutil and mount_smbfs man > pages, and manu@ suggested having the userland utilities emit a > warning when they are used. > > I am interested in comments, objections, or reports that anyone is in > fact using smbfs. > It seems that smbfs might be used with some level of frequency in virtualized environments. I wonder if providing a 9pfs client would be a good step in helping deprecate smbfs. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 09, 2021 at 09:46:24AM +0200, FreeBSD User wrote: > On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > appliance failed very early in the build process of the 13-STABLE > sources as shown below. 13-STABLE is most recent, since the sources are > fetched every time the build process is triggered. > > The framework for the build process is nanoBSD, the same error occurs > when building poudriere's jail based upon 13-STABLE from scratch via > the FreeBSD native build framework. > > "Cross building" of 13-STABLE on a CURRENT platform worked in most > cases and most time, hopefully this hickup is a solveable problem and > it would be nice to have this fixed. > > What is the reason for the linker fail? > > Are there any recommenadtions how to "cross build" 13-STABLE on a > 14-CURRENT platform in case the approach of mine s not a desireable on? > > Thanks in advance, > > Oliver > > [...] > > sh > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > -s -o root -g wheel -m 555 compile_et > /pool/home/ohartmann/Projects/router/router/apu2 > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: undefined > symbol: setupterm > >>> referenced by Process.cpp > >>> Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > >>> in archive > >>> /pool/home/ohartmann/Projects/router/router/apu2c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a > Anyone else still hitting this? I am. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: [HEADSUP] making /bin/sh the default shell for root
On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > For years now, csh is the default root shell for FreeBSD, csh can be > > confusing > > as a default shell for many as all other unix like settled on a bourne shell > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like other > > shells > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > * support for history as described by POSIX. > > > > This makes it a usable shell by default, which is why I would like to > > propose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > > > If no strong arguments has been raised until October 15th, I will make this > > proposal happen. > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > I think this is fine. I would also be fine with either removing 'toor' from > the > default password file or just leaving it as-is for POLA. (I would probably > prefer removing it outright.) HardenedBSD recently removed toor. No one has complained (yet?). A small Twitter poll[0] showed that 85% of people who responded do not use toor. [0]: https://twitter.com/HardenedBSD/status/1415781911063056389 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Call for participation
On Thu, Sep 02, 2021 at 08:43:21AM -0600, Warner Losh wrote: > Greetings, > > As teased on twitter, now that summer is over, it's a good time to start > working on the next steps with git. When we moved to git, we knew a number > of things would come in phase 2 since phase 1 was limited to moving away > from subversion and to git. > > Now's the time for phase 2. The deferred items included better CI > pipelines, better integration with popular hosting sites like github and > gitlab, a look at the tools we have today and how they fit together, and a > bunch of other items that were less well defined. I've spent the last > several months looking at the different practices in open source, > looking at our tools, etc. We have bits and pieces of many of these items, > but are missing some glue between what we have. Other areas need more > extensive work. > > To coordinate this work, I'll be leading a team to look at what we can do > in the short term, the medium term and where we think we want to be in the > long term. I plan on having bi-weekly meetings to discuss different issues > that come up, to coordinate work and experiments and to give some structure > to encouragement for progress to be made. > > This will be a collaborative effort between the developers and the user > community that contributes patches to any part of FreeBSD (the base, ports > and docs). If you are interested in participating, please drop me a line. > We'll have a core office hours to talk about this soon, and I'd like to > start discussions with those that are interested before hand, as well as > invite people to participate in the office hours. After that, we'll have a > kick off meeting that's open to everybody who can respectfully contribute. > > Looking forward to hearing from you. Hey Warner, I'd be happy to talk about HardenedBSD's switch from GitHub to Gitea and finally to GitLab. We had a lot of troubles with Gitea and ended up with GitLab. When are you thinking of holding that meeting? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Patch for patch, but not foreach :-)
On Fri, May 07, 2021 at 03:49:00PM +0200, Hans Petter Selasky wrote: > Time has come that I make a patch for the most central patching tool in > FreeBSD, patch :-) > > https://reviews.freebsd.org/D30160 As stupid as it sounds, '*' is a valid filename. -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Arm64 Tier 1 FreeBSD 13 Phones
On Sat, Apr 10, 2021 at 04:07:49AM -0400, grarpamp wrote: > FreeBSD Phones... > > https://en.wikipedia.org/wiki/Librem_5 > NXP i.MX 8M Quad core Cortex-A53, 64bit ARM > > https://en.wikipedia.org/wiki/PinePhone > Allwinner A64 ARM Quad core Cortex-A53 > > https://www.youtube.com/watch?v=c32-QOrI4cw > https://www.youtube.com/watch?v=fCKMxzz9cjs > https://www.youtube.com/watch?v=lVJo9faE1fM > https://www.youtube.com/watch?v=NV0RnWorPpQ > > Happy hacking :) There's a company (called Potabi? Fivnex?) that claims to be developing a FreeBSD-based phone on PinePhone hardware. They claim to eventually be able to run Android apps on it. As it stands, I'm seeing more marketing material than development efforts published by them. If I were to hazard a guess, this "development" effort will fizzle out. I'd like to see it come to fruition, but I'm pretty skeptical. https://potabi.fivnex.co/development Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
On Sat, Feb 27, 2021 at 10:29:14PM -0700, Warner Losh wrote: > On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote: > > > > > > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add > > > any security, except imaginary? The only purpose of it is to have a > > > check-list item ticked green. > > > > I don't know if I should parse this as sarcasm (or any other form of > > "humor") or is a serious statement? But this does leave me with a whole > > bunch of questions.. > > > > If this is really how Konstantin is describing it then is it OK to say > > about this to the whole Internet? Why FreeBSD Foundation is paying for > > meaningless work then? Why members of the Core team do this work? Does > > this mean that FreeBSD is working to satisfy the silly needs of some fat > > customer? What about project independence and not being controlled by > > big money? > > > > Where can I read about ASLR and security myths? > > Why not spend time and explain why this does not work? > > > > Not to rise to the baitiness of all these leading questions (they really > are quite contrary to how our community usually comports itself, but for > the sake of civil discourse, I'll ignore) > > I'll bet it has something to do with the many known ASLR attacks. One is > chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show > how MMU side channels can defeat ASLR. Or maybe he's familiar with the > offset2lib attack against Linux 64-bit ASLR documented in this paper > https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. > There's many others as well that show the shortcomings of ASLR and disclose > ways to defeat it using various clever means. Problem with these papers is that they put ASLR on a pedestal it doesn't deserve. If you take a look at PaX's original ASLR paper, you'll learn that ASLR was not designed to protect against local attacks. You'll also learn that the infoleak weakness was already postulated, even in its initial design and implementation. Attacks against the MMU require local code execution--for example, javascript in a browser. ASLR was never meant to protect against such a case. We must take the original design into account when discussing ASLR's valid shortcomings. The point of ASLR is to combine it with W^X. Without W^X, ASLR makes no sense. FreeBSD recently gained a W^X implementation that requires opt-in. When combined with W^X, exploit authors must chain together multiple vulnerabilities in order to successfully exploit. The combination of ASLR and W^X have forever changed the very foundation of exploitation. Both, when combined, do their job well--that of raising the economic cost of successful remote exploitation. Now that FreeBSD has both a form of ASLR known as ASR and a W^X implementation, FreeBSD can move on to other exploit mitigations, such as CFI and SafeStack (both of which are already integrated in some form in HardenedBSD.) This is likely to be my only response to this thread as I'm incredibly tired of rehashing the same arguments, especiall with regards to kib@, over the span of many years. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021 at 09:00:45AM -0700, Warner Losh wrote: > On Sun, Jan 24, 2021, 6:05 AM Jeffrey Bouquet > wrote: > > > > > > > On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl < > > s...@troutmask.apl.washington.edu> wrote: > > > > > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: > > > > From: Steve Kargl > > > > Subject: Getting /usr/src to match specific git hash? > > > > Date: Sat, 23 Jan 2021 19:58:52 -0800 > > > > > > > > > Suppose one has an empty /usr/src. > > > > > > > > > > Suppose further that one had to re-install a 32-bit > > > > > i386-*-freebsd with the 24 Dec 2020 image available > > > > > from freebsd.org. > > > > > > > > > > uname -a for the booted kernel shows > > > > > > > > > > % uname -a > > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > > > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > > > > > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC > > i386 > > > > > > > > > > How does one use git to pull the exact sources that match > > > > > this specifc kernel? > > > > > > > > cd /usr > > > > git clone https://git.freebsd.org/src.git > > > > cd src > > > > git checkout 3cc0c0d66a0 > > > > > > > > > > Thank you. > > > > > > -- > > > Steve > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > Can this be put in /usr/src/UPDATING with an explanation of precisely how > > each > > of the git commands populates or repopulated the directories in /usr??? > > > > It is in the mini primer I wrote, along with how to bisect and other useful > things. This will migrate into the handbook once the doc tree converts to > asciidoc (happening this weekend). > > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md I'm glad this is moving to FreeBSD's documentation. Following the process of FreeBSD's migration to git has been a bit troublesome with some docs somewhere other docs elsewhere. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Sat, Jan 02, 2021 at 08:37:14AM +0800, Li-Wen Hsu wrote: > On Sat, Jan 2, 2021 at 4:25 AM Christian Weisgerber > wrote: > > > > On 2021-01-01, Shawn Webb wrote: > > > > > This is why I asked FreeBSD to provide anonymous read-only ssh:// > > > support for git. I'm very grateful they support it. > > > > > > One thing that I need to do with the HardenedBSD infrastructure is > > > publish on our site the ssh pubkeys of the server (both RSA and > > > ed25519). I plan to do that sometime this coming week. I wonder if it > > > would be a good idea for FreeBSD to do the same > > > > The draft FreeBSD Git docs have the SSH fingerprints of the Git > > servers. > > https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md > > > > Here's one from my own ~/.ssh/known_hosts: > > SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519) > > And the ssh-keys file is available on the project site, signed with > security-officer's key: > > https://www.freebsd.org/internal/ssh-keys.asc > > And in that file's header: > """ > Note that all machines listed below also have signed SSHFP records in > DNS. If you have a DNSSEC-aware resolver and set VerifyHostKeyDNS to > "ask" or "yes" in ~/.ssh/config, OpenSSH will verify host keys against > these SSHFP records. > """ Awesome! Thanks for the clarification! Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, Dec 31, 2020 at 09:25:08PM -0500, grarpamp wrote: > > There is already HTTPS to protect the "authenticity" of the magnet > > link. > > No. FreeBSD fails to publish signed fingerprints of their TLS pubkeys, > therefore users can't pin them down, therefore any MITM can bypass > CA game and MITM attack users at will, feed them bogus infohash, > isos, git repo tofu, pkg, etc. MITM is bad, MITM is in use, > and MITM fails when sig'd, verified, and pinned. There's also nation states that require use of a nation state-owned root CA cert so that they can MITM every single SSL/TLS connection. Connections that don't use/support their custom trusted root cert are either blocked or reported (or both). In this case, MITM isn't theoretically broken, it's broken in practice. And, it's broken in the worst case scenario: downloading source code that the nation state can modify in-transit. This is why I asked FreeBSD to provide anonymous read-only ssh:// support for git. I'm very grateful they support it. I also use it for HardenedBSD's sync scripts due to my own distrust of browser-based SSL/TLS PKI, even in the USA. One thing that I need to do with the HardenedBSD infrastructure is publish on our site the ssh pubkeys of the server (both RSA and ed25519). I plan to do that sometime this coming week. I wonder if it would be a good idea for FreeBSD to do the same (note: I'm not trying to commit FreeBSD to do any work; I'm just spitballing ideas.) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Enabling AESNI by default
On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote: > We've had the AESNI module for quite a few years now, and it has not > caused any problems. > > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), > you need to load aesni.ko' > > Userspace crypto that uses openssl or similar libraries is already > taking advantage of these CPU instructions if they are available, by > excluding this feature from GENERIC we are just causing the "out of the > box" experience to by very very slow for crypto. > > For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) > device: > > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz > > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync > --group_reporting --fallocate=none --runtime=60 --time_based > > > stock: > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) > > with aesni.ko loaded: > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) > > > Does anyone have a compelling reason to deny our users the 5x speedup? Note: HardenedBSD has had AESNI enabled on amd64 for nearly six years. Not a single complaint. For reference, HardenedBSD commit: a5aabd1c8dcc2a5097de56c54ec2a1c8d9352896 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: git tools for building in base?
On Wed, Nov 25, 2020 at 04:00:50PM +0100, Baptiste Daroussin wrote: > On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: > > On Tue, Nov 24, 2020 at 2:19 PM tech-lists wrote: > > > > > As subject - what will there be in base to interact with the new git repo? > > > I mean, right now, for svn there is svnlite. What for git? > > > > > > > 'pkg add git' is your choice now. > > pkg install not pkg add There's also fetch for a one-time download of the ports tree (bootstrapping ports, for example). A HardenedBSD user would do this: fetch -o ports.tar.gz \ https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/archive/master.tar.gz mkdir -p /usr/ports tar -xf ports.tar.gz --strip-components 1 -C /usr/ports Something similar could be done in FreeBSDlandia. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: iflib/bridge kernel panic
On Tue, Sep 29, 2020 at 05:36:15PM -0400, Shawn Webb wrote:
> On Tue, Sep 29, 2020 at 11:20:44PM +0200, Kristof Provost wrote:
> >
> >
> > On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:
> >
> > > Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16
> > > +0200):
> > >
> > > > On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:
> > > > > Quoting Kristof Provost (from Sun, 27 Sep 2020
> > > > > 17:51:32 +0200):
> > > > > > Here???s an early version of a task queue based approach:
> > > > > > http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch
> > > > > >
> > > > > > That still needs to be cleaned up, but this should resolve
> > > > > > the sleep issue and the LOR.
> > > > >
> > > > > There are some issues... seems like inside a jail I can't ping
> > > > > systems outside of the hardware.
> > > > >
> > > > > Bridge setup:
> > > > >- member jail A
> > > > >- member jail B
> > > > >- member external_if of host
> > > > >
> > > > > If I ping the router from the host, it works. If I ping from one
> > > > > jail to another, it works. If I ping from the jail to the IP of
> > > > > the external_if, it works. If I ping from a jail to the router,
> > > > > I do not get a response.
> > > > >
> > > > Can you check for 'failed ifpromisc' error messages in dmesg? And
> > > > verify that all bridge member interfaces are in promiscuous mode?
> > >
> > > I have a panic for you...:
> > > - startup still in progress = 22 jails in startup, somewhere after a
> > > few jails started the panic happened
> > > - tcpdump was running on the external interface
> > > - a ping to a jail IP from another system was running, the first ping
> > > went through, then it paniced
> > >
> > > First regarding your questions about promisc mode: no error, but the
> > > promisc mode is directly disabled again on all interfaces.
> > >
> > I think I see why you had issues with the promiscuous setting. I???ve
> > updated the patch to be even more horrific than it was before.
> >
> > I can???t explain the panic, and the backtrace also doesn???t appear to be
> > directly related to this patch. Not sure what???s going on with that.
>
> I should have time to test the new patch this weekend. ${LIFE} is
> keeping me busy the past few weeks. I'm gonna add an event in my
> calendar to remind me to test the patch. heh.
Sorry for the delay. I rebuilt with the new patch this morning.
Looking good on all fronts, including LORs.
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
Re: iflib/bridge kernel panic
On Tue, Sep 29, 2020 at 11:20:44PM +0200, Kristof Provost wrote:
>
>
> On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:
>
> > Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16
> > +0200):
> >
> > > On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:
> > > > Quoting Kristof Provost (from Sun, 27 Sep 2020
> > > > 17:51:32 +0200):
> > > > > Here???s an early version of a task queue based approach:
> > > > > http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch
> > > > >
> > > > > That still needs to be cleaned up, but this should resolve
> > > > > the sleep issue and the LOR.
> > > >
> > > > There are some issues... seems like inside a jail I can't ping
> > > > systems outside of the hardware.
> > > >
> > > > Bridge setup:
> > > >- member jail A
> > > >- member jail B
> > > >- member external_if of host
> > > >
> > > > If I ping the router from the host, it works. If I ping from one
> > > > jail to another, it works. If I ping from the jail to the IP of
> > > > the external_if, it works. If I ping from a jail to the router,
> > > > I do not get a response.
> > > >
> > > Can you check for 'failed ifpromisc' error messages in dmesg? And
> > > verify that all bridge member interfaces are in promiscuous mode?
> >
> > I have a panic for you...:
> > - startup still in progress = 22 jails in startup, somewhere after a
> > few jails started the panic happened
> > - tcpdump was running on the external interface
> > - a ping to a jail IP from another system was running, the first ping
> > went through, then it paniced
> >
> > First regarding your questions about promisc mode: no error, but the
> > promisc mode is directly disabled again on all interfaces.
> >
> I think I see why you had issues with the promiscuous setting. I???ve
> updated the patch to be even more horrific than it was before.
>
> I can???t explain the panic, and the backtrace also doesn???t appear to be
> directly related to this patch. Not sure what???s going on with that.
I should have time to test the new patch this weekend. ${LIFE} is
keeping me busy the past few weeks. I'm gonna add an event in my
calendar to remind me to test the patch. heh.
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
Re: iflib/bridge kernel panic
On Mon, Sep 21, 2020 at 09:57:40AM +0200, Kristof Provost wrote: > On 21 Sep 2020, at 2:52, Shawn Webb wrote: > >> From latest HEAD on a Dell Precision 7550 laptop: > > > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > > > The last working boot environment was 14 Aug 2020. If I get some time to > > bisect commits, I'll try to figure out the culprit. > > > Try https://reviews.freebsd.org/D26418 That seems to fix the kernel panic. dmesg gets spammed with a freak ton of these LOR messages now: BEGIN LOG 01 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] Sleeping on "e1000_delay" with the following non-sleepable locks held: Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xf8001ea07218) locked @ /usr/src/sys/net/if_bridge.c:827 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] stack backtrace: Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #0 0x80c6c4a1 at witness_debugger+0x71 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #1 0x80c6d5bd at witness_warn+0x40d Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #2 0x80c09b8b at _sleep+0x5b Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #3 0x80c0a38e at pause_sbt+0xfe Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #4 0x80652b2d at e1000_write_phy_reg_mdic+0xed Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #5 0x80656bde at __e1000_write_phy_reg_hv+0x1ce Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #6 0x80640ea9 at e1000_lv_jumbo_workaround_ich8lan+0x799 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #7 0x8062329e at em_if_init+0x151e Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #8 0x80d347a9 at iflib_init_locked+0x2d9 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #9 0x80d36b08 at iflib_if_ioctl+0x1b8 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #10 0x83c582ac at bridge_set_ifcap+0x8c Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #11 0x83c544c8 at bridge_ioctl_add+0x4c8 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #12 0x83c560ff at bridge_ioctl+0x2df Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #13 0x80d9f1a1 at in_control+0x341 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #14 0x80d16266 at ifioctl+0x766 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #15 0x80c715a0 at kern_ioctl+0x290 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #16 0x80c71267 at sys_ioctl+0x127 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #17 0x8122bf4c at amd64_syscall+0x14c END LOG 01 BEGIN LOG 02 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] lock order reversal: (sleepable after non-sleepable) Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] 1st 0xf800374616a0 ure0 (ure0, sleep mutex) @ /usr/src/sys/dev/usb/usb_request.c:714 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] 2nd 0x81eb1ab8 sysctl lock (sysctl lock, sleepable rm) @ /usr/src/sys/kern/kern_sysctl.c:837 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] lock order ure0 -> sysctl lock attempted at: Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #0 0x80c6c1dc at witness_checkorder+0xdcc Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #1 0x80bf76bb at _rm_wlock_debug+0x6b Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #2 0x80c0c7a6 at sysctl_add_oid+0x46 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #3 0x83c64ea1 at ure_attach_post+0x1a91 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #4 0x83c6a1af at ue_attach_post_task+0x2f Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #5 0x80a2b749 at usb_process+0xf9 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #6 0x80bb9fe5 at fork_exit+0x85 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #7 0x81200a9e at fork_trampoline+0xe END LOG 02 At work, I have two ethernet interfaces: the onboard em0 and a usb ethernet dongle. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
iflib/bridge kernel panic
>From latest HEAD on a Dell Precision 7550 laptop: https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 The last working boot environment was 14 Aug 2020. If I get some time to bisect commits, I'll try to figure out the culprit. Thanks, Shawn Webb (Sorry for the brevity. Only partially working system due to above breakage.) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Documentation regarding NFSv4
Hey all, It appears the Handbook and the nfsv4 manpages don't really agree, leading to some confusion as to how to properly set up an NFSv4 server on FreeBSD. Any guidance would be appreciated. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: `zfs list` permission denied
On Thu, Sep 10, 2020 at 12:46:45PM -0400, Ryan Moeller wrote: > > On 9/10/20 12:33 PM, Shawn Webb wrote: > > I used to be able to run `zfs list` as an unprivileged user. Now I > > can't, even when my user is in the operator group. > > > > BEGIN LOG > > hbsd-current-01[shawn]:/home/shawn $ zfs list > > Operation not permitted > > hbsd-current-01[shawn]:/home/shawn (1) $ id > > uid=1001(shawn) gid=1001(shawn) groups=1001(shawn),0(wheel),5(operator) > > hbsd-current-01[shawn]:/home/shawn $ ls -l /dev/zfs > > crw-rw-rw- 1 root operator 0x52 Sep 10 10:43 /dev/zfs > > END LOG > > > > Thanks, > > > You probably don't have the zfs module loaded. The commands will try to load > it if it isn't, and that will fail if you aren't root. Using root on ZFS: BEGIN LOG hbsd-current-01[shawn]:/scratch/logs (141) $ sudo kldstat Password: Id Refs AddressSize Name 1 150x0 2343700 kernel 210x0 652cb0 zfs.ko 310x0 b778 opensolaris.ko 410x0 2a10 mac_ntpd.ko END LOG I think I see the problem with your hint. Prior to the post-ZoL OpenZFS merge, we had detected whether the user running the command was non-root and only attempted module load if the user was root. We do this because we restrict access to kld*/mod* syscalls to root. And, as you can see from the output above, we scrub sensitive data from being returned from the kldstat syscall. I think I just need to re-apply that logic after this OpenZFS merge. Thanks for the hint! Sometimes I forget having written code from years back. ;) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
`zfs list` permission denied
I used to be able to run `zfs list` as an unprivileged user. Now I can't, even when my user is in the operator group. BEGIN LOG hbsd-current-01[shawn]:/home/shawn $ zfs list Operation not permitted hbsd-current-01[shawn]:/home/shawn (1) $ id uid=1001(shawn) gid=1001(shawn) groups=1001(shawn),0(wheel),5(operator) hbsd-current-01[shawn]:/home/shawn $ ls -l /dev/zfs crw-rw-rw- 1 root operator 0x52 Sep 10 10:43 /dev/zfs END LOG Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Please check the current beta git conversions
On Tue, Sep 01, 2020 at 01:14:10PM -0400, Ed Maste wrote: > We've been updating the svn-git converter and pushing out a new > converted repo every two weeks, and are now approaching the time where > we'd like to commit to the tree generated by the exporter, and > guarantee that hashes will remain consistent from this point. At this > point the Git Working Group believes the conversion represents a > high-fidelity translation of the Subversion history, but would > appreciate additional review in case we've missed anything. > > I'd ask folks with an interest in the FreeBSD repository to clone the > beta conversion and review the converted history in the specific areas > they are interested in - e.g., specific contrib/ software, device > drivers, etc. This will also present our final opportunity to change > the author map file, if necessary. > > The beta src tree can be cloned via: > % git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta > > Please follow up this week if you notice any discrepancies or author > entries that require updates. I'm curious if there's any plans for read-only access over ssh. Trusting FreeBSD's ssh key material is likely easier than trusting HTTPS in certain regions. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Length of ZFS volume names
Hey FreeBSD peeps, The zfs(8) manpage says that the maximum length of a dataset name is MAXNAMELEN (256 bytes). I've created a ZFS volume that has a dataset name length of 62. I don't see the ZFS volume in /dev/zvol and I noticed this sanitized error in dmesg: Aug 24 11:07:24 bh-build-01 kernel: [2395] ZFS WARNING: Unable to create ZVOL tank/bhyve/productname/dev/users/username/username-shortened_productname-dev-01/disk-01 (error=63). So I'm left wondering, does devfs have a smaller limit than ZFS for node paths? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Boot failure on refreshed Dell Precision 7550
On Fri, Jul 10, 2020 at 09:43:59AM -0400, Shawn Webb wrote: > On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: > > > > > > > On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > > > > > Hey all, > > > > > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > > > on it and UEFI boot failed. The screen goes black immedately when > > > selecting the memstick and around ten to twenty seconds later, the > > > system reboots. > > > > > > I'm thinking there might be a bug in the UEFI loader. I have zero > > > experience in this area, but would love to learn. Can someone punish > > > me with ideas on how to debug this? ;P > > > > > > I'll try to get whatever patches/fixes that come out of this effort > > > upstreamed. > > > > Just in case, is secure boot turned off? > > It is. FWIW, the laptop shipped with Ubuntu. I just built HardenedBSD 13-CURRENT install media from HardenedBSD commit 4fd20919a535d41571f0b4140a6ec953f1bb38b2 and that booted fine. I used the latest FreeBSD snapshot image, so I wonder what changed between that snapshot image and today that would allow it to boot. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Boot failure on refreshed Dell Precision 7550
On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: > > > > On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > > > Hey all, > > > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > > on it and UEFI boot failed. The screen goes black immedately when > > selecting the memstick and around ten to twenty seconds later, the > > system reboots. > > > > I'm thinking there might be a bug in the UEFI loader. I have zero > > experience in this area, but would love to learn. Can someone punish > > me with ideas on how to debug this? ;P > > > > I'll try to get whatever patches/fixes that come out of this effort > > upstreamed. > > Just in case, is secure boot turned off? It is. FWIW, the laptop shipped with Ubuntu. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Boot failure on refreshed Dell Precision 7550
Hey all, I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD on it and UEFI boot failed. The screen goes black immedately when selecting the memstick and around ten to twenty seconds later, the system reboots. I'm thinking there might be a bug in the UEFI loader. I have zero experience in this area, but would love to learn. Can someone punish me with ideas on how to debug this? ;P I'll try to get whatever patches/fixes that come out of this effort upstreamed. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: One True Awk upgrade
On Sun, Jun 02, 2019 at 10:55:41AM -0600, Warner Losh wrote: > I'm upgrading the in-tree version of one-true-awk. Normally, this isn't a > problem, but there's a number of small differences I'm still trying > to figure out due to our... contorted history. Some of the revisions we had > in the vendor branch of our repo were accepted as-is, some completely, and > some not yet, We've also added bug fixes we've found, as well as fixes from > other BSDs, which has also caused at least one unexplained difference. > > I should have it sorted out in the next day or so, but wanted to give a > heads up. I doubt anybody would notice, but each of the differences is > going to take a little time to sort out, chase back to the failing case, > work out with upstream if there's a bug or not, etc. There's also a small > window between r348513 and r348515 where the tree fails to build (due to > svn's commit subtree vs git's commit while tree differences). > > Also, I've not tagged this as such, but my plans are to MFC to 12 next > week, and to 11 after 11.3R goes out the door. Hey Warner, Thanks for maintaining one-true-awk in the tree! I was planning on publishing a new binary update of 13-CURRENT for HardenedBSD users. Should I hold off until the dust settles? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: FreeBSD and Coreboot
Hey Eric, My response is inline. On Mon, May 27, 2019 at 11:13:46AM -0400, Eric McCorkle wrote: > Hello everyone, > > I'm through enough of my job change that I can start working on FreeBSD > again. One thing I've had on my list to examine is using FreeBSD with > coreboot, so I wanted to put out a call for anyone who has done work on > this, or knows anything about it. > > Here is what I know: > > * Coreboot _can_ boot kernels directly, but this requires two things: 1) > you must flash your BIOS every time you update a kernel, 2) the kernel > must be able to work without the usual device initialization that the > BIOS does. > > * Coreboot has two significant payload options beyond a kernel: Seabios > and GRUB (supposedly Tianocore EFI is an option, but it apparently > doesn't really work). > > * Scrounging the coreboot wiki seems to produce some conflicting > information. One page claims that the FreeBSD kernel can boot directly > as a coreboot payload; another claims GRUB or Seabios to be the only > options. > > * The PC Engines boards evidently use coreboot, and I've heard multiple > reports of them running FreeBSD systems without a problem. I don't know > whether they use GRUB or Seabios. (Aside: I'm thinking about ordering > some of these boards for my own use, so I'm generally interested in how > well they function with FreeBSD) I own several PC Engines APU boards. They definitely use Coreboot as maintained by these peeps: https://twitter.com/3mdeb_com The Coreboot for the APU boards uses Seabios. > > > My plan is roughly this: > > * Refurbish the GRUB port, get it working again in QEMU (possibly on one > of my machines), also possibly push a patch to GRUB to use the keybufs > mechanism to pass in GELI keys. > > * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU > > * Possibly create a coreboot port (uncertain how this would work, since > Coreboot has its own extensive config menu) > > * Hold my breath and test it out on real hardware (I have a Librem 13 r1 > for this purpose) > > * Possibly try getting the FreeBSD kernel to work as a coreboot payload. > > > Here's what I don't know/what would be useful knowledge for me: > > * Anyone else who's been experimenting/working on coreboot support, and > what they found > > * Any working examples of using Coreboot with FreeBSD > > * Down the road, anything about adapting the FreeBSD kernel to work with > a new boot platform (ie. low level details about how to set it up in > memory on a bare-metal system and start execution) > Reach out to 3mdeb (feel free to CC me, if you'd like). See what they'd like help with. There's certainly a lot more work that could be done. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: HEAD'S UP: fusefs sysctls going away
On Thu, Mar 21, 2019 at 09:55:15AM -0600, Alan Somers wrote: > On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb wrote: > > > > Hey Alan, > > > > Thank you very much for your work in maintaining fusefs. I only use > > fusefs in very limited circumstances, so take what I'm about to say > > with a grain of salt. > > > > On Thu, Mar 21, 2019 at 09:43:07AM -0600, Alan Somers wrote: > > > fusefs has several sysctl knobs that seem to be workarounds for bugs > > > in particular fuse daemons. However, there is no indication as to > > > which those daemons are, neither in the code nor in SVN. All of the > > > workarounds are at least 6.5 years old, so the original bugs may have > > > been fixed already. Since the original bugs aren't documented, I > > > consider these workarounds to be unmaintainable, and I'm planning to > > > delete them unless anybody objects. Please pipe up if you still use > > > them! > > > > > > vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also > > > non-zero, enable mmap(2) of FUSE files > > > > I'm curious if the security impacts of removing the toggle to disable > > mmap support for fusefs. Is there a per-fusefs replacement for > > mmap_enable? From a security perspective, it would be nice to keep the > > ability to disable mapping of files mounted on a fusefs. > > As a matter of fact, there are three other ways to disable mmap: > 1) Set vfs.fusefs.data_cache_mode=0. This completely disables caching > file data, which precludes mmap. > 2) Use the undocumented -o no_datacache mount option, which does the > same thing on a per-mount basis. > 3) Use the undocumented -o no_mmap mount option, which disables mmap > on a per-mount basis. Awesome! I wasn't aware of these. Thanks! > > Are you aware of any general security problems with using mmap? > Anything that would apply to fusefs but not other filesystems? Primarily because I trust the filesystems natively implemented in my OS more than I trust some (potentially random) fusefs module. For example, if I'm in a shared hosting environment, implemented with jails, and I let the customer mount a fusefs module in the jail (which is now possible, if I remember right), then I must trust that the module's mmap integration is properly implemented. I'm not sure I personally am okay with that level of trust. However, the point is moot now that you documented the three ways to disable mmap (two of which work on a per-mount basis). Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEAD'S UP: fusefs sysctls going away
Hey Alan, Thank you very much for your work in maintaining fusefs. I only use fusefs in very limited circumstances, so take what I'm about to say with a grain of salt. On Thu, Mar 21, 2019 at 09:43:07AM -0600, Alan Somers wrote: > fusefs has several sysctl knobs that seem to be workarounds for bugs > in particular fuse daemons. However, there is no indication as to > which those daemons are, neither in the code nor in SVN. All of the > workarounds are at least 6.5 years old, so the original bugs may have > been fixed already. Since the original bugs aren't documented, I > consider these workarounds to be unmaintainable, and I'm planning to > delete them unless anybody objects. Please pipe up if you still use > them! > > vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also > non-zero, enable mmap(2) of FUSE files I'm curious if the security impacts of removing the toggle to disable mmap support for fusefs. Is there a per-fusefs replacement for mmap_enable? From a security perspective, it would be nice to keep the ability to disable mapping of files mounted on a fusefs. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: r344798: c++: error: linker command failed with exit code
On Tue, Mar 05, 2019 at 05:45:11PM +0100, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > recent buildworld on a CURRENT box (FreeBSD 13.0-CURRENT #246 r344742: Sun > Mar 3 21:26:44 CET > 2019 amd64) fails to build due to: > > [...] > > Building /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/clang/clang > - --- clang --- > ld: error: undefined symbol: llvm::createBPFMIPreEmitCheckingPass() > >>> referenced by BPFTargetMachine.cpp > >>> BPFTargetMachine.o:((anonymous > >>> namespace)::BPFPassConfig::addPreEmitPass()) > >>> in archive > >>> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a > ld: error: undefined symbol: llvm::BTFDebug::BTFDebug(llvm::AsmPrinter*) > >>> referenced by BPFAsmPrinter.cpp > >>> BPFAsmPrinter.o:((anonymous > >>> namespace)::BPFAsmPrinter::doInitialization(llvm::Module&)) in > >>> archive > >>> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** [clang] Error code 1 > > make[4]: stopped in /usr/src/usr.bin/clang/clang > [...] > > I tried to rebuild world from a fresh /usr/src and /usr/obj but the host gets > always stuck at > the same error. Do you have a custom src.conf and make.conf? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: 12-STABLE revision 344629: pid 26 (sh), jid 0, uid 0: exited on signal 11
On Wed, Feb 27, 2019 at 08:08:24PM +0100, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Running 12-STABLE and CURRENT on a PCengine APU4C (CPU: AMD GX-412TC SOC, > Coreboot Version: > v4.9.0.2), I ran into trouble running latest 12-STABLE on that hardware. > > The box is quitting with > > > [...] > mmcsd0: 31GB at mmc0 > 50.0MHz/4bit/65535-block > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > ada0: Command Queueing enabled > ada0: 61057MB (125045424 512 byte sectors) > Trying to mount root from ufs:/dev/gpt/dsks1a [ro]... > TCP Hpts created 4 swi interrupt thread and bound 0 > uhub1: 4 ports with 4 removable, self powered > pid 26 (sh), jid 0, uid 0: exited on signal 11 > 2019-02-27T19:42:35.721885+01:00 init 1 - - /bin/sh on /etc/rc terminated > abnormally, going > to single user mode Enter root password, or ^D to go multi-user > Password: > uhub0: 2 ports with 2 removable, self powered > ugen1.2: at usbus1 > uhub2 on uhub0 > uhub2: on > usbus1 > uhub2: 4 ports with 4 removable, self powered > random: unblocking device. > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > [...] > > > ... and when typing the password, the prompter is immediately at > > 2019-02-27T19:42:35.721885+01:00 init 1 - - /bin/sh on /etc/rc terminated > abnormally, going > to single user mode Enter root password, or ^D to go multi-user > Password: > > > Running > > FreeBSD 12.0-STABLE #36 r343871: Thu Feb 7 17:34:44 CET 2019 amd64 > > Doesn't show this phenomenon with the very same configuration and kernel. Have you enabled retpoline? There are known issues with ifunc in libc and retpoline. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: IPv6 RFC3041 temporary address broken?
On Tue, Feb 12, 2019 at 11:44:42AM -0200, Renato Botelho wrote: > On 12/02/19 11:03, Shawn Webb wrote: > > Hey all, > > > > I have net.inet6.ip6.use_tempaddr and net.inet6.ip6.prefer_tempaddr > > both set to 1. Yet, I'm not seeing temporary addresses created upon > > receipt of a router advertisement. I'm only seeing the HostID-based > > SLAAC IP be generated. Has something changed recently that would > > prevent RFC3041 from working in FreeBSD HEAD? > > > > Thanks, > > > > It's working as expected here: > > lagg0: flags=8843 metric 0 mtu 1500 > ether 3c:97:0e:48:3f:f8 > inet6 fe80::3e97:eff:fe48:3ff8%lagg0 prefixlen 64 scopeid 0x4 > inet6 2804:f1c:800:e00:3e97:eff:fe48:3ff8 prefixlen 64 autoconf > inet6 2804:f1c:800:e00:30e9:88ac:84fc:ebea prefixlen 64 autoconf > temporary > inet 172.21.4.121 netmask 0xff00 broadcast 172.21.4.255 > laggproto failover lagghash l2,l3,l4 > laggport: em0 flags=1 > laggport: wlan0 flags=4 > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=23 > > ??? uname -a > FreeBSD x230 13.0-CURRENT FreeBSD 13.0-CURRENT #83 r344002: Mon Feb 11 > 11:54:18 -02 2019 > root@x230:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 False alarm. Glitch in the matrix. I had a typo in a config file. Sorry for the noise and thanks for the quick response! Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
IPv6 RFC3041 temporary address broken?
Hey all, I have net.inet6.ip6.use_tempaddr and net.inet6.ip6.prefer_tempaddr both set to 1. Yet, I'm not seeing temporary addresses created upon receipt of a router advertisement. I'm only seeing the HostID-based SLAAC IP be generated. Has something changed recently that would prevent RFC3041 from working in FreeBSD HEAD? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
On Wed, Dec 26, 2018 at 10:20:05AM +, Graham Perrin wrote: > grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v > Wed Dec 26 10:18:52 GMT 2018 > FreeBSD 13.0-CURRENT r342466 GENERIC-NODEBUG > grahamperrin@momh167-gjp4-8570p:~ % iridium > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" > grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' iridium-browser > www/iridium 2018.5.67_6 FreeBSD > grahamperrin@momh167-gjp4-8570p:~ % > > Any ideas? I can confirm that I'm getting this, too, on my Pinebook running HardenedBSD 13-CURRENT/arm64. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: The future of ZFS in FreeBSD
On Tue, Dec 18, 2018 at 10:49:48PM -0800, Matthew Macy wrote: > The sources for FreeBSD's ZFS support are currently taken directly > from Illumos with local ifdefs to support the peculiarities of FreeBSD > where the Solaris Portability Layer (SPL) shims fall short. FreeBSD > has regularly pulled changes from Illumos and tried to push back any > bug fixes and new features done in the context of FreeBSD. In the past > few years the vast majority of new development in ZFS has taken place > in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced > that they will be moving to ZoL > https://www.delphix.com/blog/kickoff-future-eko-2018 This shift means > that there will be little to no net new development of Illumos. While > working through the git history of ZoL I have also discovered that > many races and locking bugs have been fixed in ZoL and never made it > back to Illumos and thus FreeBSD. This state of affairs has led to a > general agreement among the stakeholders that I have spoken to that it > makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf > has graciously encouraged me to add FreeBSD support directly to ZoL > https://github.com/zfsonfreebsd/ZoF so that we might all have a single > shared code base. > > A port for ZoF can be found at https://github.com/miwi-fbsd/zof-port > Before it can be committed some additional functionality needs to be > added to the FreeBSD opencrypto framework. These can be found at > https://reviews.freebsd.org/D18520 > > This port will provide FreeBSD users with multi modifier protection, > project quotas, encrypted datasets, allocation classes, vectorized > raidz, vectorized checksums, and various command line improvements. > > Before ZoF can be merged back in to ZoL several steps need to be taken: > - Integrate FreeBSD support into ZoL CI > - Have most of the ZFS test suite passing > - Complete additional QA testing at iX > > We at iX Systems need to port ZoL's EC2 CI scripts to work with > FreeBSD and make sure that most of the ZFS Test Suite (ZTS) passes. > Being integrated in to their CI will mean that, among other things, > most integration issues will be caught before a PR is merged upstream > rather than many months later when it is MFVed into FreeBSD. I???m > hoping to submit the PR to ZoL some time in January. > > This port will make it easy for end users on a range of releases to > run the latest version of ZFS. Nonetheless, transitioning away from an > Illumos based ZFS is not likely to be entirely seamless. The > stakeholders I???ve spoken to all agree that this is the best path > forward but some degree of effort needs to be made to accommodate > downstream consumers. The current plan is to import ZoF and unhook the > older Illumos based sources from the build on April 15th or two months > after iX systems QA deems ZoF stable - which ever comes later. The > Illumos based sources will be removed some time later - but well > before 13. This will give users a 3 month period during which both the > port and legacy Illumos based ZFS will be available to users. Pools > should interoperate between ZoF and legacy provided the user does not > enable any features available only in ZoF. We will try to accommodate > any downstream consumers in the event that they need that date pushed > back. We ask that any downstream consumers who are particularly > sensitive to changes start testing the port when it is formally > announced and report back any issues they have. I will do my best to > ensure that this message is communicated to all those who it may > concern. However, I can???t ensure that everyone reads these lists. That > is the responsibility of -CURRENT users. Hey Matt, Thank you for your detailed and informative post. It really helps downstream consumers of FreeBSD. I'm curious what this means for OpenZFS. I was under the impression that OpenZFS was the upstream for all the ZFS implementations (sans Oracle). Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > Dell 7510 laptop was happily running FreeBSD12-alpha9 > from Oct. 10th. I decided to update to top-of-tree > today, which would be FreeBSD13 at r341703. > > % cd /usr/obj > % rm -rf usr > % cd ../src > % svn update > % make -j6 buildwould (OK) > % make -j6 buildkernel (OK) > % make installkernel(OK) > % mergemaster -p > % > % mount -a > % cd /usr/src > % make installworld > > Dies with a segfault in make(1) half way through the update. > /sbin has been update. > > Rebooted with new kernel. Laptop locks up. > Rebooted with kernel.old/kernel (known good kernel). Laptop locks up. > Rebooted with verbose info. Lockup occurs right after > > Starting /sbin/init > > is printed to console. > > Reboot to Dell laptop BIOS and run system diagnostics. > > Reboot with old FreeBSD installation cdrom. Mounted the > laptop's root filesystem on /mnt. > > % chflags nochgs /mnt/sbin/init > % cp /mnt/sbin/init.bak /mnt/sbin/init > > Reboot laptop and finally get back to multi-user mode. Post trauma > analysis > > make core dumps. > devd core dumps. > init core dumps. > cc core dumps. > c++ core dumps. > > Something seems to be broken. There have been (and still are) issues with the introduction of ifunc in libc (r339898). The symptoms you're describing sound a lot like the symptoms I experienced early on. Do you have any non-standard settings in make.conf/src.conf? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
RTLD busted in 13-CURRENT/amd64
Hey All, Looks like the RTLD is segfaulting apps for me in 13-CURRENT/amd64 both on bare metal and in bhyve. I don't have the time right now to bisect the commit. On a related note: I love ZFS boot environments. Thanks, FreeBSD, for making ZFS a first-class citizen. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: unknown -z value: common-page-size=4096
On Fri, Sep 28, 2018 at 10:01:31PM -0400, Charlie Li wrote: > I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64 > base starting with r338990, and among other issues, ld.lld70 refuses to > link the kernel: > > Building /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE/kernel.full > --- kernel.full --- > linking kernel.full > ld.lld: error: unknown -z value: common-page-size=4096 > ld.lld: error: unknown -z value: ifunc-noplt > *** [kernel.full] Error code 1 > > make[2]: stopped in /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE > > (ARDMORE is basically GENERIC-NODEBUG, not that it matters) > > The ifunc-noplt is a known issue, it obviously didn't make it upstream > in time for LLVM 7.0.0, and thus we carry the feature downstream. > > The crux of this link error though, emaste@ quipped in PR 230604 that > LLD prior to 7.0.0 accepted but ignored unknown options, but now at > least 7.0.0 disallows unknown options entirely. Which brings up the -z > common-page-size=4096: has LLD been ignoring this part the whole time, > and is it of any meaningful use anymore (it seemed to mean something > with bfd)? I noticed the same issues. I reverted parts of recent work by upstream FreeBSD in HardenedBSD's Cross-DSO CFI branch since that branch uses clang/llvm/lld 7.0.0. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: jail exec.clean busted in 12?
On Tue, Sep 11, 2018 at 03:58:02PM -0400, Michael W. Lucas wrote:
>
> Hi,
>
> storm~;uname -a
> FreeBSD storm 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #10 r338496: Thu Sep 6
> 12:29:00 EDT 2018 root@storm:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
>
> It appears that exec.clean is busted. Here's my jail.conf:
>
> ---
>
> $j="/jail";
> path="$j/$name";
> host.hostname="$name.mwl.io";
>
> mount.devfs;
> exec.clean=0;
> exec.start="sh /etc/rc";
> exec.stop="sh /etc/rc.shutdown";
>
> loghost {
> ip4.addr="203.0.113.231";
> allow.raw_sockets=1;
> jid=99;
> }
>
> logdb {
> host.hostname="logdb.mwl.io";
> ip4.addr="203.0.113.232";
> }
>
> ---
>
> exec.clean is not explicitly defined on the command line, but it's the
> default, so it maybe shouldn't be?
>
> storm~;jls -n
> devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable
> jid=8 linux=new name=logdb osreldate=1200084 osrelease=12.0-ALPHA4 parent=0
> path=/jail/logdb nopersist securelevel=-1 sysvmsg=disable sysvsem=disable
> sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount
> allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs
> allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs
> allow.mount.nozfs allow.noquotas allow.noraw_sockets allow.reserved_ports
> allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0
> children.max=0 cpuset.id=6 host.domainname="" host.hostid=0
> host.hostname=logdb.mwl.io host.hostuuid=----
> ip4.addr=203.0.113.232 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux
> linux.osrelease=2.6.32 linux.oss_version=198144
> devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable
> jid=99 linux=new name=loghost osreldate=1200084 osrelease=12.0-ALPHA4
> parent=0 path=/jail/loghost nopersist securelevel=-1 sysvmsg=disable
> sysvsem=disable sysvshm=disable vnet=inherit allow.nochflags allow.nomlock
> allow.nomount allow.mount.nodevfs allow.mount.nofdescfs
> allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs
> allow.mount.notmpfs allow.mount.nozfs allow.noquotas allow.raw_sockets
> allow.reserved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc
> children.cur=0 children.max=0 cpuset.id=7 host.domainname="" host.hostid=0
> host.hostname=loghost.mwl.io
> host.hostuuid=---- ip4.addr=203.0.113.231
> ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32
> linux.oss_version=198144
>
> Anyway, I found this by:
>
> # jexec loghost env
> HOME=/home/mwlucas
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mwlucas/bin
> TERM=xterm
> LC_COLLATE=C
> LANG=en_US.UTF-8
> SSH_CLIENT=203.0.113.70 59076 22
> SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
> SSH_TTY=/dev/pts/2
> SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
> LC_CTYPE=en_US.ISO-8859-1
> MAIL=/var/mail/root
> ...
>
> I'm highly confident my SSH environment shouldn't be in the jail. Yes,
> it goes away if I add -l, but my (admittedly sketchy) reading of the
> jexec source says that jexec handles stripping the environment before
> running the command.
>
> Even if I start it the hard way (from a discussion at
> https://github.com/iocage/iocage/issues/610)
>
> storm~;jail -c path=/jail/loghost/ host.hostname=loghost exec.clean=1 persist
> storm~;jls
>JID IP Address Hostname Path
> 9 loghost /jail/loghost
>
> storm~;jexec 9 env | grep -i ssh
> SSH_CLIENT=203.0.113.70 59076 22
> SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
> SSH_TTY=/dev/pts/2
> SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
> storm~;
>
> Any ideas?
Hey Michael,
It appears the jail.exec option is for jail(8) only. You need to pass
the -l option to jexec(8) to sanitize the environment.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: ifnet use after free
On Fri, Aug 24, 2018 at 06:19:55PM -0400, Shawn Webb wrote:
> Hey All,
>
> Somewhere in the last month or so, a use after free was introduced. I
> don't have the time right now to bisect the commits and figure out
> which commit introduced the breakage. Attached is the core.txt (which
> seems nonsensical because the dump is reporting on a different
> thread). If the core.txt gets scrubbed, I've posted it here:
> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a
>
> I'm running HardenedBSD 12-CURRENT/amd64, commit 6091fec317a.
>
> FreeBSD hbsd-dev-laptop 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #4
> 6091fec317a(hardened/current/master)-dirty: Thu Aug 23 18:37:45 EDT
> 2018
> shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64
New core.txt: https://gist.github.com/d1ee63e578c09f35d40c977093b402d6
I'm not sure if it's the same issue, but at least I'm getting a proper
backtrace. I wonder if ifp or ifp->if_xname is already freed by the time
ifunit_ref is called.
FreeBSD hbsd-dev-laptop 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #6
a581146ba17(hardened/current/master)-dirty: Mon Sep 3 12:51:49 EDT 2018
shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64
panic: vm_fault_hold: fault on nofault entry, addr: 0xfe685000
GNU gdb (GDB) 8.1.1 [GDB v8.1.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Unread portion of the kernel message buffer:
[12101] panic: vm_fault_hold: fault on nofault entry, addr: 0xfe685000
[12101] cpuid = 3
[12101] time = 1536281241
[12101] __HardenedBSD_version = 1200058 __FreeBSD_version = 1200083
[12101] version = FreeBSD 12.0-ALPHA4 #6
a581146ba17(hardened/current/master)-dirty: Mon Sep 3 12:51:49 EDT 2018
[12101] shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC
[12101] KDB: stack backtrace:
[12101] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1fef53d1c0
[12101] vpanic() at vpanic+0x1a8/frame 0xfe1fef53d220
[12101] panic() at panic+0x43/frame 0xfe1fef53d280
[12101] vm_fault_hold() at vm_fault_hold+0x1faf/frame 0xfe1fef53d3d0
[12101] vm_fault() at vm_fault+0x60/frame 0xfe1fef53d410
[12101] trap_pfault() at trap_pfault+0x188/frame 0xfe1fef53d460
[12101] trap() at trap+0x560/frame 0xfe1fef53d570
[12101] calltrap() at calltrap+0x8/frame 0xfe1fef53d570
[12101] --- trap 0xc, rip = 0x80bd5455, rsp = 0xfe1fef53d640, rbp =
0xfe1fef53d640 ---
[12101] strncmp() at strncmp+0x15/frame 0xfe1fef53d640
[12101] ifunit_ref() at ifunit_ref+0x51/frame 0xfe1fef53d680
[12101] ifioctl() at ifioctl+0x7bd/frame 0xfe1fef53d750
[12101] kern_ioctl() at kern_ioctl+0x2c0/frame 0xfe1fef53d7b0
[12101] sys_ioctl() at sys_ioctl+0x16e/frame 0xfe1fef53d880
[12101] amd64_syscall() at amd64_syscall+0x29e/frame 0xfe1fef53d9b0
[12101] fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe1fef53d9b0
[12101] --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x3c2595b7f8a, rsp =
0x7461b1772838, rbp = 0x7461b17728a0 ---
[12101] Uptime: 3h21m41s
[12101] Dumping 8310 out of 65330
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0 __curthread () at ./machine/pcpu.h:230
#1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:368
#2 0x80aec5b6 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:448
#3 0x80aeca08 in vpanic (fmt=, ap=0xfe1fef53d260)
at /usr/src/sys/kern/kern_shutdown.c:877
#4 0x80aec763 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:801
#5 0x80e285cf in vm_fault_hold (map=0xf80005001000,
vaddr=, fault_type=1 '\001', fault_flags=,
m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:585
#6 0x80e265d0 in vm_fault (map=0xf80005001000,
vaddr=, fault_type=1 '\001', fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:536
#7 0x80fc0648 in trap_pfault (frame=0xfe1fef53d580,
usermode=) at /usr/src/sys/amd64/amd6
Reviewer needed for D17067
FreeBSD recently introduced a new ELF auxiliary vector, AT_EHDRFLAGS. procstat(1) needs to be updated to reflect the new auxvec. Patch is up for review here: https://reviews.freebsd.org/D17067 Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
redzone catching a buffer overflow in swapoff_one
I'm unsure whether this is a false positive or true positive, but it looks like there may be a buffer overflow in swapoff_one: Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] REDZONE: Buffer overflow detected. 16 bytes corrupted after 0xfe1fe0023248 (2237000 bytes allocated). Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Allocation backtrace: Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0x80e188e1 at redzone_setup+0xe1 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0x80ac8007 at malloc+0x1d7 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0x80b1f449 at blist_create+0x99 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0x80e1daa7 at swaponsomething+0xe7 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0x80e1c233 at sys_swapon+0x413 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0x80fc0e5e at amd64_syscall+0x29e Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0x80f9dc9d at fast_syscall_common+0x101 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Free backtrace: Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0x80e18c28 at redzone_check+0x2f8 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0x80ac85af at free_dbg+0x5f Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0x80ac84aa at free+0x1a Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0x80e1cae5 at swapoff_one+0x675 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0x80e1cc57 at swapoff_all+0xd7 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0x80b9991a at bufshutdown+0x2ca Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0x80aec36e at kern_reboot+0x21e Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #7 0x80aec0f9 at sys_reboot+0x3a9 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #8 0x80fc0e5e at amd64_syscall+0x29e Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #9 0x80f9dc9d at fast_syscall_common+0x101 Of course, I'm running HardenedBSD 12-CURRENT/amd64. I've synced with FreeBSD at this commit: https://github.com/freebsd/freebsd/commit/2f2449cc1cdfc19ae34b2317e792af489418a01a So my src tree is at this commit: https://github.com/HardenedBSD/hardenedBSD/commit/98f90fadab000b818a731be4650ac1a47144501c I've not yet studied the swap pager's code and plan to start learning it soon. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: What's this gregset_t gregs thing
On Mon, Aug 20, 2018 at 08:33:04AM +0800, blubee blubeeme wrote: > Linux has gregset_t gregs; > https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h Please note that that repo is hopelessly old and out-of-date. I created it as a mirror of the official glibc repo because I was doing some offensive research against GNU's RTLD way back in 2011-2012. The repo hasn't been updated since. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: zpool scrub. Wtf?
On Tue, Aug 07, 2018 at 10:50:13PM +0700, Alex V. Petrov wrote: > # zpool status > pool: zroot > state: ONLINE > scan: scrub in progress since Tue Aug 7 21:21:51 2018 > 804G scanned at 163M/s, 1,06T issued at 219M/s, 834G total > 0 repaired, 129,87% done, 929637 days 13:43:01 to go > config: > > NAMESTATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > ada0p4ONLINE 0 0 0 > > errors: No known data errors > > smart is OK > > FreeBSD 12.0-CURRENT #3 r337364: Mon Aug 6 07:01:42 +07 2018 amd64 I'm seeing the same issue. -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Booting arm64 uefi broken
On Sat, Jul 28, 2018 at 01:55:07PM -0600, Warner Losh wrote: > On Sat, Jul 28, 2018 at 1:50 PM, Emmanuel Vadot > wrote: > > > On Sat, 28 Jul 2018 13:27:08 -0600 > > Warner Losh wrote: > > > > > Let me know the rev... all my fixes are in the tree... > > > > > > Warner > > > > Fixed by r336837 > > > > Yea, I thought I'd pushed all my in-flight src/stand branches yesterday, > but I had one on a different machine that wasn't, and it was this one. > Sorry for the hassle, it had been ready to go for a couple days... Thanks for commiting the fix! I really appreciate it. :) -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Booting arm64 uefi broken
On Sat, Jul 28, 2018 at 08:34:31PM +0200, Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 20:28:30 +0200 > Emmanuel Vadot wrote: > > > On Sat, 28 Jul 2018 13:17:45 -0400 > > Shawn Webb wrote: > > > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > > boot process gets stuck after the "Using DTB provided by..." message. > > > > > > This is on my SoftIron OverDrive 1000: > > > > > > >> FreeBSD EFI boot block > > > >> > > >Loader path: /boot/loader.efi > > > > > > > > > > > >Initializing modules: ZFS UFS > > > > > >Load Path: \EFI\BOOT\BOOTAA64.EFI > > > > > >Load Device: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > >BootCurrent: 0002 > > > > > >BootOrder: 0001 0005 0006 0002[*] > > > > > >Probing 7 block devices..+..* done > > > > > > ZFS found the following pools: rpool > > > > > > UFS found 1 partition > > > > > > Consoles: EFI console > > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > > > (Sat Jul 28 11:32:06 UTC 2018 r...@nyi-01.build.hardenedbsd.org) > > > > > > > > > > > >Command line arguments: loader.efi > > > > > >EFI version: 2.60 > > > > > >EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > > > >Console: efi (0) > > > > > >Load Path: > > > HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > >Load Device: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > >BootCurrent: 0002 > > > > > >BootOrder: 0001 0005 0006 0002[*] > > > > > >BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > > > > Ignoring Boot0002: Only one DP found > > > > > > Trying ESP: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > Setting currdev to disk1p2: > > > > > > Loading /boot/defaults/loader.conf > > > > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > > > syms=[0x8+0x11d108+0x8+0x10e646] > > > /boot/entropy size=0x1000 > > > > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal > > > Graphics Adapter present > > > > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > > > > Booting [/boot/kernel/kernel]... > > > > > > Using DTB provided by EFI at 0x801fe0. > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder and Security Engineer > > > HardenedBSD > > > > > > Tor-ified Signal:+1 443-546-8752 > > > Tor+XMPP+OTR:latt...@is.a.hacker.sx > > > GPG Key ID: 0x6A84658F52456EEE > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > > > > Lat
Booting arm64 uefi broken
It appears with the latest 12-CURRENT/arm64, booting is broken. The boot process gets stuck after the "Using DTB provided by..." message. This is on my SoftIron OverDrive 1000: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: \EFI\BOOT\BOOTAA64.EFI Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) BootCurrent: 0002 BootOrder: 0001 0005 0006 0002[*] Probing 7 block devices..+..* done ZFS found the following pools: rpool UFS found 1 partition Consoles: EFI console FreeBSD/arm64 EFI loader, Revision 1.1 (Sat Jul 28 11:32:06 UTC 2018 r...@nyi-01.build.hardenedbsd.org) Command line arguments: loader.efi EFI version: 2.60 EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) Console: efi (0) Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) BootCurrent: 0002 BootOrder: 0001 0005 0006 0002[*] BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) Ignoring Boot0002: Only one DP found Trying ESP: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) Setting currdev to disk1p2: Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc syms=[0x8+0x11d108+0x8+0x10e646] /boot/entropy size=0x1000 efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics Adapter present Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x801fe0. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Tool Chain Migration: objdump users, please test llvm-objdump
On Wed, Jun 20, 2018 at 07:31:21PM -0400, Ed Maste wrote: > On 20 June 2018 at 18:25, Shawn Webb wrote: > > > > Would you like me to quantify the compilation breakages due to the > > full llvm toolchain switch? If so, I can do that after July 12th. > > Thanks Shawn, right now I'm interested specifically in llvm-objdump, > with the goal of sorting it out in advance of FreeBSD 12. > > I think it's a worthwhile endeavour to quantify the breakage from > using all of the LLVM tools though, and if you're able to triage the > issues and submit LLVM, FreeBSD, or upstream port issues as > appropriate that would be much appreciated. (It's just not yet on the > critical path for me.) Sounds good. Can you ping me again after July 12th? Also, if Tor is available for you, the amd64 Poudriere web UI is accessible via a Tor v3 Onion Service: http://3jkjhrvkdbdkqisnwhdpe4afh2j2g3suhsfcewiemsyk5ecd6gadmxyd.onion:8081/index.html Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Tool Chain Migration: objdump users, please test llvm-objdump
On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > Work is in progress to migrate fully to modern and permissively > licensed components for the tool chain. This includes moving away from > the three obsolete binutils components that are still in the base > system (as, ld, objdump). objdump is a tool to report information > about binary objects (such as headers, symbols, etc.), is not required > as a build tool, and in any case many uses of objdump are better > served by readelf. > > For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is > open to track tasks related to its removal, and users who need GNU > objdump can install an up-to-date version from the ports tree or the > binutils package. > > That said, llvm includes a somewhat equivalent llvm-objdump, and it is > built by default in FreeBSD now. If llvm-objdump's command line option > support and output format is "close enough" to GNU objdump for most > users we may decide to install it as /usr/bin/objdump. Therefore, I > would like to ask users of GNU objdump in FreeBSD to give llvm-objdump > a try. Please let me know if it works for your uses, or describe > deficiencies that you found. In preparation for Cross-DSO CFI support, HardenedBSD switched to llvm-ar, llvm-nm, and llvm-objdump on 12-CURRENT/arm64 with commit a3db6f9006499b55c2042faccd0ed6a6777b9d9f (22 Dec 2017). There are some issues with the ports tree, but I haven't quantified them, yet. All high-visibility applications (firefox, apache, nginx, openvpn, etc.) all work with a full llvm toolchain (again: llvm-ar, llvm-nm, and llvm-objdump). Some applications break during runtime and not build time. Certain pidgin plugins break, for example, at runtime due to a full llvm toolchain, but compile just fine. Would you like me to quantify the compilation breakages due to the full llvm toolchain switch? If so, I can do that after July 12th. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Weird conditional logic in lib/libpmc/Makefile
Hey all,
Below is some logic pasted from lib/libpmc/Makefile:
.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
.if ${MACHINE_ARCH} == "aarch64"
EVENT_ARCH="arm64"
.elif ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
EVENT_ARCH="x86"
.elif ${MACHINE_ARCH} == "powerpc"
EVENT_ARCH="powerpc"
.endif
JEVENTS= ${BTOOLSPATH:U.}/pmu-events/jevents
# This file is built in a subdirectory so never try to rebuild
# it here due to missing meta file.
${JEVENTS}: .NOMETA
libpmc_events.c: ${JEVENTS}
${JEVENTS} ${EVENT_ARCH} ${.CURDIR}/pmu-events/arch libpmc_events.c
SRCS+= libpmc_events.c
.endif
Why perform the conditionals for aarch64 and powerpc when it can't be
those? "Am I missing something?
I'm looping in Matt Macy, who was the last person to touch the file.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: snapshot of april 12th wont boot at all
On Tue, Apr 17, 2018 at 10:52:40PM +, Beeblebrox wrote: > My proposed plan did not work anyway, as both MINIMAL and GENERIC fail to > build. > I'll have to clone the FreeBSD repo unless Shawn has something to comment on > this. Due to our changing of certain kernel structures, GENERIC likely won't build anymore. FreeBSD's kernel source code contains compile-time assertions that detect when offsets of values within certain key structures are different than expected (example commit f9f820f2e418f9b68f9d94631171135bfb79989f in hardened/current/master). I'm unsure why PTI causes issues in these cases. I would love to attempt to make an effort to debug it myself, but I would need some way to replicate the issue on my end. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: snapshot of april 12th wont boot at all
On Tue, Apr 17, 2018 at 11:13:51AM -0400, Beeblebrox wrote: > Hey Shawn, > > > What happens when you set vm.pmap.pti=0 at the loader prompt? > Yep, that fixed it. Booted into MYKERN without problem. > Assuming Page Table Isolation still a bit buggy? > > FreeBSD 12.0-CURRENT #3 5b8586c22aa(hardened/current/master): > Tue Apr 17 08:11:53 EDT 2018 HardenedBSD enables PTI regardless of underlying CPU by default. We've found that some older AMD CPUs have issues with PTI as currently implemented. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: snapshot of april 12th wont boot at all
On Tue, Apr 17, 2018 at 10:47:00AM -0400, Beeblebrox wrote: > I have (possibly) similar problem, running kernel from March 29 as > fall-back (older kernel, latest world). > > * OS: HardenedBSD-12 on amd64 Athlon II X3 460 > * Kernels built yesterday: MYKERN & HARDENEDBSD (GENERIC with Debug). > Both kernels fail. No errors encountered during buildworld/kernel. > World installs normally. > * Boot process: Grub -> /boot/loader -> Kernel Selection. No EFI (MBR). > Grub has own partition (ext2fs), /boot/loader on ZFS. > * zpool: Striped on 2 HDD's, scrub returns clean pool. > > FAILURE POINT: System freeze, completely unresponsive, requires hard > reset. > * Initially seems like failure is at "Mount Root from zpool/ROOT/bsd". > Further inspection of dmesg shows garbled text at services stage > (start reading /etc/rc.conf) > * /etc/rc.conf: Everything disabled for bug hunting. Cause does not > seem related to linux / radeonkms either. > * Selecting "Safe Mode" (kern.smp.disabled ?) gets me to single-user > mode, and later multi-user but system freezes as soon as I login. > Not 100% sure about this behaviour though, as I have been at it since > early morning yesterday. > * Have not tried with ACPI disabled. Dmesg: Firmware Warning (ACPI): > 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20180313/tbfadt-748) > > There was a recent bug involving databases failing to start due to > "limits: NO: No such file or directory". I have Mariadb-Server-100 > installed with the new patch for this bug. I wonder whether these two > could be related? > > Would prefer not posting my verbose boot log dmesg file here, can email > it (or download link) to developers (at FreeBSD.org) if needed though. What happens when you set vm.pmap.pti=0 at the loader prompt? -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: more fallout from removal of lint
On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote: > Since lint was removed from 12.0-CURRENT, it is not possible to build > 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that > by copying /usr/bin/true to /usr/bin/lint. Unfortunately, that trick > doesn't work when updating a 11.1-STABLE poudriere jail on a > 12.0-CURRENT host. > > ===> usr.bin/xlint (install) > ===> usr.bin/xlint/lint1 (install) > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g > wheel -m 555 lint1 /var/poudriere/jails/111STABLEi386/usr/libexec/lint1 > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > -m 444 lint1.debug > /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint1.debug > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > -m 444 lint.7.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man7/ > ===> usr.bin/xlint/lint2 (install) > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g > wheel -m 555 lint2 /var/poudriere/jails/111STABLEi386/usr/libexec/lint2 > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > -m 444 lint2.debug > /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint2.debug > ===> usr.bin/xlint/xlint (install) > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g > wheel -m 555 xlint /var/poudriere/jails/111STABLEi386/usr/bin/lint > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > -m 444 lint.debug > /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/bin/lint.debug > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > -m 444 lint.1.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man1/ > ===> usr.bin/xlint/llib (install) > lint -cghapbx > -I/usr/obj/i386.i386/var/poudriere/jails/111STABLEi386/usr/src/tmp/usr/include > -Cposix > /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib/llib-lposix > sh: lint: not found > *** [llib-lposix.ln] Error code 127 > > make[6]: stopped in > /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib > 1 error > > > # ls -l /usr/bin/lint /usr/bin/true > -r-xr-xr-x 1 root wheel 4976 Dec 30 12:37 /usr/bin/lint > -r-xr-xr-x 1 root wheel 4976 Dec 29 21:13 /usr/bin/true I had filed[1] a bug report about this a little over a month ago and FreeBSD was disinterested in even discussing it. HardenedBSD worked around the issue by disabling the build of lint in its 11-STABLE and 10-STABLE trees. [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223892 Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: evdev broken
On Fri, Dec 29, 2017 at 02:36:34PM -0500, Shawn Webb wrote: > On Fri, Dec 29, 2017 at 08:33:15PM +0100, Michael Gmelin wrote: > > > > > > > On 29. Dec 2017, at 20:15, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > > > > > Hey All, > > > > > > It looks like evdev support in the kernel is broken. > > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > > > different evdev-related symbols. > > > > > > I have the following options in my kernel config: > > > > > > options EVDEV_SUPPORT > > > options EVDEV_DEBUG > > > options UINPUT_DEBUG > > > > Did you add "device evdev"? > > Good catch! I did not. Adding now and I'll report back when > buildkernel finishes. That did the trick. Thanks! Seems like evdev doesn't have a manpage, which is why I didn't know to include it in my kernel config. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: evdev broken
On Fri, Dec 29, 2017 at 08:33:15PM +0100, Michael Gmelin wrote: > > > > On 29. Dec 2017, at 20:15, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > > > Hey All, > > > > It looks like evdev support in the kernel is broken. > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > > different evdev-related symbols. > > > > I have the following options in my kernel config: > > > > options EVDEV_SUPPORT > > options EVDEV_DEBUG > > options UINPUT_DEBUG > > Did you add "device evdev"? Good catch! I did not. Adding now and I'll report back when buildkernel finishes. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
evdev broken
t;> referenced by kbdmux.c:503 (/usr/src/sys/dev/kbdmux/kbdmux.c:503)
>>> kbdmux.o:(kbdmux_init)
ld: error: undefined symbol: evdev_support_led
>>> referenced by kbdmux.c:504 (/usr/src/sys/dev/kbdmux/kbdmux.c:504)
>>> kbdmux.o:(kbdmux_init)
>>>
>>>
ld: error: undefined symbol: evdev_support_led
>>> referenced by kbdmux.c:505 (/usr/src/sys/dev/kbdmux/kbdmux.c:505)
>>> kbdmux.o:(kbdmux_init)
ld: error: undefined symbol: evdev_register
>>> referenced by kbdmux.c:507 (/usr/src/sys/dev/kbdmux/kbdmux.c:507)
>>> kbdmux.o:(kbdmux_init)
ld: error: undefined symbol: evdev_free
>>> referenced by kbdmux.c:508 (/usr/src/sys/dev/kbdmux/kbdmux.c:508)
>>>
>>>
>>> kbdmux.o:(kbdmux_init)
ld: error: undefined symbol: evdev_free
>>> referenced by kbdmux.c:583 (/usr/src/sys/dev/kbdmux/kbdmux.c:583)
>>> kbdmux.o:(kbdmux_term)
ld: error: undefined symbol: evdev_rcpt_mask
>>> referenced by kbdmux.c:750 (/usr/src/sys/dev/kbdmux/kbdmux.c:750)
>>>
>>>
>>> kbdmux.o:(kbdmux_read_char)
>>>
>>>
ld: error: undefined symbol: evdev_scancode2key
>>> referenced by kbdmux.c:751 (/usr/src/sys/dev/kbdmux/kbdmux.c:751)
>>>
>>>
>>> kbdmux.o:(kbdmux_read_char)
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: Replacing OpenSSL in base -- does it work?
On Tue, Dec 12, 2017 at 05:57:29PM -0800, Chris H wrote: > Hi all, > I just fired off a fresh build on a new 12-CURRENT install. But forgot > to add WITHOUT_OPENSSL to src.conf(5), as I had intended to. :-( > Anyway, I'd like to remove OpenSSL from base. Any recommendations on the > best approach, and best alternatives? Both HardenedBSD and TrueOS use LibreSSL in base. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: GPTZFSBOOT in Current r326622 has problems
On Wed, Dec 06, 2017 at 10:35:37AM -0500, Thomas Laus wrote: > Group: > > I updated my amd64 computer today to r326622 and copied the > /boot/gptzfsboot file to each of my ZFS hard drives p1 partition. The > BTX loader stopped and could not load. This rendered my system > 'un-bootable'. I copied this file from an earlier live filesystem CD, > which restored my computer and enabled me to boot. > > I also see the problem with the loader logs dumping core that others > have reported recently. I'm seeing the same issue with recent HardenedBSD 12-CURRENT/amd64 memstick images. Booting in UEFI mode works, however. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Booting UEFI ZFS is broken on arm64
On Fri, Dec 01, 2017 at 02:53:53PM -0700, Warner Losh wrote: > On Fri, Dec 1, 2017 at 2:49 PM, Shawn Webb <shawn.w...@hardenedbsd.org> > wrote: > > > On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh <i...@bsdimp.com> wrote: > > > > > > > > > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb < > > shawn.w...@hardenedbsd.org> > > > > wrote: > > > > > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb < > > shawn.w...@hardenedbsd.org > > > >> > > > > >> > wrote: > > > >> > > > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > > > >> shawn.w...@hardenedbsd.org> > > > >> > > > wrote: > > > >> > > > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 > > snapshot, > > > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots > > up > > > >> to > > > >> > > > > this line: > > > >> > > > > > > > >> > > > > Using DTB provided by EFI at 0x801fe0. > > > >> > > > > > > >> > > > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > > > >> > > > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > > >> > > > > > >> > > It also happens on latest HEAD, so it would appear to still be > > broken. > > > >> > > > > >> > > > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing > > the > > > >> > latter, but wanted to make sure. If so, then we're past the point > > where > > > >> > boot1.efi would have failed (besides, it was fixed before that > > > >> snapshot). > > > >> > > > >> With DEBUG turned on for stand/fdt: > > > >> > > > >> Booting [/boot/kernel/kernel]... > > > >> fdt_copy(): fdt_copy va 0x01208000 > > > >> fdt_setup_fdtp(): fdt_setup_fdtp() > > > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe0) > > > >> Using DTB provided by EFI at 0x801fe0. > > > >> Loaded the platform dtb: 0x81f56f1630. > > > >> fdt_fixup(): fdt_fixup() > > > >> > > > >> ^ hangs after that message > > > > > > > > > > > > That doesn't sound like anything I've changed, but it could well be... > > I > > > > think to find this breakage, you may need to bisect backwards along > > stand / > > > > sys/boot until we find the spot where it broke. > > > > > > > > > > There's been several conversations on IRC about how others are hitting a > > > scheduler bug, at least on x86. hps' fix seems to do the trick for their > > > issues. > > > > > > Author: hselasky <hselasky@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f> > > > Date: Wed Nov 29 23:28:40 2017 + > > > > > > The sched_add() function is not only used when the thread is > > initially > > > started, but also by the turnstiles to mark a thread as runnable for > > > all locks, for instance sleepqueues do: > > > setrunnable()->sched_wakeup()->sched_add() > > > > > > In r326218 code was added to allow booting from non-zero CPU numbers > > > by setting the ts_cpu field inside the ULE scheduler's sched_add() > > > function. This had an undesired side-effect that prior sched_pin() > > and > > > sched_bind() calls got disregarded. This patch fixes the > > > initialization of the ts_cpu field for the ULE scheduler to only > > > happen once when the initial thread is constructed during system > > > init. Forking will then later on ensure that a valid ts_cpu value > > gets > > > copied to all children. > > > > > > Reviewed by:jhb, kib > > > Discussed with: nwhitehorn > > > MFC after: 1 month > > > Differential revision: https://revi
Re: Booting UEFI ZFS is broken on arm64
On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh <i...@bsdimp.com> wrote: > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb <shawn.w...@hardenedbsd.org> > > wrote: > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb <shawn.w...@hardenedbsd.org > >> > > >> > wrote: > >> > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > >> shawn.w...@hardenedbsd.org> > >> > > > wrote: > >> > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up > >> to > >> > > > > this line: > >> > > > > > >> > > > > Using DTB provided by EFI at 0x801fe0. > >> > > > > >> > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > >> > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > >> > > > >> > > It also happens on latest HEAD, so it would appear to still be broken. > >> > > >> > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing the > >> > latter, but wanted to make sure. If so, then we're past the point where > >> > boot1.efi would have failed (besides, it was fixed before that > >> snapshot). > >> > >> With DEBUG turned on for stand/fdt: > >> > >> Booting [/boot/kernel/kernel]... > >> fdt_copy(): fdt_copy va 0x01208000 > >> fdt_setup_fdtp(): fdt_setup_fdtp() > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe0) > >> Using DTB provided by EFI at 0x801fe0. > >> Loaded the platform dtb: 0x81f56f1630. > >> fdt_fixup(): fdt_fixup() > >> > >> ^ hangs after that message > > > > > > That doesn't sound like anything I've changed, but it could well be... I > > think to find this breakage, you may need to bisect backwards along stand / > > sys/boot until we find the spot where it broke. > > > > There's been several conversations on IRC about how others are hitting a > scheduler bug, at least on x86. hps' fix seems to do the trick for their > issues. > > Author: hselasky <hselasky@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f> > Date: Wed Nov 29 23:28:40 2017 + > > The sched_add() function is not only used when the thread is initially > started, but also by the turnstiles to mark a thread as runnable for > all locks, for instance sleepqueues do: > setrunnable()->sched_wakeup()->sched_add() > > In r326218 code was added to allow booting from non-zero CPU numbers > by setting the ts_cpu field inside the ULE scheduler's sched_add() > function. This had an undesired side-effect that prior sched_pin() and > sched_bind() calls got disregarded. This patch fixes the > initialization of the ts_cpu field for the ULE scheduler to only > happen once when the initial thread is constructed during system > init. Forking will then later on ensure that a valid ts_cpu value gets > copied to all children. > > Reviewed by:jhb, kib > Discussed with: nwhitehorn > MFC after: 1 month > Differential revision: https://reviews.freebsd.org/D13298 > Sponsored by: Mellanox Technologies > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > is the fix But the bug it fixes post-dates the snapshot, so maybe this > isn't the same thing... Definitely is not the same thing. I've so far got it printf'd to where the uefi loader jumps into the kernel's entry point. So the loader itself might be fine. Something in the kernel, then, is going funky. Booting in verbose mode does not provide any additional input. Here's the output I get (some of the output is from printf's I've done): FreeBSD/arm64 EFI loader, Revision 1.1 (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x7e0a78 data=0xaad80+0x443f62 syms=[0x8+0x10ec78+0x8+0x1021d4] /boot/entropy size=0x1000 /boot/kernel/zfs.ko text=0x99070 text=0x130390 data=0x21ff8+0x9ef98 syms=[0x8+0x22c68+0x8+0x1b99b] /boot/kernel/opensolaris.ko text=0x1330 text=0xd00 data=0x10160+0x125d0 syms=[0x8+0xff0+0x8+0x8d8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x801fe0. fdt_copy returned. dtb_size is 9060. bi_load finished. err: 0 dev_cleanup finished About to call into the entry point at 0x81ee601000 Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Booting UEFI ZFS is broken on arm64
On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb <shawn.w...@hardenedbsd.org> > wrote: > > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb <shawn.w...@hardenedbsd.org> > > > wrote: > > > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > > > this line: > > > > > > > > Using DTB provided by EFI at 0x801fe0. > > > > > > > > > Which snapshot is that? Boot1 was broken until recently. > > > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > > > It also happens on latest HEAD, so it would appear to still be broken. > > > Is this boot1.efi producing the output, or loader.efi? I'm guessing the > latter, but wanted to make sure. If so, then we're past the point where > boot1.efi would have failed (besides, it was fixed before that snapshot). With DEBUG turned on for stand/fdt: Booting [/boot/kernel/kernel]... fdt_copy(): fdt_copy va 0x01208000 fdt_setup_fdtp(): fdt_setup_fdtp() fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe0) Using DTB provided by EFI at 0x801fe0. Loaded the platform dtb: 0x81f56f1630. fdt_fixup(): fdt_fixup() ^ hangs after that message -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Booting UEFI ZFS is broken on arm64
On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb <shawn.w...@hardenedbsd.org> > wrote: > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > this line: > > > > Using DTB provided by EFI at 0x801fe0. > > > Which snapshot is that? Boot1 was broken until recently. FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img It also happens on latest HEAD, so it would appear to still be broken. -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Booting UEFI ZFS is broken on arm64
It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to this line: Using DTB provided by EFI at 0x801fe0. Then all output stops. I'm in the process of building a custom install ISO that has DEBUG turned on in the fdt code. I hope to report back soon-ish, unless anyone else has any ideas as to what could be wrong. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sun, Jul 23, 2017 at 09:16:26PM -0400, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: > > On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > > > Shawn Webb shawn.webb at hardenedbsd.org wrote on > > > Sat Jul 22 15:33:14 UTC 2017 : > > > > > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > > > default linker, but it looks like we in HardenedBSD are getting an > > > > undefined symbol during buildworld. > > > > > > In an amd64 -> TARGET_ARCH=powerpc64 cross build context > > > for FreeBSD -r321371 I got a similar report for the: > > > > > > /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: > > > lldb_private::AppleObjCRuntime::GetFoundationVersion() > > > >>> referenced by > > > >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp > > > >>> > > > >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > > >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in > > > >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a > > > > > > part of your report (logfile). The context used > > > devel/powerpc64-binutils : > > > > > > # /usr/local/powerpc64-freebsd/bin/ld --version > > > GNU ld (GNU Binutils) 2.28 > > > Copyright (C) 2017 Free Software Foundation, Inc. > > > This program is free software; you may redistribute it under the terms of > > > the GNU General Public License version 3 or (at your option) a later > > > version. > > > This program has absolutely no warranty. > > > > > > (lld is not yet working option for powerpc64 as > > > far as I know.) > > > > > > For this part of your report I doubt that anything > > > that you listed is required for the problem to happen. > > > > > > In my context the error text was: > > > > > > --- lldb.full --- > > > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): > > > In function > > > `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > > lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': > > > /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): > > > undefined reference to > > > `lldb_private::AppleObjCRuntime::GetFoundationVersion()' > > > > Hey Mark, > > > > I wasn't doing a cross-build, but rather a native build for amd64. I'm > > getting errors again. In fact, I'm getting the same error you just > > posted above. I have no clue why the error's happening. That you're > > also getting the error shows that the issue isn't specific to > > HardenedBSD at the very least. > > I've figured out how to fully reproduce. The following assumes world > still is at clang/llvm 4.0. The following also assumes the source tree > is at /usr/src and is latest FreeBSD HEAD. And MAKEOBJDIRPREFIX is unset > or left as default. Native build on amd64. > > 1. Set ld.lld as the linker: >a. rm /usr/bin/ld >b. ln -s ld.lld /usr/bin/ld >c. Verify: `ld -version` should show: > LLD 4.0.0 (FreeBSD 297347) (compatible with GNU linkers) > 2. Ensure the object tree is clean: >a. rm -rf /usr/obj/usr/src > 3. Build world: >a. make -sj$(sysctl -n hw.ncpu) buildworld > 4. Relax, grab a drink, eat some Skittles > 5. Come back to buildworld failing to link lldb.full in >usr.bin/clang/lldb Found the regression: It looks like lldb 5.0.0 doesn't support being compiled with SafeStack. I'll report this upstream to llvm. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > > Shawn Webb shawn.webb at hardenedbsd.org wrote on > > Sat Jul 22 15:33:14 UTC 2017 : > > > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > > default linker, but it looks like we in HardenedBSD are getting an > > > undefined symbol during buildworld. > > > > In an amd64 -> TARGET_ARCH=powerpc64 cross build context > > for FreeBSD -r321371 I got a similar report for the: > > > > /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: > > lldb_private::AppleObjCRuntime::GetFoundationVersion() > > >>> referenced by > > >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp > > >>> > > >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in > > >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a > > > > part of your report (logfile). The context used > > devel/powerpc64-binutils : > > > > # /usr/local/powerpc64-freebsd/bin/ld --version > > GNU ld (GNU Binutils) 2.28 > > Copyright (C) 2017 Free Software Foundation, Inc. > > This program is free software; you may redistribute it under the terms of > > the GNU General Public License version 3 or (at your option) a later > > version. > > This program has absolutely no warranty. > > > > (lld is not yet working option for powerpc64 as > > far as I know.) > > > > For this part of your report I doubt that anything > > that you listed is required for the problem to happen. > > > > In my context the error text was: > > > > --- lldb.full --- > > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): > > In function > > `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': > > /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): > > undefined reference to > > `lldb_private::AppleObjCRuntime::GetFoundationVersion()' > > Hey Mark, > > I wasn't doing a cross-build, but rather a native build for amd64. I'm > getting errors again. In fact, I'm getting the same error you just > posted above. I have no clue why the error's happening. That you're > also getting the error shows that the issue isn't specific to > HardenedBSD at the very least. I've figured out how to fully reproduce. The following assumes world still is at clang/llvm 4.0. The following also assumes the source tree is at /usr/src and is latest FreeBSD HEAD. And MAKEOBJDIRPREFIX is unset or left as default. Native build on amd64. 1. Set ld.lld as the linker: a. rm /usr/bin/ld b. ln -s ld.lld /usr/bin/ld c. Verify: `ld -version` should show: LLD 4.0.0 (FreeBSD 297347) (compatible with GNU linkers) 2. Ensure the object tree is clean: a. rm -rf /usr/obj/usr/src 3. Build world: a. make -sj$(sysctl -n hw.ncpu) buildworld 4. Relax, grab a drink, eat some Skittles 5. Come back to buildworld failing to link lldb.full in usr.bin/clang/lldb Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > Shawn Webb shawn.webb at hardenedbsd.org wrote on > Sat Jul 22 15:33:14 UTC 2017 : > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > default linker, but it looks like we in HardenedBSD are getting an > > undefined symbol during buildworld. > > In an amd64 -> TARGET_ARCH=powerpc64 cross build context > for FreeBSD -r321371 I got a similar report for the: > > /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: > lldb_private::AppleObjCRuntime::GetFoundationVersion() > >>> referenced by > >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp > >>> > >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in > >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a > > part of your report (logfile). The context used > devel/powerpc64-binutils : > > # /usr/local/powerpc64-freebsd/bin/ld --version > GNU ld (GNU Binutils) 2.28 > Copyright (C) 2017 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later version. > This program has absolutely no warranty. > > (lld is not yet working option for powerpc64 as > far as I know.) > > For this part of your report I doubt that anything > that you listed is required for the problem to happen. > > In my context the error text was: > > --- lldb.full --- > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): > In function > `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': > /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): > undefined reference to > `lldb_private::AppleObjCRuntime::GetFoundationVersion()' Hey Mark, I wasn't doing a cross-build, but rather a native build for amd64. I'm getting errors again. In fact, I'm getting the same error you just posted above. I have no clue why the error's happening. That you're also getting the error shows that the issue isn't specific to HardenedBSD at the very least. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sat, Jul 22, 2017 at 01:32:17PM -0400, Shawn Webb wrote: > On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: > > On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > > > Hi, > > > > > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > > > (trunk r308421) into head. Universe builds went just fine, but if you > > > encounter any snags during world and/or kernel builds, please file PRs. > > > > > > Since upstream has just created their 5.0.0 release branch, this is a > > > good month to shake out any remaining issues for FreeBSD. If you are > > > certain bugs or regressions you encounter are due to upstream, file PRs > > > there, but otherwise, just report them on the FreeBSD bug tracker. > > > > Hey Dimitry, > > > > Thank you very much for your hard work and dedication to bringing the > > llvm toolchain to FreeBSD. > > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > default linker, but it looks like we in HardenedBSD are getting an > > undefined symbol during buildworld. > > > > Here's the logfile: > > > > http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-amd64/910/consoleText > > > > I'm working right now on figuring out what caused it. I'll report back > > when I know more. > > Found the culprit: WITH_LLD_BOOTSTRAP. It looks like when > MK_LLD_BOOTSTRAP is set to yes, then you get the error in the Jenkins > log above. At least, on amd64. I do _not_ get the error on arm64. I forgot to mention that WITH_LLD_IS_LD is set, too. I haven't tested WITH_LLD_BOOTSTRAP && WITHOUT_LLD_IS_LD. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: > On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > > Hi, > > > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > > (trunk r308421) into head. Universe builds went just fine, but if you > > encounter any snags during world and/or kernel builds, please file PRs. > > > > Since upstream has just created their 5.0.0 release branch, this is a > > good month to shake out any remaining issues for FreeBSD. If you are > > certain bugs or regressions you encounter are due to upstream, file PRs > > there, but otherwise, just report them on the FreeBSD bug tracker. > > Hey Dimitry, > > Thank you very much for your hard work and dedication to bringing the > llvm toolchain to FreeBSD. > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > default linker, but it looks like we in HardenedBSD are getting an > undefined symbol during buildworld. > > Here's the logfile: > > http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-amd64/910/consoleText > > I'm working right now on figuring out what caused it. I'll report back > when I know more. Found the culprit: WITH_LLD_BOOTSTRAP. It looks like when MK_LLD_BOOTSTRAP is set to yes, then you get the error in the Jenkins log above. At least, on amd64. I do _not_ get the error on arm64. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > Hi, > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > (trunk r308421) into head. Universe builds went just fine, but if you > encounter any snags during world and/or kernel builds, please file PRs. > > Since upstream has just created their 5.0.0 release branch, this is a > good month to shake out any remaining issues for FreeBSD. If you are > certain bugs or regressions you encounter are due to upstream, file PRs > there, but otherwise, just report them on the FreeBSD bug tracker. Hey Dimitry, Thank you very much for your hard work and dedication to bringing the llvm toolchain to FreeBSD. I haven't nailed down whether it's SafeStack, CFI, or using lld as the default linker, but it looks like we in HardenedBSD are getting an undefined symbol during buildworld. Here's the logfile: http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-amd64/910/consoleText I'm working right now on figuring out what caused it. I'll report back when I know more. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Possible to set security.bsd.stack_guard_page to a negative value
Even though it'd be a stupid thing to do, the security.bsd.stack_guard_page sysctl node can be set to a negative integer value. This will cause all applications to crash with SIGABRT. -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Reproducible panic with MAP_GUARD and security.bsd.stack_guard_page > 1
When running my Stack Clash PoC on a vanilla FreeBSD 12-CURRENT/amd64 VM and security.bsd.stack_guard_page is > 1: https://goo.gl/photos/vZQY4B9jKJRLrNwP7 The PoC doesn't need to be run as root on vanilla FreeBSD with a default configuration. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: ZFS ABD Panic
On Tue, Jun 27, 2017 at 10:25:16AM -0400, Shawn Webb wrote: > On Tue, Jun 27, 2017 at 05:22:39PM +0300, Andriy Gapon wrote: > > On 27/06/2017 17:16, Shawn Webb wrote: > > > On Tue, Jun 27, 2017 at 05:12:01PM +0300, Andriy Gapon wrote: > > >> On 26/06/2017 03:31, Shawn Webb wrote: > > >>> This is on the latest HardenedBSD 12-CURRENT on one of my servers: > > >>> > > >>> [141] panic: sleepq_add: td 0xf80008d20560 to sleep on wchan > > >>> 0xf803b7d4e810 with sleeping prohibited > > >>> [141] cpuid = 5 > > >>> [141] time = 1498436043 > > >>> [141] KDB: stack backtrace: > > >>> [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > >>> 0xfe2fc8b0 > > >>> [141] vpanic() at vpanic+0x19c/frame 0xfe2fc930 > > >>> [141] kassert_panic() at kassert_panic+0x126/frame 0xfe2fc9a0 > > >>> [141] sleepq_add() at sleepq_add+0x34f/frame 0xfe2fc9f0 > > >>> [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfe2fcaa0 > > >>> [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfe2fcae0 > > >>> [141] refcount_remove_many() at refcount_remove_many+0x2a/frame > > >>> 0xfe2fcb20 > > >>> [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfe2fcb50 > > >>> [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame > > >>> 0xfe2fcb70 > > >>> [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame > > >>> 0xfe2fcba0 > > >>> [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfe2fcbb0 > > >>> [141] fork_exit() at fork_exit+0x84/frame 0xfe2fcbf0 > > >>> [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfe2fcbf0 > > >> > > >> Seems like another architectural incompatibility between illumos and > > >> FreeBSD. > > >> Are you able to reproduce the crash more or less reliably? > > > > > > Yup. I just need to do a buildworld and it's triggered. > > > > > > > Could you please test this patch? > > http://dpaste.com/12M183A.txt > > I put it together rather quickly, but I think that it should work :) > > Can do later today. I'll report back either tonight or tomorrow. That seems to have fixed it! No kernel panic as of yet. It has survived two world + kernel builds. Thanks a lot for the help! -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: ZFS ABD Panic
On Tue, Jun 27, 2017 at 05:22:39PM +0300, Andriy Gapon wrote: > On 27/06/2017 17:16, Shawn Webb wrote: > > On Tue, Jun 27, 2017 at 05:12:01PM +0300, Andriy Gapon wrote: > >> On 26/06/2017 03:31, Shawn Webb wrote: > >>> This is on the latest HardenedBSD 12-CURRENT on one of my servers: > >>> > >>> [141] panic: sleepq_add: td 0xf80008d20560 to sleep on wchan > >>> 0xf803b7d4e810 with sleeping prohibited > >>> [141] cpuid = 5 > >>> [141] time = 1498436043 > >>> [141] KDB: stack backtrace: > >>> [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >>> 0xfe2fc8b0 > >>> [141] vpanic() at vpanic+0x19c/frame 0xfe2fc930 > >>> [141] kassert_panic() at kassert_panic+0x126/frame 0xfe2fc9a0 > >>> [141] sleepq_add() at sleepq_add+0x34f/frame 0xfe2fc9f0 > >>> [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfe2fcaa0 > >>> [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfe2fcae0 > >>> [141] refcount_remove_many() at refcount_remove_many+0x2a/frame > >>> 0xfe2fcb20 > >>> [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfe2fcb50 > >>> [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame > >>> 0xfe2fcb70 > >>> [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfe2fcba0 > >>> [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfe2fcbb0 > >>> [141] fork_exit() at fork_exit+0x84/frame 0xfe2fcbf0 > >>> [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfe2fcbf0 > >> > >> Seems like another architectural incompatibility between illumos and > >> FreeBSD. > >> Are you able to reproduce the crash more or less reliably? > > > > Yup. I just need to do a buildworld and it's triggered. > > > > Could you please test this patch? > http://dpaste.com/12M183A.txt > I put it together rather quickly, but I think that it should work :) Can do later today. I'll report back either tonight or tomorrow. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: ZFS ABD Panic
On Tue, Jun 27, 2017 at 05:12:01PM +0300, Andriy Gapon wrote: > On 26/06/2017 03:31, Shawn Webb wrote: > > This is on the latest HardenedBSD 12-CURRENT on one of my servers: > > > > [141] panic: sleepq_add: td 0xf80008d20560 to sleep on wchan > > 0xf803b7d4e810 with sleeping prohibited > > [141] cpuid = 5 > > [141] time = 1498436043 > > [141] KDB: stack backtrace: > > [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe2fc8b0 > > [141] vpanic() at vpanic+0x19c/frame 0xfe2fc930 > > [141] kassert_panic() at kassert_panic+0x126/frame 0xfe2fc9a0 > > [141] sleepq_add() at sleepq_add+0x34f/frame 0xfe2fc9f0 > > [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfe2fcaa0 > > [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfe2fcae0 > > [141] refcount_remove_many() at refcount_remove_many+0x2a/frame > > 0xfe2fcb20 > > [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfe2fcb50 > > [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame > > 0xfe2fcb70 > > [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfe2fcba0 > > [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfe2fcbb0 > > [141] fork_exit() at fork_exit+0x84/frame 0xfe2fcbf0 > > [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfe2fcbf0 > > Seems like another architectural incompatibility between illumos and FreeBSD. > Are you able to reproduce the crash more or less reliably? Yup. I just need to do a buildworld and it's triggered. -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
ZFS ABD Panic
This is on the latest HardenedBSD 12-CURRENT on one of my servers: [141] panic: sleepq_add: td 0xf80008d20560 to sleep on wchan 0xf803b7d4e810 with sleeping prohibited [141] cpuid = 5 [141] time = 1498436043 [141] KDB: stack backtrace: [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe2fc8b0 [141] vpanic() at vpanic+0x19c/frame 0xfe2fc930 [141] kassert_panic() at kassert_panic+0x126/frame 0xfe2fc9a0 [141] sleepq_add() at sleepq_add+0x34f/frame 0xfe2fc9f0 [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfe2fcaa0 [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfe2fcae0 [141] refcount_remove_many() at refcount_remove_many+0x2a/frame 0xfe2fcb20 [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfe2fcb50 [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfe2fcb70 [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfe2fcba0 [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfe2fcbb0 [141] fork_exit() at fork_exit+0x84/frame 0xfe2fcbf0 [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfe2fcbf0 pool: rpool state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM rpoolONLINE 0 0 0 mirror-0 ONLINE 0 0 0 mfid0p3 ONLINE 0 0 0 mfid1p3 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 mfid2ONLINE 0 0 0 mfid3ONLINE 0 0 0 errors: No known data errors Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: ino64 package fallout
;Compiling libc v0.2.21 >Compiling gcc v0.3.43 >Compiling getopts v0.2.14 >Compiling num_cpus v0.2.13 >Compiling filetime v0.1.10 >Compiling build_helper v0.1.0 > (file:///wrkdirs/usr/ports/lang/rust/work/rustc > -1.17.0-src/src/build_helper) >Compiling cmake v0.1.21 >Compiling toml v0.1.30 >Compiling bootstrap v0.0.0 > (file:///wrkdirs/usr/ports/lang/rust/work/rustc-1. > 17.0-src/src/bootstrap) > Finished dev [unoptimized] target(s) in 31.38 secs > Build completed unsuccessfully in 0:00:45 > gmake[1]: *** [Makefile:24: all] Error 245 > > > ... and lots more ports skipped because of the above. HardenedBSD, too, is seeing huge fallout with package building due to ino64. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: 64-bit inodes (ino64) Status Update and Call for Testing
On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote: > On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > > Inodes are data structures corresponding to objects in a file system, > > such as files and directories. FreeBSD has historically used 32-bit > > values to identify inodes, which limits file systems to somewhat under > > 2^32 objects. Many modern file systems internally use 64-bit identifiers > > and FreeBSD needs to follow suit to properly and fully support these > > file systems. > > > > The 64-bit inode project, also known as ino64, started life many years > > ago as a project by Gleb Kurtsou (gleb@). After that time several > > people have had a hand in updating it and addressing regressions, after > > mckusick@ picked up and updated the patch, and acted as a flag-waver. > > > > Sponsored by the FreeBSD Foundation I have spent a significant effort > > on outstanding issues and integration -- fixing compat32 ABI, NFS and > > ZFS, addressing ABI compat issues and investigating and fixing ports > > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > > jhb@ provided feedback and review on the ABI transition support. pho@ > > performed extensive testing and identified a number of issues that > > have now been fixed. kris@ performed an initial ports investigation > > followed by an exp-run by antoine@. emaste@ helped with organization > > of the process. > > > > This note explains how to perform useful testing of the ino64 branch, > > beyond typical smoke tests. > > > > 1. Overview. > > > > The ino64 branch extends the basic system types ino_t and dev_t from > > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > > layout is modified due to the larger size of ino_t, and also gains a > > d_off (directory offset) member. As ino64 implies an ABI change anyway > > the struct statfs f_mntfromname[] and f_mntonname[] array length > > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > > names. > > > > ABI breakage is mitigated by providing compatibility using versioned > > symbols, ingenious use of the existing padding in structures, and by > > employing other tricks. Unfortunately, not everything can be fixed, > > especially outside the base system. For instance, third-party APIs > > which pass struct stat around are broken in backward and forward- > > incompatible way. > > > > 2. Motivation. > > > > The main risk of the ino64 change is the uncontrolled ABI breakage. > > Due to expansion of the basic types dev_t, ino_t and struct dirent, > > the impact is not limited to one part of the system, but affects: > > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > > and more) > > - libc interface (mostly related to the readdir(3), FTS(3)) > > - collateral damage in other libraries that happens to use changed types > > in the interfaces. See, for instance, libprocstat, for which compat > > was provided using symbol versioning, and libutil, which shlib version > > was bumped. > > > > 3. Quirks. > > > > We handled kinfo sysctl MIBs, but other MIBs which report structures > > depended on the changed type, are not handled in general. It was > > considered that the breakage is either in the management interfaces, > > where we usually allow ABI slip, or is not important. > > > > Struct xvnode changed layout, no compat shims are provided. > > > > For struct xtty, dev_t tty device member was reduced to uint32_t. It > > was decided that keeping ABI compat in this case is more useful than > > reporting 64bit dev_t, for the sake of pstat. > > > > 4. Testing procedure. > > > > The ino64 project can be tested by cloning the project branch from > > GitHub or by applying the patch > at URL | attached> to a working tree. The authorative source is the > > GitHub, I do not promise to update the review for each update. > > > > To clone from GitHub: > > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64 > > > > To fetch the patch from Phabricator: > > - Visit https://reviews.freebsd.org/D10439 > > - Click "Download Raw Diff" at the upper right of the page > > > > Or > > % arc patch D10439 > > > > After that, in the checkout directory do > > % (cd sys/kern && touch syscalls.master && make sysent) > > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > > If you use custom kernel
Re: 64-bit inodes (ino64) Status Update and Call for Testing
On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > Inodes are data structures corresponding to objects in a file system, > such as files and directories. FreeBSD has historically used 32-bit > values to identify inodes, which limits file systems to somewhat under > 2^32 objects. Many modern file systems internally use 64-bit identifiers > and FreeBSD needs to follow suit to properly and fully support these > file systems. > > The 64-bit inode project, also known as ino64, started life many years > ago as a project by Gleb Kurtsou (gleb@). After that time several > people have had a hand in updating it and addressing regressions, after > mckusick@ picked up and updated the patch, and acted as a flag-waver. > > Sponsored by the FreeBSD Foundation I have spent a significant effort > on outstanding issues and integration -- fixing compat32 ABI, NFS and > ZFS, addressing ABI compat issues and investigating and fixing ports > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > jhb@ provided feedback and review on the ABI transition support. pho@ > performed extensive testing and identified a number of issues that > have now been fixed. kris@ performed an initial ports investigation > followed by an exp-run by antoine@. emaste@ helped with organization > of the process. > > This note explains how to perform useful testing of the ino64 branch, > beyond typical smoke tests. > > 1. Overview. > > The ino64 branch extends the basic system types ino_t and dev_t from > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > layout is modified due to the larger size of ino_t, and also gains a > d_off (directory offset) member. As ino64 implies an ABI change anyway > the struct statfs f_mntfromname[] and f_mntonname[] array length > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > names. > > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and by > employing other tricks. Unfortunately, not everything can be fixed, > especially outside the base system. For instance, third-party APIs > which pass struct stat around are broken in backward and forward- > incompatible way. > > 2. Motivation. > > The main risk of the ino64 change is the uncontrolled ABI breakage. > Due to expansion of the basic types dev_t, ino_t and struct dirent, > the impact is not limited to one part of the system, but affects: > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > and more) > - libc interface (mostly related to the readdir(3), FTS(3)) > - collateral damage in other libraries that happens to use changed types > in the interfaces. See, for instance, libprocstat, for which compat > was provided using symbol versioning, and libutil, which shlib version > was bumped. > > 3. Quirks. > > We handled kinfo sysctl MIBs, but other MIBs which report structures > depended on the changed type, are not handled in general. It was > considered that the breakage is either in the management interfaces, > where we usually allow ABI slip, or is not important. > > Struct xvnode changed layout, no compat shims are provided. > > For struct xtty, dev_t tty device member was reduced to uint32_t. It > was decided that keeping ABI compat in this case is more useful than > reporting 64bit dev_t, for the sake of pstat. > > 4. Testing procedure. > > The ino64 project can be tested by cloning the project branch from > GitHub or by applying the patch at URL | attached> to a working tree. The authorative source is the > GitHub, I do not promise to update the review for each update. > > To clone from GitHub: > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64 > > To fetch the patch from Phabricator: > - Visit https://reviews.freebsd.org/D10439 > - Click "Download Raw Diff" at the upper right of the page > > Or > % arc patch D10439 > > After that, in the checkout directory do > % (cd sys/kern && touch syscalls.master && make sysent) > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > If you use custom kernel configuration, ensure that > options COMPAT_FREEBSD11 > is included into the config. Then build world and kernel in the > usual way, install kernel, reboot, install new world. Do not make > shortcuts in the update procedure. Hey Kostik, On my HardenedBSD system, world compiled fine with the patch, but the kernel didn't compile. I've uploaded the log to: https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log This was from importing the patch from Phabricator into hardened/current/master in HardenedBSD. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ?
On Tue, May 09, 2017 at 12:07:47PM +0200, Henri Hennebert wrote: > Hello, > > I build current -r317181 with crochet for my PINE64. > > the kernel can boot with loader.conf.local: > > geom_mirror_load="YES" > > If I add to loader.conf.local: > > zfs_load="YES" > > or if I strike the space bar during loader.efi and I load zfs manually: > > OK load zfs > ... > OK boot > > the kernel don't boot and the console stay with the last line: > > Using DTB provided by EFI at 0x4900. > > Moreover the opensolaris.ko is not loader. > > Maybe DTB is smashed by zfs.ko > > Any idea ? I see the same symptom with root-on-ZFS with my SoftIron OverDrive 1000. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Boot failure - svn up from this morning
On Fri, Mar 03, 2017 at 02:30:08PM +0100, Michael Tuexen wrote: > > On 3 Mar 2017, at 12:59, Dexuan Cui <de...@microsoft.com> wrote: > > > >> From: Dexuan Cui > >> Sent: Friday, March 3, 2017 19:50 > >>> From: Alex Deiter > >>> Sent: Friday, March 3, 2017 17:22 > >>> Hello, > >>> The same issue with FreeBSD 12.0-CURRENT-r314563: > >>> elf64_loadimage: could not read symbols - skipped! > >>> > >>> I suspect regression after: > >>> > >>> Revision 314547 - Directory Listing > >>> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan > >>> loader.efi: reduce the size of the staging area if necessary > >> > >> Yes, I believe the issue is caused by the patch, which is supposed to PR > >> 211746: > >> ... > >> Can you please try the patch to dump the memory map? > >> ... > > > > BTW, I understand it's really annoying to boot the host first... > > I'm really sorry for this. > > > > I suppose you're able to build or find a good 'loader.efi' binary on > > another host, > > and then manage to replace the bad 'loader.efi' on the host broken by me. > > :-) > This problem also occurred on a Dell R430... And in bhyve with UEFI mode. -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat
On Fri, Jan 27, 2017 at 12:35:21PM -0500, Allan Jude wrote: > On 2017-01-27 12:33, Shawn Webb wrote: > > On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote: > >> On 2017-01-27 12:05, Warner Losh wrote: > >>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome <tso...@me.com> wrote: > >>>> > >>>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) > >>>>> <yaneurab...@gmail.com> wrote: > >>>>> > >>>>> Hi, > >>>>> I tried upgrading one of my workstations and unfortunately the > >>>>> freebsd-boot partition is too small (I follow manpage directions, > >>>>> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), > >>>>> and I don???t have enough space or ability to resize the partition and > >>>>> make it bigger. So, I???m in need of a build knob to control the bloat, > >>>>> and/or having an alternative boot loader without geli/skein/crypto > >>>>> support compiled in. Would you be opposed to the work? > >>>>> Thanks, > >>>>> -Ngie > >>>> > >>>> > >>>> I do agree that since the geli knob is already there, it may do. Of > >>>> course we also can think of additional knobs, but there is an issue - it > >>>> wont help just to exclude some files, the additional features also do > >>>> sit in the code, so the replacement stubs will be needed, also testing > >>>> them all over will take some time. And the preprocessor spaghetti really > >>>> is nasty thing to deal with;) > >>>> > >>>> And then there is another issue (partly why I did the feature support in > >>>> first place) - as the kernel does not block user from enabling the > >>>> features, the user can end up facing non-bootable setup which is also > >>>> not good, as user is using perfectly legal options, and still the whole > >>>> thing is just rendered unusable??? > >>> > >>> I'm curious why you can't find the space for a bigger partition? > >>> Almost all drives these days are partitioned with a little wasted > >>> space, and that wasted space should be more than enough to cover us > >>> here. Also, most drives have a swap partition that can be shrunk a > >>> trivial amount to get space for this... > >>> > >>> Warner > >>> > >> > >> I need to do some testing to make a recipe that works for it, but the > >> other option is to use the ZFS bootcode area. > >> > >> ZFS it self, reserves something like 3.5 mb of space in the ZFS > >> partition, for boot code. This is how we boot ZFS on MBR. > >> > >> It should be possible to use this on GPT as well, we just don't. > > > > In the future, maybe it'd be a good idea for the installer to leave > > more space (a few MB, perhaps?) between the freebsd-boot and > > freebsd-swap partitions? At least, for ZFS installs. > > > > Thanks, > > > > The PMBR code has a limitation for 536kb, and it all has to fit under > the 640k barrier, so the current 512kb size is plenty. The issue is some > people are upgrading from systems that were isntalled long ago, when > 64kb or less was the default. Gotcha. Thanks for the explanation. -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat
On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote: > On 2017-01-27 12:05, Warner Losh wrote: > > On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome <tso...@me.com> wrote: > >> > >>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) > >>> <yaneurab...@gmail.com> wrote: > >>> > >>> Hi, > >>> I tried upgrading one of my workstations and unfortunately the > >>> freebsd-boot partition is too small (I follow manpage directions, > >>> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), > >>> and I don???t have enough space or ability to resize the partition and > >>> make it bigger. So, I???m in need of a build knob to control the bloat, > >>> and/or having an alternative boot loader without geli/skein/crypto > >>> support compiled in. Would you be opposed to the work? > >>> Thanks, > >>> -Ngie > >> > >> > >> I do agree that since the geli knob is already there, it may do. Of course > >> we also can think of additional knobs, but there is an issue - it wont > >> help just to exclude some files, the additional features also do sit in > >> the code, so the replacement stubs will be needed, also testing them all > >> over will take some time. And the preprocessor spaghetti really is nasty > >> thing to deal with;) > >> > >> And then there is another issue (partly why I did the feature support in > >> first place) - as the kernel does not block user from enabling the > >> features, the user can end up facing non-bootable setup which is also not > >> good, as user is using perfectly legal options, and still the whole thing > >> is just rendered unusable??? > > > > I'm curious why you can't find the space for a bigger partition? > > Almost all drives these days are partitioned with a little wasted > > space, and that wasted space should be more than enough to cover us > > here. Also, most drives have a swap partition that can be shrunk a > > trivial amount to get space for this... > > > > Warner > > > > I need to do some testing to make a recipe that works for it, but the > other option is to use the ZFS bootcode area. > > ZFS it self, reserves something like 3.5 mb of space in the ZFS > partition, for boot code. This is how we boot ZFS on MBR. > > It should be possible to use this on GPT as well, we just don't. In the future, maybe it'd be a good idea for the installer to leave more space (a few MB, perhaps?) between the freebsd-boot and freebsd-swap partitions? At least, for ZFS installs. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
