Re: svn commit: r338204 - in head: etc etc/defaults sbin/devfs
On Thu, Aug 23, 2018, at 8:34 AM, Rodney W. Grimes wrote:
> > On 8/22/18 8:37 PM, Mark Millard wrote:
> > > I'm just using this move as an example for some more
> > > general questions.
> > >
> > > After this change when I look at:
> > >
> > > https://www.freebsd.org/cgi/man.cgi?query=devfs.conf=0=5=FreeBSD+12-current=default=html
> > >
> > > I see in the man page:
> > >
> > > FILES
> > > /etc/devfs.conf
> > > /usr/share/examples/etc/devfs.conf
> > >
> > > So . . .
> > >
> > > Roughly when are the "FreeBSD+12-current" man pages going to
> > > track the moves? Once everything has been moved?
> > >
> > > Are the examples also going to be moved/reorganized? Similar
> > > timing question to the above (if yes).
> >
> > The installed location of the files doesn't change, only their location
> > in the source tree. It does seem that share/examples has not been
> > handled to date, as they probably belong in the same package as the thing
> > they are samples of.
Yes, that was an oversight on my part that I am looking into.
> > I really wish that the Makefiles were smart enough to use .PATH or
> > some such to reach over into ${SRCTOP}/etc to find the files without
> > requiring them to actually move in the tree since it's not very
> > intuitive where to find many of these files now. (And the source
> > locations are starting to no longer mimic the layout on the host,
> > such as syslog.d being "flattened".)
>
> I believe it would of been possible, and not too much work,
> to leave all of it in ${SRCTOP}/etc by adding CONF-foo:
> targets that did the write things with variable settings
> and calling make ${SRCTOP}/etc/Makefile CONF-foo from the
> respective utilities.
But we never had all files in etc/ consistently anyways, so this is kind of a
moot point..
> I also believe that certain of these files just belong in
> a pkg called etc, these are the files that are always needed
> for a functional system, like services (ok, if you remove
> all networking you do not need that one, but it clearly
> does not belong with the option services_mkdb that simply
> makes /var/db/services.db.) Anyway, any files that got
> moved into libc are always going to be installed, correct?
> I do not believe you can make a running system without
> libc, so why move them? Do we support a static link anymore?
It makes little sense to have an etc pkg and for people building embedded
systems or thousands of jails.. Not to mention the people that will pkg delete
FreeBSD-sendmail\* and want to see all the sendmail related configs gone as
well.
> But when brd was asked what his plans where we got very
> little feedback, and now, what I feel is a poorly thought
> out implementation.
I held a session at BSDCan and in fact at every DevSummit I have been to
(AsiaBSDCon, BSDCam, EuroBSDCon, vBSDCon, ..). Later I was asked to post on
-arch and I did.. With very little feedback and none from you..
Regards,
Brad Davis
___
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: svn commit: r338204 - in head: etc etc/defaults sbin/devfs
> On 8/22/18 8:37 PM, Mark Millard wrote:
> > I'm just using this move as an example for some more
> > general questions.
> >
> > After this change when I look at:
> >
> > https://www.freebsd.org/cgi/man.cgi?query=devfs.conf=0=5=FreeBSD+12-current=default=html
> >
> > I see in the man page:
> >
> > FILES
> > /etc/devfs.conf
> > /usr/share/examples/etc/devfs.conf
> >
> > So . . .
> >
> > Roughly when are the "FreeBSD+12-current" man pages going to
> > track the moves? Once everything has been moved?
> >
> > Are the examples also going to be moved/reorganized? Similar
> > timing question to the above (if yes).
>
> The installed location of the files doesn't change, only their location
> in the source tree. It does seem that share/examples has not been
> handled to date, as they probably belong in the same package as the thing
> they are samples of.
>
> I really wish that the Makefiles were smart enough to use .PATH or
> some such to reach over into ${SRCTOP}/etc to find the files without
> requiring them to actually move in the tree since it's not very
> intuitive where to find many of these files now. (And the source
> locations are starting to no longer mimic the layout on the host,
> such as syslog.d being "flattened".)
I believe it would of been possible, and not too much work,
to leave all of it in ${SRCTOP}/etc by adding CONF-foo:
targets that did the write things with variable settings
and calling make ${SRCTOP}/etc/Makefile CONF-foo from the
respective utilities.
I also believe that certain of these files just belong in
a pkg called etc, these are the files that are always needed
for a functional system, like services (ok, if you remove
all networking you do not need that one, but it clearly
does not belong with the option services_mkdb that simply
makes /var/db/services.db.) Anyway, any files that got
moved into libc are always going to be installed, correct?
I do not believe you can make a running system without
libc, so why move them? Do we support a static link anymore?
But when brd was asked what his plans where we got very
little feedback, and now, what I feel is a poorly thought
out implementation.
By paint is blue.. always blue...
--
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"
Re: CFT: TRIM Consolodation on UFS/FFS filesystems
On 8/23/18 5:38 AM, bob prohaska wrote: On Tue, Aug 21, 2018 at 06:47:19PM -0700, Mark Millard wrote: I've used a SSD both directly via SATA and via a USB enclosure, the same partitions/file systems across the uses. Only when it was SATA-style-use did TRIM work. This is likely the key to my question. If USB blocks the TRIM service the behavior of the device doesn't matter. This is kind of off-topic in this thread about UFS, but if you investigate TRIM on USB enclosures: Some of them advertise TRIM support, for example Startech SM21BMU31C3 (based on Asmedia ASM1351 USB 3.1 Gen 2 chipset), but that is not the whole story. Using the UASP protocol, they pass on the ata trim command, which is used by Windows for NTFS trim support, but they do not pass the SCSI UNMAP command, which is used by Linux. Sorry, I have not yet tested this on FreeBSD, but on Linux, security erase of the entire SSD works with the enclosure I have just mentioned, whereas trimming of a filesystem (fstrim) does not work. I have had exactly one enclosure that offered trimming on filesystems on Linux: I have bought it on Ebay directly from China and I think it is based on JMicron JMS567 USB 3.0 chipset. I have not found an mSATA enclosure from any vendor in Europe that has this chipset. Of course, having the right chipset is not enough, either, the firmware also has to support it. Please, correct me if I am wrong, but I think FreeBSD does not implement UASP, yet. Hence, I doubt there will be any kind of trim support for any USB-SATA bridge on FreeBSD and even security erase will probably not be passed on. Cheers, Jan Henrik ___ 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: Native Encryption for ZFS on FreeBSD CFT
> That doesn't answer the question about what happens when dedup is turned off. > In that case, is the HMAC still used as the IV? If so, then watermarking > attacks are still possible. Quoting the comment from the code above: "For non-dedup blocks we derive the IV randomly". When dedup is enabled, we do leak this information, but the dedup table already leaks that information anyway. The dedup table needs to be in plaintext so that we can repair it even when keys are not loaded. This is a known and documented trade off of using encryption + dedup. > Only encrypting L0 blocks also leaks a lot of information. That means that, > if encryption is set to anything but "off", watermarking attacks will still > be possible based on the size and sparsity of a file. Because I believe that > with any encryption mode, ZFS turns continuous runs of zeros into holes First of all, with encryption=off, watermarking attacks are really quite easy :). The information that can be gained about a file from ZFS by looking at the raw disk are: 1) The size of the file (rounded up to the nearest sector size): Almost all applications that encrypt data will leak the approximate size of the protected payload. 2) The locations of holes within a file: ZFS does not turn runs of zeros into holes if you have compression off. However, data that is never written is maintained as a hole (ie if you never write any data to block 3 of a file). You are correct that technically this is a small leak of information, but we decided while designing the encryption scheme that the performance and space savings are worth it here. Is this enough information to be an attack vector? I would argue not, but if you are paranoid you could always turn compression off and fill in all the holes of your files with zeros. 3) If dedup is on, you can see which blocks have deduped against other blocks within a clone family. Encrypted dedup only works within applications that share the same master encryption key, which is essentially just snapshots and clones of snapshots. You cannot write data to one encrypted dataset and analyze the dedup tables to see i the data you wrote deduped against another dataset's data. 4) If compression + encryption is on a CRIME attack is possible, but in almost every scenario this attack is impractical. It requires the filesystem to have the key loaded, an application that appends a secret to the data controlled by an attacker, the attacker requires root access to the running system (to read the raw disk without rebooting and unloading the encryption key), and the attacker needs to be able to do many iterations of writing this attacker + secret data to disk and checking the resulting plaintext. During the implementation of native ZFS encryption we evaluated these and came to the conclusion that the security risks here are easily outweighed by the usability and performance benefits. If you have any further questions about the design, feel free to email me again or take a look at the (largely diagram based) docs on the implementation: https://docs.google.com/presentation/d/1km-z3MVNHYwlQLY6yEC3iq-TD05eredH9Ih4umGdkJw/edit?usp=sharing On Wed, Aug 22, 2018 at 6:39 PM Matthew Macy wrote: > > Hi Thomas, > > Alan believes that, even with dedup disabled, the ZFS native encryption > support is vulnerable to watermarking attacks. I don't have enough exposure > to crypto to pass any judgement and was hoping that you'd share your point of > view. Thanks in advance. > > -M > > > > On Wed, Aug 22, 2018 at 12:42 PM Alan Somers wrote: >> >> Only encrypting L0 blocks also leaks a lot of information. That means that, >> if encryption is set to anything but "off", watermarking attacks will still >> be possible based on the size and sparsity of a file. Because I believe >> that with any encryption mode, ZFS turns continuous runs of zeros into >> holes. And I don't see anything in zio_crypt.c that addresses that. >> -Alan >> >> On Wed, Aug 22, 2018 at 1:23 PM Sean Fagan wrote: >>> >>> On Aug 22, 2018, at 12:20 PM, Alan Somers wrote: >>> > ]That doesn't answer the question about what happens when dedup is turned >>> > off. In that case, is the HMAC still used as the IV? If so, then >>> > watermarking attacks are still possible. If ZFS switches to a random IV >>> > when dedup is off, then it would probably be ok. >>> >>> From the same file: >>> >>> * Initialization Vector (IV): >>> * An initialization vector for the encryption algorithms. This is used to >>> * "tweak" the encryption algorithms so that two blocks of the same data are >>> * encrypted into different ciphertext outputs, thus obfuscating block >>> patterns. >>> * The supported encryption modes (AES-GCM and AES-CCM) require that an IV >>> is >>> * never reused with the same encryption key. This value is stored >>> unencrypted >>> * and must simply be provided to the decryption function. We use a 96 bit >>> IV >>> * (as recommended by NIST) for all block
Re: Loading carp module crash i386 (12-ALPHA2), seems VNET related
On Wed, Aug 22, 2018 at 10:38 PM Olivier Cochard-Labbé
wrote:
> On Tue, Aug 21, 2018 at 3:15 PM Bjoern A. Zeeb <
> bzeeb-li...@lists.zabbadoz.net> wrote:
>
>> On 21 Aug 2018, at 12:31, Olivier Cochard-Labbé wrote:
>>
>>
>> Do you have a last-good revision?
>>
>>
>> Hi,
>
>
> Since VIMAGE was enabled by default on GENERIC
>
> (r327969).
>
> So perhaps VIMAGE+carp never works on i386 ?
>
>
My answer was not clear:
- last good revision: r327968
- broken since: r327969 ("Enable VIMAGE in i386 GENERIC")
___
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: svn commit: r338204 - in head: etc etc/defaults sbin/devfs
On 8/22/18 8:37 PM, Mark Millard wrote:
> I'm just using this move as an example for some more
> general questions.
>
> After this change when I look at:
>
> https://www.freebsd.org/cgi/man.cgi?query=devfs.conf=0=5=FreeBSD+12-current=default=html
>
> I see in the man page:
>
> FILES
> /etc/devfs.conf
> /usr/share/examples/etc/devfs.conf
>
> So . . .
>
> Roughly when are the "FreeBSD+12-current" man pages going to
> track the moves? Once everything has been moved?
>
> Are the examples also going to be moved/reorganized? Similar
> timing question to the above (if yes).
The installed location of the files doesn't change, only their location
in the source tree. It does seem that share/examples has not been
handled to date, as they probably belong in the same package as the thing
they are samples of.
I really wish that the Makefiles were smart enough to use .PATH or
some such to reach over into ${SRCTOP}/etc to find the files without
requiring them to actually move in the tree since it's not very
intuitive where to find many of these files now. (And the source
locations are starting to no longer mimic the layout on the host,
such as syslog.d being "flattened".)
--
John Baldwin
___
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"
