Re: Deprecating smbfs(5) and removing it before FreeBSD 14
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. David
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
stat(1) isn't honouring locale
stat(1) isn't honouring locale. The manual page says: -t timefmt Display timestamps using the specified format. This format is passed directly to strftime(3). strftime(3) says: %+is replaced by national representation of the date and time (the format is similar to that produced by date(1)). However: - % date Fri Oct 29 00:14:12 BST 2021 % date +%+ Fri Oct 29 00:14:19 BST 2021 % stat -t%+ -f '%Sm' . Fri Oct 29 00:13:38 BST 2021 - % setenv LANG en_GB.UTF-8 % date Fri 29 Oct 2021 00:14:57 BST % date +%+ Fri 29 Oct 2021 00:15:05 BST % stat -t%+ -f '%Sm' . Fri Oct 29 00:13:38 BST 2021 - Including and adding: (void) setlocale(LC_TIME, ""); before the call to strftime() in usr.bin/stat/stat.c fixes this Is there any reason this isn't in place? Cheers, Jamie
Re: LAN ure interface problem
Ludovit Koren wrote this message on Fri, Oct 22, 2021 at 16:00 +0200: > I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty > on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN > interface: > > ure0 on uhub0 > ure0: on > usbus1 > miibus0: on ure0 > rgephy0: PHY 0 on miibus0 > rgephy0: OUI 0x00e04c, model 0x, rev. 0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: bpf attached > ue0: Ethernet address: 00:e0:4c:68:04:20 > > > When there is bigger load on the interface, for example rsync of the big > directory, the carrier is lost. The only solution I found is to remove > and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did not > help. The output of the ifconfig: > > ue0: flags=8843 metric 0 mtu 1500 > > options=68009b > ether 00:e0:4c:68:04:20 > inet 192.168.1.18 netmask 0xff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > I do not know and did not find anything relevant, if the driver is buggy > or the hardware has some problems. Please, advice. I have seen similar behavior, and unable to get an vendor support, so have stopped working on the driver. I have not found a reliable way to reset the hardware to a working state, even via power_off/power_on commands. Sorry that I don't have a solution for you. The closest that I could suggest is to try to drop the USB id from the ure driver or switch it's mode to try the ucdce driver instead. I've seen that it's been more reliable, but it could be because it also runs MUCH slower, and doesn't hit the same bug. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
