Re: HEADS-UP: PIE enabled by default on main
On 2021-02-27 22:29, 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. Warner, thanks for the links. They are indeed interesting. > > You clearly should mean something useful and much more important than > > that, > > Maybe he'd like to understand how PIE accomplishes better security give the > known ASLR weaknesses. And rather than take a sarcastic tone, he asked for > more details that back up the earlier claims of improved security so we > could all learn something. The conclusion of the paper in the second link clearly says: We present a new weakness on the current implementationof the ASLR Linux systems which affects PIE compiled ex-ecutables. Applications compiled with PIE are consideredto be more robust since it makes attacks more difficult. Which I read as ASLR and PIE work better together. This is the same what Gordon was saying. The whole situation is wrong on 2 different levels. First: saying that ASLR is not perfect and can be broken is not the same thing as saying "The only purpose of it is to have a check-list item ticked green" There are no perfect security measures, and you guys (kernel and OS developers) should know that better than us (users). Hackers find new exploits, developers find ways to mitigate them and cycle repeats. Just the fact that ASLR can be broken is not the reason to not have it. Second: look at this exchange from a distance Ed: we are enabling security feature X, please rebuild your worlds.. Godron: great progress! go team! Konstantin: why do you think this is great progress? (implying it is not) Gordon: well, I heard feature X works best with feature Y Konstantin: feature Y is useless checkbox, next time you speak make sure you say something useful! Considering the fact that Konstantin himself worked on ASLR this is at least confusing.. Also does this also mean that feature X (PIE) is also useless checkbox? Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but it does not look good form the outside. You are sending mixed signals to your auditory. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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. > You clearly should mean something useful and much more important than > that, > > when stating that FreeBSD made a huge step forward. So I want to be > aware > > of the advance. > > Why attack a person who was really happy for the project? > This DOES sound a agressive, even for a sarcastic joke.. > I am saying this someone who shares the same native language with Mr. > Belousov, > it is not a "language/culture" difference thing. > just your regular user who reads mailing list ocassionally > Maybe he'd like to understand how PIE accomplishes better security give the known ASLR weaknesses. And rather than take a sarcastic tone, he asked for more details that back up the earlier claims of improved security so we could all learn something. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
> > 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? > You clearly should mean something useful and much more important than that, > when stating that FreeBSD made a huge step forward. So I want to be aware > of the advance. Why attack a person who was really happy for the project? This DOES sound a agressive, even for a sarcastic joke.. I am saying this someone who shares the same native language with Mr. Belousov, it is not a "language/culture" difference thing. - just your regular user who reads mailing list ocassionally ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Fri, Feb 26, 2021 at 08:32:26PM +0100, Gordon Bergling wrote: > On Fri, Feb 26, 2021 at 08:57:55PM +0200, Konstantin Belousov wrote: > > On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote: > > > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote: > > > > As of 9a227a2fd642 (main-n245052) base system binaries are now built > > > > as position-independent executable (PIE) by default, for 64-bit > > > > architectures. PIE executables are used in conjunction with address > > > > randomization as a mitigation for certain types of security > > > > vulnerabilities. > > > > > > > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > > > > do one initial clean build -- either run `make cleanworld` or set > > > > WITH_CLEAN=yes. > > > > > > > > No significant user-facing changes are expected from this change, but > > > > there are some minor ones. For example, `file` will indicate that > > > > binaries are PIE by reporting something like `ELF 64-bit LSB pie > > > > executable` rather than `ELF 64-bit LSB executable`. Also, for most > > > > workloads no notable performance impact is expected. > > > > > > > > For almost all ports this should result in no change. There are a > > > > small number of ports that use base system /usr/share/mk > > > > infrastructure and thus inherit the base system default, and some of > > > > those initially failed to build. Those found during an exp-run in > > > > PR253275 have been addressed or have patches waiting. > > > > > > > > Please watch out for any new issues after you next update the base > > > > system and/or ports, and report issues via a Bugzilla PR or in reply > > > > here. > > > > > > Thats a huge step forward in terms on security. > > Can you explain why? > > > > Thanks. > > I can try. Enabling PIE for every 64bit architecture is in that matter a step > forward in security as it enables ASLR for further adoption. 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. You clearly should mean something useful and much more important than that, when stating that FreeBSD made a huge step forward. So I want to be aware of the advance. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
Thanks. I adjusted the namecache. However, the nfs fix provided by Rick should go in regardless. On 2/27/21, Juraj Lutter wrote: > > >> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: >> >> Can you dump 'struct componentname *cnp'? This should do the trick: >> f 12 >> p cnp >> >> Most notably I want to know if the name to added is a literal dot. >> > > Yes, it is a dot (the directory itself): > > cn_nameptr = 0xfe0011428018 ".", cn_namelen = 1 > > otis > > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: > > Can you dump 'struct componentname *cnp'? This should do the trick: > f 12 > p cnp > > Most notably I want to know if the name to added is a literal dot. > Yes, it is a dot (the directory itself): cn_nameptr = 0xfe0011428018 ".", cn_namelen = 1 otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
You should be able to just use kgdb on the old kernel and the
crashdump you already collected, provided both are still around.
Alternatively boot with this without the fix:
diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c
index fef1e31d197b..c4d2990b155d 100644
--- a/sys/kern/vfs_cache.c
+++ b/sys/kern/vfs_cache.c
@@ -2266,6 +2266,9 @@ cache_enter_time(struct vnode *dvp, struct vnode
*vp, struct componentname *cnp,
KASSERT(cnp->cn_namelen <= NAME_MAX,
("%s: passed len %ld exceeds NAME_MAX (%d)", __func__,
cnp->cn_namelen,
NAME_MAX));
+ if (dvp == vp) {
+ panic("%s: same vnodes; cnp [%s] len %ld\n", __func__,
cnp->cn_nameptr, cnp->cn_namelen);
+ }
VNPASS(dvp != vp, dvp);
VNPASS(!VN_IS_DOOMED(dvp), dvp);
VNPASS(dvp->v_type != VNON, dvp);
On 2/27/21, Juraj Lutter wrote:
> I am now running a patched kernel, without problems.
>
> I can boot to unpatched one and see the output of these ddb commands.
>
> otis
>
> —
> Juraj Lutter
> XMPP: juraj (at) lutter.sk
> GSM: +421907986576
>
>> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote:
>>
>> Can you dump 'struct componentname *cnp'? This should do the trick:
>> f 12
>> p cnp
>>
>
>
>
--
Mateusz Guzik
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
I am now running a patched kernel, without problems. I can boot to unpatched one and see the output of these ddb commands. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: > > Can you dump 'struct componentname *cnp'? This should do the trick: > f 12 > p cnp > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
Can you dump 'struct componentname *cnp'? This should do the trick: f 12 p cnp Most notably I want to know if the name to added is a literal dot. That case is handled if necessary, but the assert was added to start making the interface stricter. If the name is a dot I'll be inclined to remove the assert for 13.x to avoid problems with other callers of the sort. Otherwise I'll have to check what's going on there. On 2/27/21, Juraj Lutter wrote: > Hi, > > thank you for the swift reaction. This patch fixed my problem. > > otis > > — > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576 > >> On 27 Feb 2021, at 16:53, Rick Macklem wrote: >> >> I reproduced the problem and the attached trivial patch >> seems to fix it. Please test the patch if you can. >> > > -- Mateusz Guzik ___ 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"
LORs in -CURRENT
I’ve got some LORs: lock order reversal: 1st 0xf8008c4f4af0 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1071 2nd 0xf8008c51a930 zfs (zfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1083 lock order zfs -> nfs established at: #0 0x80c7bb7d at witness_checkorder+0x46d #1 0x80bdcf18 at lockmgr_lock_flags+0x188 #2 0x80af1b9c at nfs_lock+0x2c #3 0x80ce485f at vop_sigdefer+0x2f #4 0x80d0e5e4 at _vn_lock+0x54 #5 0x80ced6a5 at vfs_domount+0xef5 #6 0x80cebb02 at vfs_donmount+0x872 #7 0x80ceb259 at sys_nmount+0x69 #8 0x810bd00e at amd64_syscall+0x12e #9 0x8108fdfe at fast_syscall_common+0xf8 lock order nfs -> zfs attempted at: #0 0x80c7c4dc at witness_checkorder+0xdcc #1 0x80bde955 at lockmgr_xlock+0x55 #2 0x80d0e5e4 at _vn_lock+0x54 #3 0x80ced6a5 at vfs_domount+0xef5 #4 0x80cebb02 at vfs_donmount+0x872 #5 0x80ceb259 at sys_nmount+0x69 #6 0x810bd00e at amd64_syscall+0x12e #7 0x8108fdfe at fast_syscall_common+0xf8 lock order reversal: 1st 0xf8008c6473f0 zfs (zfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1071 2nd 0xf80035f4dcb0 devfs (devfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1083 lock order devfs -> zfs established at: #0 0x80c7bb7d at witness_checkorder+0x46d #1 0x80bde955 at lockmgr_xlock+0x55 #2 0x80d0e5e4 at _vn_lock+0x54 #3 0x80ced6a5 at vfs_domount+0xef5 #4 0x80cebb02 at vfs_donmount+0x872 #5 0x80cf01f7 at kernel_mount+0x57 #6 0x80cf2bc1 at parse_mount+0x4a1 #7 0x80cf1027 at vfs_mountroot+0x587 #8 0x80b9a4ff at start_init+0x1f #9 0x80bc7470 at fork_exit+0x80 #10 0x8109055e at fork_trampoline+0xe lock order zfs -> devfs attempted at: #0 0x80c7c4dc at witness_checkorder+0xdcc #1 0x80bde955 at lockmgr_xlock+0x55 #2 0x80d0e5e4 at _vn_lock+0x54 #3 0x80ced6a5 at vfs_domount+0xef5 #4 0x80cebb02 at vfs_donmount+0x872 #5 0x80ceb259 at sys_nmount+0x69 #6 0x810bd00e at amd64_syscall+0x12e #7 0x8108fdfe at fast_syscall_common+0xf8 lock order reversal: 1st 0xf8008c6f7230 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_syscalls.c:4135 2nd 0xfe000ee1dc50 bufwait (bufwait, lockmgr) @ /usr/src/sys/kern/vfs_bio.c:1674 3rd 0xf8008c6f73f0 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:2915 lock order nfs -> bufwait established at: #0 0x80c7bb7d at witness_checkorder+0x46d #1 0x80bdd5ec at lockmgr_xlock_hard+0x6c #2 0x80bde303 at __lockmgr_args+0x613 #3 0x80ccf504 at getnewbuf+0x334 #4 0x80ccc839 at getblkx+0x359 #5 0x80ccf1b2 at getblk+0x22 #6 0x80afd3b6 at nfs_getcacheblk+0x46 #7 0x80afcd4b at ncl_bioread+0x58b #8 0x80af1aff at nfs_readdir+0x18f #9 0x80ce485f at vop_sigdefer+0x2f #10 0x81181f38 at VOP_READDIR_APV+0x38 #11 0x80d0b18b at kern_getdirentries+0x1fb #12 0x80d0b399 at sys_getdirentries+0x29 #13 0x810bd00e at amd64_syscall+0x12e #14 0x8108fdfe at fast_syscall_common+0xf8 lock order bufwait -> nfs attempted at: #0 0x80c7c4dc at witness_checkorder+0xdcc #1 0x80bdcf18 at lockmgr_lock_flags+0x188 #2 0x80af1b9c at nfs_lock+0x2c #3 0x80ce485f at vop_sigdefer+0x2f #4 0x80d0e5e4 at _vn_lock+0x54 #5 0x80cf6e0f at vget_finish+0x4f #6 0x80ce6b3c at vfs_hash_get+0xbc #7 0x80af9d09 at nfscl_nget+0x119 #8 0x80ae291a at nfsrpc_readdirplus+0xaaa #9 0x80aed43c at ncl_readdirplusrpc+0xdc #10 0x80afdbe3 at ncl_doio+0x423 #11 0x80afcd8c at ncl_bioread+0x5cc #12 0x80af1aff at nfs_readdir+0x18f #13 0x80ce485f at vop_sigdefer+0x2f #14 0x81181f38 at VOP_READDIR_APV+0x38 #15 0x80d0b18b at kern_getdirentries+0x1fb #16 0x80d0b399 at sys_getdirentries+0x29 #17 0x810bd00e at amd64_syscall+0x12e kernel is GENERIC, stock config. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
Hi, thank you for the swift reaction. This patch fixed my problem. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 16:53, Rick Macklem wrote: > > I reproduced the problem and the attached trivial patch > seems to fix it. Please test the patch if you can. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: condition seqc_in_modify(_vp->v_seqc) not met at zfs_acl.c:1147 (zfs_acl_chown_setattr)
On 16/02/2021 22:38, Mateusz Guzik wrote:
> I think for future proofing it would be best if all vnodes going there
> had seqc marked, thus I think this should do the trick:
>
> diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> index d5f0da9ecd4b..8172916c4329 100644
> --- a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> +++ b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> @@ -2756,7 +2756,9 @@ zfs_setattr(znode_t *zp, vattr_t *vap, int
> flags, cred_t *cr)
> err = zfs_acl_chown_setattr(zp);
> ASSERT(err == 0);
> if (attrzp) {
> + vn_seqc_write_begin(ZTOV(attrzp));
> err = zfs_acl_chown_setattr(attrzp);
> + vn_seqc_write_end(ZTOV(attrzp));
> ASSERT(err == 0);
> }
> }
>
> I don't see other calls to the routine.
This patch works perfectly for me.
Thank you!
> On 2/16/21, Andriy Gapon wrote:
>> On 15/02/2021 11:45, Andriy Gapon wrote:
>>> On 15/02/2021 10:22, Andriy Gapon wrote:
I've got this panic once when copying a couple of files.
The system is stable/13 as of 1996360d7338d, a custom kernel
configuration, but
no local source code modifications.
Unread portion of the kernel message buffer:
VNASSERT failed: ({ seqc_t __seqc = (_vp->v_seqc);
__builtin_expect((__seqc &
1), 0); }) not true at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
(zfs_acl_chown_setattr)
0xf8013e4e85b8: type VDIR
usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0
hold count flags ()
flags ()
lock type zfs: EXCL by thread 0xfe01dd1cd560 (pid 30747,
kdeinit5, tid
159911)
panic: condition seqc_in_modify(_vp->v_seqc) not met at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
(zfs_acl_chown_setattr)
Any ideas, suggestions, hints?
Thanks!
>>> ...
#4 0x8036fd21 in zfs_acl_chown_setattr (zp=0xf801ccd203b0)
at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
#5 0x8037e52d in zfs_setattr (zp=0xf8024b04f760,
vap=vap@entry=0xfe029a36c870, flags=flags@entry=0,
cr=, cr@entry=0xf8003ecedc00)
at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:2758
>>>
>>> So, this is actually the second zfs_acl_chown_setattr call here:
>>> err = zfs_acl_chown_setattr(zp);
>>> ASSERT(err == 0);
>>> if (attrzp) {
>>> err = zfs_acl_chown_setattr(attrzp);
>>> ASSERT(err == 0);
>>> }
>>>
>>> I am not sure if the assertion is actually applicable to attrzp (extended
>>> attributes "directory").
>>> At least I do not see any seq calls for it.
>>>
>>
>> So, I think that the problem should be reproducible by simply chown-ing a
>> file
>> with an extended attribute. The kernel should be compiled with both
>> DEBUG_VFS_LOCKS and INVARIANTS.
>>
>> --
>> Andriy Gapon
>>
>
>
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
I reproduced the problem and the attached trivial patch seems to fix it. Please test the patch if you can. Mateusz, I assume the directory shouldn't try and add a cache entry for itself? I don't test NFSv3 much and I don't test "rdirplus" much, so it slipped through the cracks. Thanks for reporting it, rick From: owner-freebsd-curr...@freebsd.org on behalf of Juraj Lutter Sent: Saturday, February 27, 2021 9:31 AM To: freebsd-current Subject: Re: -CURRENT panics in NFS CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca And a kgdb backtrace: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0x804c7b2a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0x804c78ee in db_command (last_cmdp=, cmd_table=, dopager=dopager@entry=1) at /usr/src/sys/ddb/db_command.c:482 #4 0x804c762d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0x804cac36 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0x80c59d04 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=, tf@entry=0xfe00d01c3d40) at /usr/src/sys/kern/subr_kdb.c:727 #7 0x810bc1ee in trap (frame=0xfe00d01c3d40) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=0x812accc9 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:506 #10 0x80c0d5d2 in vpanic (fmt=, ap=, ap@entry=0xfe00d01c3ea0) at /usr/src/sys/kern/kern_shutdown.c:907 #11 0x80c0d363 in panic (fmt=0x81e9a178 "\177\256&\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:843 #12 0x80cd6d74 in cache_enter_time (dvp=0xf80079321e00, vp=0xf80079321e00, cnp=cnp@entry=0xfe00d01c4030, tsp=tsp@entry=0xfe00d01c40e0, dtsp=) at /usr/src/sys/kern/vfs_cache.c:2274 #13 0x80ae2bd6 in nfsrpc_readdirplus (vp=, vp@entry=0xf80079321e00, uiop=, uiop@entry=0xfe00d01c4540, cookiep=cookiep@entry=0xfe00d01c44e0, cred=cred@entry=0xf80079307e00, p=, p@entry=0xfe00de06be00, nap=nap@entry=0xfe00d01c4400, attrflagp=0xfe00d01c44f0, eofp=0xfe00d01c44f4, stuff=0x0) at /usr/src/sys/fs/nfsclient/nfs_clrpcops.c:3766 #14 0x80aed4ec in ncl_readdirplusrpc (vp=vp@entry=0xf80079321e00, uiop=uiop@entry=0xfe00d01c4540, cred=0xf80079307e00, td=td@entry=0xfe00de06be00) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2490 #15 0x80afdc93 in ncl_doio (vp=vp@entry=0xf80079321e00, bp=bp@entry=0xfe000ee1c610, cr=0xfe00d01c3d00, cr@entry=0xf80079307e00, td=td@entry=0xfe00de06be00, called_from_strategy=called_from_strategy@entry=0) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1686 #16 0x80afce3c in ncl_bioread (vp=, vp@entry=0xf80079321e00, uio=, ioflag=ioflag@entry=0, cred=) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:604 #17 0x80af1baf in nfs_readdir (ap=ap@entry=0xfe00d01c4918) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2383 #18 0x80ce490f in vop_sigdefer (vop=, a=0xfe00d01c4918) at /usr/src/sys/kern/vfs_default.c:1471 #19 0x81181f38 in VOP_READDIR_APV (vop=0x81af00d8 , a=a@entry=0xfe00d01c4918) at vnode_if.c:1939 #20 0x80d0b23b in VOP_READDIR (vp=0xf80079321e00, uio=0xfe00d01c48d0, cred=, eofflag=0xfe00d01c48cc, ncookies=0x0, cookies=0x0) at ./vnode_if.h:985 #21 kern_getdirentries (td=, fd=, buf=0x801851000 , count=4096, basep=basep@entry=0xfe00d01c49b0, residp=residp@entry=0x0, bufseg=UIO_USERSPACE) at /usr/src/sys/kern/vfs_syscalls.c:4142 #22 0x80d0b449 in sys_getdirentries (td=0x81e9a178 , uap=0xfe00de06c1e8) at /usr/src/sys/kern/vfs_syscalls.c:4089 #23 0x810bd00e in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #24 amd64_syscall (td=0xfe00de06be00, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #25 #26 0x0008012a83fa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffd928 — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:18, Juraj Lutter wrote: > > Reliably reproducible: > ___ 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" rdirplus.patch Description: rdirplus.patch ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KTLS with zfs recv
On Sat, Feb 27, 2021 at 7:10 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > My understanding is that KTLS works very well with OpenSSL for > sending, > > > but > > > > not as well for receiving, because there's nothing like a recvfile > > > > syscall. However, it works great for both send and receive with NFS, > > > where > > > > all the data remains in the kernel. What about zfs recv? A very > common > > > > pattern is for an application to read from an SSL socket and then > pipe > > > the > > > > data to zfs recv. For example, zrepl does that. Could zfs recv > instead > > > > read directly from the KTLS socket, bypassing userspace? That could > > > > potentially save a _lot_ of cycles for a _lot_ of people. > > > > > > I did some patches and a short presentation at BSDCan that basically > > > shoves the whole zfs send and zfs recv process into the kernel, ie > > > it opens the sockets up, makes the connections, then the socket > > > is passed into the kernel(s) and it all runs in kernel mode. > > > > > > > > > > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf > > > > > > A few things need fixed like reversing who does the listen for > > > security reasons, but this feature is probably ready for prime > > > time. > > > > > > > -Alan > > > > > > -- > > > Rod Grimes > > > rgri...@freebsd.org > > > > > > That looks potentially useful, but it doesn't use encryption. Would it > > work if the socket had been opened by openssl with ktls? > > Alan, > Should I revise the code to meet the state that was discussed > during the BSDCan talk so that it can be committed? Matt Aherns said > at the time he felt if I just reversed the listen/connect relationship > between send and recv that it addressed enough of the security concern > to be usable "on a local and well administered" network and would > probably be safe to import into upstream ZFS. (This was prior to > FreeBSD moving to openzfs.) > > From other discussion in this thread it does not sound difficult to > implement the KTLS end of it, but I doubt that would be portable > enough to upstream, maybe someone can speak to that issue? > > -- > Rod Grimes > rgri...@freebsd.org Rod, it would be great if we can get that code committed. I'll try to come up with a OpenSSL->zfs recv POC program next week. And I think we should try to upstream it to OpenZFS, too. They aren't strict about portability; plenty of OS-specific features have made it into their repo. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 13.0-BETA4 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The fourth BETA build of the 13.0-RELEASE release cycle is now available. Installation images are available for: o 13.0-BETA4 amd64 GENERIC o 13.0-BETA4 i386 GENERIC o 13.0-BETA4 powerpc GENERIC o 13.0-BETA4 powerpc64 GENERIC64 o 13.0-BETA4 powerpc64le GENERIC64LE o 13.0-BETA4 powerpcspe MPC85XXSPE o 13.0-BETA4 armv6 RPI-B o 13.0-BETA4 armv7 GENERICSD o 13.0-BETA4 aarch64 GENERIC o 13.0-BETA4 aarch64 RPI o 13.0-BETA4 aarch64 PINE64 o 13.0-BETA4 aarch64 PINE64-LTS o 13.0-BETA4 aarch64 PINEBOOK o 13.0-BETA4 aarch64 ROCK64 o 13.0-BETA4 aarch64 ROCKPRO64 o 13.0-BETA4 riscv64 GENERIC o 13.0-BETA4 riscv64 GENERICSD Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use Git to do a source based update of an existing system, use the "releng/13.0" branch. A summary of changes since 13.0-BETA3 includes: o A possible race between jail_remove(2) and fork(2) had been fixed. o An issue with the pf(4) osfp configuration had been fixed. o An update to the ena(4) driver had been added. o A bug fix to flex(1) had been addressed. o Fixes for FreeBSD-SA-21:06.xen and FreeBSD-SA-21:03.pam_login_access had been addressed. o A fix to ZFS to address a potential system crash if scrubbing after removing a slog device had been addressed. o And other miscellaneous fixes. A list of changes since 12.2-RELEASE is available in the releng/13.0 release notes: https://www.freebsd.org/releases/13.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 13.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64, i386, and aarch64 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD download mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA4/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. BASIC-CI images can be found at: https://download.freebsd.org/ftp/snapshots/CI-IMAGES/ === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: af-south-1 region: ami-018ff0bbb489cc147 eu-north-1 region: ami-0d254e869c98cee4c ap-south-1 region: ami-0fbf06953c56b6f0d eu-west-3 region: ami-052a22f0481d6b334 eu-west-2 region: ami-015353db614403879 eu-south-1 region: ami-00846500ffe1975b8 eu-west-1 region: ami-0b515b56fa3b7332b ap-northeast-2 region: ami-06803a95877671551 me-south-1 region: ami-08de3623ff267603a ap-northeast-1 region: ami-05161601758e32a63 sa-east-1 region: ami-0d06cd4055c68ba45 ca-central-1 region: ami-0d0388a8a169d558f ap-east-1 region: ami-0451191bad1ef9693 ap-southeast-1 region: ami-0ebd0fd4279e33ec8 ap-southeast-2 region: ami-05ade971900f558c0 eu-central-1 region: ami-0ad78f12e0a41a4b0 us-east-1 region: ami-0d05110d430079833 us-east-2 region: ami-02da8e14277738938 us-west-1 region: ami-01f37e43b49871d73 us-west-2 region: ami-0f07edd632e38b962 FreeBSD/aarch64 EC2 AMIs are available in the following regions: af-south-1 region: ami-0967dd10e7b2b5dff eu-north-1 region: ami-09fb93f6c2c7109e5 ap-south-1 region: ami-0034cc6c0c95e6f1c eu-west-3 region: ami-01b1667281c168197 eu-west-2 region: ami-02ecf0f64094a745c eu-south-1 region: ami-07481931ee179e035 eu-west-1 region: ami-07b117d18ce82445e ap-northeast-2
Re: -CURRENT panics in NFS
And a kgdb backtrace: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0x804c7b2a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0x804c78ee in db_command (last_cmdp=, cmd_table=, dopager=dopager@entry=1) at /usr/src/sys/ddb/db_command.c:482 #4 0x804c762d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0x804cac36 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0x80c59d04 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=, tf@entry=0xfe00d01c3d40) at /usr/src/sys/kern/subr_kdb.c:727 #7 0x810bc1ee in trap (frame=0xfe00d01c3d40) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=0x812accc9 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:506 #10 0x80c0d5d2 in vpanic (fmt=, ap=, ap@entry=0xfe00d01c3ea0) at /usr/src/sys/kern/kern_shutdown.c:907 #11 0x80c0d363 in panic (fmt=0x81e9a178 "\177\256&\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:843 #12 0x80cd6d74 in cache_enter_time (dvp=0xf80079321e00, vp=0xf80079321e00, cnp=cnp@entry=0xfe00d01c4030, tsp=tsp@entry=0xfe00d01c40e0, dtsp=) at /usr/src/sys/kern/vfs_cache.c:2274 #13 0x80ae2bd6 in nfsrpc_readdirplus (vp=, vp@entry=0xf80079321e00, uiop=, uiop@entry=0xfe00d01c4540, cookiep=cookiep@entry=0xfe00d01c44e0, cred=cred@entry=0xf80079307e00, p=, p@entry=0xfe00de06be00, nap=nap@entry=0xfe00d01c4400, attrflagp=0xfe00d01c44f0, eofp=0xfe00d01c44f4, stuff=0x0) at /usr/src/sys/fs/nfsclient/nfs_clrpcops.c:3766 #14 0x80aed4ec in ncl_readdirplusrpc (vp=vp@entry=0xf80079321e00, uiop=uiop@entry=0xfe00d01c4540, cred=0xf80079307e00, td=td@entry=0xfe00de06be00) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2490 #15 0x80afdc93 in ncl_doio (vp=vp@entry=0xf80079321e00, bp=bp@entry=0xfe000ee1c610, cr=0xfe00d01c3d00, cr@entry=0xf80079307e00, td=td@entry=0xfe00de06be00, called_from_strategy=called_from_strategy@entry=0) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1686 #16 0x80afce3c in ncl_bioread (vp=, vp@entry=0xf80079321e00, uio=, ioflag=ioflag@entry=0, cred=) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:604 #17 0x80af1baf in nfs_readdir (ap=ap@entry=0xfe00d01c4918) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2383 #18 0x80ce490f in vop_sigdefer (vop=, a=0xfe00d01c4918) at /usr/src/sys/kern/vfs_default.c:1471 #19 0x81181f38 in VOP_READDIR_APV (vop=0x81af00d8 , a=a@entry=0xfe00d01c4918) at vnode_if.c:1939 #20 0x80d0b23b in VOP_READDIR (vp=0xf80079321e00, uio=0xfe00d01c48d0, cred=, eofflag=0xfe00d01c48cc, ncookies=0x0, cookies=0x0) at ./vnode_if.h:985 #21 kern_getdirentries (td=, fd=, buf=0x801851000 , count=4096, basep=basep@entry=0xfe00d01c49b0, residp=residp@entry=0x0, bufseg=UIO_USERSPACE) at /usr/src/sys/kern/vfs_syscalls.c:4142 #22 0x80d0b449 in sys_getdirentries (td=0x81e9a178 , uap=0xfe00de06c1e8) at /usr/src/sys/kern/vfs_syscalls.c:4089 #23 0x810bd00e in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #24 amd64_syscall (td=0xfe00de06be00, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #25 #26 0x0008012a83fa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffd928 — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:18, Juraj Lutter wrote: > > Reliably reproducible: > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
Reliably reproducible: VNASSERT failed: dvp != vp not true at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) 0xf80079321e00: type VDIR usecount 4, writecount 0, refcount 3 seqc users 0 mountedhere 0 hold count flags () flags (VV_ROOT|VV_VMSIZEVNLOCK) v_object 0xf801eeaf1d68 ref 0 pages 2 cleanbuf 1 dirtybuf 0 lock type nfs: SHARED (count 1) fileid 34 fsid 0x3a3a00ff02 panic: condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) cpuid = 1 time = 1614435453 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00d01c3e10 vpanic() at vpanic+0x181/frame 0xfe00d01c3e60 panic() at panic+0x43/frame 0xfe00d01c3ec0 cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00d01c3fa0 nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00d01c43d0 ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00d01c4520 ncl_doio() at ncl_doio+0x423/frame 0xfe00d01c45b0 ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00d01c4740 nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00d01c4850 vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00d01c4880 VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00d01c48a0 kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00d01c4990 sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00d01c49c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00d01c4af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00d01c4af0 --- syscall (554, FreeBSD ELF64, sys_getdirentries), rip = 0x8012a83fa, rsp = 0x7fffd928, rbp = 0x7fffd960 --- KDB: enter: panic [ thread pid 1879 tid 101207 ] Stopped at kdb_enter+0x37: movq$0,0x128bdde(%rip) db> — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:10, Juraj Lutter wrote: > > - poudriere data stored on NFS > - NFS server 12-STABLE > - NFS client (that panicked) 14-CURRENT > - Panic string: > > condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 > (cache_enter_time) > > backtrace: > > Tracing pid 27294 tid 100893 td 0xfe00ea1a3500 > kdb_enter() at kdb_enter+0x37/frame 0xfe00ea3dee10 > vpanic() at vpanic+0x1b2/frame 0xfe00ea3dee60 > panic() at panic+0x43/frame 0xfe00ea3deec0 > cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00ea3defa0 > nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00ea3df3d0 > ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00ea3df520 > ncl_doio() at ncl_doio+0x423/frame 0xfe00ea3df5b0 > ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00ea3df740 > nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00ea3df850 > vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00ea3df880 > VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00ea3df8a0 > kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00ea3df990 > sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00ea3df9c0 > amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00ea3dfaf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00ea3dfaf0 > > > running processes: > > 27295 27179 27179 0 S+ piperd 0xf800090b4ba0 xargs > 27294 27179 27179 0 R+ CPU 1 find > 27179 816 27179 0 S+ wait0xf80181b69528 sh > > Dump header from device: /dev/vtbd0p3 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 1860571136 > Blocksize: 512 > Compression: none > Dumptime: 2021-02-27 14:59:59 +0100 > Hostname: b14.builder.wilbury.net > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 14.0-CURRENT #0 main-n245107-172f2fc11cc: Fri Feb 26 > 15:20:00 CET 2021 >r...@b14.builder.wilbury.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > Panic String: condition dvp != vp not met at > /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) > Dump Parity: 1481068399 > Bounds: 0 > Dump Status: good > > — > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576 > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KTLS with zfs recv
> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > My understanding is that KTLS works very well with OpenSSL for sending, > > but > > > not as well for receiving, because there's nothing like a recvfile > > > syscall. However, it works great for both send and receive with NFS, > > where > > > all the data remains in the kernel. What about zfs recv? A very common > > > pattern is for an application to read from an SSL socket and then pipe > > the > > > data to zfs recv. For example, zrepl does that. Could zfs recv instead > > > read directly from the KTLS socket, bypassing userspace? That could > > > potentially save a _lot_ of cycles for a _lot_ of people. > > > > I did some patches and a short presentation at BSDCan that basically > > shoves the whole zfs send and zfs recv process into the kernel, ie > > it opens the sockets up, makes the connections, then the socket > > is passed into the kernel(s) and it all runs in kernel mode. > > > > > > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf > > > > A few things need fixed like reversing who does the listen for > > security reasons, but this feature is probably ready for prime > > time. > > > > > -Alan > > > > -- > > Rod Grimes > > rgri...@freebsd.org > > > That looks potentially useful, but it doesn't use encryption. Would it > work if the socket had been opened by openssl with ktls? Alan, Should I revise the code to meet the state that was discussed during the BSDCan talk so that it can be committed? Matt Aherns said at the time he felt if I just reversed the listen/connect relationship between send and recv that it addressed enough of the security concern to be usable "on a local and well administered" network and would probably be safe to import into upstream ZFS. (This was prior to FreeBSD moving to openzfs.) >From other discussion in this thread it does not sound difficult to implement the KTLS end of it, but I doubt that would be portable enough to upstream, maybe someone can speak to that issue? -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
-CURRENT panics in NFS
- poudriere data stored on NFS - NFS server 12-STABLE - NFS client (that panicked) 14-CURRENT - Panic string: condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) backtrace: Tracing pid 27294 tid 100893 td 0xfe00ea1a3500 kdb_enter() at kdb_enter+0x37/frame 0xfe00ea3dee10 vpanic() at vpanic+0x1b2/frame 0xfe00ea3dee60 panic() at panic+0x43/frame 0xfe00ea3deec0 cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00ea3defa0 nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00ea3df3d0 ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00ea3df520 ncl_doio() at ncl_doio+0x423/frame 0xfe00ea3df5b0 ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00ea3df740 nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00ea3df850 vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00ea3df880 VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00ea3df8a0 kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00ea3df990 sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00ea3df9c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00ea3dfaf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00ea3dfaf0 running processes: 27295 27179 27179 0 S+ piperd 0xf800090b4ba0 xargs 27294 27179 27179 0 R+ CPU 1 find 27179 816 27179 0 S+ wait0xf80181b69528 sh Dump header from device: /dev/vtbd0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 1860571136 Blocksize: 512 Compression: none Dumptime: 2021-02-27 14:59:59 +0100 Hostname: b14.builder.wilbury.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 14.0-CURRENT #0 main-n245107-172f2fc11cc: Fri Feb 26 15:20:00 CET 2021 r...@b14.builder.wilbury.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC Panic String: condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) Dump Parity: 1481068399 Bounds: 0 Dump Status: good — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic
Great. Committed as c01da939b0998f8de068a23c9016c377e761255e. As you might have guessed, I don't have a current cardbus system, though I need to bring one up to finish the removal of PC Card support. Warner On Sat, Feb 27, 2021 at 1:13 AM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > That fixes the problem. Thanks for the quick response. > > -- > steve > > On Sat, Feb 27, 2021 at 12:02:54AM -0700, Warner Losh wrote: > > What does https://reviews.freebsd.org/D28963 do for you? > > > > Warner > > > > On Fri, Feb 26, 2021 at 9:48 PM Steve Kargl < > > s...@troutmask.apl.washington.edu> wrote: > > > > > Ejecting a D-Link DWL-G630 AirPlus G NIC leads to > > > > > > panic: mutex Giant not owned at /usr/src/sys/kern/subr_bus.c:3001 > > > cpuid = 1 > > > time = 1614400775 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > > 0xfe0062fc3b40 > > > vpanic() at vpanic+0x181/frame 0xfe0062fc3b90 > > > panic() at panic+0x43/frame 0xfe0062fc3bf0 > > > __mtx_assert() at __mtx_assert+0xb0/frame 0xfe0062fc3c00 > > > device_detach() at device_detach+0x2e/frame 0xfe0062fc3c40 > > > bus_generic_detach() at bus_generic_detach+0x38/frame > 0xfe0062fc3c60 > > > cardbus_detach_card() at cardbus_detach_card+0xf/frame > 0xfe0062fc3c80 > > > cbb_event_thread() at cbb_event_thread+0x1be/frame 0xfe0062fc3cf0 > > > fork_exit() at fork_exit+0x80/frame 0xfe0062fc3d30 > > > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0062fc3d30 > > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > > KDB: enter: panic > > > > > -- > Steve > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic
That fixes the problem. Thanks for the quick response. -- steve On Sat, Feb 27, 2021 at 12:02:54AM -0700, Warner Losh wrote: > What does https://reviews.freebsd.org/D28963 do for you? > > Warner > > On Fri, Feb 26, 2021 at 9:48 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > Ejecting a D-Link DWL-G630 AirPlus G NIC leads to > > > > panic: mutex Giant not owned at /usr/src/sys/kern/subr_bus.c:3001 > > cpuid = 1 > > time = 1614400775 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe0062fc3b40 > > vpanic() at vpanic+0x181/frame 0xfe0062fc3b90 > > panic() at panic+0x43/frame 0xfe0062fc3bf0 > > __mtx_assert() at __mtx_assert+0xb0/frame 0xfe0062fc3c00 > > device_detach() at device_detach+0x2e/frame 0xfe0062fc3c40 > > bus_generic_detach() at bus_generic_detach+0x38/frame 0xfe0062fc3c60 > > cardbus_detach_card() at cardbus_detach_card+0xf/frame 0xfe0062fc3c80 > > cbb_event_thread() at cbb_event_thread+0x1be/frame 0xfe0062fc3cf0 > > fork_exit() at fork_exit+0x80/frame 0xfe0062fc3d30 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0062fc3d30 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > KDB: enter: panic > > -- 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"
