kyua test
I've started running kyua test when I load the weekly current snapshot, and I'm a little confused about if I should run kyua test as user or root. In order to make the /usr/ports/devel/kyua port you need to be root and I have just been doing the test as root, but I notice in the instructions I'm using in the test(7) manpage it says: $ kyua test -k /usr/tests/Kyuafile Which suggested to me run as user with the $ (not #) Of course, when I run it as user as I'm doing right now, it skips some tests that are only for root. I guess I could use a little advice. Clay ___ 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: how to use the ktls
On Tue, Jan 28, 2020 at 11:01:31PM +, Rick Macklem wrote: > John Baldwin wrote: > [stuff snipped] > >I don't know yet. :-/ With the TOE-based TLS I had been testing with, this > >doesn't > >happen because the NIC blocks the data until it gets the key and then it's > >always > >available via KTLS. With software-based KTLS for RX (which I'm going to > >start > >working on soon), this won't be the case and you will potentially have some > >data > >already ready by OpenSSL that needs to be drained from OpenSSL before you can > >depend on KTLS. It's probably only the first few messsages, but I will need > >to figure > >out a way that you can tell how much pending data in userland you need to > >read via > >SSL_read() and then pass back into the kernel before relying on KTLS (it > >would just > >be a single chunk of data after SSL_connect you would have to do this for). > I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and then > it throws > away non-application data records. (Not sure, ssl3_read_bytes() gets pretty > convoluted at > a glance.;-) Yes, SSL_read() interprets the TLS record type and only passes application data records through to the application. It doesn't exactly "throw away" the other records, though -- they still get processed, just internally to libssl :) I expect based on heuristics that the 485 bytes are a NewSessionTicket message, but that actual length is very much not a protocol constant and is an implementation detail of the TLS server. (That said, an openssl server is going to be producing the same length every time, for a given version of openssl, unless you configure it otherwise.) -Ben ___ 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: easy way to work around a lack of a direct map on i386
On Thu, Jan 30, 2020 at 11:23:02PM +, Rick Macklem wrote: > Hi, > > The current code for KERN_TLS uses PHYS_TO_DMAP() > to access unmapped external pages on m_ext.ext_pgs > mbufs. > I also need to do this to implement RPC-over-TLS. > > The problem is that some arches, like i386, don't > support PHYS_TO_DMAP(). > > Since it appears that there will be at most 4 pages on > one of these mbufs, my thinking was... > - Acquire four pages of kva from the kernel_map during > booting. > - Then just use pmap_qenter() to fill in the physical page > mappings for long enough to copy the data. > > Does this sound reasonable? > Is there a better way? Use sfbufs, they should work on all arches. In essence, they provide MI interface to DMAP where possible. I do not remember did I bumped the limit for i386 after 4/4 went in. There is currently no limits for sfbufs use per subsystem, but I think it is not very likely to cause too much troubles. Main rule is to not sleep waiting for more sfbufs if you already own one.. ___ 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"
easy way to work around a lack of a direct map on i386
Hi, The current code for KERN_TLS uses PHYS_TO_DMAP() to access unmapped external pages on m_ext.ext_pgs mbufs. I also need to do this to implement RPC-over-TLS. The problem is that some arches, like i386, don't support PHYS_TO_DMAP(). Since it appears that there will be at most 4 pages on one of these mbufs, my thinking was... - Acquire four pages of kva from the kernel_map during booting. - Then just use pmap_qenter() to fill in the physical page mappings for long enough to copy the data. Does this sound reasonable? Is there a better way? Thanks for your comments, rick ___ 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"
