Jupiter Broadcasting

Crypto HAMMER | BSD Now 251

Angela Fisher

##Headlines
###DragonflyBSD: Towards a HAMMER1 master/slave encrypted setup with LUKS

I just wanted to share my experience with setting up DragonFly master/slave HAMMER1 PFS’s on top of LUKS
So after a long time using an Synology for my NFS needs, I decided it was time to rethink my setup a little since I had several issues with it :

I have been playing with DragonFly in the past and knew about HAMMER, now I just had the perfect excuse to actually use it in production 🙂 After setting up the OS, creating the LUKS partition and HAMMER FS was easy :

kdload dm
cryptsetup luksFormat /dev/serno/<id1>
cryptsetup luksOpen /dev/serno/<id1> fort_knox
newfs_hammer -L hammer1_secure_master /dev/mapper/fort_knox
cryptsetup luksFormat /dev/serno/<id2>
cryptsetup luksOpen /dev/serno/<id2> fort_knox_slave
newfs_hammer -L hammer1_secure_slave /dev/mapper/fort_knox_slave

mount /dev/mapper/fort_knox /fort_knox
mount /dev/mapper_fort_know_slave /fort_knox_slave

You can now put your data under /fort_knox
Now, off to setting up the replication, first get the shared-uuid of /fort_knox

hammer pfs-status /fort_knox

Create a PFS slave “linked” to the master

hammer pfs-slave /fort_knox_slave/pfs/slave shared-uuid=f9e7cc0d-eb59-10e3-a5b5-01e6e7cefc12

And then stream your data to the slave PFS !

hammer mirror-stream /fort_knox /fort_knox_slave/pfs/slave

After that, setting NFS is fairly trivial even though I had problem with the /etc/exports syntax which is different than Linux

There’s a few things I wish would be better though but nothing too problematic or without workarounds :

Overall, I am happy, HAMMER1 and PFS are looking really good, DragonFly is a neat Unix and the community is super friendly (Matthew Dillon actually provided me with a kernel patch to fix the broken ACPI on the PC holding this setup, many thanks!), the system is still a “work in progress” but it is already serving my files as I write this post.

Let’s see in 6 months how it goes in the longer run !

###BSDCan 2018 Recap

“Automating Network Infrastructures with Ansible on FreeBSD” in the DevSummit track. A good talk that connected well with his Ansible tutorial and even allowed some discussions among participants.
“All along the dwatch tower”: Devin delivered a well prepared talk. I first thought that the number of slides would not fit into the time slot, but she even managed to give a demo of her work, which was well received. The dwatch tool she wrote should make it easy for people to get started with DTrace without learning too much about the syntax at first. The visualizations were certainly nice to see, combining different tools together in a new way.
ZFS BoF, lead by Allan and Matthew Ahrens
SSH Key Management by Michael W. Lucas. Yet another great talk where I learned a lot. I did not get to the SSH CA chapter in the new SSH Mastery book, so this was a good way to wet my appetite for it and motivated me to look into creating one for the cluster that I’m managing.
The rest of the day was spent at the FreeBSD Foundation table, talking to various folks. Then, Allan and I had an interview with Kirk McKusick for National FreeBSD Day, then we had a core meeting, followed by a core dinner.

Digital Ocean

###NomadBSD 1.1-RC1 Released

The first – and hopefully final – release candidate of NomadBSD 1.1 is available!

##News Roundup
###LDAP client added to -current

CVSROOT:    /cvs
Module name:    src
Changes by: reyk@cvs.openbsd.org    2018/06/13 09:45:58

Log message:
    Import ldap(1), a simple ldap search client.
    We have an ldapd(8) server and ypldap in base, so it makes sense to
    have a simple LDAP client without depending on the OpenLDAP package.
    This tool can be used in an ssh(1) AuthorizedKeysCommand script.
    
    With feedback from many including millert@ schwarze@ gilles@ dlg@ jsing@
    
    OK deraadt@
    
    Status:
    
    Vendor Tag: reyk
    Release Tags:   ldap_20180613
    
    N src/usr.bin/ldap/Makefile
    N src/usr.bin/ldap/aldap.c
    N src/usr.bin/ldap/aldap.h
    N src/usr.bin/ldap/ber.c
    N src/usr.bin/ldap/ber.h
    N src/usr.bin/ldap/ldap.1
    N src/usr.bin/ldap/ldapclient.c
    N src/usr.bin/ldap/log.c
    N src/usr.bin/ldap/log.h
    
    No conflicts created by this import

###Intel® FPU Speculation Vulnerability Confirmed

Summary:

System software may utilize the Lazy FP state restore technique to delay the restoring of state until an instruction operating on that state is actually executed by the new process. Systems using Intel® Core-based microprocessors may potentially allow a local process to infer data utilizing Lazy FP state restore from another process through a speculative execution side channel.

Description:

System software may opt to utilize Lazy FP state restore instead of eager save and restore of the state upon a context switch. Lazy restored states are potentially vulnerable to exploits where one process may infer register values of other processes through a speculative execution side channel that infers their value.

    ·    CVSS - 4.3 Medium CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Affected Products:

Intel® Core-based microprocessors.

Recommendations:

If an XSAVE-enabled feature is disabled, then we recommend either its state component bitmap in the extended control register (XCR0) is set to 0 (e.g. XCR0[bit 2]=0 for AVX, XCR0[bits 7:5]=0 for AVX512) or the corresponding register states of the feature should be cleared prior to being disabled. Also for relevant states (e.g. x87, SSE, AVX, etc.), Intel recommends system software developers utilize Eager FP state restore in lieu of Lazy FP state restore.

Acknowledgements:

Intel would like to thank Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology GmbH (https://www.cyberus-technology.de/), Zdenek Sojka from SYSGO AG (https://sysgo.com), and Colin Percival for reporting this issue and working with us on coordinated disclosure.

iXsystems
iX Ad Spot
###iX Systems – BSDCan 2018 Recap

###FreeBSD gets pNFS support

Merge the pNFS server code from projects/pnfs-planb-server into head.

This code merge adds a pNFS service to the NFSv4.1 server. Although it is
a large commit it should not affect behaviour for a non-pNFS NFS server.
Some documentation on how this works can be found at:
Merge the pN https://people.freebsd.org/~rmacklem/pnfs-planb-setup.txt
and will hopefully be turned into a proper document soon.
This is a merge of the kernel code. Userland and man page changes will
come soon, once the dust settles on this merge.
It has passed a "make universe", so I hope it will not cause build problems.
It also adds NFSv4.1 server support for the "current stateid".

Here is a brief overview of the pNFS service:
A pNFS service separates the Read/Write operations from all the other NFSv4.1
Metadata operations. It is hoped that this separation allows a pNFS service
to be configured that exceeds the limits of a single NFS server for either
storage capacity and/or I/O bandwidth.
It is possible to configure mirroring within the data servers (DSs) so that
the data storage file for an MDS file will be mirrored on two or more of
the DSs.
When this is used, failure of a DS will not stop the pNFS service and a
failed DS can be recovered once repaired while the pNFS service continues
to operate.  Although two way mirroring would be the norm, it is possible
to set a mirroring level of up to four or the number of DSs, whichever is
less.
The Metadata server will always be a single point of failure,
just as a single NFS server is.

A Plan B pNFS service consists of a single MetaData Server (MDS) and K
Data Servers (DS), all of which are recent FreeBSD systems.
Clients will mount the MDS as they would a single NFS server.
When files are created, the MDS creates a file tree identical to what a
single NFS server creates, except that all the regular (VREG) files will
be empty. As such, if you look at the exported tree on the MDS directly
on the MDS server (not via an NFS mount), the files will all be of size 0.
Each of these files will also have two extended attributes in the system
attribute name space:
pnfsd.dsfile - This extended attrbute stores the information that
    the MDS needs to find the data storage file(s) on DS(s) for this file.
pnfsd.dsattr - This extended attribute stores the Size, AccessTime, ModifyTime
    and Change attributes for the file, so that the MDS doesn't need to
    acquire the attributes from the DS for every Getattr operation.
For each regular (VREG) file, the MDS creates a data storage file on one
(or more if mirroring is enabled) of the DSs in one of the "dsNN"
subdirectories.  The name of this file is the file handle
of the file on the MDS in hexadecimal so that the name is unique.
The DSs use subdirectories named "ds0" to "dsN" so that no one directory
gets too large. The value of "N" is set via the sysctl vfs.nfsd.dsdirsize
on the MDS, with the default being 20.
For production servers that will store a lot of files, this value should
probably be much larger.
It can be increased when the "nfsd" daemon is not running on the MDS,
once the "dsK" directories are created.

For pNFS aware NFSv4.1 clients, the FreeBSD server will return two pieces
of information to the client that allows it to do I/O directly to the DS.
DeviceInfo - This is relatively static information that defines what a DS
             is. The critical bits of information returned by the FreeBSD
             server is the IP address of the DS and, for the Flexible
             File layout, that NFSv4.1 is to be used and that it is
             "tightly coupled".
             There is a "deviceid" which identifies the DeviceInfo.
Layout     - This is per file and can be recalled by the server when it
             is no longer valid. For the FreeBSD server, there is support
             for two types of layout, call File and Flexible File layout.
             Both allow the client to do I/O on the DS via NFSv4.1 I/O
             operations. The Flexible File layout is a more recent variant
             that allows specification of mirrors, where the client is
             expected to do writes to all mirrors to maintain them in a
             consistent state. The Flexible File layout also allows the
             client to report I/O errors for a DS back to the MDS.
             The Flexible File layout supports two variants referred to as
             "tightly coupled" vs "loosely coupled". The FreeBSD server always
             uses the "tightly coupled" variant where the client uses the
             same credentials to do I/O on the DS as it would on the MDS.
             For the "loosely coupled" variant, the layout specifies a
             synthetic user/group that the client uses to do I/O on the DS.
             The FreeBSD server does not do striping and always returns
             layouts for the entire file. The critical information in a layout
             is Read vs Read/Writea and DeviceID(s) that identify which
             DS(s) the data is stored on.

At this time, the MDS generates File Layout layouts to NFSv4.1 clients
that know how to do pNFS for the non-mirrored DS case unless the sysctl
vfs.nfsd.default_flexfile is set non-zero, in which case Flexible File
layouts are generated.
The mirrored DS configuration always generates Flexible File layouts.
For NFS clients that do not support NFSv4.1 pNFS, all I/O operations
are done against the MDS which acts as a proxy for the appropriate DS(s).
When the MDS receives an I/O RPC, it will do the RPC on the DS as a proxy.
If the DS is on the same machine, the MDS/DS will do the RPC on the DS as
a proxy and so on, until the machine runs out of some resource, such as
session slots or mbufs.
As such, DSs must be separate systems from the MDS.

***

###[What does {some strange unix command name} stand for?](https://www.unixguide.net/unix/faq/1.3.shtml)

+ awk = "Aho Weinberger and Kernighan" 
+ grep = "Global Regular Expression Print" 
+ fgrep = "Fixed GREP". 
+ egrep = "Extended GREP" 
+ cat = "CATenate" 
+ gecos = "General Electric Comprehensive Operating Supervisor" 
+ nroff = "New ROFF" 
+ troff = "Typesetter new ROFF" 
+ tee = T 
+ bss = "Block Started by Symbol
+ biff = "BIFF" 
+ rc (as in ".cshrc" or "/etc/rc") = "RunCom" 
+ Don Libes' book "Life with Unix" contains lots more of these 
tidbits. 
***

##Beastie Bits
+ [RetroBSD: Unix for microcontrollers](https://retrobsd.org/wiki/doku.php)
+ [On the matter of OpenBSD breaking embargos (KRACK)](https://marc.info/?l=openbsd-tech&m=152910536208954&w=2)
+ [Theo's Basement Computer Paradise (1998)](https://zeus.theos.com/deraadt/hosts.html)
+ [Airport Extreme runs NetBSD](https://jcs.org/2018/06/12/airport_ssh)
+ [What UNIX shell could have been](https://rain-1.github.io/shell-2.html)

***
Tarsnap ad
***

##Feedback/Questions
+ We need more feedback and questions. Please email feedback@bsdnow.tv 
+ Also, many of you owe us BSDCan trip reports! We have shared what our experience at BSDCan was like, but we want to hear about yours. What can we do better next year? What was it like being there for the first time?
+ [Jason writes in](https://slexy.org/view/s205jU58X2)
    + https://www.wheelsystems.com/en/products/wheel-fudo-psm/
+ [June 19th was National FreeBSD Day](https://twitter.com/search?src=typd&q=%23FreeBSDDay)
***

- Send questions, comments, show ideas/topics, or stories you want mentioned on the show to [feedback@bsdnow.tv](mailto:feedback@bsdnow.tv)
***