Re: ZFS v28 is ready for wider testing.
Wiadomość napisana przez Anonymous w dniu 2010-09-05, o godz. 20:56: > Pawel Jakub Dawidek writes: > >> Hello. >> >> I'd like to give you ZFS v28 for testing. If you are neither brave nor >> mad, you can stop here. > [...] >> So test whatever you can and report back. Look for regressions, > >> strange behaviour, > > I wonder why new files tend to have different ACLs than old ones. > > $ ls -lh foo > -rw-r--r-- 1 holo holo17K Aug 19 11:43 foo > $ cp foo bar > $ ls -lh bar > -rw-r--r--+ 1 holo holo17K Sep 5 21:20 bar > $ getfacl foo bar > # file: foo > # owner: holo > # group: holo > owner@:--x---:--:deny > owner@:rw-p---A-W-Co-:--:allow > group@:-wxp--:--:deny > group@:r-:--:allow > everyone@:-wxp---A-W-Co-:--:deny > everyone@:r-a-R-c--s:--:allow See http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbaum. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: One-shot-oriented event timers management
On 2010-Sep-02 13:08:25 +0200, Ian FREISLICH wrote: >It's a compaq mini-110: >CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) Hmmm... I have a N270 in an Aspire One. >dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11000 >933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250 100/625 That's rather more frequencies than I would expect. Do you have acpi_throttle enabled? If so, you might like to disable it - it's not particularly effective (and caused regular hands on my AMD Turion laptop). >dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 I'm also intrigued as to where C4 comes from. I have: dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 -- Peter Jeremy pgpvhNJEeD5Wc.pgp Description: PGP signature
Re: One-shot-oriented event timers management
Peter Jeremy wrote: > On 2010-Sep-02 13:08:25 +0200, Ian FREISLICH wrote: > >It's a compaq mini-110: > >CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) > > Hmmm... I have a N270 in an Aspire One. > > >dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11= > 000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250= > 100/625 > > That's rather more frequencies than I would expect. Do you have > acpi_throttle enabled? If so, you might like to disable it - it's not > particularly effective (and caused regular hands on my AMD Turion > laptop). No acpi_throttle in my sysctl mib: [mini] ~ $ sysctl -a |grep acpi_throttle [mini] ~ $ I can set all of these frequencies. They don't really save any power, they just make the system slow. > >dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 > > I'm also intrigued as to where C4 comes from. I have: > > dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 And I can set C4. But the acpi battery method can't determine the discharge rate so I don't know if it actually reduces power either. [mini] ~ $ acpiconf -i 0 Design capacity:5100 mAh Last full capacity: 4952 mAh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn):496 mAh Capacity (low): 347 mAh Low/warn granularity: 0 mAh Warn/full granularity: 100 mAh Model number: Primary Serial number: Type: LION OEM info: Hewlett-Packard State: discharging Remaining capacity: 100% Remaining time: unknown Present rate: unknown Voltage:12363 mV It might have something to do with the hardware verdor or bios vendor. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On Mon, 6 Sep 2010, Gleb Kurtsou wrote: I would like to ask for feedback on a kernel level stacked cryptographic filesystem. It has started as Summer Of Code'2009 project and matured a lot since then. I've recently added support for sparse files and switched to XTS encryption mode. I've been using it to encrypt my home directory for almost a year already, and use fsx, dbench and blogbench for testing. So it should be fairly stable. Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and 8-STABLE supported. Please email me separately if you're willing to help testing on big endian machine, XTS code doesn't look endian correct. At this point all of the project goals complete and I'd like it to get wider coverage in terms of tests and reviews and hope to see it commited to HEAD soon. Hi Gleb: This sounds like really exciting work! Do you have much in the way of formal documentation of your crypto design at this point? I'd like to point some of the local crypto gurus at Cambridge at it to do some analysis of your approach. However, as they rightly point out, reverse engineering crypto from code is rather a high barrier of entry for a crypto review, so detailed documentation of the approach and a formal format description would be much prefered :-). Thanks, Robert Installation instructions: 1a. Clone git repository: # git clone git://github.com/glk/pefs.git pefs # cd pefs 1b. Or download latest snapshot from github: http://github.com/glk/pefs/archives/master 2. Build and install: # make obj all # make install 3. Mount pefs filesystem: # pefs mount ~/Private ~/Private 4. Enter passphrase: # pefs addkey ~/Private 5. Test it and report back. There is also a man page available. 6. Example how to save your key in keychain database. pefs has to be mounted and key specified to make fs writable, create keychain with single entry (keychain -Z option): # pefs addchain -Z ~/Private Don't encrypt .pefs.db: # mv ~/Private/.pefs.db /tmp # umount ~/Private # mv /tmp/.pefs.db ~/Private # pefs mount ~/Private ~/Private Use -c option to verify key is in database # pefs addkey -c ~/Private 7. You can setup pam_pefs (not compiled by default) to add key to home directory and authenticate against keychain database on login, e.g. by adding the following line to /etc/pam.d/system before pam_unix.so: authsufficient pam_pefs.so try_first_pass The following is a list of its most important features: * Kernel level file system, no user level daemons needed. Transparently runs on top of existing file systems. * Random per file tweak value used for encryption, which guaranties different cipher texts for the same encrypted files. * Saves metadata only in encrypted file name, but not in file itself. * Supports arbitrary number of keys per file system, default directory key, mixing files encrypted with different keys in same directory. * Allows defining key chains, can be used to add/delete several keys by specifying only master key. * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, PKCS#5v2 and HKDF for key generation. Github repository: http://github.com/glk/pefs More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs Thanks, Gleb. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On 09/06/10 20:38, Gleb Kurtsou wrote: Hello, I would like to ask for feedback on a kernel level stacked cryptographic filesystem. It has started as Summer Of Code'2009 project and matured a lot since then. I've recently added support for sparse files and switched to XTS encryption mode. I've tried it and so far it works :) 3. Mount pefs filesystem: # pefs mount ~/Private ~/Private I see you've used the same example in the man page. Maybe it would be better for educational purposes to use two separate directories, e.g. ~/Private and ~/Decrypted to avoid confusion by new users (of course not all examples need to use this). 6. Example how to save your key in keychain database. This is probably in line with what rwatson said (and would be covered by the same document): can you describe what keychains actually do? 7. You can setup pam_pefs (not compiled by default) to add key to home directory and authenticate against keychain database on login, e.g. by adding the following line to /etc/pam.d/system before pam_unix.so: authsufficient pam_pefs.so try_first_pass So, this would bypass passwd and let the user in if his password authenticates against the "keychain database" in his home directory? Will it automagically pefs-mount his home directory? * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, PKCS#5v2 and HKDF for key generation. I do have an request: since you are already using kernel crypto support, it would be simple to just throw Blowfish in :) If for nothing else, consider it a gift to those who are fond of Blowfish's large key sizes (upto 448 bits). Actually, it would probably be seen as a reflection of consistency to implement the same algorithms that geli(8) implements. geli doesn't implement XTS yet - if your XTS code proves to be stable it would be a good thing to include it as standard and then use it from geli. I see you've copied SHA2 code to the pefs code. What is wrong with just using the kernel's SHA2 implementation? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On 09/06/10 20:38, Gleb Kurtsou wrote: Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and 8-STABLE supported. You probably didn't test it, but I've tried pefs on top of ext2fs (I use ext2fs to share data between OSes) and it quickly panicked. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On (07/09/2010 14:28), Robert Watson wrote: > On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > > > I would like to ask for feedback on a kernel level stacked cryptographic > > filesystem. It has started as Summer Of Code'2009 project and matured a lot > > since then. I've recently added support for sparse files and switched to > > XTS > > encryption mode. > > > > I've been using it to encrypt my home directory for almost a year already, > > and use fsx, dbench and blogbench for testing. So it should be fairly > > stable. > > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > > 8-STABLE supported. > > > > Please email me separately if you're willing to help testing on big endian > > machine, XTS code doesn't look endian correct. > > > > At this point all of the project goals complete and I'd like it to get > > wider > > coverage in terms of tests and reviews and hope to see it commited to HEAD > > soon. > > Hi Gleb: > > This sounds like really exciting work! Do you have much in the way of formal > documentation of your crypto design at this point? I'd like to point some of > the local crypto gurus at Cambridge at it to do some analysis of your > approach. However, as they rightly point out, reverse engineering crypto > from > code is rather a high barrier of entry for a crypto review, so detailed > documentation of the approach and a formal format description would be much > prefered :-). Hello Robert, I've updated my older blog post on pefs crypto design, it's not formal but hope it helps. If there is anything else you might need, I'd be happy to help: http://glebkurtsou.blogspot.com/2009/09/pefs-crypto-primitives.html Thanks, Gleb > > Thanks, > > Robert > > > > > > > > Installation instructions: > > > > 1a. Clone git repository: > > # git clone git://github.com/glk/pefs.git pefs > > # cd pefs > > > > 1b. Or download latest snapshot from github: > > http://github.com/glk/pefs/archives/master > > > > 2. Build and install: > > # make obj all > > # make install > > > > 3. Mount pefs filesystem: > > # pefs mount ~/Private ~/Private > > > > 4. Enter passphrase: > > # pefs addkey ~/Private > > > > 5. Test it and report back. There is also a man page available. > > > > 6. Example how to save your key in keychain database. > > > > pefs has to be mounted and key specified to make fs writable, create > > keychain with single entry (keychain -Z option): > > # pefs addchain -Z ~/Private > > Don't encrypt .pefs.db: > > # mv ~/Private/.pefs.db /tmp > > # umount ~/Private > > # mv /tmp/.pefs.db ~/Private > > # pefs mount ~/Private ~/Private > > Use -c option to verify key is in database > > # pefs addkey -c ~/Private > > > > 7. You can setup pam_pefs (not compiled by default) to add key to home > > directory and authenticate against keychain database on login, e.g. by > > adding the following line to /etc/pam.d/system before pam_unix.so: > > > > authsufficient pam_pefs.so try_first_pass > > > > > > The following is a list of its most important features: > > > > * Kernel level file system, no user level daemons needed. > >Transparently runs on top of existing file systems. > > * Random per file tweak value used for encryption, which guaranties > >different cipher texts for the same encrypted files. > > * Saves metadata only in encrypted file name, but not in file itself. > > * Supports arbitrary number of keys per file system, default directory > >key, mixing files encrypted with different keys in same directory. > > * Allows defining key chains, can be used to add/delete several keys > >by specifying only master key. > > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > >PKCS#5v2 and HKDF for key generation. > > > > > > Github repository: http://github.com/glk/pefs > > > > More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs > > > > Thanks, > > Gleb. > > > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Use MACHINE_ARCH for boot loader
Dnia 27.08.2010 John Baldwin napisał/a: > On Thursday, August 26, 2010 8:50:01 pm Xin LI wrote: >> Hi, >> >> The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and >> FreeBSD/amd64 on amd64. >> >> Comments welcome! I'll commit it in by the weekend if there is no >> objection on this. > > As others have noted, the 'x86' is on purpose, and I would rather it continue > to do that rather than this change. Not sure about it, the loader and boot block are 32-bit code, aren't they? (That actually made me to hack some patches to make ficl 64-bit, but that's another story). So I think i386 is better designation for pure 32-bit code I think. -- << Marcin Cieslak // sa...@saper.info >> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS v28 is ready for wider testing.
The atomic.h patch does not apply anymore and buildworld fails without it. At work so can't post results On Sep 6, 2010 6:09 PM, "Martin Matuska" wrote: > To avoid user and developer confusion, my patch was just a chain of > pjd's patch + pjd's atomic.h fix + my v19 boot patch. > > I have removed (= split) the chained patch in my posting and altered my > blog article with updated build instructions that actually just > summarize what has been written on this list. > > Thanks for understanding! > > Dňa 6. 9. 2010 13:50, Martin Matuska wrote / napísal(a): >> Hi everyone, >> I have put together a slightly improved patch of Pawel's that compiles >> correctly and supports booting from ZFS v19 pools. >> >> You can download the patch here: >> http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch >> >> For users who don't want to compile I have created a mfsBSD ISO image >> with a zfs-only install of 9-CURRENT-amd64: >> http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso >> >> You can read more about all of this here: >> http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html >> >> More information about ZFS pool and filesystem versions: >> http://blog.vx.sk/archives/4-ZFS-pool-and-filesystem-versions.html >> >> Thanks to everybody participating in testing, >> mm > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: One-shot-oriented event timers management
> From: Ian FREISLICH > Date: Tue, 07 Sep 2010 13:40:33 +0200 > Sender: owner-freebsd-curr...@freebsd.org > > Peter Jeremy wrote: > > On 2010-Sep-02 13:08:25 +0200, Ian FREISLICH wrote: > > >It's a compaq mini-110: > > >CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) > > > > Hmmm... I have a N270 in an Aspire One. > > > > >dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11= > > 000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250= > > 100/625 > > > > That's rather more frequencies than I would expect. Do you have > > acpi_throttle enabled? If so, you might like to disable it - it's not > > particularly effective (and caused regular hands on my AMD Turion > > laptop). > > No acpi_throttle in my sysctl mib: > [mini] ~ $ sysctl -a |grep acpi_throttle > [mini] ~ $ > > I can set all of these frequencies. They don't really save any > power, they just make the system slow. > > > >dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 > > > > I'm also intrigued as to where C4 comes from. I have: > > > > dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > And I can set C4. But the acpi battery method can't determine the > discharge rate so I don't know if it actually reduces power either. > > [mini] ~ $ acpiconf -i 0 > Design capacity:5100 mAh > Last full capacity: 4952 mAh > Technology: secondary (rechargeable) > Design voltage: 10800 mV > Capacity (warn):496 mAh > Capacity (low): 347 mAh > Low/warn granularity: 0 mAh > Warn/full granularity: 100 mAh > Model number: Primary > Serial number: > Type: LION > OEM info: Hewlett-Packard > State: discharging > Remaining capacity: 100% > Remaining time: unknown > Present rate: unknown > Voltage:12363 mV > > It might have something to do with the hardware verdor or bios vendor. Throttling is currently (unfortunately) on by default. You need to turn it off by adding: hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" to your /boot/loader.conf file. You really only want EST or equivalent. I'd love to see throttling/TCC removed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pam_pefs setup (Re: RFC: pefs - stacked cryptographic filesystem)
On (07/09/2010 16:32), Thomas Vogt wrote: [...] > > I've an issue with pam_pefs: > > ===> lib/libpam/modules/pam_pefs (install) > install -C -o root -g wheel -m 444 libpam_pefs.a /usr/lib > install -C -o root -g wheel -m 444 libpam_pefs_p.a /usr/lib > install -o root -g wheel -m 444 pam_pefs.8.gz /usr/share/man/man8 > > I do not see any pam_pefs.so which makes login not possible if > pam.d/system is modified as mentioned in your description: > > auth sufficient pam_pefs.so try_first_pass Sorry, I don't quite understand you here. Don't hesitate contacting me again if didn't understand you correctly. I've also missed one more line, which actually adds the key: session optionalpam_pefs.so Setup I've posted makes possible to login using pefs key or standard pam_unix.so password. Here is my /etc/pam.d/system file: # auth authsufficient pam_opie.so no_warn no_fake_prompts authrequisite pam_opieaccess.so no_warn allow_local authsufficient pam_pefs.so try_first_pass authrequiredpam_unix.so no_warn try_first_pass nullok # account account requiredpam_login_access.so account requiredpam_unix.so # session session optionalpam_pefs.so session requiredpam_lastlog.so no_fail # password passwordrequiredpam_unix.so no_warn try_first_pass I have "stronger" password for pefs, while traditional password is "weaker" and easier to type. I use pefs password to login only the first time and add key my home directory. Please note that your home directory has to be mounted, I mount it in /etc/rc.local, but don't add any keys. pam_pefs adds the key. Also note that it has to be exactly your home directory (/home/gleb in my case), to prevent possible attacks. And keychain database has to be created, so that pam_pefs knows how to verify the key. Details on how to create it available in my original email. That's rather inconvenient procedure, but you need to do it just once, it's so complicated because pefs is read-only if no key specified, but database should not be encrypted to make it accessible by pam_pefs: > 3. Mount pefs filesystem: > # pefs mount /home/ME /home/ME > > 4. Enter passphrase: > # pefs addkey /home/ME > > # pefs addchain -Z /home/ME > Don't encrypt .pefs.db: > # mv ~/Private/.pefs.db /tmp > # umount ~/Private > # mv /tmp/.pefs.db /home/ME > # pefs mount /home/ME /home/ME > Use -c option to verify key is in database > # pefs addkey -c /home/ME I'll try to make it easier, I didn't actually expect anyone to try it, and just mentioned it without providing instructions not to write long setup procedure. You can also try adding debug option to pam_pefs.so config if something goes wrong. I don't remember details but pefs/Makefile contains the following comment by me: # Should be built from sources tree # SUBDIR+= lib/libpam/modules/pam_pefs But if you are able to build it, it should be fine. Thanks, Gleb. > > Regards, > Thomas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a lot > since then. I've recently added support for sparse files and switched to XTS > encryption mode. > > I've been using it to encrypt my home directory for almost a year already, > and use fsx, dbench and blogbench for testing. So it should be fairly > stable. > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > 8-STABLE supported. > > Please email me separately if you're willing to help testing on big endian > machine, XTS code doesn't look endian correct. > > At this point all of the project goals complete and I'd like it to get wider > coverage in terms of tests and reviews and hope to see it commited to HEAD > soon. I've got to ask a probably dumb question...how is this better then geli encrypted objects? I've used them for sometime with excellent results. Or does it provide functionality that geli does not? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
Thanks to Peter Holm and Thomas Vogt for finding several bugs: * Compilation with DIAGNOSTIC option * Vnode reference and lock leak in pefs_rename() I've uploaded new version to test: http://github.com/downloads/glk/pefs/pefs-2010-09-07.tar.gz Github repository is also updated. Also note, that if you have extra debugging options like DEBUG_LOCKS in your kernel config pefs module has to be build with same options. I set KERNBUILDDIR to my kernel build directory to make it work: # uname -v FreeBSD 9.0-CURRENT #25 r212049+d758796: Tue Aug 31 22:09:45 EEST 2010 r...@tops:/usr/obj/freebsd-src/local/sys/TOPS # export KERNBUILDDIR=/usr/obj/freebsd-src/local/sys/TOPS # cd pefs/sys/modules/pefs # make clean # make && make install Thanks, Gleb. On (06/09/2010 21:38), Gleb Kurtsou wrote: > Hello, > > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a > lot since then. I've recently added support for sparse files and > switched to XTS encryption mode. > > I've been using it to encrypt my home directory for almost a year > already, and use fsx, dbench and blogbench for testing. So it should be > fairly stable. > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT > and 8-STABLE supported. > > Please email me separately if you're willing to help testing on big > endian machine, XTS code doesn't look endian correct. > > At this point all of the project goals complete and I'd like it to get > wider coverage in terms of tests and reviews and hope to see it commited > to HEAD soon. > > > Installation instructions: > > 1a. Clone git repository: > # git clone git://github.com/glk/pefs.git pefs > # cd pefs > > 1b. Or download latest snapshot from github: > http://github.com/glk/pefs/archives/master > > 2. Build and install: > # make obj all > # make install > > 3. Mount pefs filesystem: > # pefs mount ~/Private ~/Private > > 4. Enter passphrase: > # pefs addkey ~/Private > > 5. Test it and report back. There is also a man page available. > > 6. Example how to save your key in keychain database. > > pefs has to be mounted and key specified to make fs writable, create > keychain with single entry (keychain -Z option): > # pefs addchain -Z ~/Private > Don't encrypt .pefs.db: > # mv ~/Private/.pefs.db /tmp > # umount ~/Private > # mv /tmp/.pefs.db ~/Private > # pefs mount ~/Private ~/Private > Use -c option to verify key is in database > # pefs addkey -c ~/Private > > 7. You can setup pam_pefs (not compiled by default) to add key to home > directory and authenticate against keychain database on login, e.g. by > adding the following line to /etc/pam.d/system before pam_unix.so: > > auth sufficient pam_pefs.so try_first_pass > > > The following is a list of its most important features: > > * Kernel level file system, no user level daemons needed. > Transparently runs on top of existing file systems. > * Random per file tweak value used for encryption, which guaranties > different cipher texts for the same encrypted files. > * Saves metadata only in encrypted file name, but not in file itself. > * Supports arbitrary number of keys per file system, default directory > key, mixing files encrypted with different keys in same directory. > * Allows defining key chains, can be used to add/delete several keys > by specifying only master key. > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > PKCS#5v2 and HKDF for key generation. > > > Github repository: http://github.com/glk/pefs > > More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs > > Thanks, > Gleb. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bge(4) problem on sparc64 between r204991M and r212097
On Mon, Sep 06, 2010 at 02:04:37PM +0100, Anton Shterenlikht wrote: > On Fri, Sep 03, 2010 at 11:25:34AM -0700, Pyun YongHyeon wrote: > > On Fri, Sep 03, 2010 at 09:42:04AM +0100, Anton Shterenlikht wrote: > > > On Thu, Sep 02, 2010 at 11:36:03AM -0700, Pyun YongHyeon wrote: > > > > On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote: > > > > > On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote: > > > > > > I just updated world and kernel from r204991M to r212097 on sparc64. > > > > > > > > > > > > Now I can't ping my gateway. If I boot kernel.old, then > > > > > > the network works fine. As far as I could see mergemaster > > > > > > didn't update any network files. > > > > > > > > > > > > Please advise > > > > > > > > > > > > In the meantime I'll try intermediate revisions. > > > > > > > > > > I narrowed down the problem to between r212050 and r212080. > > > > > Will continue tomorrow. > > > > > > > > > > > > > Thanks for reporting. There was a big change in r212061, so try > > > > backing out that revision and see whether this makes differences > > > > or not. > > > > > > yes, r212061 is the offending revision, r212060 works fine. > > > Please let me know if you want any further information. > > > > Thanks for narrowing down guilty revision. Would you show me > > verbose boot message? > > First here's diff between dmesg outputs from r212060 and r212061: > [...] > This is full dmesg from r212060, below that is r212061. > [...] Thanks. It seems there was a bug in r212061. I committed fix for that in r212302. Would you give it try and let me know how it goes on your box? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On (07/09/2010 10:57), Kevin Oberman wrote: > On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > > > I would like to ask for feedback on a kernel level stacked cryptographic > > filesystem. It has started as Summer Of Code'2009 project and matured a lot > > since then. I've recently added support for sparse files and switched to > > XTS > > encryption mode. > > > > I've been using it to encrypt my home directory for almost a year already, > > and use fsx, dbench and blogbench for testing. So it should be fairly > > stable. > > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > > 8-STABLE supported. > > > > Please email me separately if you're willing to help testing on big endian > > machine, XTS code doesn't look endian correct. > > > > At this point all of the project goals complete and I'd like it to get > > wider > > coverage in terms of tests and reviews and hope to see it commited to HEAD > > soon. > > I've got to ask a probably dumb question...how is this better then geli > encrypted objects? I've used them for sometime with excellent results. > > Or does it provide functionality that geli does not? If geli works for you I'd suggest you continue using geli, geli design is order of magnitude simpler due to being block device but not a filesystem. Besides geli provides data authentication, which is very important, and something that can't be easily implemented in stacked filesystem. Pros of stacked filesystem approach: * You don't have to create separate filesystem (use separate partition), just encrypt part of existing filesystem * It's easier to create/manage snapshots/backups (imho) * Ability to use multiple keys, each directory can have its own key, files with different keys can be mixed in one directory, etc. You don't have to create another filesystem and claim that you don't know password for this one if you're asked to provide it, in case you have something to hide ;) Cons: * pefs maximum file name length is ~180 bytes, but not 255 * Stacked filesystem is likely to be slower due to extra overhead I don't really know what makes one better then other, it has only on thing in common - encryption - everything else is different. It depends on how you intend to use it. I was using geli myself, the only problem I had was that at some point I realized that initial partition size was too small :) But that more or less applies to both approaches. E.g. non-standard example where stacked filesystem may be preferred is to use it for encrypted crash dumps: if dump available on dumpdev mount /var/crash as pefs; ask user for password, or automatically add random one and let user to save it later after boot. Crash dumps are encrypted without extra cost of setting up partition, geli, etc. Thanks, Gleb. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: ober...@es.netPhone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On (07/09/2010 17:04), Ivan Voras wrote: > On 09/06/10 20:38, Gleb Kurtsou wrote: > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT > > and 8-STABLE supported. > > You probably didn't test it, but I've tried pefs on top of ext2fs (I use > ext2fs to share data between OSes) and it quickly panicked. I've tried it once, it paniced. msdosfs is known to work, but I'd say it shouldn't :) I'll look at it tomorrow, thanks for pointing it. If you are going to use it note that lower filesystem should be case sensitive, the same applies to ZFS. Thanks, Gleb. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: pefs - stacked cryptographic filesystem
On (07/09/2010 16:27), Ivan Voras wrote: > On 09/06/10 20:38, Gleb Kurtsou wrote: > > Hello, > > > > I would like to ask for feedback on a kernel level stacked cryptographic > > filesystem. It has started as Summer Of Code'2009 project and matured a > > lot since then. I've recently added support for sparse files and > > switched to XTS encryption mode. > > I've tried it and so far it works :) > > > 3. Mount pefs filesystem: > > # pefs mount ~/Private ~/Private > > I see you've used the same example in the man page. Maybe it would be > better for educational purposes to use two separate directories, e.g. > ~/Private and ~/Decrypted to avoid confusion by new users (of course not > all examples need to use this). Actually I've used the same directory solely for educational purposes -- there is just one directory, it's either encrypted or not. Users should think of it as of nullfs on steroids, but that doesn't sound acceptable for man page. Seriously, any help on documentation is more than welcome. I'm not good at writing it, and there is too much to document. We could discuss all the details privately to write a decent man page, if you have time to help. > > 6. Example how to save your key in keychain database. > > This is probably in line with what rwatson said (and would be covered by > the same document): can you describe what keychains actually do? Yes. I was thinking about 6 and 7 as of feature list, so no documentation or instructions. Keychains are mentioned in man page, but once again documentation is far from being good. Help wanted. Most important fact is that keychains have nothing to do with filesystem, it's solely userspace utility concept. Chain is a series of keys (keychain db entries). Each db entry consists of two keys: parent key and child key. Child key may be zero, i.e. end of chain marker, (created by addchain -Z). Keychain database itself is a dictionary of the following form: db[parent_key] = child_key Consider the following database: db[k0] = 0 (zero child key) db[k1] = k2 db[k2] = k3 db[k3] = 0 k0 is special. Its child key is zero (end of chain). Chain would consist only of one key: k0 If user enters k1, the following chain can be retrieved from the database: k1 k2 k3. All three keys are then added to filesystem. In case of k2 chain is k2 k3. All entries stored encrypted in a way that child entry can be decrypted only by parent key. Using key chains one can emulate access levels. (Don't miss 'pefs randomchain' command which was invented especially to make some fun for those trying to look at your data) > > 7. You can setup pam_pefs (not compiled by default) to add key to home > > directory and authenticate against keychain database on login, e.g. by > > adding the following line to /etc/pam.d/system before pam_unix.so: > > > > authsufficient pam_pefs.so try_first_pass > > So, this would bypass passwd and let the user in if his password > authenticates against the "keychain database" in his home directory? Exactly, that's the way I use it. More detailed description available here: http://marc.info/?l=freebsd-current&m=128388197901390&w=2 > Will it automagically pefs-mount his home directory? No, not mounting pefs is intentional. It automagically adds keys to already mounted pefs filesystem. > > > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > > PKCS#5v2 and HKDF for key generation. > > I do have an request: since you are already using kernel crypto support, > it would be simple to just throw Blowfish in :) If for nothing else, > consider it a gift to those who are fond of Blowfish's large key sizes > (upto 448 bits). XTS requires 128 bit block cipher. One can use Blowfish to encrypt two 64 bit subblocks, but one would need to mix these blocks somehow, that what XTS does :) A bit tricky to implement. Adding serpent or twofish should be easy. > Actually, it would probably be seen as a reflection of consistency to > implement the same algorithms that geli(8) implements. geli doesn't > implement XTS yet - if your XTS code proves to be stable it would be a > good thing to include it as standard and then use it from geli. The problem is 128 bit block in XTS, in my opinion hacking XTS to add support for algorithms with other block sizes is a very bad idea. There are more than enough modern algorithms that can be used instead. Not sure how far "reflection of consistency" extends but pefs is very likely not to support modes other then XTS, because for now it's the only widespread standard mode of operation with arbitrary sector size and arbitrary offset encryption. > I see you've copied SHA2 code to the pefs code. What is wrong with just > using the kernel's SHA2 implementation? That was accidental, or there was a reason I've already forgotten about. Anyway it's just a copy from kernel, my intention was to make it easier to test by users. There's hmac which is one-to-one copy from geli. I've extracted it be
Re: RFC: pefs - stacked cryptographic filesystem
On 7 September 2010 22:05, Gleb Kurtsou wrote: > On (07/09/2010 16:27), Ivan Voras wrote: >> On 09/06/10 20:38, Gleb Kurtsou wrote: >> > Hello, >> > >> > I would like to ask for feedback on a kernel level stacked cryptographic >> > filesystem. It has started as Summer Of Code'2009 project and matured a >> > lot since then. I've recently added support for sparse files and >> > switched to XTS encryption mode. >> >> I've tried it and so far it works :) >> >> > 3. Mount pefs filesystem: >> > # pefs mount ~/Private ~/Private >> >> I see you've used the same example in the man page. Maybe it would be >> better for educational purposes to use two separate directories, e.g. >> ~/Private and ~/Decrypted to avoid confusion by new users (of course not >> all examples need to use this). > Actually I've used the same directory solely for educational purposes -- > there is just one directory, it's either encrypted or not. The other directory is a mount point - this is what I was aiming at. > If user enters k1, the following chain can be retrieved from the > database: k1 k2 k3. All three keys are then added to filesystem. > > In case of k2 chain is k2 k3. > > All entries stored encrypted in a way that child entry can be decrypted > only by parent key. > > Using key chains one can emulate access levels. I don't know if it is cryptographically sound but it seems like too much trouble :) >> > 7. You can setup pam_pefs (not compiled by default) to add key to home >> > directory and authenticate against keychain database on login, e.g. by >> > adding the following line to /etc/pam.d/system before pam_unix.so: >> > >> > auth sufficient pam_pefs.so try_first_pass >> >> So, this would bypass passwd and let the user in if his password >> authenticates against the "keychain database" in his home directory? > Exactly, that's the way I use it. More detailed description available > here: http://marc.info/?l=freebsd-current&m=128388197901390&w=2 > >> Will it automagically pefs-mount his home directory? > No, not mounting pefs is intentional. It automagically adds keys to > already mounted pefs filesystem. Ok, so for example on a desktop client, a pefs-protected home directory would always be mounted from fstab, and then decrypted on login. Makes sense. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pam_pefs setup (Re: RFC: pefs - stacked cryptographic filesystem)
On 08/09/2010, at 3:22, Gleb Kurtsou wrote: > Please note that your home directory has to be mounted, I mount it in > /etc/rc.local, but don't add any keys. pam_pefs adds the key. Also note > that it has to be exactly your home directory (/home/gleb in my case), to > prevent possible attacks. And keychain database has to be created, so > that pam_pefs knows how to verify the key. Have you considered something similar to pam_mount? (http://pam-mount.sourceforge.net/) ie pam_pefs could mount your home directory itself and unmount it on logout. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Re: TSO panic
On Fri, Sep 03, 2010 at 10:10:33AM +0200, Andre Oppermann wrote: > On 02.09.2010 00:11, ben wilber wrote: > > On Sep 1, 2010, at 8:57 AM, Andre Oppermann wrote: > > > >> On 01.09.2010 01:13, ben wilber wrote: > >>> Hi, > >>> > >>> I just upgraded from r210042 to r212073 and keep getting the panic > >>> introduced in r211317: > >>> > >>> panic: tcp_output: len<= tso_segsz > >> > >> Please try the attached patch and report back whether it > >> fixes the issue. > > > > The system ran for 8 hours or so before I received the same panic. > > Previously, it would panic within 20 minutes. > > Attached is an updated patch that should fix the panic. > Please try. Running for almost three days now with no problem. Looks good! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
