Re: Improve support of Go

[Joel Sing]

On 24-02-13 08:17:20, Theo de Raadt wrote:
> Stuart Henderson  wrote:
> 
> > On 2024/02/13 07:36, Theo de Raadt wrote:
> > > Stuart Henderson  wrote:
> > > 
> > > > On 2024-02-13, Kirill A  Korinsky  wrote:
> > > > > Good day,
> > > > >
> > > > > I'm updating go's syscall table to modern OpenBSD (7.4).
> > > > 
> > > > Save your time. Post-7.4 you cannot call syscall() any more.
> > > 
> > > The result seems to have nothing to do with syscalls.
> > > 
> > > It is the same as the build process for kdump: It is finding cpp 
> > > definitions
> > > most of which are argument flags, but also a few structs in /usr/include, 
> > > and
> > > making them available at some level inside the go ecosystem. So if in go 
> > > you
> > > call a system call via the regular stub API, you may need those flags.  
> > > you may
> > > also need them for some other higher-level function call?  go doesn't pull
> > > from /usr/include otherwise, does it?
> > > 
> > > 
> > 
> > Oh, yes those are still needed then, I'd forgotten they were part of the
> > same thing from last time I tried to get them updated ...
> 
> there probably needs to be a formal process to update at least once a year,
> or just before a release, and also upstream.

The operating system specific parts of the Go syscall package are effectively
deprecated/frozen (and have been for nearly 10 years, hence not being updated):

  https://pkg.go.dev/syscall

  
https://go.googlesource.com/proposal/+/refs/heads/master/design/freeze-syscall.md

On the other hand, golang.org/x/sys/unix is maintained and updated
semi-regularly:

  https://pkg.go.dev/golang.org/x/sys/unix

With the exception of the OpenBSD syscall numbers:

  
https://cs.opensource.google/go/x/sys/+/master:unix/zsysnum_openbsd_amd64.go;l=8

Re: Server certs expired higher up the chain, imaps and https

[Joel Sing]

On 21-09-30 19:45:38, James Cook wrote:
> On Thu, Sep 30, 2021 at 10:02:17AM -0700, Chris Bennett wrote:
> > Hi,
> > 
> > I'm getting that the certs are expired, but https works fine in Firefox,
> > including when looking at the full chain.
> > 
> > 
> > openssl s_client -servername mail.strengthcouragewisdom.rocks -connect 
> > mail.strengthcouragewisdom.rocks:imaps
> > 
> > openssl s_client -servername mail.strengthcouragewisdom.rocks -connect 
> > mail.strengthcouragewisdom.rocks:https
> > 
> > However are not happy. I force updated my ssl certs, syspatch, pkg_add
> > -u and rebooted.
> > 
> > I didn't rebuild dh.pem for dovecot.
> > 
> > Is this just a DNS propagation issue?
> > Or should I do something further myself?
> > 
> > Thanks
> > Chris Bennett
> 
> A certificate in LetsEncrypt's chain expired today or yesterday. The
> issue is a bit complicated.
> 
> 
> There's a page here:
> 
> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
> 
> and a forum thread here:
> 
> https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190
> 
> 
> Summary: generally, newer clients and web browsers will not give the
> cert expired error, because the middle certificate on the chain is a
> root cert in its own right. Other clients, including as far as I can
> tell the LibreSSL version included in OpenBSD 6.9, are more strict and
> reject the whole chain because the last certificate in the chain
> expired.
> 
> E.g. I just tried "ftp -o x
> 'https://mail.strengthcouragewisdom.rocks/'" on -current and it
> worked.

Current uses the new X.509 verifier and is not impacted by this problem.

> LetsEncrypt does not want to remove that last one from the chain
> because older Android phones don't have that middle certificate as a
> root CA.
> 
> Some post(s) in the thread claim it is possible to request an alternate
> chain from LetsEncrypt, if you want one that doesn't end with the
> expired one. I couldn't find this functionality in OpenBSD's
> acme-client. However, I tried manually editing the fullchain pem file
> downloaded by acme-client, deleting the third of three certificates in
> the file, and now my older clients are happy (but presumably old
> Android phones will not be happy).

Let's Encrypt is supplying alternate certificate chains. When you
fetch the certificate from the ACME order, HTTP Link headers with
'rel="alternate"' are potentially provided and these can be fetched
in the same way as the primary certificate chain. Unfortunately,
acme-client does not currently support this (not to mention that
chain selection also becomes messy from a application/configuration
stand point).

Re: Key-based FDE /w UEFI fails

[Joel Sing]

On Thursday 29 November 2018 20:38:23 Stefan Wollny wrote:
> Hi there!
> 
> I need help / advice with a fresh install onto a Thinkpad T450s which I
> recently bought on eBay.
> 
> The system starts with UEFI enabled and was running fine with a rather
> small SSD without FDE. dmesg from some recent posts may be found.
> 
> I followed the steps as given in the FAQ
> (http://www.openbsd.org/faq/faq14.html#softraid) with a new, larger SSD
> and the key disk both initialized with
> 'fdisk -iy -g -b 960 sd0' (and '... sd2' for the key disk).
> 
> On both disks I created a 'a'-partion with type RAID as zero'd the first
> blocks.
> 
> softraid is activated with 'bioctl -c C -k sd2a -l sd0a softraid0'.
> 
> The installation was without noticable deviation to a non-FDE installation.
> 
> The layout is identical to an other FDE-secured laptop which starts with
> BIOS:
> sd0a  /
> sd0b  swap
> sd0d  /tmp
> sd0e  /var
> sd0f  /usr
> sd0g  /usr/local
> sd0h  /home
> (As this is a 1TB-SSD each partition has lots of capacity...)
> 
> Yet after rebooting the first time I get the following:
> 
> probing: pc0 mem[352K 204K 3256M 4832M]
> disk: hd0 hd1 sr0*
> 
> >> OpenBSD/amd64 BOOTS64 3.40
> 
> open(hd0a:/etc/boot.con f): Invalid argument
> boot>
> cannot open hd0a:/etc/random.seed: Invalid argument
> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
>  failed(22). will try /bsd
> boot>
> cannot open hd0a:/etc/random.seed: Invalid argument
> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
>  failed(22). will try /bsd
> Turning timeout off.
> boot>
> 
> At this point I am lost. Tried to google for any information that makes
> sense but only found very old posts (from 2011 and older) which didn't
> provide hints on how to proceed.
> 
> Anybody with a clue?

The 'sr0*' in the above output shows that the boot loader found the softraid 
volume and believes that it is bootable. What should have happened is that the 
boot loader identified that the disk you booted from is part of the softraid 
volume and switched to sr0 as the boot device - for some reason it did not and 
continued to try to boot from hd0 instead.

You should be able to boot by manually specifying:

  boot sr0a:/bsd

at the boot> prompt.

If that works we'll have to track down the reason why the automatic switching 
of the boot device failed (line 146 of sys/arch/amd64/stand/libsa/dev_i386.c 
and the code that leads up to it).

Re: Why stacking softraid disciplines is not supported?

[Joel Sing]

On Thursday 29 November 2018 12:05:08 Justus Hämäläinen wrote:
> Hi,
> 
> I see that stacking softraid disciplines is not supported, but why I
> wonder? I was thinking about running fulldisk encryption on softraid
> RAID1.
> 
> Is it unsupported because it hasn't been tested enough that it doesn't
> explode? (Can do this myself)
> Is it just unimportant enough that nobody has worked on this? (I can at
> least waste my time on this)
> 
> Or is it just plain stupid idea? If so why it shouldn't be done?

It works and you can do it, but it is not officially supported - as in if it 
breaks you get to either keep both bit... or figure out how to fix it yourself 
(I have done it myself in the past, for example).

There is no technical reason for it not to work, however there are several 
"gotchas" that you need to be aware of, along with several inefficiencies. The 
two main things are that boot and auto-assembly will not work - the boot 
loader will assemble the first softraid volume, but it will not find or 
assemble 
the stacked volume. Same goes with auto-assembly by the kernel at boot time 
(for a non-boot disk).

The inefficiency comes from the fact that each discipline is attached and 
exposed as a separate sd(4) device, which means that reads/writes effectively 
get performed on one virtual device, before bouncing around and being 
performed on the second virtual device, before bouncing around and being 
performed on the actual underlying physical devices. Ideally this would be 
handled internally so that you handle the (for example) crypto transformation, 
then RAID 1 transformation, then write to the physical devices - this way you 
also only expose one sd(4) device for the volume (which also avoids things 
messing with the intermediate discipline). There are a few ways that this 
could be done - generically, or by implementing specific disciplines that would 
be commonly used (e.g. RAID 1C, RAID 10, RAID 10C, RAID 5C, etc...).

Hope this helps.

Re: Help with LibreSSL manpages

[Joel Sing]

On Sunday 25 November 2018 17:36:16 Ingo Schwarze wrote:
> Stephen Gregoratto wrote on Mon, Nov 26, 2018 at 12:26:21AM +1100:
> >
> > Would I need to fully grok the code before I could write the docs?
> 
> Absolutely not.  You could spend an infinite amount of time to
> understand the code if you tried to understand everything.
> Of course, there is nothing wrong with studying whatever interests
> you.

In addition to what Ingo has already said, I would add that I think it is 
actually beneficial for someone who is not highly familiar with the code to 
write the documentation, as it gives you a fresh set of eyes and a different 
perspective. You'll question and challenge things rather than accepting them 
at face value. However, you obviously you need to at least be able to read the 
code to generally understand what it is doing.

Furthermore, I'd suggest that you start small (fix some typos, correct some 
gramatical issues) and then work up to bigger changes (rewriting poorly 
written documentation or creating new man mages). This will let you become 
familiar with the documentation style and review/commit process, with faster 
reviews and feedback.

Re: Boot reboot issue after upgrade to 6.4 on amd64

[Joel Sing]

On Tuesday 27 November 2018 16:07:18 Riccardo Mottola wrote:
> Hi Nick,
> 
> Nick Holland wrote:
> > So far, with one or two exceptions, everyone complaining about this has
> > a One Big Partition disk layout.  A bad idea, not suggested, and I don't
> > think you will get much sympathy.
> 
> yes of course (TM).. I won't get much sympathy, but it is the best
> set-up for a dual-booting laptop it works for every OS I test and worked
> until 6.3 for me.
> For other set-ups I use different partitioning schemes, but I suppose in
> the past twenty years or so, we all had our issues with disk layouts.
> 
> > I know of one machine that behaves as you describe with a very modest
> > (smaller than suggested) root partition, but I'm feeling very alone
> > here. :D
> 
> what is the actual size limit? from where? I wonder that I cannot even
> boot the old kernel which worked.. at the previous boot!
> 
> I cannot shuffle the partitions, I cannot even reinstall from scratch,
> since I am unable to boot from an USB key with the installer image, it
> crashes both the 6.4 installer image as the old 6.3.

The specific "heap full" issue that can be triggered by using a single large 
partition is not likely to be at fault here - if you cannot boot the ramdisk 
(bsd.rd/installer) for 6.3 or 6.4 from a USB key, then something else is 
presumably up (unless you're actually trying to load the installed kernel or 
ramdisk from the hard disk). 

> All important data is backed up, but I need to reinstall at least and
> cennot even do that. Of course booting abd being able to copy a last
> snapshot of my home directory would be even best, to retain my profiles.
> 
> Should I try boot from optical media? could that help? I suppose not...
> 
> Thanks,
> 
> 
> Riccardo

Re: Boot reboot issue after upgrade to 6.4 on amd64

[Joel Sing]

On Tuesday 27 November 2018 21:54:36 Angelo Rossi wrote:
> Sorry,
> 
> To fix this problem I changed /usr/src/sys/arch/amd64/stand/Makefile.inc
> 
> line #45 from
> 
> HEAP_LIMIT=0xA
> 
> to
> 
> HEAP_LIMIT=0xB

That may work on your machine, however it is not a change that can be safely 
made (at least, not without a massive amount of testing). The correct solution 
is to reduce the memory usage/requirements, such that it remains within the 
existing allocated heap size.

> On Tue, Nov 27, 2018 at 9:37 PM Angelo Rossi
> 
> wrote:
> > -- Forwarded message -
> > From: Angelo Rossi 
> > Date: Tue, Nov 27, 2018 at 9:31 PM
> > Subject: Re: Boot reboot issue after upgrade to 6.4 on amd64
> > To: 
> > 
> > 
> > I agree with you, but it happens, anyway I found a simple trick to
> > override the problem: recompile boot changing HEAP_SIZE to 1 MB.
> > 
> > Angelo
> > 
> > On Tue, Nov 27, 2018 at 9:28 PM Theo de Raadt  wrote:
> >> Angelo Rossi  wrote:
> >> > Now it is a bug... Nice, when me and other people posted same comment
> >> 
> >> it wasn't! And
> >> 
> >> > yes OpenBSD is indeed a magical OS.
> >> 
> >> It is a bug.
> >> 
> >> 
> >> And using a single large partition is idiotic, completely ignoring a
> >> safety pattern built into the system.  Similar to making your password
> >> "1234" because your machine isn't always on the internet.

Re: ldap search fails with Let's Encrypt certificate

[Joel Sing]

On Monday 05 November 2018 17:02:50 Joel Carnat wrote:
> Le 05/11/2018 16:38, Stuart Henderson a écrit :
> > On 2018-11-05, Joel Carnat  wrote:
> >> Le 05/11/2018 13:48, Stuart Henderson a écrit :
> >>> On 2018-11-05, Joel Carnat  wrote:
>  TLS:
> New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384

AES256-GCM-SHA384 is not in:

> # openssl ciphers
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA
> 20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-EC
> DSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DH
> E-RSA-AES128-GCM-SHA256
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-
> GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-A
> ES128-GCM-SHA256

Since it is not an ephemeral cipher suite (and presumably the server does not 
support any DHE or ECDHE cipher suites). As Stuart mentioned earlier, you'd 
need to relax the cipher suite list used by ldap(1) to be at least "compat" 
(or specifically include this cipher suite).

Re: Installboot uses wrong device for secondary boot loader

[Joel Sing]

On Saturday 28 April 2018 22:21:08 Eric Zylstra wrote:
> I’m installing 6.3 on a RAID1.  Install was fine until ending with an error
> message, “invalid boot record signature…”.
> I manually ran installboot:
> >. installboot -v -r /mnt sd4
> 
> Hand transcription:
> 
> Using /mnt as root
> Installing bootstrap on /dev/rsd4c
> Using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot
> sd4:  softraid volume with 2 disk(s)
> sd4:  installing boot loader on softraid volume
> /mnt/usr/mdec/boot is 6 blocks x 16384 bytes
> sd0a:  installing boot blocks on /dev/rsd0c, part offset 144
> Master boot record (MBR) at sector 0
> Install boot:  invalid boot record signature (0x) @ sector 0
> 
> I did not typo the secondary boot block install.  It attempts to install on
> sd0 instead of sd4 as specified in my command.

In order to boot a softraid volume, the underlying disks have to be bootable 
with the first stage boot block being installed in the MBR (at least for 
i386/amd64). This is why it's looked at sd4, then gone to install the first 
stage boot block on sd0... however there is no MBR on this device to install 
it into. This suggests that you've not run fdisk correctly - but with 
insufficient details I can only guess.

Re: Clarification re: rebuilding softraid mirror

[Joel Sing]

On Friday 27 April 2018 11:17:07 Jordan Geoghegan wrote:
> Thanks for the reply, I have rebuilt a softraid mirror before, I was
> just hoping for some clarification as the faq wording is a little
> ambiguous as to whether drives can be rebuilt in multi user mode or not.

Rebuild is a background kernel operation - you can initiate it in either 
single user or multi user mode.

> I was also curious how the system handles write operations to the array
> while it is rebuilding.

Writes go to chunks that are in an online or rebuilding state, while reads 
only come from online chunks. Other than the overhead from the background I/O 
there is no reason you cannot operate as normal during a rebuild.

> Similarly, is the reboot required for the newly repaired array to be 
> initialized/function?

The need to shutdown/reboot is really only hardware dependent - if you have 
hotplugable devices then there is no need to reboot - you can however reboot 
half way through a rebuild and it will pick up where it left off (providing the 
chunks are available).

> I have a simple production storage NAS I am setting up, and would
> appreciate any input on softraid "best practices".

As per some previous advice test - build the volume, pull a disk (or bioctl -
O), rebuild, etc - make sure you know how it is going to work before you put 
data on it.

> On 04/26/18 17:48, IL Ka wrote:
> > Hello,
> > 
> > No, you do not need to reboot. At least this is how it worked for me
> > for raid 1:
> > 
> > 1) bioctl softraid0 said raid degraded
> > 2) I installed new disk (sd2).
> > 3) kenrel reported on console that disk is detected
> > 4) I created MBR using fdisk on it
> > 5) I created disklabel with RAID type on it
> > 6) bioctl -R /dev/sd2a sd0
> > 
> > I suggest you to try it yourself, but not on production system)
> > 
> > 
> > 
> > On Fri, Apr 27, 2018 at 2:21 AM, Jordan Geoghegan
> > 
> > > wrote:
> > Hello,
> > 
> > Sorry for my ignorance, I was hoping someone could clarify for me
> > the proper procedure for rebuilding a softraid mirror. The man
> > 
> > page/faq says:
> > Rebuilding a mirror
> > 
> > When a drive failure happens, you will replace the failed
> > drive, create the RAID and other disklabel partitions, then
> > rebuild the mirror. Assuming your RAID volume is sd2 and you
> > are replacing the failed device with sd1m, the following
> > commands should work:
> > 
> > #*bioctl -R /dev/sd1m sd2*
> > #*reboot*
> > 
> > These steps can be performed in either single user mode
> >  > > or from the
> > install kernel  > >.
> > 
> > Does this mean that a RAID rebuild can *only* be performed from
> > single user mode or install kernel, or is it possible to rebuild
> > an array while the system is in full operation?
> > 
> > To phrase my question a different way:
> > Is it possible to hot swap drives and rebuild arrays on the fly,
> > or will this bork my system?
> > 
> > Thanks,
> > Jordan Geoghegan

Re: LibreSSL Linux portability and OpenBSD security

[Joel Sing]

On Saturday 10 February 2018 11:09:04 Kevin Chadwick wrote:
> On Sat, 10 Feb 2018 16:24:38 +1100
> 
> > > Just in case some libressl dev doesn't want read the full thread in
> > > the Alpine list, they want also a workaround for the lack of time_t
> > > for 32bits platforms on Linux.
> > 
> > We've already addressed this - a notafter that exceeds 2038 is
> > clamped to 2038 on system that only has 32-bit time_t - see r1.65 of
> > src/lib/libcrypto/x509/x509_vfy.c:
> > 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c
> > .diff?r1=1.64=1.65
>
> Natanael had already found that but William says TAI64n is required to
> be conformant. Perhaps you will understand where he is coming
> from or whether he has an unspoken agenda? His original email did not
> seem to be a fair representation of facts though.

Conformant with what exactly? I do not recall seeing anything regarding TAI64N 
in TLS/X509 RFCs, where everything is handled in ASN.1 GENERALIZEDTIME or 
UTCTIME.
 
> I can't see how this (assuming this is the TAI64N in question) helps but
> I assume I am missing something.
> 
> https://cr.yp.to/daemontools/tai64n.html
> 
> "Beware that most gettimeofday implementations are not Y2038-compliant."

Re: LibreSSL Linux portability and OpenBSD security

[Joel Sing]

On Saturday 10 February 2018 00:05:27 Juan Francisco Cantero Hurtado wrote:
[snip]
> Just in case some libressl dev doesn't want read the full thread in the
> Alpine list, they want also a workaround for the lack of time_t for
> 32bits platforms on Linux.

We've already addressed this - a notafter that exceeds 2038 is clamped to 2038 
on system that only has 32-bit time_t - see r1.65 of 
src/lib/libcrypto/x509/x509_vfy.c:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c.diff?r1=1.64=1.65

> FYI: Adelie is a downstream distro of Alpine which wants to support
> "old" platforms. https://adelielinux.org/info.html#platforms

Re: installboot(8)

[Joel Sing]

On Tuesday 04 July 2017 20:55:25 Paul de Weerd wrote:
> On Tue, Jul 04, 2017 at 08:34:56PM +0200, Stefan Wollny wrote:
> | Hi there!
> | 
> | Sorry if this may sound like a rather stupid question:
> | (Referencing the examples section of man installboot(8))
> | 
> | Can s.o. verifiy that instead  of
> | # installboot sd0
> | 
> | it is equally safe to issue
> | # installboot 
> | (the DUID itself, of course)?
> | 
> | My system is fully encrypted with sd1 usually being the (unencrypted)
> | boot disk - but if external USB disks are attached that number seems not
> | to be quaranteed.
> 
> simply `installboot $(df -h / | grep -o -E '[ws]d[0-9]+')`
> 
> There's definitely a difference between using the device name and the
> DUID:
> 
> [weerd@pom] $ doas installboot -v `awk -F. '/ \/ / {print $1}' /etc/fstab`
> Using / as root
> installing bootstrap on /dev/rsd14c
> using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
> 5c0d9a38cc895a7d: softraid volume with 0 disk(s)
> 5c0d9a38cc895a7d: installing boot loader on softraid volume
> /usr/mdec/boot is 6 blocks x 16384 bytes
> 
> [weerd@pom] $ doas installboot -v  $(df -h / | grep -o -E '[ws]d[0-9]+')
> Using / as root
> installing bootstrap on /dev/rsd14c
> using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
> sd14: softraid volume with 1 disk(s)
> sd14: installing boot loader on softraid volume
> /usr/mdec/boot is 6 blocks x 16384 bytes
> sd0a: installing boot blocks on /dev/rsd0c, part offset 144
> master boot record (MBR) at sector 0
> partition 3: type 0xA6 offset 64 size 1953520001
> /usr/mdec/biosboot will be written at sector 64
> 
> So if I were you, I'd continue using the device for now.

Note that this will only apply in the case where the disk is a bootable 
softraid volume - in the non-softraid case either is fine and the DUID is 
likely preferable.

Re: installboot(8)

[Joel Sing]

On Tuesday 04 July 2017 20:34:56 Stefan Wollny wrote:
> Hi there!
> 
> Sorry if this may sound like a rather stupid question:
> (Referencing the examples section of man installboot(8))
> 
> Can s.o. verifiy that instead  of
> # installboot sd0
> 
> it is equally safe to issue
> # installboot 
> (the DUID itself, of course)?
> 
> My system is fully encrypted with sd1 usually being the (unencrypted)
> boot disk - but if external USB disks are attached that number seems not
> to be quaranteed.

As long as sd0 is not a softraid volume, it is perfectly fine (and in fact, 
likely preferable) to use the DUID instead of the device name. However, in the 
case of a softraid volume you currently need to use the device name.

Re: Libressl issue verifying self-signed certs with tls-auth and Openvpn

[Joel Sing]

On Tuesday 20 June 2017 23:26:10 Andrew Lemin wrote:
> Hi,
> 
> Sadly in my testing it seems that CVE-2017-8301 (
> http://seclists.org/oss-sec/2017/q2/145) is still broken with the
> latest LibreSSL
> (2.5.4) and OpenVPN 2.4.2.
> 
> Here is someone else reporting the same issue;
> https://discourse.trueos.org/t/libre-openssl-tls-error-when-using-openvpn/13
> 58/4
> 
> Of course I may have gotten this wrong somewhere, but for now it seems not
> possible to use OpenVPN as a client with TLS static certificate based
> server on OpenBSD.
> 
> Hope this helps clarify for anyone else finding the same issue until some
> clever person does a fix.
> 
> 
> Error same with latest;
> 
> Tue Jun 20 22:51:15 2017 OpenVPN 2.4.2 x86_64-unknown-openbsd6.1 [SSL
> (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 20 2017
> 
> Tue Jun 20 22:51:15 2017 library versions: LibreSSL 2.5.4, LZO 2.10
> 
> Tue Jun 20 22:52:08 2017 VERIFY ERROR: depth=0, error=self signed
> certificate: < Cert Info >
> 
> Tue Jun 20 22:52:08 2017 OpenSSL: error:14007086:SSL
> routines:CONNECT_CR_CERT:certificate verify failed
> 
> Tue Jun 20 22:52:08 2017 TLS_ERROR: BIO read tls_read_plaintext error
> 
> Tue Jun 20 22:52:08 2017 TLS Error: TLS object -> incoming plaintext read
> error
> 
> Tue Jun 20 22:52:08 2017 TLS Error: TLS handshake failed
> 
> Tue Jun 20 22:52:08 2017 SIGUSR1[soft,tls-error] received, process
> restarting

This should be fixed on -current (via r1.30 of libcrypto/x509v3/v3_purp.c) - 
you should also be able to workaround the issue by using different CNs for the 
CA and server certificates (they're likely identical in this case).

Re: Bioctl rounds doesn't appear to affect the passphrase time?

[Joel Sing]

On Sunday 25 June 2017 22:28:17 Kevin Chadwick wrote:
> Doh...  Yeah, starting from scratch with -r works. I guess quickly finding
> how long rounds take is not quite as easy as bioctl -d and try again.

The number of rounds can also be changed when you change the passphrase on an 
existing volume.

Re: Rebuilding a degraded RAID5 softraid array

[Joel Sing]

On Friday 16 June 2017 10:11:20 LÉVAI Dániel wrote:
> Karel Gardas @ 2017-06-15T09:07:39 +0200:
> > On Thu, Jun 15, 2017 at 7:04 AM, LEVAI Daniel  wrote:
> [...]
> 
> > > Strangest thing is, if I boot with the 'bad' (=failing) drive as
> > > part of the array, softraid brings the volume online (albeit
> > > degraded) and I can even decrypt/mount the volume and use it (only
> > > one drive being bad in the array of RAID5).  If I remove/replace
> > > said failing drive, I'm not getting a degraded volume, just the
> > > error about the missing chunk and that it refuses to bring it
> > > online.
> 
> [...]
> [...]
> 
> > So I see you do have two possibilities probably:
> > 
> > 1) IMHO more safe. If you do have enough SATA ports, then attach both
> > your failing drive and your new drive to the system. Boot. OpenBSD
> > should detect and attach RAID5 in degraded state and then you will be
> > able to perform your rebuild (if your failing drive is not offline,
> > you can use bioctl to offline it)
> > or
> 
> Thanks Karel, this indeed did the trick. I'm still baffled however, that
> the whole purpose of the RAID setup was diminished by a missing disk 8-\

This is certainly not expected behaviour - I've only skimmed/picked over parts 
of this thread, however softraid will attempt to bring a degraded array online 
(which it seemed to be doing):

softraid0: not all chunks were provided; attempting to bring volume 1 online
softraid0: trying to bring up sd7 degraded
softraid0: sd7 is offline, will not be brought online

For some reason it was unable to bring it up in a degraded state (for example, 
multiple missing disks in a RAID 5 array, different metadata versions, etc) - 
obviously the logging does not explain why this is the case and we may not be 
able to reproduce the situation now.

For future travellers, using dd to capture the start of each partition (which 
contains the softraid metadata), would allow this to be analysed further.

> You in fact gave the advice at a so lucky time, that I was about to
> return the disk for a warranty replacement -- had I done that, I could
> not have been able to repair the array. So thanks again, and I guess
> you'll have a beer on me when you're around Budapest ;)

Just to clarify, you're saying that when you plugged all of the original disks 
back in the array came up again correctly? And if this is correct, was this at 
boot time?

> (Just a side note: to attach the new disk, I had to remove one of the
> system disks that are in a RAID1 setup, also with softraid. Softraid
> however had no problem bringing up *that* RAID1 volume in a degraded
> state with the missing disk...)

Right - that is how it should behave.

> > 2) less safe (read completely untested and unverified by reading the
> > code on my side). Use bioctl -c 5 -l 
> >  to attach the RAID5 array including the new drive. Please do
> > *NOT* force this. See if bioctl complains for example about missing
> > metadata or if it automatically detects new drive and start rebuild.
> > 
> > Generally speaking I'd use (1) since I used this in the past and had
> > no issue with it.
> 
> Now this was more interesting. I tried eg. (re)creating the RAID5 array
> with only the remaining three (out of four) disks, with:
> # bioctl -c 5 -l /dev/sd2a,/dev/sd3a,/dev/sd4a softraid0
> 
> Now the result was a firmly reproducable kernel panic and a ddb console.
> I tried with 6.1 and 6.0 (and 5.8 :) ), just for kicks, but it seems
> this is a not supported feature(tm) :).

I can reproduce this and will investigate - for future reference, reporting 
this as a bug and providing the trace would be helpful :)
 
> When I specified the remaining three disks plus the new/clean one,
> softraid complained that 'not all chunks are of the native metadata',
> whatever this means.

Right - basically it is saying that the fourth chunk does not contain softraid 
metadata and is not part of the volume.

> But for some reason I liked this idea better, 'cause I wouldn't have
> keep the failing disk connected.

As per earlier, you should be able to bring it up in a degraded state, then 
rebuild onto an additional chunk.

> Anyway, all sync'd now, and the rebuild speed was quite good -- around
> 100MB/s --, so it basically finished overnight.

Good, glad to hear.

Re: bioctl crypto size limitation ?

[Joel Sing]

On Friday 26 May 2017 15:59:18 sharon s. wrote:
> On 05/26/17 15:49, sharon s. wrote:
> > disklabel: ioctl DIOCWDINFO: Open partition would move or shrink
> > disklabel: unable to write label
> 
> Stupid me, I forgot that the softraid device was still attached.
> 
> 12Tb, 14Tb and 15Tb works as well, 16 seems to be where it breaks.

Okay, this makes more sense:

#define SR_CRYPTO_MAXKEYS   32  /* max keys per volume */
#define SR_CRYPTO_KEY_BLKSHIFT  30  /* 0.5TB per key */

32 * 0.5TB == 16TB

That said, the original design of softraid crypto was to use 0.5TB per volume 
key, however there has been a very long standing bug where it only uses the 
first key for the entire disk. Unfortunately, when the bug was found it was 
impossible to change this since it would break anyone who had a volume larger 
than 0.5TB. The plan was to address this when the crypto metadata was 
redesigned, which is still yet to happen (and fixing it also means there is 
another bug that has to be addressed first...)

Something is obviously still checking/hitting this limit though and is 
triggering the failure. There are probably a couple of things to fix here - the 
error message from bioctl should at least tell you what the issue is instead 
of "unknown error". It is also possible to remove the 16TB restriction (which 
I thought was ineffective) since there is really no technical limit - it does 
however potentially make key guessing attacks easier (which is why the 
intention was to use multiple keys per volume)...

And overall, I guess we need to look at bumping the limit since people are now 
hitting it (unfortunately, I don't have access to appropriate hardware for 
testing though :)

Re: bioctl crypto size limitation ?

[Joel Sing]

On Saturday 27 May 2017 01:56:06 Joel Sing wrote:
> On Friday 26 May 2017 01:05:59 sharon s. wrote:
> > On 05/26/17 00:45, Ted Unangst wrote:
> > > myml...@gmx.com wrote:
> > >> Steps to recreate:
> > >> 
> > >> dd if=/dev/random of=/dev/rsd0c bs=1m   (took over a week)
> > >> 
> > >> fdisk -iy -g sd0  (I left off the "-b 960" because this is not a
> > >> bootable partiton)
> > >> 
> > >> disklabel -E sd0
> > >> 
> > >> Label editor (enter '?' for help at any prompt)
> > >> 
> > >>   > a a
> > >> 
> > >> offset: [64]
> > >> size: [70319603585]
> > >> FS type: [4.2BSD] RAID
> > >> 
> > >>   > w
> > >>   > q
> > >> 
> > >> # bioctl -v -c C -l sd0a softraid0
> > >> New passphrase:
> > >> Re-type passphrase:
> > >> Deriving key using bcrypt PBKDF with 16 rounds...
> > >> bioctl: unknown error
> > >> 
> > >> softraid0: invalid metadata format
> > > 
> > > You filled the disk with random data, which is not a valid metadata
> > > format...
> > 
> > I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto .
> 
> Hrmmm, it looks like that part of the FAQ is incorrect or missing a step.
> You should be able to work around it by either zeroing the first ~1MB of
> disk (per the FAQ), or by using 'bioctl -C force' (carefully).

Actually, re-reading this it should be correct - the "invalid metadata format" 
error is more likely indicating an issue identifying the partition type/size 
(as unhelpful as that is). Could you provide the output from `disklabel sd0'?

Re: bioctl crypto size limitation ?

[Joel Sing]

On Friday 26 May 2017 01:05:59 sharon s. wrote:
> On 05/26/17 00:45, Ted Unangst wrote:
> > myml...@gmx.com wrote:
> >> Steps to recreate:
> >> 
> >> dd if=/dev/random of=/dev/rsd0c bs=1m   (took over a week)
> >> 
> >> fdisk -iy -g sd0  (I left off the "-b 960" because this is not a
> >> bootable partiton)
> >> 
> >> disklabel -E sd0
> >> 
> >> Label editor (enter '?' for help at any prompt)
> >> 
> >>   > a a
> >> 
> >> offset: [64]
> >> size: [70319603585]
> >> FS type: [4.2BSD] RAID
> >> 
> >>   > w
> >>   > q
> >> 
> >> # bioctl -v -c C -l sd0a softraid0
> >> New passphrase:
> >> Re-type passphrase:
> >> Deriving key using bcrypt PBKDF with 16 rounds...
> >> bioctl: unknown error
> >> 
> >> softraid0: invalid metadata format
> > 
> > You filled the disk with random data, which is not a valid metadata
> > format...
>
> I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto .

Hrmmm, it looks like that part of the FAQ is incorrect or missing a step. You 
should be able to work around it by either zeroing the first ~1MB of disk (per 
the FAQ), or by using 'bioctl -C force' (carefully).

Re: httpd and Curve25519 (X25519)

[Joel Sing]

On Sunday 14 May 2017 14:30:55 Bryan wrote:
> OpenBSD 6.1 httpd is (according to Qualys SSL Labs) using "Supported EC
> Named Curves x25519, secp256r1, secp384r1 (server preferred order)"
> when `tls ecdhe "auto"` is used in the server configuration.
> 
> Is it possible to configure httpd to use only x25519?

Not currently.
 
> Trying various ways of specifying this curve, "x25519", "X25519",
> "curve25519", and "Curve25519" have been unsuccessful. This curve is
> also not returned with `$ openssl ecparam -list_curves`. I believe I
> read somewhere that Curve25519 is implemented differently than the
> other elliptic curves and this is why it does not display with the
> above command. However, somehow it is being utilized by httpd, and so I
> wonder if there is a way to enforce the use of only this curve.

It is on the TODO list - there is a change needed to libtls, which will then 
allow httpd to specify which EC curves are to be enabled for TLS key exchange 
(including X25519).

Re: Encryption

[Joel Sing]

On Wednesday 22 March 2017 18:17:12 Jan Betlach wrote:
> Solene, Ken,
>
> thanks a lot for quick responses. Primarily I need to protect the laptop
> against losing/stealing it. Therefore FDE would be ideal, however I've red
> somewhere that FDE is not officially supported on OpenBSD.

This is inaccurate - amd64 and i386 gained boot support for softraid crypto at
the end of 2012 and it has been pretty much supported since then. That said,
the installer does not provide support for an FDE configuration, however the
steps required to configure it are not overly complex and are documented in
the
FAQ.

> It would probably make sense to combine both - FDE and to have most
> sensitive data additionally encrypted using virtual block device (as I do
> not need to have these permanently mounted).
>
> Jan
>
> On Wed, Mar 22, 2017 at 6:11 PM, Ken  wrote:
> > To expand on Solène's reponse. Keep in mind if you need to cover both
> > scenarios for whatever your threat-model is... you can do both too.
> >
> > Another valuable result of FDE is that it helps ensure the integrity
> > of your boot drive (presuming your encrypting your boot volume). i.e.
> > prevents attacks like the sysadmin sticky-keys "attack" on windows
> > boxes. So someone can't just boot and mount the partition and modify
> > your shadow file to add a new root user or other backdoor. Good for
> > scenarios where physical access isn't necessarily controlled by the
> > 3Gs (guards, gates, guns).
> >
> > In my experience, setting up FDE with OpenBSD has been very easy with
> > just a couple of calls to bioctl to set it up. Pretty much seamless if
> > you have a quick tutorial on it.
> >
> > Don't lose your passphrases/keys, and have fun!
> >
> > On Wed, Mar 22, 2017 at 9:38 AM, Solène Rapenne  wrote:
> > > Le 2017-03-22 17:28, Jan Betlach a écrit :
> > >> Hi misc,
> > >>
> > >> planning to install -current on my Thinkpad T450s (SSD).
> > >>
> > >> I need to have several data directories encrypted, however would not
> >
> > mind
> >
> > >> whole-disk encryption. Which method would be more supported /
> >
> > recommended?
> >
> > >> Whole-disk encryption or creating a container file, loop device and
> > >> then
> > >> virtual device with the encryption layer on it?
> > >>
> > >> Thanks in advance
> > >>
> > >> Jan
> > >
> > > Hello Jan,
> > >
> > > That would depend on your need, do you want to protect against someone
> > > who would steal your computer, or against some malicious software
> > > running under your system to read your data ?
> > >
> > > In the first case, you should go with FDE (full disk encryption), your
> > > data would be available only after you type the password at boot.
> > >
> > > In the second case, you should use some kind of encrypted volume that
> > > would be available only when you need to. I think that's possible to
> > > create an encrypted ffs volume contained into a file, that you can
> > > mount when you need.
> > >
> > > Regards

Re: tlsv1 alert decrypt error

[Joel Sing]

On Thursday 02 March 2017 13:28:08 Kirill Miazine wrote:
> Recently I've noticed a number of error messages in my Exim mail log:
> 
> TLS error on connection from mx1.slc.paypal.com (mx0.slc.paypal.com)
> [173.0.84.226] \ (SSL_accept): error:1403741B:SSL
> routines:ACCEPT_SR_KEY_EXCH:tlsv1 alert decrypt error TLS client
> disconnected cleanly (rejected our certificate?)

This is most likely the same issue as that reported on the libressl@ mailing 
list a day or so ago - expect a fix to arrive shortly.

Re: Tor no longer works on -current ?

[Joel Sing]

On Saturday 07 January 2017 21:14:29 Olivier Antoine wrote:
> Hi all,
>
> Is it only me or Tor no longer works on -current ?

I believe this should already be rectified in -current (via a partial
reversion
of src/lib/libcrypto/x509/x509_vfy.c r1.54). Thanks for the report.

> Every port or compiled version of stable or unstable branch of Tor on a
> fresh OpenBSD snapshot fail at the same bootstrap stage…
>
> Don't know since when exactly, but the last snapshot working for me was :
> OpenBSD 6.0-current (GENERIC.MP) #72: Tue Dec 27 22:00:51 MST 2016
>
> The first failed for me was :
> OpenBSD 6.0-current (GENERIC.MP) #98: Tue Jan  3 21:07:10 MST 2017
>
> Here is a fragment of the Tor bootstrapping log :
>
> Jan 07 18:14:43.000 [notice] Bootstrapped 10%: Finishing handshake with
> directory server
>
> Jan 07 18:14:43.000 [debug] connection_tls_start_handshake(): starting TLS
> handshake on fd 8
>
> Jan 07 18:14:43.000 [debug] tor_tls_handshake(): About to call SSL_connect
> on 0x820e1d00 (before/accept initialization)
>
> Jan 07 18:14:43.000 [debug] tor_tls_debug_state_callback(): SSL 0x7a8b2600
> is now in state before/connect initialization [type=16,val=1].
>
> Jan 07 18:14:43.000 [debug] tor_tls_debug_state_callback(): SSL 0x7a8b2600
> is now in state before/connect initialization [type=4097,val=1].
>
> Jan 07 18:14:43.000 [debug] tor_tls_debug_state_callback(): SSL 0x7a8b2600
> is now in state unknown state [type=4097,val=1].
>
> Jan 07 18:14:43.000 [debug] tor_tls_debug_state_callback(): SSL 0x7a8b2600
> is now in state SSLv3 read server hello A [type=4097,val=1].
>
> Jan 07 18:14:43.000 [debug] tor_tls_debug_state_callback(): SSL 0x7a8b2600
> is now in state SSLv3 read server certificate B [type=16392,val=560].
>
> Jan 07 18:14:43.000 [debug] tor_tls_debug_state_callback(): SSL 0x7a8b2600
> is now in state SSLv3 read server certificate B [type=4098,val=-1].
>
> Jan 07 18:14:43.000 [debug] tor_tls_debug_state_callback(): SSL 0x7a8b2600
> is now in state SSLv3 read server certificate B [type=4098,val=-1].
>
> Jan 07 18:14:43.000 [debug] tor_tls_handshake(): After call, 0x820e1d00 was
> in state SSLv3 read server certificate B
>
> Jan 07 18:14:43.000 [info] TLS error while handshaking with [scrubbed]:
> certificate verify failed (in SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:SSLv3 read server certificate B)
>
> Jan 07 18:14:43.000 [info] connection_tls_continue_handshake(): tls error
> [misc error]. breaking connection.
>
> Jan 07 18:14:43.000 [debug] connection_mark_for_close_internal_(): Calling
> connection_mark_for_close_internal_() on an OR conn at
> src/or/connection_or.c:1341
> Jan 07 18:14:43.000 [debug] channel_close_for_error(): Closing channel
> 0x7a8b2a00 due to lower-layer error
>
> Jan 07 18:14:43.000 [debug] channel_change_state(): Changing state of
> channel 0x7a8b2a00 (global ID 0) from "opening" to "closing"
>
> Jan 07 18:14:43.000 [debug] channel_remove_from_digest_map(): Removed
> channel 0x7a8b2a00 (global ID 0) from identity map in state closing (4)
> with digest 8FA37B93397015B2BC5A525C908485260BE9F4$
> 2
>
>
> Jan 07 18:14:43.000 [debug] conn_close_if_marked(): Cleaning up connection
> (fd 8).
>
> Jan 07 18:14:43.000 [debug] circuit_n_chan_done(): chan to NULL/
> 178.254.44.135:9001, status=0
>
> Jan 07 18:14:43.000 [info] circuit_n_chan_done(): Channel failed; closing
> circ.
>
> Don't know if the problem is on the Tor side or OpenBSD side…
>
> Bye
>
> --
> Olivier

Re: Unable to boot encrypted drive

[Joel Sing]

On Friday 06 January 2017 15:23:32 Timo Myyrä wrote:
> Here's the output of installboot on running system:
> $ doas installboot -v sd1
> Using / as root
> installing bootstrap on /dev/rsd1c
> using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
> sd1: softraid volume with 1 disk(s)
> sd1: installing boot loader on softraid volume
> /usr/mdec/boot is 6 blocks x 16384 bytes
> sd0a: installing boot blocks on /dev/rsd0c, part offset 1104
> master boot record (MBR) at sector 0
> partition 0: type 0xEF offset 64 size 960
> partition 3: type 0xA6 offset 1024 size 1000205876
> /usr/mdec/biosboot will be written at sector 1024
>
> and heres from bsd.rd shell:
> Using /mnt as root
> installing bootstrap on /dev/rsd1c
> using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot
> sd1: softraid volume with 1 disk(s)
> sd1: installing boot loader on softraid volume
> /mnt/usr/mdec/boot is 6 blocks x 16384 bytes
> sd0a: installing boot blocks on /dev/rsd0c, part offset 1104
> master boot record (MBR) at sector 0
>   partition 0: type 0xEF offset 64 size 960
>   partition 3: type 0xA6 offset 1024 size 1000205876
> /mnt/usr/mdec/biosboot will be written at sector 1024
>
> Looking at the output it seems to just copy the regular boot files and
skips
> processing EFI stuff. And as the system boots with EFI it uses the old
> bootloader and hence the problems with opening the crypto volume.

Correct - it is installing the MBR/PBR boot block and boot loader, rather than
the EFI one.

> Should there be check to see if the booted device has i partition with efi
> folder and copy the EFI bootloader in that case?

The code in question is the findgptefisys() function in
src/usr.sbin/installboot/i386_installboot.c. It is likely that there is
something up with your disk configuration (missing protective MBR, incorrect
GPT header, incorrect GPT signature, corrupt checksum, etc) that is making it
think that this is an MBR system, rather than a GPT one. That said, it is also
possible that it is a bug/corner case...

If you're able to sprinkle some printf's through that function and determine
what check is failing, it would help narrow down the issue. You probably also
want to check the MBR and GPT to see what is actually on the disk.

Re: Unable to boot encrypted drive

[Joel Sing]

On Friday 06 January 2017 12:24:02 Timo Myyrä wrote:
> And found it. Seems the efi partitions boot loader isn't updated.

It should be - `installboot -r /mnt ${disk}` is run at the end of the
upgrade.

> Manually copying the efi bootloader fixed the boot:
> https://blog.jasper.la/openbsd-uefi-bootloader-howto/
>
> Why isn't the installer handling this?

I cannot immediately see any reason why it should not be, but I do not have a
GPT machine available to test/verify - I presume there are no failures
reported towards the end of the upgrade?

Can you try running `installboot -v` against the softraid volume?

If that works, can you boot bsd.rd, drop into a shell, mount the root volume
on /mnt, then run `installboot -v -r /mnt` against the root disk?

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Joel Sing]

On Friday 14 October 2016 18:19:21 Bryan Linton wrote:
> On 2016-10-14 09:21:24, Peter Janos  wrote:
> > Hello,
> > 
> > [snip]
> > 
> > ps.: it would be nice to have a feature in the default installer to
> > install
> > with full disc encryption :) we still have to escape to shell during
> > install and ex.:
> > 
> > install60.iso
> > (S)hell
> > dmesg | grep MB # or: sysctl hw.disknames
> > dd if=/dev/urandom of=/dev/rsd0c bs=1m # not needed, only for paranoids
> > dd if=/dev/zero of=/dev/rsd0c bs=1m count=1
> > fdisk -iy sd0
> > disklabel -E sd0
> > a a
> > enter
> > enter
> > RAID
> > w
> > q
> > bioctl -c C -l /dev/sd0a -r 2000 softraid0
> > # use a random high iteration number x > 10 000 000
> 
> I just want to point out (for the archives as well as others) that
> the softraid crypto discipline has recently been switched from
> PBKDF2 to bcrypt.
> 
> http://marc.info/?l=openbsd-cvs=147430724911779=2
> http://www.openbsd.org/faq/current.html#r20160919
> 
> Since bcrypt calculates its rounds based on the exponentiation of
> the number (i.e. the default of 16 rounds actually performs 2^16
> rounds or 65536 rounds), the default number of "rounds" was
> reduced from 8192 to only 16.  If you were to use 20 million
> "rounds" with the new bcrypt algorithm, I wouldn't be surprised if
> it took weeks, months, or even YEARS to actually mount your disk
> after inputting your password.
>
> For reference, I tried to simply calculate 2^20 millionth power
> using dc for my own amusement and gave up after it crunched numbers
> for over a minute with no answer returned.
> 
> A value of 24 (2^24 or 16,777,216) or 25 (2^25 or 33,554,432)
> would probably be closer to what you actually want.

The number of rounds specified for bcrypt_pbdkf(3) is linear, not logarithmic 
(unlike bcrypt(3)). That said, the processing required for each round is 
significantly higher than that of pkcs5_pbkdf2(3) (using `bioctl -r auto -v` 
will tell you rounds your machine will do in ~1s).
 
> > exit
> > Start install to the newly created bioctl/crypt raid device: sdX, where X
> > is ex.: 2...
> > 
> > with a random (but very high) number for iteration, afaik iteration only
> > counts when typing in the password, much higher iteration would slow down
> > brute-force attackers.
> 
> Indeed it would.  Quite significantly in fact.

Re: error building -stable 6.0/amd64 from source on qemu

[Joel Sing]

On Tuesday 20 September 2016 18:26:42 Joel Sing wrote:
> On Tuesday 20 September 2016 09:54:31 soko.tica wrote:
> > Hello,
> > 
> > In trying to build -stable from source, I get an error. I have downloaded
> > and unterred sys.tar.gz and src.tar.gz according to
> > http://www.openbsd.org/faq/faq5.html#Release and updated the sources
> > through cvs, according to the instructions http://man.openbsd.org/release
> > .
> > After I execute (as root, the first time doas produced the same error)
> > 
> > #cd /usr/src && make build
> > 
> > I get the following:
> > 
> > cc
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i
> > nc lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/..
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i
> > n
> > clude
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot
> > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID
> > -D_STANDALONE -nostdinc -fno-builtin -Os -Wall -Werror
> > -fno-stack-protector
> > -DMDRANDOM
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i
> > nc lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/..
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i
> > n
> > clude
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot
> > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID
> > -D_STANDALONE -nostdinc -fno-builtin -Wno-pointer-sign
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../..
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../libsa -I.
> > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64 -DSMALL -DSLOW -DNOBYFOUR
> > -D__INTERNAL_LIBSA_CREAD -DHEAP_LIMIT=0xc0 -c
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > t
> > raid.c: In function 'sr_crypto_decrypt_keys':
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:155: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:155: error: 'SR_CRYPTOKDFT_PKCS5_PBKDF2' undeclared (first use in
> > this function)
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > t
> > raid.c:155: error: (Each undeclared identifier is reported only once
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:155: error: for each function it appears in.)
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:156: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:156: error: 'SR_CRYPTOKDFT_BCRYPT_PBKDF' undeclared (first use in
> > this function)
> 
> I'm not sure what you've done (since the actual commands you ran are not
> specified), however this is -current source, not -stable. Further more
> you've ended up with a mix - sys/dev/softraidvar.h is older than
> sys/lib/libsa/softraid.c.

Actually, sys/lib/libsa/softraid.c is using your installed headers - so your 
source is possibly all -current.
 
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > t
> > raid.c:157: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:180: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:183: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:183: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:185: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:191: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:191: error: dereferencing pointer to incomplete type
> > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof
> > tr aid.c:193: erro

Re: error building -stable 6.0/amd64 from source on qemu

[Joel Sing]

On Tuesday 20 September 2016 09:54:31 soko.tica wrote:
> Hello,
> 
> In trying to build -stable from source, I get an error. I have downloaded
> and unterred sys.tar.gz and src.tar.gz according to
> http://www.openbsd.org/faq/faq5.html#Release and updated the sources
> through cvs, according to the instructions http://man.openbsd.org/release .
> After I execute (as root, the first time doas produced the same error)
> 
> #cd /usr/src && make build
> 
> I get the following:
> 
> cc
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/inc
> lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/..
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/in
> clude
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot
> -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID
> -D_STANDALONE -nostdinc -fno-builtin -Os -Wall -Werror -fno-stack-protector
> -DMDRANDOM
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/inc
> lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/..
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/in
> clude
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot
> -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID
> -D_STANDALONE -nostdinc -fno-builtin -Wno-pointer-sign
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../..
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../libsa -I.
> -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64 -DSMALL -DSLOW -DNOBYFOUR
> -D__INTERNAL_LIBSA_CREAD -DHEAP_LIMIT=0xc0 -c
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/soft
> raid.c: In function 'sr_crypto_decrypt_keys':
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:155: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:155: error: 'SR_CRYPTOKDFT_PKCS5_PBKDF2' undeclared (first use in this
> function)
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/soft
> raid.c:155: error: (Each undeclared identifier is reported only once
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:155: error: for each function it appears in.)
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:156: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:156: error: 'SR_CRYPTOKDFT_BCRYPT_PBKDF' undeclared (first use in this
> function)

I'm not sure what you've done (since the actual commands you ran are not 
specified), however this is -current source, not -stable. Further more you've 
ended up with a mix - sys/dev/softraidvar.h is older than 
sys/lib/libsa/softraid.c.

> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/soft
> raid.c:157: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:180: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:183: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:183: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:185: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:191: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:191: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:193: error: dereferencing pointer to incomplete type
> /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr
> aid.c:198: error: dereferencing pointer to incomplete type
> *** Error 1 in sys/arch/amd64/stand/efiboot/bootx64 (:87
> 'softraid.o')
> *** Error 1 in sys/arch/amd64/stand/efiboot (:48 'all')
> *** Error 1 in sys/arch/amd64/stand (:48 'all')
> *** Error 1 in sys/arch/amd64 (:48 'all')
> *** Error 1 in sys (:48 'all')
> *** Error 1 in . (:48 'all')
> *** Error 1 in /usr/src (Makefile:82 'build')
> # ^D
> 
> Script done on Tue Sep 20 07:16:08 2016
> ==
> 
> Thanks in advance for your input.

Re: encrypted disk image

[Joel Sing]

On Friday 20 May 2016 18:38:08 Ted Unangst wrote:
> Peter Wens wrote:
> > On a encrypted (sd1) OpenBSD 5.9 install (amd64, (qemu, virtio)):
> > 
> > I created a diskimage (dd if=/dev/urandom of=disk.img bs=1m count=100
> > vnconfig vnd0 disk.img
> > fdisk -iy vnd0
> > disklabel -E vnd0 ( a a RAID)
> > 
> > bioctl -c C -l /dev/vnd0a softraid0
> > 
> >   creates sd2newfs /dev/rsd2c
> > 
> > mount /dev/rsd2c /mnt
> > installboot -v -r /mnt sd2 /usr/mdec/biosboot /usr/mdec/boot
> > 
> > then copy some files and at some point the systems locks up.
> > 
> > The same procedure on a unencrypted install no troubles at all.
> > 
> > any suggestion in what's happening?
> 
> Stacking softraid doesn't work. This has irked me for some time, but it's
> the way things are for now.

Stacking softraid does work in general - it is specifically softraid crypto, on 
vnd, on softraid crypto that is known to deadlock (which should now be fixed).

Re: bringing degraded softraid online

[Joel Sing]

On Saturday 06 February 2016 16:09:53 Johan Huldtgren wrote:
> > Not sure. Perhaps these drives don't have good meta data due to the
> > crash?
> > Can you set sr_debug = SR_D_STATE | SR_D_META and see if that prints
> > anything informative?
> 
> well we now get lots more:
> 
> softraid0 at root
> scsibus5 at softraid0: 256 targets
> softraid0: sr_boot_assembly
> softraid0: sr_meta_native_bootprobe
[snip]
> softraid0: assembling volume 05a4f9a1-e533-4e6b-ad0c-7051a541c881 volid
> 0 with 8 chunks
> softraid0: using ondisk metadata version 64 for chunk 0
> softraid0: using ondisk metadata version 64 for chunk 1
> softraid0: using ondisk metadata version 63 for chunk 2
> softraid0: using ondisk metadata version 63 for chunk 3
> softraid0: using ondisk metadata version 63 for chunk 4
> softraid0: using ondisk metadata version 63 for chunk 5
> softraid0: using ondisk metadata version 63 for chunk 6
> softraid0: using ondisk metadata version 63 for chunk 7

This is the reason that the volume will not reassemble - two of your chunks 
have metadata with version 64, while the rest have version 63. As such, only 
chunks 0 and 1 are considered to be online - all others have old metadata and 
are marked offline.

This most likely occurred due to the original panic (from another mail in the 
same thread):

panic: Non dma-reachable buffer at curaddr 0x81115888(raw)
Stopped at Debugger+0x9: leave
TID PID UID PRFLAGS PFLAGS CPU COMMAND
*25637 25637 0 0x14000 0x200 1 srdis
Debugger() at Debugger+0x9
panic() at panic+0xfe
_bus_dmamap_load_buffer() at _bus_dmamap_load_buffer+0x1b6
_bus_dmamap_load() at _bus_dmamap_load+0x7f
ahci_load_prdt() at ahci_load_prdt+0x97
ahci_ata_cmd() at ahci_ata_cmd+0x69
atascsi_disk_cmd() at atascsis_disk_cmd+0x1b1
scsi_xs_exec() scsi_xs_exec+0x35
sdstart() at sdstart+0x16f
scsi_iopool_run() at scsi_iopool_run+0x5d
scsi_xsh_runqueue() at scsi_xsh_runqueue+0x13d
scsi_xsh_add() at scsi_xsh_add+0x98
sdstrategy() at sdstrategy+0x10f
spec_strategy() at spec_strategy+0x53

My guess is that it was in the process of writing out new metadata (version 
64) when it paniced due to the AHCI driver being passed a non dma-reachable 
buffer. This is most likely due to a bug in the softraid code - we're likely 
using a malloc'd buffer in a place where we need to use a dma_alloc'd one.

Re: Killing Rebound(8) in current hard locks system.

[Joel Sing]

On Wednesday 28 October 2015 21:26:16 Ted Unangst wrote:
> Gerald Hanuer wrote:
> >  Hello misc@,
> >  
> >  Killing Rebound(8) in current hard locks system.
> 
> Thanks. We've found the cause of the bug. Now we're trying to find the bug.
> :)

This is fixed with r1.66 of sys/kern/kern_event.c.

Re: Unbound(8) error: could not set SSL_OP_NO_SSLv2

[Joel Sing]

On Monday 26 October 2015 10:42:01 Gerald Hanuer wrote:
>  Hello misc@,
> 
>  Unbound(8) in current errors out, not starting.
> 
>  This is not a bug report.
>  If this is known to devs@ please disregard.
> 
> 
>  /usr/bin/unbound -v
> 
>  Version 1.5.4
>  linked libs: libevent 1.4.15-stable (it uses kqueue), LibreSSL 2.3.1
>  linked modules: dns64 validator iterator
>  BSD licensed, see LICENSE in source package for details.
>  Report bugs to unbound-b...@nlnetlabs.nl
> 
> 
>  /usr/bin/unbound -v -v -d
> 
>  [1445853347] unbound[21343:0] notice: Start of unbound 1.5.4.
>  [1445853347] unbound[21343:0] debug: increased limit(open files) from
> 128 to 4140
>  [1445853347] unbound[21343:0] debug: creating udp4 socket 127.0.0.1 53
>  [1445853347] unbound[21343:0] debug: creating tcp4 socket 127.0.0.1 53
>  [1445853347] unbound[21343:0] error: could not set SSL_OP_NO_SSLv2 \
>  crypto error::lib(0):func(0):reason(0)
>  [1445853347] unbound[21343:0] fatal error: could not set up connect SSL_CTX

Thanks, this should now be fixed.

Re: SR RAID5 rebuild/stability issue.

[Joel Sing]

On Tuesday 22 September 2015 09:58:57 Karel Gardas wrote:
> On Tue, Sep 22, 2015 at 3:20 AM, Chris Cappuccio  wrote:
> > Karel Gardas [gard...@gmail.com] wrote:
> >> Let me ask, should SR RAID5 survive such testing or is for example
> >> rebuilding with off-lined drive considered unsupported feature?
> > 
> > It's new, considered experimental and not well tested.
> 
> OK so I'll omit this from my testing.
> 
> > Are you working with someone to bring your RAID1 changes in tree? The
> > complete, understood improvements should be individually labeled
> > and committed, one by one.
> 
> So far on tech@ I was merely ignored, but this is probably due to the
> fact that I posted patches[1][2][3] clearly marked as a
> work-in-progress. Once the patch is complete I will offer my view how
> it may be divided and perhaps discussion will start...

It has not been ignored; but you've not yet received a reply :)

> [1] https://www.mail-archive.com/tech@openbsd.org/msg25388.html
> [2] https://www.mail-archive.com/tech@openbsd.org/msg25419.html
> [3] https://www.mail-archive.com/tech@openbsd.org/msg25716.html

Re: SR RAID5 rebuild/stability issue.

[Joel Sing]

On Monday 21 September 2015 23:02:39 Karel Gardas wrote:
> Hello,
> 
> due to work on SR RAID1 check summing support where I've touched SR
> RAID internals (workunit scheduling) I'd like to test SR RAID5/6
> functionality on snapshot and on my tree to see that I've not broken
> the stuff while hacking it. My current problem is that I'm not able to
> come with some testing which would not break RAID5 (I'm starting with
> it) after several hours of execution while using snapshot. My test is
> basically:
> - on one console in loop
>   mount raid to /raid
>   rsync /usr/src/ to /raid
>   compute sha1 sums of all files in /raid
>   umount /raid
>   mount /raid
>   check sha1 -- if failure, fail the test, if not, just repeat
> - on another console in loop
>   - off line random drive
>   - wait random time (up to minute)
>   - rebuild raid with the offlined drive
>   - wait random time (up to 2 minutes)
>   - repeat
> 
> Now, the issue with this is that I get sha1 errors from time to time.
> Usually in such case the problematic source file contain some garbage.
> Since I do not yet have a machine dedicated to this testing, I'm using
> for this thinkpad T500 with one drive. I just created 4 RAID slices in
> OpenBSD partition. Last week I've been using vndX devices (and files),
> but this way I even got to kernel panic (on snapshot) like this one:
> http://openbsd-archive.7691.n7.nabble.com/panic-ffs-valloc-dup-alloc-td25473
> 8.html -- so this weekend I've started testing with slices and so far not
> panic, but still data corruption issue. Last snapshot I'm using for testing
> is from last Sunday.
> 
> Let me ask, should SR RAID5 survive such testing or is for example
> rebuilding with off-lined drive considered unsupported feature?

RAID5 should work (ignore RAID6 - it is still incomplete) and rebuilding 
should be functional:

 http://undeadly.org/cgi?action=article=20150413071009

When I reenabled RAID5, I had tested it reasonably as I could, but it still 
needs to be put through its paces. How are you offlining the drive? If you're 
doing it via bioctl then it will potentially behave differently to a hardware 
failure (top down through the bio(4)/softraid(4) driver, instead of bottom up 
via the I/O path). If you can dependably reproduce the issue then I would 
certainly be interested in tracking down the cause.

Re: How to create "paranoid" cipher list in httpd.conf

[Joel Sing]

On Tuesday 01 September 2015 15:14:17 Andreas Thulin wrote:
> Hi misc readers!
> 
> This is my first attempt to ask for help using misc@openbsd.org, so please
> bear with me if I'm making mistakes. Also, apologies if I'm asking about
> something recently discussed.
> 
> I want to limit the number of tls ciphers​ in httpd.conf so that only
> strong (>128 bit) ciphers with Forward Secrecy capabilities (ECDHE) are
> accepted. I'm also only using TLSv1.2.
> 
> My current httpd.conf contains a line saying
> 
> tls ciphers "STRONG:ECDHE:!aNULL:!SSLv3:@STRENGTH"

You could also just use secure (or default):

  tls ciphers "secure"

That will get you "TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE" (looks like I need to 
improve the documentation here...). DHE will be off by default, unless you also 
enable it via "tls dhe ..." (hint: there is a reason why it is off by default).

> which renders out "Configuration OK" with '# /usr/sbin/httpd -n'.
> Also, when testing that string using
> 
> # openssl ciphers -v 'STRONG:ECDHE:!aNULL:!SSLv3:@STRENGTH'
> 
> I get a nice, acceptable list of the ciphers. However, when running a
> server test
> (https://www.ssllabs.com/ssltest/analyze.html?d=andreasthulin.se),
> there's a much longer list of ciphers, including both non-FS and medium
> strength ciphers.
> 
> I'm thinking that either
> 
>1. my assumption that my httpd.conf is all dandy is wrong (highly
>probable),
>2. SSL Labs is lying to me (improbable), or
>3. there's some sort of bug in httpd (improbable).
> 
> Does anyone have any pointers?
>
> OpenBSD 5.8-current (GENERIC) #1095: Mon Aug 24. i386.
> 
> BR
> Andreas

Re: Softraid 1 takes forever to declare disk space free after delete

[Joel Sing]

On Saturday 13 June 2015, Joel Sing wrote:
 On Friday 12 June 2015, Noth wrote:
  Hi misc@
 
 I've got a couple of softraid 1 volumes on a server and the /home one
  was filling up a bit too much so I had to delete a bunch of isos and
  other non necessary items. I did this yesterday and it still hasn't
  cleared the disk space completely yet:
 
  # bioctl -ih sd2
  Volume  Status   Size Device
  softraid0 0 Online   910G sd2 RAID1
 0 Online   910G 0:0.0   noencl sd0d
 1 Online   910G 0:1.0   noencl sd1d
 
  # df -kh
  Filesystem SizeUsed   Avail Capacity  Mounted on
  /dev/sd3a 19.7G5.6G   13.0G30%/
  /dev/sd2a  906G859G1.2G   100%/home
 
  /home # du -sh
  782G.
 
  So there's a rather large disparity there! I've tried issuing sync
  commands a few times over the past 24 hours but to no avail :

 This has nothing to do with softraid - softraid is just a virtual HBA that
 provides a SCSI block device, which you've then put a (presumably FFS) file
 system on top of.

Okay, I'll soften this slightly - if you are actually using softdeps you may 
be encountering an issue with softraid that is slowing/delaying the 
background processing... I'll see if I can reproduce it here once you 
confirm.

  Is there any solution to this apart from waiting for days on end?

 You did not actually give the output from mount(8), however I'm going to
 guess - stop using softdeps?
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Softraid 1 takes forever to declare disk space free after delete

[Joel Sing]

On Friday 12 June 2015, Noth wrote:
 Hi misc@

I've got a couple of softraid 1 volumes on a server and the /home one
 was filling up a bit too much so I had to delete a bunch of isos and
 other non necessary items. I did this yesterday and it still hasn't
 cleared the disk space completely yet:

 # bioctl -ih sd2
 Volume  Status   Size Device
 softraid0 0 Online   910G sd2 RAID1
0 Online   910G 0:0.0   noencl sd0d
1 Online   910G 0:1.0   noencl sd1d

 # df -kh
 Filesystem SizeUsed   Avail Capacity  Mounted on
 /dev/sd3a 19.7G5.6G   13.0G30%/
 /dev/sd2a  906G859G1.2G   100%/home

 /home # du -sh
 782G.

 So there's a rather large disparity there! I've tried issuing sync
 commands a few times over the past 24 hours but to no avail :

This has nothing to do with softraid - softraid is just a virtual HBA that 
provides a SCSI block device, which you've then put a (presumably FFS) file 
system on top of.

 Is there any solution to this apart from waiting for days on end?

You did not actually give the output from mount(8), however I'm going to 
guess - stop using softdeps?
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: OpenBSD 5.7 httpd tls intermediate/chain certificate problem

[Joel Sing]

On Thursday 14 May 2015, Michal Lesniewski wrote:
 Hello,

 I'm trying to configure OpenBSD 5.7 httpd with tls with
 intermediate/chain certificate without no success.

 my httpd.conf:

 server default {
  listen on 10.11.0.200 tls port 443

  tls {
  certificate /etc/ssl/server-unified.pem
  key /etc/ssl/private/server.key
  }

  root /htdocs/default
 }

 types {
  include /usr/share/misc/mime.types
 }



 My certificate is intermediate/chain certificate. That mean I need to
 supply next level certificate that is between my certificate and CA.

 I made that chain certificate concatenating PEM format files with
 corresponding certs (all certs Signature Algorithm:
 sha256WithRSAEncryption)

 cat server.pem sub.class2.server.ca.pem ca-sha2.pem 
 /etc/ssl/server-unified.pem

 server-unified.pem looks like:

 -BEGIN CERTIFICATE-
 (Primary SSL certificate: server.pem)
 -END CERTIFICATE-
 -BEGIN CERTIFICATE-
 (Intermediate certificate: sub.class2.server.ca.pem)
 -END CERTIFICATE-
 -BEGIN CERTIFICATE-
 (Root certificate: ca-sha2.pem)
 -END CERTIFICATE-

 Certificate and key installed in default locations:

 # ls -alh /etc/ssl/private/server.key
 -r  1 root  wheel   6.2K May 13 19:40 /etc/ssl/private/server.key
 # ls -alh /etc/ssl/server.pem
 -rw-r--r--  1 root  wheel   3.3K May 13 19:41 /etc/ssl/server.pem
 # ls -alh /etc/ssl/server-unified.pem
 -rw-r--r--  1 root  wheel   8.0K May 14 13:53 /etc/ssl/server-unified.pem


 I try to test using openssl s_client:

 michal@michal-MSQ87TN:~$ openssl s_client -connect 10.11.0.200:443
 CONNECTED(0003)
 GET / HTTP/1.0



 httpd log:


 # httpd -dvv
 startup
 server_tls_load_keypair: using certificate /etc/ssl/server-unified.pem
 server_tls_load_keypair: using private key /etc/ssl/private/server.key
 socket_rlimit: max open files 1024
 socket_rlimit: max open files 1024
 server_privinit: adding server default
 server_privinit: adding server default
 socket_rlimit: max open files 1024
 server_launch: running server default
 server_launch: running server default
 server_launch: running server default

  there is no server_tls_init
  nothing apears when started openssl s_client command

This smells very much like the same problem that has been mentioned on the 
list earlier - with a 6KB private key and a 8KB bundle, you're almost 
certainly hitting the 16K limit for a single imsg. Unfortunately there were 
missing return value checks which means that this fails silently. If you can 
try httpd from -current you will likely see an error instead of a silent 
failure. Otherwise you can try removing one of the certificates from the 
bundle in order to reduce the size and see if it then 
reports server_tls_init and starts working.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: OpenBSD 5.7 httpd tls intermediate/chain certificate problem

[Joel Sing]

On Thursday 14 May 2015, Michal Lesniewski wrote:
 On 14.05.2015 15:02, Joel Sing wrote:
  On Thursday 14 May 2015, Michal Lesniewski wrote:
  Hello,
 
  I'm trying to configure OpenBSD 5.7 httpd with tls with
  intermediate/chain certificate without no success.
 
  my httpd.conf:
 
  server default {
listen on 10.11.0.200 tls port 443
 
tls {
certificate /etc/ssl/server-unified.pem
key /etc/ssl/private/server.key
}
 
root /htdocs/default
  }
 
  types {
include /usr/share/misc/mime.types
  }
 
 
 
  My certificate is intermediate/chain certificate. That mean I need to
  supply next level certificate that is between my certificate and CA.
 
  I made that chain certificate concatenating PEM format files with
  corresponding certs (all certs Signature Algorithm:
  sha256WithRSAEncryption)
 
  cat server.pem sub.class2.server.ca.pem ca-sha2.pem 
  /etc/ssl/server-unified.pem
 
  server-unified.pem looks like:
 
  -BEGIN CERTIFICATE-
  (Primary SSL certificate: server.pem)
  -END CERTIFICATE-
  -BEGIN CERTIFICATE-
  (Intermediate certificate: sub.class2.server.ca.pem)
  -END CERTIFICATE-
  -BEGIN CERTIFICATE-
  (Root certificate: ca-sha2.pem)
  -END CERTIFICATE-
 
  Certificate and key installed in default locations:
 
  # ls -alh /etc/ssl/private/server.key
  -r  1 root  wheel   6.2K May 13 19:40
  /etc/ssl/private/server.key # ls -alh /etc/ssl/server.pem
  -rw-r--r--  1 root  wheel   3.3K May 13 19:41 /etc/ssl/server.pem
  # ls -alh /etc/ssl/server-unified.pem
  -rw-r--r--  1 root  wheel   8.0K May 14 13:53
  /etc/ssl/server-unified.pem
 
 
  I try to test using openssl s_client:
 
  michal@michal-MSQ87TN:~$ openssl s_client -connect 10.11.0.200:443
  CONNECTED(0003)
  GET / HTTP/1.0
 
 
 
  httpd log:
 
 
  # httpd -dvv
  startup
  server_tls_load_keypair: using certificate /etc/ssl/server-unified.pem
  server_tls_load_keypair: using private key /etc/ssl/private/server.key
  socket_rlimit: max open files 1024
  socket_rlimit: max open files 1024
  server_privinit: adding server default
  server_privinit: adding server default
  socket_rlimit: max open files 1024
  server_launch: running server default
  server_launch: running server default
  server_launch: running server default
 
  there is no server_tls_init
  nothing apears when started openssl s_client command
 
  This smells very much like the same problem that has been mentioned on
  the list earlier - with a 6KB private key and a 8KB bundle, you're almost
  certainly hitting the 16K limit for a single imsg. Unfortunately there
  were missing return value checks which means that this fails silently. If
  you can try httpd from -current you will likely see an error instead of a
  silent failure. Otherwise you can try removing one of the certificates
  from the bundle in order to reduce the size and see if it then
  reports server_tls_init and starts working.

 tested on -current:

 # httpd -dv
 startup
 server_tls_load_keypair: using certificate /etc/ssl/server-unified.pem
 server_tls_load_keypair: using private key /etc/ssl/private/server.key
 socket_rlimit: max open files 1024
 server_privinit: adding server default
 server_privinit: adding server default
 config_setserver: failed to compose IMSG_CFG_SERVER imsg for `default':
 Result too large
 fatal: send server: Result too large
 socket_rlimit: max open files 1024
 logger exiting, pid 4965
 socket_rlimit: max open files 1024
 server exiting, pid 10727
 server exiting, pid 32594
 server exiting, pid 5337

 Above situation occurs when I have server cert + intermediate + ca and
 only server cert + intermediate in server-chain.pem.
 httpd starts only when I supply only my server cert to it.
 Is there any solution to run httpd with such big private key?

Try this (albeit only tested a little beyond compilation...)

Index: config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.37
diff -u -p -r1.37 config.c
--- config.c11 Apr 2015 14:52:49 -  1.37
+++ config.c14 May 2015 13:58:57 -
@@ -193,14 +193,6 @@ config_setserver(struct httpd *env, stru
iov[c].iov_base = srv-srv_conf.return_uri;
iov[c++].iov_len = srv-srv_conf.return_uri_len;
}
-   if (srv-srv_conf.tls_cert_len != 0) {
-   iov[c].iov_base = srv-srv_conf.tls_cert;
-   iov[c++].iov_len = srv-srv_conf.tls_cert_len;
-   }
-   if (srv-srv_conf.tls_key_len != 0) {
-   iov[c].iov_base = srv-srv_conf.tls_key;
-   iov[c++].iov_len = srv-srv_conf.tls_key_len;
-   }
 
if (id == PROC_SERVER 
(srv-srv_conf.flags  SRVFLAG_LOCATION) == 0) {
@@ -220,6

Re: smtpd outbound SSL3_GET_KEY_EXCHANGE:bad dh p length

[Joel Sing]

On Tuesday 31 March 2015, Marcus MERIGHI wrote:
 Hello,

 frankenstein warning: stable.mtier.org, all patches applied

 the mail server in question doesn't deliver to a certain destination
 (Network error on destination MXs). Other destinations work. When I
 connect manually I can send messages via the destination server. But no
 TLS involved this way. SMTP greeting of destination server:

 $ nc 216.55.105.124 25
 220 mobile-systems.at ESMTP Sendmail 8.14.5/8.13.4; Mon, 30 Mar 2015
   13:12:39 +0200 (CEST)

 log entries on originating server:

 Mar 30 13:11:18 frax smtpd[28031]: smtp-out: Connecting to
   smtp+tls://216.55.105.124:25 (216.55.105.124.hera.net) on session
   23d6e647b646bf14...
 Mar 30 13:11:18 frax smtpd[28031]: smtp-out: Connected on session
   23d6e647b646bf14
 Mar 30 13:11:24 frax smtpd[28031]: smtp-out: Error on session
   23d6e647b646bf14: IO Error: error:1408D06E:SSL
   routines:SSL3_GET_KEY_EXCHANGE:bad dh p length
 Mar 30 13:11:24 frax smtpd[28031]: smtp-out: Disabling route [] -
   216.55.105.124 (216.55.105.124.hera.net) for 800s
 Mar 30 13:11:24 frax smtpd[28031]: smtp-out: No valid route for
   [connector:[]-[relay:yyy.at,heloname=mail.xxx.at],0x0]
 Mar 30 13:11:24 frax smtpd[28031]: smtp-out: No valid route for
   [connector:[]-[relay:yyy.at,heloname=mail.xxx.at],0x0]

 I guess it's about the line:

 Error on session 23d6e647b646bf14: IO Error: error:1408D06E:SSL
   routines:SSL3_GET_KEY_EXCHANGE:bad dh p length

 Any hints on what's going wrong here?

Assuming you've patched, this is most likely due to the restrictions imposed 
on the minimum size of the DH parameters supplied in the ServerKeyExchange 
for TLS (r1.108 of src/lib/libssl/src/ssl/s3_clnt.c) - this means the remote 
end is probably using 512-bit DH params.

That said, they seem to be offering 1024-bit DH currently:

$ openssl s_client -connect 216.55.105.124:25 -starttls smtp
...
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1
Cipher: DHE-RSA-AES256-SHA
..

Is it now working?

 Any hints on how to solve or work around?

From your side you could disable 'ALL:!DHE', lower the minimum from 1024 to 
512 in s3_clnt.c or get the remote side to use better DH parameters (assuming 
they have not already changed it).

 Thanks in advance, Marcus

 P.S.: is m...@opensmtpd.org dead? https://www.opensmtpd.org/list.html
 does not say so, but upon sending to the list it I got a not
 subscribed warning message to my subscription address (checked the
 address with old subscribtion notification).

 OpenBSD 5.6 (GENERIC.MP) #5: Thu Dec 11 09:51:08 CET 2014

 r...@stable-56-amd64.mtier.org:/binpatchng/work-binpatch56-amd64/src/sys/ar
ch/amd64/compile/GENERIC.MP real mem = 4276822016 (4078MB)
 avail mem = 4154187776 (3961MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcff9c000 (46 entries)
 bios0: vendor Dell Inc. version 1.4.3 date 06/05/2009
 bios0: Dell Inc. PowerEdge R200
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S4 S5
 acpi0: tables DSDT FACP APIC SPCR HPET MCFG WDAT SLIC ERST HEST BERT EINJ
 SSDT SSDT SSDT acpi0: wakeup devices PCI0(S5)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz, 1600.30 MHz
 cpu0:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2
,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu0: 3MB 64b/line 8-way L2
 cache
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 266MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz, 1600.06 MHz
 cpu1:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2
,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu1: 3MB 64b/line 8-way L2
 cache
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 0, remapped to apid 2
 ioapic1 at mainbus0: apid 3 pa 0xfec1, version 20, 24 pins
 ioapic1: misconfigured as apic 0, remapped to apid 3
 acpihpet0 at acpi0: 14318179 Hz
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 1 (PEX1)
 acpiprt2 at acpi0: bus 2 (SBE0)
 acpiprt3 at acpi0: bus 3 (PXHA)
 acpiprt4 at acpi0: bus 4 (SBE4)
 acpiprt5 at acpi0: bus 5 (SBE5)
 acpiprt6 at acpi0: bus 6 (COMP)
 acpicpu0 at acpi0: PSS
 acpicpu1 at acpi0: PSS
 ipmi at mainbus0 not configured
 cpu0: Enhanced SpeedStep 1600 MHz: speeds: 2667, 

Re: questions to the security of softraid_crypto

[Joel Sing]

On Monday 02 March 2015, Peter J. Philipp wrote:
 On 03/01/15 23:17, Ted Unangst wrote:
  Peter J. Philipp wrote:
  Hi,
 
  I am not the best C reader and programmer out there so I try to make
  myself tools that may seem useless in order to better understand.  I see
  this in /sys/dev/softraid_crypto.c
 
  
  int
  sr_crypto_encrypt(u_char *p, u_char *c, u_char *key, size_t size, int
  alg) {
  rijndael_ctxctx;
  int i, rv = 1;
 
  switch (alg) {
  case SR_CRYPTOM_AES_ECB_256:
 
  This function is only used to encrypt the master key, which is a small
  chunk of random data.

 Thanks for taking a look Tedu, I really appreciate it.  I'm wondering
 does this master key use salt to protect against rainbow tables?  At a
 glance at the code I see not mention of salt.

I would strongly suggest that you follow the entire path through, rather than 
reading small pieces of code and guessing as to how the rest of the code may 
be implemented. In other words, you might want to undertake some research and 
see if you can answer the following questions (the questions that you are 
asking will likely be answered in the process):

- What encryption algorithm/mode is used for disk block encryption?

- Where do the keys come from that are used for the disk block 
encryption/decryption?

- How are the keys that are used to encrypt the disk blocks stored?

- When creating a new softraid crypto volume, where does the key come from?

- What happens if you use a keydisk instead of a passphrase?

  dd if=/dev/zero of=EFS2 bs=1g count=1
  vnconfig vnd0 EFS2
  bioctl -c C -l /dev/vnd0a softraid0
 
  And I created a filesystem on it and populated it.  In fact I use this
  EFS2 file for storing work related things in it (so I can never share
  it).  I ran this program over the EFS2 file:
 
  so it says that there is 652063 occurences where AES blocks were
  duplicated, to me that's near 10 MB of material someone can use like the
  above [1] where it says it could describe the data pattern.
 
  It seems more likely you found the 652063 zero blocks that haven't been
  written to yet.
 
  Note that if you are concerned about people doing stat analysis on your
  encrypted disk, you should be sure to overwrite the entirety of it.
  Either with /dev/random on the outside, or /dev/zero on the inside, to
  ensure the used and unused portions look the same.

 That's good advice I'll try to fill up the space inside with a file and
 see if the number of those blocks goes down.  It isn't all zero blocks
 but the majority of it could be.

By design softraid does not scrub or overwrite what is on the underlying disk 
chunks until such time as you actually write data to the softraid volume. As 
Ted noted, you will need to fill the disk chunks (or softraid volume) 
yourself if you want to guarantee such a state.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: postgresql-server exiting abnormally after upgrade to -snapshot

[Joel Sing]

On Saturday 14 February 2015, Hugo Osvaldo Barrera wrote:
 On 2015-02-14 02:28, Abel Abraham Camarillo Ojeda wrote:
  On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera h...@barrera.io

 wrote:
   On 2015-02-13 13:20, Stuart Henderson wrote:
   On 2015-02-12, Hugo Osvaldo Barrera h...@barrera.io wrote:
On 2015-02-12 10:18, Stuart Henderson wrote:
On 2015-02-11, Hugo Osvaldo Barrera h...@barrera.io wrote:
 Can
 someone else confirm postgres9.4 work fine on the latest
 -snapshot?
  
   (the
  
 confirmation would be helpful to reafirm that it's not an issue

 with

   some
  
 dependency or library).
   
Works fine on my bacula box, running 9.4.1 (and previously 9.4.0)
on
  
   amd64.
  
Ok, so now I know that the issue is on my end. Which leaves me even

 more

confused. You're running the latest snapshots too, right? (eg: the

 ones

   from
  
feb 10th?).
   
Aside from a clean install, do you have any more changes? Perhaps
  
   login.conf?
  
   I have the login.conf section from the example in the pkg-readme,
  
   postgresql:\
  
   :openfiles-cur=768:\
   :tc=daemon:
  
   and this in sysctl.conf
  
   # postgresql
   kern.seminfo.semmni=256
   kern.seminfo.semmns=2048
   kern.shminfo.shmmax=50331648
  
   sthen@hutch:~:532$ ls -l /bin/ls /usr/local/bin/postgres
   -r-xr-xr-x  1 root  bin   267968 Feb 10 23:19 /bin/ls*
   -r-xr-xr-x  1 root  bin  6508711 Feb  9 03:21 /usr/local/bin/postgres*
  
   sthen@hutch:~:533$ sysctl kern.version
   kern.version=OpenBSD 5.7-beta (GENERIC) #797: Tue Feb 10 16:26:12 MST

 2015

   t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
  
   Thanks for all the details. It looks like almost everything is
   identical except our kernels (I had a few extra fields in sysctl.conf
   edited for

 pg,

   but
   reverted them just to make sure they weren't screwing up).
  
 # sysctl kern.version
 kern.version=OpenBSD 5.7-beta (GENERIC.MP) #852: Tue Feb 10 16:31:16

 MST

   2015
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  
   I switched to the SP kernel just to discard any possible regressions
   that might
   be affecting this scenario, but no change.
  
   It looks like the issue is elsewhere, but I've no idea where to look.
   I've

 so

   far failed to build postgresql-server with debug symbols enabled too,
   but that's just lack of knowledge on my part.
  
   --
   Hugo Osvaldo Barrera
   A: Because we read from top to bottom, left to right.
   Q: Why should I start my reply below the quoted text?
  
   [demime 1.01d removed an attachment of type application/pgp-signature]
 
  you should give more information about how to reproduce this problem,
  how accurately can you reproduce it, are you sending just a given query
  and it always crashes?

 It always crashes extremely frequently. I haven't noticed a pattern, and
 the server never lives more than a few senconds. No particular query seems
 to trigger it, and adding log_statement showed that it may even crash
 *before* any
 queries are executed (see below as well).

  you should get more error context, maybe try log_statement into

 postgresql.conf

  and try to log all statements and see which one crashes it...
 
  http://www.postgresql.org/docs/9.4/static/runtime-config-logging.html
 
  are you using any custom C extension?

 Nope, this is a plain default install from snapshots with nothing extra.

  did you dump and restore database ? did you use 'custom format' or
  'plain format' ?

 My latest tests reproduce the same issue on a clean out-of-the-box db
 (eg: not importing any data).

  there where any errors on import? - postgres just warns about some
  import errors,
  which in my opinion are severe...

 This is a log with log_statement and a most logging turned on. I'd only run
 the
 server *once* post-initialization before this. The database was completely
 empty:

 http://sprunge.us/UVGj

 While a query managed to get through once, the server usually crashed
 before that happens.

The interesting/useful part is:

LOG:  statement: SELECT ... ORDER BY c.oid
LOG:  server process (PID 11531) was terminated by signal 6: Abort trap

So the server process is being sent a SIGABRT, which is causing it to 
terminate. There is a good chance this this is coming from the stack 
protector, which sends a SIGABRT if the stack is smashed.

Is there anything in dmesg or syslog that correlates?

Failing that your next step is likely to run it under gdb and get a backtrace 
from the point where the SIGABRT occurs. You can also bisect by rolling back 
to an older snapshot to see if you can locate the change that has triggered 
the issue.

 Here's another, finer-grained log, with nothing useful (apperently) either:

 http://sprunge.us/FQaJ

 Thanks,

 --
 Hugo Osvaldo Barrera
 A: Because we read from top to bottom, left to right.
 Q: Why should I start my reply below the quoted text?

 [demime 1.01d 

Re: Too much SUID/SGID files!

[Joel Sing]

On Tuesday 06 January 2015, whoami toask wrote:
 Hello,

 isn't there too much SUID/SGID files on a default OpenBSD install?

 Can this number be reduced?

Of course it can!

$ find / -perm -4000 -o -perm -2000 -exec chmod 0 {} \;

 Example: why does wall, write, modstat need an SGID?

 # uname -a
 OpenBSD notebook.lan 5.6 GENERIC.MP#333 amd64
 # find / -perm -4000 -o -perm -2000 -ls -print
  78047 5856 -rwxr-sr-x1 root auth  2970920 Aug  6 21:45
 /usr/X11R6/bin/xlock/usr/X11R6/bin/xlock 78068 1216 -rwxr-sr-x1 root   
  utmp   592056 Aug  6 22:09 /usr/X11R6/bin/xterm/usr/X11R6/bin/xterm
 1147497   60 -r-xr-sr-x1 root kmem30200 Jul 31 11:50
 /usr/local/bin/libgtop_server2/usr/local/bin/libgtop_server2 78031   32
 -r-xr-sr-x1 root utmp15864 Jul 31 09:57
 /usr/local/libexec/gnome-pty-helper/usr/local/libexec/gnome-pty-helper
 155910   84 -r-xr-sr-x4 root crontab 41752 Aug  8 08:06
 /usr/bin/at/usr/bin/at 155910   84 -r-xr-sr-x4 root crontab
 41752 Aug  8 08:06 /usr/bin/atq/usr/bin/atq 155910   84 -r-xr-sr-x4
 root crontab 41752 Aug  8 08:06 /usr/bin/atrm/usr/bin/atrm 155910  
 84 -r-xr-sr-x4 root crontab 41752 Aug  8 08:06
 /usr/bin/batch/usr/bin/batch 155943   72 -r-xr-sr-x1 root crontab  
   36504 Aug  8 08:06 /usr/bin/crontab/usr/bin/crontab 156014   24
 -r-xr-sr-x1 root auth11672 Aug  8 08:06
 /usr/bin/lock/usr/bin/lock 156019   60 -r-xr-sr-x1 root daemon 
 28952 Aug  8 08:06 /usr/bin/lpq/usr/bin/lpq 156033   20 -r-xr-sr-x1
 root _lkm 8952 Aug  8 08:06 /usr/bin/modstat/usr/bin/modstat
 156035  292 -r-xr-sr-x1 root kmem   148216 Aug  8 08:06
 /usr/bin/netstat/usr/bin/netstat 156093   24 -r-xr-sr-x1 root auth 
   11544 Aug  8 08:06 /usr/bin/skeyaudit/usr/bin/skeyaudit 156094   16
 -r-xr-sr-x1 root auth 8184 Aug  8 08:06
 /usr/bin/skeyinfo/usr/bin/skeyinfo 156095   44 -r-xr-sr-x1 root
 auth20632 Aug  8 08:06 /usr/bin/skeyinit/usr/bin/skeyinit 156105 
 704 -r-xr-sr-x1 root _sshagnt   333656 Aug  8 08:07
 /usr/bin/ssh-agent/usr/bin/ssh-agent 156112  284 -r-xr-sr-x1 root
 kmem   144568 Aug  8 08:06 /usr/bin/systat/usr/bin/systat 156146   32
 -r-xr-sr-x1 root tty 15928 Aug  8 08:06
 /usr/bin/wall/usr/bin/wall 156152   28 -r-xr-sr-x1 root tty
 13080 Aug  8 08:06 /usr/bin/write/usr/bin/write 103939   40 -r-xr-sr-x4
 root _token  20344 Aug  8 08:06
 /usr/libexec/auth/login_activ/usr/libexec/auth/login_activ 103939   40
 -r-xr-sr-x4 root _token  20344 Aug  8 08:06
 /usr/libexec/auth/login_crypto/usr/libexec/auth/login_crypto 103943   40
 -r-xr-sr-x1 root _radius 19928 Aug  8 08:06
 /usr/libexec/auth/login_radius/usr/libexec/auth/login_radius 103945   24
 -r-xr-sr-x1 root auth11608 Aug  8 08:06
 /usr/libexec/auth/login_skey/usr/libexec/auth/login_skey 103939   40
 -r-xr-sr-x4 root _token  20344 Aug  8 08:06
 /usr/libexec/auth/login_snk/usr/libexec/auth/login_snk 103939   40
 -r-xr-sr-x4 root _token  20344 Aug  8 08:06
 /usr/libexec/auth/login_token/usr/libexec/auth/login_token 103947   40
 -r-xr-sr-x1 root auth20408 Aug  8 08:06
 /usr/libexec/auth/login_yubikey/usr/libexec/auth/login_yubikey 103987 1568
 -r-xr-sr-x1 root smmsp  783576 Aug  8 08:08
 /usr/libexec/sendmail/sendmail/usr/libexec/sendmail/sendmail 52023   80
 -r-xr-sr-x1 root daemon  39736 Aug  8 08:06
 /usr/sbin/lpc/usr/sbin/lpc 52024  160 -r-xr-s---1 root daemon 
 80952 Aug  8 08:06 /usr/sbin/lpd/usr/sbin/lpd 52073   52 -r-xr-sr-x1
 root kmem24664 Aug  8 08:06 /usr/sbin/pstat/usr/sbin/pstat
 5196804 drwxrws---2 root wheel 512 Aug  8 08:05
 /var/audit/var/audit # find / -perm -4000 -o -perm -2000 -ls -print | wc -l
 32

 Thanks,

 have a secure day!



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: freeradius problem - ephemeral RSA key generation

[Joel Sing]

On Wednesday 31 December 2014, Kapetanakis Giannis wrote:
 On 31/12/14 04:37, Joel Sing wrote:
  On Wednesday 31 December 2014, Kapetanakis Giannis wrote:
  Hi,
 
  After upgrading to latest snapshot I have problems with freeradius 2.2.5
  package not starting.
 
  Especially the problem occurs in loading of module eap-tls
 
  rlm_eap_tls: Couldn't set ephemeral RSA key
  rlm_eap: Failed to initialize type tls
  /etc/raddb/eap.conf[17]: Instantiation failed for module eap
 
  I've tried installing version 2.2.6 but I have the same problem.
 
  The program fails at:
  src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c
 
  /*
 * Generate ephemeral RSA keys.
 */
  static int generate_eph_rsa_key(SSL_CTX *ctx)
  {
   RSA *rsa;
 
   rsa = RSA_generate_key(512, RSA_F4, NULL, NULL);
 
   if (!SSL_CTX_set_tmp_rsa(ctx, rsa)) {
  radlog(L_ERR, rlm_eap_tls: Couldn't set ephemeral RSA key);
  return -1;
   }
 
   RSA_free(rsa);
   return 0;
  }
 
  is this related to freeradius or something with OpenBSD ssl libraries?
 
  Support for ephemeral RSA keys was removed from LibreSSL, since it should
  only be needed for export ciphers (no longer supported) or otherwise
  violating RFCs (as at first glance FreeRADIUS appears to do above).
 
  Since you're already looking at the code, does it set
  SSL_OP_EPHEMERAL_RSA anywhere? If not, the above function is probably a
  noop. At the very least it is likely buggy since they are supposed to
  call SSL_CTX_need_tmp_RSA() to see if the temporary RSA key should be
  set, before calling SSL_CTX_set_tmp_rsa().

 Well I've already made it working last night by adding a check
 for SSL_CTX_need_tmp_RSA before calling SSL_CTX_set_tmp_rsa

Excellent. You might want to see if you can get that upstream.

 So if I get it right, since I'm using HIGH ciphersuite I will never need
 an ephemeral RSA key correct?

Correct - LibreSSL no longer has any export ciphersuites and no longer 
supports ephemeral RSA keys.

 Is there a case were that SSL_CTX_need_tmp_RSA() will be true?

Not if you are using LibreSSL (or BoringSSL) - from s3_lib.c:

case SSL_CTRL_NEED_TMP_RSA:
ret = 0;
break;
case SSL_CTRL_SET_TMP_RSA:
case SSL_CTRL_SET_TMP_RSA_CB:
SSLerr(SSL_F_SSL3_CTRL, ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED);
break;

 SSL_OP_EPHEMERAL_RSA is not defined anywhere.

So presumably it was added so that they could support export cipher suites... 
the commit message that added the code appears to be useless though:

http://www.project-moonshot.org/gitweb/?p=freeradius.git;a=commitdiff;h=12b7f6efb1bbf6c70061d590a5ddfb1f71b0fefd
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: freeradius problem - ephemeral RSA key generation

[Joel Sing]

On Wednesday 31 December 2014, Kapetanakis Giannis wrote:
 On 31/12/14 11:29, Joel Sing wrote:
  Well I've already made it working last night by adding a check
  for SSL_CTX_need_tmp_RSA before calling SSL_CTX_set_tmp_rsa
 
  Excellent. You might want to see if you can get that upstream.

 Yes i've subscribed to their list and send it already.

Thanks.

  So if I get it right, since I'm using HIGH ciphersuite I will never need
  an ephemeral RSA key correct?
 
  Correct - LibreSSL no longer has any export ciphersuites and no longer
  supports ephemeral RSA keys.

 I'm a bit confused with LibreSSL. Has it already replaced OpenSSL in
 OpenBSD?
 radiusd is linked with libssl and libcrypto. Are these from OpenSSL or
 LibreSSL?
 I thought LibreSSL is libtls/libressl
 (http://www.openbsd.org/faq/current.html#20141031)

The libssl/libcrypto in OpenBSD 5.6 is LibreSSL.

Quoting www.libressl.org, LibreSSL is composed of four parts:

1. The openssl(1) utility, which provides tools for managing keys, 
certificates, etc.
2. libcrypto: a library of cryptography fundamentals
3. libssl: a TLS library, backwards-compatible with OpenSSL
4. libtls: a new TLS library, designed to make it easier to write foolproof 
applications

We renamed libressl to libtls to avoid confusion on that front :)

  Is there a case were that SSL_CTX_need_tmp_RSA() will be true?
 
  Not if you are using LibreSSL (or BoringSSL) - from s3_lib.c:
 
   case SSL_CTRL_NEED_TMP_RSA:
   ret = 0;
   break;
   case SSL_CTRL_SET_TMP_RSA:
   case SSL_CTRL_SET_TMP_RSA_CB:
   SSLerr(SSL_F_SSL3_CTRL,
  ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED); break;
 
  SSL_OP_EPHEMERAL_RSA is not defined anywhere.
 
  So presumably it was added so that they could support export cipher
  suites... the commit message that added the code appears to be useless
  though:
 
  http://www.project-moonshot.org/gitweb/?p=freeradius.git;a=commitdiff;h=1
 2b7f6efb1bbf6c70061d590a5ddfb1f71b0fefd



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: freeradius problem - ephemeral RSA key generation

[Joel Sing]

On Wednesday 31 December 2014, Kapetanakis Giannis wrote:
 Hi,

 After upgrading to latest snapshot I have problems with freeradius 2.2.5
 package not starting.

 Especially the problem occurs in loading of module eap-tls

 rlm_eap_tls: Couldn't set ephemeral RSA key
 rlm_eap: Failed to initialize type tls
 /etc/raddb/eap.conf[17]: Instantiation failed for module eap

 I've tried installing version 2.2.6 but I have the same problem.

 The program fails at:
 src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c

 /*
   * Generate ephemeral RSA keys.
   */
 static int generate_eph_rsa_key(SSL_CTX *ctx)
 {
 RSA *rsa;

 rsa = RSA_generate_key(512, RSA_F4, NULL, NULL);

 if (!SSL_CTX_set_tmp_rsa(ctx, rsa)) {
radlog(L_ERR, rlm_eap_tls: Couldn't set ephemeral RSA key);
return -1;
 }

 RSA_free(rsa);
 return 0;
 }

 is this related to freeradius or something with OpenBSD ssl libraries?

Support for ephemeral RSA keys was removed from LibreSSL, since it should only 
be needed for export ciphers (no longer supported) or otherwise violating 
RFCs (as at first glance FreeRADIUS appears to do above).

Since you're already looking at the code, does it set SSL_OP_EPHEMERAL_RSA 
anywhere? If not, the above function is probably a noop. At the very least it 
is likely buggy since they are supposed to call SSL_CTX_need_tmp_RSA() to see 
if the temporary RSA key should be set, before calling SSL_CTX_set_tmp_rsa().

 regards,

 Giannis

-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: ssl handshake errors with python

[Joel Sing]

On Thu, 6 Nov 2014, Rusty wrote:
 On 11/05/14 20:04, Joel Sing wrote:
  On Thu, 6 Nov 2014, Ted Unangst wrote:
  I see errors trying to download some https URLs using python, but the
  base ftp client isn't affected. 5.6 release and current. One example is
  https://www.duosecurity.com/feed.
 
  athens:/tmp python2.7
  Python 2.7.8 (default, Oct  6 2014, 13:51:42)
  [GCC 4.2.1 20070719 ] on openbsd5
  Type help, copyright, credits or license for more information.
 
  import urllib
  urllib.urlopen('https://www.duosecurity.com/feed')
 
  Traceback (most recent call last):
 File stdin, line 1, in module
 File /usr/local/lib/python2.7/urllib.py, line 87, in urlopen
   return opener.open(url)
 File /usr/local/lib/python2.7/urllib.py, line 208, in open
   return getattr(self, name)(url)
 File /usr/local/lib/python2.7/urllib.py, line 437, in open_https
   h.endheaders(data)
 File /usr/local/lib/python2.7/httplib.py, line 991, in endheaders
   self._send_output(message_body)
 File /usr/local/lib/python2.7/httplib.py, line 844, in _send_output
   self.send(msg)
 File /usr/local/lib/python2.7/httplib.py, line 806, in send
   self.connect()
 File /usr/local/lib/python2.7/httplib.py, line 1198, in connect
   self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
 File /usr/local/lib/python2.7/ssl.py, line 392, in wrap_socket
   ciphers=ciphers)
 File /usr/local/lib/python2.7/ssl.py, line 148, in __init__
   self.do_handshake()
 File /usr/local/lib/python2.7/ssl.py, line 310, in do_handshake
   self._sslobj.do_handshake()
  IOError: [Errno socket error] [Errno 1] _ssl.c:510: error:14077410:SSL
  routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
 
  The server requires SNI, which libtls/ftp(1) does. If you make s_client
  do SNI it works:
 
  $ openssl s_client -connect www.duosecurity.com:443 \
 -servername www.duosecurity.com
 
  So you'd need to make Python handle SNI if you want to talk to it... FWIW
  the site is hosted on Amazon Cloudfront, so you'll probably see the same
  with any other site that uses it.
 
  athens:/tmp ftp https://www.duosecurity.com/feed
  Trying 54.192.22.134...
  Requesting https://www.duosecurity.com/feed
  118278 bytes received in 0.17 seconds (673.14 KB/s)

 hmm. not documented at all.
 I am not sure if this actually explains anything but it throws a few
 names and acronyms around that can be used for further information.

Thanks. Unfortunately this diff is against /usr/share/man/man1/openssl.1, 
which is not current so it failed to apply. I've just committed a version of 
this diff, including part from the current OpenSSL documentation.

You'd be surprised how many options existing in openssl(1) that are not 
documented and not in usage... OpenSSL documented some of these 
semi-recently - it would be a useful exercise for someone to identify these 
and document the ones that are worth documenting.

 --- /usr/share/man/man1/openssl.1   Fri Oct 31 17:43:53 2014
 +++ openssl.1   Wed Nov  5 23:33:46 2014
 @@ -6617,6 +6617,7 @@
   .Op Fl psk_identity Ar identity
   .Op Fl quiet
   .Op Fl reconnect
 +.Op Fl servername Ar host
   .Op Fl showcerts
   .Op Fl ssl3
   .Op Fl starttls Ar protocol
 @@ -6773,6 +6774,8 @@
   .It Fl reconnect
   Reconnects to the same server 5 times using the same session ID; this can
   be used as a test that session caching is working.
 +.It Fl servername Ar host
 +Use specified host name as the Server Name Indicater (SNI)
   .It Fl showcerts
   Display the whole server certificate chain: normally only the server
   certificate itself is displayed.

-- 

   Stop assuming that systems are secure unless demonstrated insecure;
start assuming that systems are insecure unless designed securely.
  - Bruce Schneier

Re: softraid crypto root with serial console?

[Joel Sing]

On Thu, 6 Nov 2014, TJ wrote:
 On Wed, Nov 05, 2014 at 11:33:21PM -0500, Ted Unangst wrote:
  On Wed, Nov 05, 2014 at 23:04, John Merriam wrote:
   Hello.  I am trying to create a 'headless' setup using a softraid
   crypto root with serial console on OpenBSD 5.6-release amd64.
  
   I have everything installed and working just fine, except I'm having a
   problem getting the 'headless' part going.
  
   I followed the instructions in section 7.6 of the FAQ at
   http://www.openbsd.org/faq/faq7.html#SerCon   I edited /etc/ttys to
   enable the getty for tty00.  I added 'set tty com0' to /etc/boot.conf
  
   It doesn't seem to work though.  The Passphrase: prompt is still output
   to pc0, not com0.
  
   If I enter a bogus password at the Passphrase: prompt on pc0 to get to
   a boot prompt, I can enter 'set tty com0' after which I get a
   Passphrase: prompt on com0 and everything works fine.
  
   It seems like for some reason /etc/boot.conf is not being seen/used?  I
   would guess it might have something to do with the softraid crypto root
   setup but I don't know.
 
  Right. boot.conf is encrypted, so of course it can't be read until
  after the passphrase has been read.
 
   Is there a bit that needs flipping somewhere to get the serial console
   to work with crypto root?  Any info or pointers on this would be
   greatly appreciated.  Thanks.
 
  If you look in sys/arch/amd64/stand/libsa/bioscons.c you'll see two
  functions, pc_probe and com_probe, which set cn-cn_pri. You'll need
  to swap MIDPRI and LOWPRI and rebuild, then rerun installboot.
 
  That either makes sense or is a bunch of gibberish. I haven't actually
  worked this out, so I can't give you a precise recipe.

 Alternatively, you could make a small unencrypted a partition on the
 disk with just an /etc/boot.conf file that contains the following:

 set tty com0
 boot sr0a:/bsd

 Then do the crypto softraid install to another partition and it should
 boot like you'd expect.

 See: http://permalink.gmane.org/gmane.os.openbsd.misc/206003

For now this is what I would recommend...
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: crypto softraid and keydisk on same harddrive

[Joel Sing]

On Wed, 29 Oct 2014, Patrik Lundin wrote:
 On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote:
  You could try this (only compile tested) diff:

 I tried this diff on 5.5-stable and it appeared to solve my problem! The
 system now boots from sr0a without asking for a passphrase. Overwriting
 the keydisk partition makes the bootloader stop at the passphrase prompt.

Thanks - I'll rehash it and get it in at some point... as an aside, the 
easiest way to destroy a softraid CRYPTO volume is to simply run 'bioctl -c 
C -C force ...' as that will replace the block encryption keys in the 
metadata (and works regardless of passphrase or key disk).

 Thanks a lot!

 Regards,
 Patrik Lundin
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: crypto softraid and keydisk on same harddrive

[Joel Sing]

On Tue, 28 Oct 2014, Patrik Lundin wrote:
 Thank you Stefan for taking a look, see comments inline:

 On Mon, Oct 27, 2014 at 12:32:30PM +0100, Stefan Sperling wrote:
  On Sun, Oct 26, 2014 at 09:19:25PM +0100, Patrik Lundin wrote:
   # disklabel -E wd0
   Create the following partitions (in this order to make the biggest
   partition last):
   wd0b (swap)
   wd0d (RAID) - keydisk (1M)
   wd0a (RAID) - the remaining part of the drive that will be encrypted.
 
  I'd use wd0d instead of wd0a, because 'a' is usually expected
  to contain a root partition, not a softraid volume. That has
  nothing to do with the problem at hand though.

 Given that wd0d is used for the keydisk, do you mean i
 should use wd0e for the remainder of the drive instead of 'a'?

This does not matter - wd0a can be RAID. Stefan was just suggesting you avoid 
using 'a' since it is normally root. There is no technical reason to change 
this.

 Would this also mean I should skip creating a sd0a altogether?

   ===
   Using drive 0, partition 3.
   Loading.
   ERR M
   ===
 
  This error means biosboot(8) can't find the boot(8) program.
  When booting from softraid, the boot program is stored at a particular
  offset in the softraid meta data area, and installboot(8) patches that
  offset into biosboot(8) before copying biosboot(8) to the MBR.
  Apparently, biosboot(8) has the wrong offset in your case.

 Hmm, interesting, thanks for the description!

  Your report lacks some information:
  - architecture (i386 / amd64 / ...)

 I am using amd64.

  - full output of 'disklabel wd0' to show exactly how you configured
partitions

 I stuck to my original layout for consistency (this has been written
 down by hand):

 ===
 # disklabel wd0
 # /dev/rwd0c:
 type: ESDI
 disk: ESDI/IDE disk
 label: VBOX HARDDISK
 duid: 175d4587e45a04a5
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 3916
 total sectors: 62914560
 boundstart: 64
 boundend: 62910540
 drivedata: 0

 16 partitions:
 #   size offset  fstype [fsize bsize cpg]
   a:586854454225095RAID
   b: 4208966 64swap
   c:62914560  0  unused
   d:   160654209030RAID
 ===

 So wd0a is 28GB, wd0b is 2G, and wd0d is 7.8M.

  - output of running installboot with the -v option on the softraid
volume: installboot -v sd0

 Since I am not able to boot on the device i have to run installboot as
 the last step in the installer. For this i need to add -r /mnt (of
 course the following is also copied by hand):

 ===
 # installbook -v -r /mnt sd0
 Using /mnt as root
 installing bootstrap on /dev/rsd0c
 using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot
 sd0: softraid volume with 2 disk(s)
 sd0: installing boot loader on softraid volume
 /mnt/usr/mdec/boot is 5 blocks x 16384 bytes
 wd0a: installing boot blocks on /dev/rwd0c, part offset 4225175
 master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 62910476
 /mnt/usr/mdec/biosboot will be written at sector 64
 wd0d: installing boot blocks on /dev/rwd0c, part offset 4209110
 master boot record (MBR) at sector 0
 partition 3: type 0xA6 offset 64 size 62910476
 /mnt/usr/mdec/biosboot will be written at sector 64
 ===

A CRYPTO key disk is slightly special in that it has softraid metadata but is 
not technically part of the same volume (well, it is in some ways but it is 
not in others). The problem in question occurs since installboot(8) installs 
the first stage boot loader on each chunk that is a member of the volume - in 
this case it installs first stage boot loader twice (once for wd0a and again 
for wd0d). The second stage boot loader is installed in the softraid metadata 
area for the sd0 volume, however in the case of a CRYPTO key disk its 
metadata area does not end up with a copy of the boot of the second stage 
loader (unlike, say a RAID 1 chunk). If the first stage boot blocks are 
installed in the CRYPTO volume then the key disk, the boot loader (in the PBR 
of wd0) will end up pointing at a boot storage area (of the key disk) that 
does not contain the second stage boot loader. The fix is to probably avoid 
installing the boot loader on the key disk.

   When I do this the system manages to boot without a passphrase, using
   the encrypted drive.
 
  I suspect there is a problem in installboot(8) in case the keydisk is
  on the same disk as the crypto volume. The boot(8) program which is the
  first program to interpret softraid meta data doesn't even get to run
  in your case.

 I see, I hope the output I supplied above can give you some insight!

 Regards,
 Patrik Lundin
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: crypto softraid and keydisk on same harddrive

[Joel Sing]

On Wed, 29 Oct 2014, Joel Sing wrote:
 On Tue, 28 Oct 2014, Patrik Lundin wrote:
[snip]
  Since I am not able to boot on the device i have to run installboot as
  the last step in the installer. For this i need to add -r /mnt (of
  course the following is also copied by hand):
 
  ===
  # installbook -v -r /mnt sd0
  Using /mnt as root
  installing bootstrap on /dev/rsd0c
  using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot
  sd0: softraid volume with 2 disk(s)
  sd0: installing boot loader on softraid volume
  /mnt/usr/mdec/boot is 5 blocks x 16384 bytes
  wd0a: installing boot blocks on /dev/rwd0c, part offset 4225175
  master boot record (MBR) at sector 0
 partition 3: type 0xA6 offset 64 size 62910476
  /mnt/usr/mdec/biosboot will be written at sector 64
  wd0d: installing boot blocks on /dev/rwd0c, part offset 4209110
  master boot record (MBR) at sector 0
  partition 3: type 0xA6 offset 64 size 62910476
  /mnt/usr/mdec/biosboot will be written at sector 64
  ===

 A CRYPTO key disk is slightly special in that it has softraid metadata but
 is not technically part of the same volume (well, it is in some ways but it
 is not in others). The problem in question occurs since installboot(8)
 installs the first stage boot loader on each chunk that is a member of the
 volume - in this case it installs first stage boot loader twice (once for
 wd0a and again for wd0d). The second stage boot loader is installed in the
 softraid metadata area for the sd0 volume, however in the case of a CRYPTO
 key disk its metadata area does not end up with a copy of the boot of the
 second stage loader (unlike, say a RAID 1 chunk). If the first stage boot
 blocks are installed in the CRYPTO volume then the key disk, the boot
 loader (in the PBR of wd0) will end up pointing at a boot storage area (of
 the key disk) that does not contain the second stage boot loader. The fix
 is to probably avoid installing the boot loader on the key disk.

You could try this (only compile tested) diff:

Index: i386_softraid.c
===
RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v
retrieving revision 1.2
diff -u -p -r1.2 i386_softraid.c
--- i386_softraid.c 9 Jun 2014 13:13:48 -   1.2
+++ i386_softraid.c 28 Oct 2014 14:21:27 -
@@ -42,6 +42,7 @@ void  sr_install_bootldr(int, char *);
 void
 sr_install_bootblk(int devfd, int vol, int disk)
 {
+   struct bioc_vol bv;
struct bioc_disk bd;
struct disklabel dl;
struct partition *pp;
@@ -56,6 +57,15 @@ sr_install_bootblk(int devfd, int vol, i
bd.bd_diskid = disk;
if (ioctl(devfd, BIOCDISK, bd) == -1)
err(1, BIOCDISK);
+
+   /* Skip CRYPTO key disks. */
+   /* XXX - pass volume in rather than volume ID. */
+   memset(bv, 0, sizeof(bv));
+   bv.bv_volid = vol;
+   if (ioctl(devfd, BIOCVOL, bv) == -1)
+   err(1, BIOCVOL);
+   if (bv.bv_level == 'C'  bd.bd_size == 0)
+   return;
 
/* Check disk status. */
if (bd.bd_status != BIOC_SDONLINE  bd.bd_status != BIOC_SDREBUILD) {

-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: multiple calls to OpenSSL_add_all_algorithms

[Joel Sing]

On Thu, 23 Oct 2014, Martijn van Duren wrote:
 Hello misc@,

 I'm currently trying to write a library that heavily relies on
 libcrypto. Because I don't want applications linking to it, to have to
 call OpenSSL_add_all_algorithms, for convenience, I added those calls to
 the appropriate places in my library. Because of this nature, the
 function is called multiple times, and even if I shielded it within my
 library it could still be called outside of it by an application using
 my library.
 On AMD64 (OpenBSD 5.5-stable) this hasn't given me any problems yet, but
 as soon as I run my code on i386 (5.6-current) it crashes with the
 following trace:
 #0  obj_name_LHASH_COMP (arg1=0x0, arg2=0x857b7630) at
 /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/objects/o_names.c:97
 #1  0x0e91190c in getrn (lh=0x867d0380, data=0x857b7630, rhash=Variable
 rhash is not available.
 ) at
 /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:419 #2 
 0x0e911c92 in lh_insert (lh=0x867d0380, data=0x857b7630) at
 /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:192
 #3  0x0e8a0852 in OBJ_NAME_add (name=0x2e800aac aes-256-cfb, type=2,
 data=0x2e815360 ­\001)
  at
 /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/objects/o_names.c:181
 #4  0x0e8a0149 in EVP_add_cipher (c=0x2e815360) at
 /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/names.c:80
 #5  0x0e8384f3 in OpenSSL_add_all_ciphers () at
 /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_allc.c:183
 #6  0x0e8357bc in OPENSSL_add_all_algorithms_noconf () at
 /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_all.c:76

 I'm aware that the OpenSSL_add_all_algorithms(3) says:
 A typical application will call OpenSSL_add_all_algorithms() initially
 and EVP_cleanup() before exiting.
 but it doesn't explicitly says that it can only be called ones without
 causing problems.

 Could anyone tell me if this kind of use of this function is the
 undefined behaviour area that I should avoid or if this is a bug? If it
 is grey area that should be avoided, what is the recommended way to
 initialise ciphers and digests from within the library without risking
 crashes from initialization from within an application? I do use
 EVP_get_{cipher,digest}bynid(3), so all ciphers and digests need to be
 available.

Something strange seems to be happening here.

As far as I can tell, OpenSSL_add_all_algorithms() should be safe to call 
multiple times and I'm not able to reproduce the crash on 
OpenBSD/i386-current (for performance reasons you probably want to avoid 
doing this whenver you can, but as far as I can tell nothing should prevent 
it from working). However, keep in mind that most of these functions are not 
thread safe.

obj_name_LHASH_COMP(arg1=0x0, arg2=0x857b7630) means that we've already ended 
up with an entry in the LHASH that has a NULL data value (not that we're 
trying to insert one). The only insert in the name_lh has an explicit NULL 
check and there should be no other way (short of manually inserting a NULL 
value or changing an existing data pointer to NULL) to trigger this.

If you can provide a minimal reproducable test case I can attempt to dig 
further.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: bioctl weirdness

[Joel Sing]

On Wed, 24 Sep 2014, Dan Becker wrote:
 two identical drives... shutdown system remove one turn the system back on

 bioctl shows the partitions as 536871980544 which is 137. something times
 bigger than the drive

 oddly enough it is 512 times the size of the partition

 536871980544/1048578087
 512.

 in a few days I will have all the data moved to another set of drives and
 be more than willing to do some debugging

That looks normal/expected - the size of the partition is in 512-byte blocks, 
the size from bioctl is in bytes. Using the -h option will give you 
human-readable output.

 # bioctl softraid0
 Volume  Status   Size Device
 softraid0 0 Degraded 536871980544 sd1 RAID1
   0 Offline 0 0:0.0   noencl wd0a
   1 Online   536871980544 0:1.0   noencl wd1a
 softraid0 1 Degraded 536871980544 sd2 RAID1
   0 Online   536871980544 1:0.0   noencl wd1b
   1 Offline 0 1:1.0   noencl wd0b
 softraid0 2 Degraded 536871980544 sd3 RAID1
   0 Online   536871980544 2:0.0   noencl wd1d
   1 Offline 0 2:1.0   noencl wd0d
 softraid0 3 Degraded 389781911040 sd4 RAID1
   0 Online   389781911040 3:0.0   noencl wd1e
   1 Offline 0 3:1.0   noencl wd0e

 # disklabel sd1
 # /dev/rsd1c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 1d42ceb8d332594e
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 65270
 total sectors: 1048578087
 boundstart: 0
 boundend: 1048578087
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   10485780480  4.2BSD   4096 327681
   c:   10485780870  unused
 # disklabel sd2
 # /dev/rsd2c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 978b49563ef3223a
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 65270
 total sectors: 1048578087
 boundstart: 0
 boundend: 1048578087
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   10485780480  4.2BSD   4096 327681
   c:   10485780870  unused
 # disklabel sd3
 # /dev/rsd3c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 8e245525f52a55d0
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 65270
 total sectors: 1048578087
 boundstart: 0
 boundend: 1048578087
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   10485780480  4.2BSD   4096 327681
   c:   10485780870  unused
 # disklabel sd4
 # /dev/rsd4c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 390559d487f82e16
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 47388
 total sectors: 761292795
 boundstart: 0
 boundend: 761292795
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:7612927360  4.2BSD   4096 327681
   c:7612927950  unused
 # disklabel
 wd0

 # /dev/rwd0c:
 type: ESDI
 disk: ESDI/IDE disk
 label: Hitachi HDS5C302
 duid: 6c7c163233d6b678
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 243201
 total sectors: 3907029168
 boundstart: 0
 boundend: 3907029168
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   1048578551   64RAID
   b:   1048578615   1048578615RAID
   c:   39070291680  unused
   d:   1048578615   2097157230RAID
   e:761293323   3145735845RAID



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: bioctl weirdness

[Joel Sing]

On Wed, 24 Sep 2014, Dan Becker wrote:
 forgot to add this relevant part

 # bioctl -R /dev/wd0a sd1
 softraid0: wd0a partition too small, at least 536871980544 bytes required
 #

Again, note the bytes vs blocks. That has most likely been fixed already, 
however without a dmesg I have no idea what kernel you're running with. My 
guess is this is a softraid volume with pre-bootable metadata...

 On Tue, Sep 23, 2014 at 7:40 PM, Dan Becker geg...@gmail.com wrote:
  two identical drives... shutdown system remove one turn the system back
  on
 
  bioctl shows the partitions as 536871980544 which is 137. something times
  bigger than the drive
 
  oddly enough it is 512 times the size of the partition
 
  536871980544/1048578087
  512.
 
  in a few days I will have all the data moved to another set of drives and
  be more than willing to do some debugging
 
 
 
  # bioctl softraid0
  Volume  Status   Size Device
  softraid0 0 Degraded 536871980544 sd1 RAID1
0 Offline 0 0:0.0   noencl wd0a
1 Online   536871980544 0:1.0   noencl wd1a
  softraid0 1 Degraded 536871980544 sd2 RAID1
0 Online   536871980544 1:0.0   noencl wd1b
1 Offline 0 1:1.0   noencl wd0b
  softraid0 2 Degraded 536871980544 sd3 RAID1
0 Online   536871980544 2:0.0   noencl wd1d
1 Offline 0 2:1.0   noencl wd0d
  softraid0 3 Degraded 389781911040 sd4 RAID1
0 Online   389781911040 3:0.0   noencl wd1e
1 Offline 0 3:1.0   noencl wd0e
 
  # disklabel sd1
  # /dev/rsd1c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 1d42ceb8d332594e
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 65270
  total sectors: 1048578087
  boundstart: 0
  boundend: 1048578087
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   10485780480  4.2BSD   4096 327681
c:   10485780870  unused
  # disklabel sd2
  # /dev/rsd2c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 978b49563ef3223a
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 65270
  total sectors: 1048578087
  boundstart: 0
  boundend: 1048578087
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   10485780480  4.2BSD   4096 327681
c:   10485780870  unused
  # disklabel sd3
  # /dev/rsd3c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 8e245525f52a55d0
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 65270
  total sectors: 1048578087
  boundstart: 0
  boundend: 1048578087
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   10485780480  4.2BSD   4096 327681
c:   10485780870  unused
  # disklabel sd4
  # /dev/rsd4c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 390559d487f82e16
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 47388
  total sectors: 761292795
  boundstart: 0
  boundend: 761292795
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:7612927360  4.2BSD   4096 327681
c:7612927950  unused
  # disklabel
  wd0
 
  # /dev/rwd0c:
  type: ESDI
  disk: ESDI/IDE disk
  label: Hitachi HDS5C302
  duid: 6c7c163233d6b678
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 243201
  total sectors: 3907029168
  boundstart: 0
  boundend: 3907029168
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   1048578551   64RAID
b:   1048578615   1048578615RAID
c:   39070291680  unused
d:   1048578615   2097157230RAID
e:761293323   3145735845RAID



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: openssl in startx/xinit: trying again

[Joel Sing]

On Fri, 29 Aug 2014, Nicholas Fleisher wrote:
 I found another place where the path to the openssl binary needs to be
 updated.  Here is a pair of diffs: one for configure and one for
 configure.ac

Thanks. According to matthieu@, the hardcoded paths to /usr/sbin/openssl 
should not be used if openssl is found by the test above:

AC_PATH_PROGS(MCOOKIE, [mcookie], [$MCOOKIE],
  [$PATH:/bin:/usr/bin:/usr/lib:/usr/libexec:/usr/local/bin])

So this should work correctly already.

 -Nick
 Index: xenocara/app/xinit/configure
 ===
 RCS file: /cvs/xenocara/app/xinit/configure,v
 retrieving revision 1.20
 diff -u -p -u -r1.20 configure
 --- xenocara/app/xinit/configure  28 Aug 2014 17:34:57 -  1.20
 +++ xenocara/app/xinit/configure  29 Aug 2014 01:48:30 -
 @@ -11075,7 +11075,7 @@ test -n $OPENSSL || OPENSSL=$OPENSSL
  else
  case $host_os in
  *openbsd*)
 -MCOOKIE='/usr/sbin/openssl rand -hex 16'
 +MCOOKIE='/usr/bin/openssl rand -hex 16'
  ;;
  *solaris*)
  MCOOKIE=/usr/bin/od -X -A n -N 16 /dev/urandom |
 /usr/bin/tr -d ' ' Index: xenocara/app/xinit/configure.ac
 ===
 RCS file: /cvs/xenocara/app/xinit/configure.ac,v
 retrieving revision 1.15
 diff -u -p -u -r1.15 configure.ac
 --- xenocara/app/xinit/configure.ac   28 Aug 2014 17:34:29 -  1.15
 +++ xenocara/app/xinit/configure.ac   28 Aug 2014 20:29:09 -
 @@ -174,7 +174,7 @@ if test x$MCOOKIE = x ; then
  else
  case $host_os in
  *openbsd*)
 -MCOOKIE='/usr/sbin/openssl rand -hex 16'
 +MCOOKIE='/usr/bin/openssl rand -hex 16'
  ;;
  *solaris*)
  MCOOKIE=/usr/bin/od -X -A n -N 16 /dev/urandom |
 /usr/bin/tr -d ' '



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Update path to openssl in startx

[Joel Sing]

On Fri, 29 Aug 2014, Nicholas Fleisher wrote:
 Hi all,

 Just upgraded to Aug 26 snapshot (amd64) and followed the current.html
 instructions, including deleting the old /usr/sbin/openssl. Upon
 trying to start X using startx, I got an error saying that the cookie
 couldn't be set because /usr/sbin/openssl couldn't be found. Changing
 /usr/sbin/openssl to /usr/bin/openssl manually in the script fixes the
 problem.

There is a possiblity that the X snapshots were lagging - the 
usr/X11R6/bin/startx script in xshare56.tgz from my local mirror (Aug 28) has 
the correct openssl path.

 I haven't tried recompiling from source, but I believe I've located
 the file that needs changing in the xenocara tree and have attached a
 diff. Others will know better than I if similar changes might need to
 be made elsewhere in the tree.

 Best,
 Nick

 [demime 1.01d removed an attachment of type application/octet-stream which
 had a name of patch]

-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Changing naming order of HDD SD drives on boot by kernel

[Joel Sing]

On Fri, 15 Aug 2014, Denis Lapshin wrote:
 My fstab has identity for main boot HDD:

 548ac03903a985e9.a / ffs rw 1 1
 548ac03903a985e9.g /home ffs rw,nodev,nosuid 1 2
 548ac03903a985e9.d /tmp ffs rw,nodev,nosuid 1 2
 548ac03903a985e9.f /usr ffs rw,nodev 1 2
 548ac03903a985e9.e /var ffs rw,nodev,nosuid 1 2
 835806792ad105b8.b none swap sw
 127.0.0.1:/home/cvs /var/www/cvs nfs rw,nodev,nosuid 0 0

 but once I installed usb flash drive and reboot the system, my main boot
 HDD stay SD3 instead of SD1 as it should be.
 The HDD is encrypted by softraid discipline additionally, so kernel
 physically determine it as SD0, softraid mount it as SD1.

 Any additional drive detected by kernel stop booting from main HDD
 SD0=SR SD1 because of renaming all SD drives.

Why?

What is referencing the sd0/sd1 device directly, rather than using a DUID?

 In FAQ I found about drives renumeration by kernel:

 The first drive of a particular type identified by OpenBSD will be
 drive '0', the second will be '1', etc. So, the first IDE-like disk will
 be wd0, the third SCSI-like disk will be sd2. If you have two SCSI-like
 drives and three IDE-like drives on a system, you would have sd0, sd1,
 wd0, wd1, and wd2 on that machine. The order is based on the order they
 are found during hardware discovery at boot. There are a few key points
 to keep in mind:

   * Drives may not be numbered in the same order as your boot ROM
 attempts to boot them (i.e., your system may attempt to boot what
 OpenBSD identifies as wd2 or sd1). Sometimes you may be able to
 change this, sometimes not.
   * Removing or adding a disk may impact the identity of other drives on
 the system.

 

 I would like bind SD labels to drives in invariable fashion.

In short, there is no way to do this - this is what DUIDs are for.

 On 15.08.2014 11:51, Daniel Jakots wrote:
  On Fri, 15 Aug 2014 11:37:56 +0400, Denis Lapshin den...@mindall.org
 
  wrote:
  Is it possible to change or set fixed device names for drives like
  SD0, SD1, SD2, SD3 and so on.
 
  http://www.openbsd.org/faq/faq14.html#DUID
 
 
  Cheers,



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: softraid not bootable in 5.4 after visiting 5.5

[Joel Sing]

On Wed, 6 Aug 2014, Raimo Niskanen wrote:
 On Wed, Aug 06, 2014 at 01:04:23AM +1000, Joel Sing wrote:
  On Tue, 5 Aug 2014, Raimo Niskanen wrote:
   On Thu, Jul 31, 2014 at 06:12:49PM +0200, Raimo Niskanen wrote:
Hello misc@
   
I once created an USB stick (uSDHC card with reader, actually) using
OpenBSD 5.4 (might have been an earlier that I later binary upgraded)
that contains a softraid encrypted and bootable OpenBSD installation.
It has worked just fine.
   
Just now I created a new stick with OpenBSD 5.5 in the same way,
since binary upgrading seemed awkward due to the time_t change,
and while doing so I attached the old stick to copy configuration
files.  When attaching it softraid0 said something about roaming disk
that was sdX but now sdY - updating metadata, which is not unusual.
   
At least I think that is what triggered the problem...
   
After this the old USB stick does not boot.  The list of disks
that show up in the boot prompt are: hd0, hd1, and sr0, but
sr0 is no longer marked with a '*' which I beleive indicates
bootability, so boot(8) tries to boot hd1 and fails.
If I tell boot(8) via set device sd0a to boot from sd0
it does so and that works fine.
   
So autmatic booting now does not work on the old stick?
Is this a bug or expected?  Can I fix the old stick?
(just curious, it is not that important)
   
Some more details: both sticks have an MBR with just the last
slot type A6 (dedicated for OpenBSD), and their disklabels
have a partition 'a' of type RAID and a swap partition 'b'.
The whole installation is then within the softraid disk.
The old stick was created on i386 and the new on amd64.
   
I hope that was enough information for someone to get an idea.
   
I myself suspect there is some kind of metadata change that
got written when roaming to OpenBSD 5.5 that the old boot(8)
loader gets confused by.  Nevertheless it is surprising that
roaming a softraid disk can change it to the worse...
  
   For the record.
  
   I have been informed that it is very likely that some kind of metadata
   change was written to the disk which confuses the old boot loader.
 
  I highly doubt this, especially given that there have been no real
  metadata related changes for multiple releases.
 
  The fact that sr0 still shows up means that the metadata is correctly
  identified. The lack of the '*' after sr0 means that the BIOC_SCBOOTABLE
  flag has been cleared - rerunning installboot on the softraid device will
  re-enable the flag (and update the boot loader).

 I booted the old system and used it's installboot.

 It worked like a charm - thanks!

Excellent. Good to hear.

   Furthermore this is an odd not prioritized use case.  What is supposed
   to work is to move a softraid disk to a new release and run it there.
 
  My guess is that you ran 'bioctl -d' to delete the volume - this will
  have cleared the BIOC_SCBOOTABLE flag and set the flags to
  BIOC_SCNOAUTOASSEMBLE. One can argue that this is a bug, however one of
  the long standing gripes with softraid is that there is no distinction
  between create vs attach and delete vs detach. Fixing this is somewhere
  on my TODO list...

 Good catch!  That I did since I wanted to detach the volume.

 Would not deleting the volume and just leaving it online until reboot have
 worked better in this case?

Yes, that would have left the flags intact.

 I wish you luck with fixing this problem.  That would be superb!

Thanks. It is not technically difficult, I just have to find the time :)

   My guess is that if there has been a metadata format change in softraid
   it is a good strategy to rewrite that metadata when the disk gets
   imported so the new softraid code then will not have to account for
   multible metadata formats during normal operation.
 
  Migrations between versions are handled - if necessary, the metadata will
  get updated when you attach the softraid volume.

 And that might mean that the volume becomes unusable in an older release...
 Correct?

Correct. Once the metadata has been upgraded to the new version, the old 
kernel will not be able to assemble it... but that's the price of progress.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: softraid not bootable in 5.4 after visiting 5.5

[Joel Sing]

On Tue, 5 Aug 2014, Raimo Niskanen wrote:
 On Thu, Jul 31, 2014 at 06:12:49PM +0200, Raimo Niskanen wrote:
  Hello misc@
 
  I once created an USB stick (uSDHC card with reader, actually) using
  OpenBSD 5.4 (might have been an earlier that I later binary upgraded)
  that contains a softraid encrypted and bootable OpenBSD installation.
  It has worked just fine.
 
  Just now I created a new stick with OpenBSD 5.5 in the same way,
  since binary upgrading seemed awkward due to the time_t change,
  and while doing so I attached the old stick to copy configuration
  files.  When attaching it softraid0 said something about roaming disk
  that was sdX but now sdY - updating metadata, which is not unusual.
 
  At least I think that is what triggered the problem...
 
  After this the old USB stick does not boot.  The list of disks
  that show up in the boot prompt are: hd0, hd1, and sr0, but
  sr0 is no longer marked with a '*' which I beleive indicates
  bootability, so boot(8) tries to boot hd1 and fails.
  If I tell boot(8) via set device sd0a to boot from sd0
  it does so and that works fine.
 
  So autmatic booting now does not work on the old stick?
  Is this a bug or expected?  Can I fix the old stick?
  (just curious, it is not that important)
 
  Some more details: both sticks have an MBR with just the last
  slot type A6 (dedicated for OpenBSD), and their disklabels
  have a partition 'a' of type RAID and a swap partition 'b'.
  The whole installation is then within the softraid disk.
  The old stick was created on i386 and the new on amd64.
 
  I hope that was enough information for someone to get an idea.
 
  I myself suspect there is some kind of metadata change that
  got written when roaming to OpenBSD 5.5 that the old boot(8)
  loader gets confused by.  Nevertheless it is surprising that
  roaming a softraid disk can change it to the worse...

 For the record.

 I have been informed that it is very likely that some kind of metadata
 change was written to the disk which confuses the old boot loader.

I highly doubt this, especially given that there have been no real metadata 
related changes for multiple releases.

The fact that sr0 still shows up means that the metadata is correctly 
identified. The lack of the '*' after sr0 means that the BIOC_SCBOOTABLE flag 
has been cleared - rerunning installboot on the softraid device will 
re-enable the flag (and update the boot loader).

 Furthermore this is an odd not prioritized use case.  What is supposed to
 work is to move a softraid disk to a new release and run it there.

My guess is that you ran 'bioctl -d' to delete the volume - this will have 
cleared the BIOC_SCBOOTABLE flag and set the flags to BIOC_SCNOAUTOASSEMBLE. 
One can argue that this is a bug, however one of the long standing gripes 
with softraid is that there is no distinction between create vs attach and 
delete vs detach. Fixing this is somewhere on my TODO list...

 My guess is that if there has been a metadata format change in softraid it
 is a good strategy to rewrite that metadata when the disk gets imported
 so the new softraid code then will not have to account for multible
 metadata formats during normal operation.

Migrations between versions are handled - if necessary, the metadata will get 
updated when you attach the softraid volume.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: LibreSSL: in-place replacement on FreeBSD?

[Joel Sing]

On Sat, 12 Jul 2014, Jens K. Loewe wrote:
 Not sure where to leave this one (is there a separate LibreSSL mailing
 iist available somewhere?), but I have just read the announcement that
 LibreSSL 2.0 is available for FreeBSD too.

 Can I use it as an in-place replacement for my existing OpenSSL
 libraries just by recompiling my ports with it?

In short, yes. Please try it and let us know if you find problems.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Why doesn't GCM HTTPS work with nginx?

[Joel Sing]

On Thu, 3 Jul 2014, Ez Egy wrote:
 Since these two are using GCM:

 www.ssllabs.com: ECDHE-RSA-AES256-GCM-SHA384
 www.google.com: ECDHE-RSA-AES128-GCM-SHA256

 We wanted to make our webserver HTTPS connection more secure (don't look at
 the self-signed certificate, that doesn't count right now..)

 We are using an OpenBSD 5.4 64bit, and the openssl ciphers command says
 that it supports the ECDHE-RSA-AES256-GCM-SHA384 cipher. On client side
 there is Firefox 30 at least.

 So here is how we setup the HTTPS server:

 # generate self signed certificate
 openssl genrsa -aes256 -out /etc/ssl/private/server.key 4096
 openssl req -new -key /etc/ssl/private/server.key -out
 /etc/ssl/private/server.csr
 openssl x509 -sha512 -req -days 365 -in /etc/ssl/private/server.csr
 -signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt

 The config:

 vi /etc/nginx/nginx.conf
 ...
 ssl_protocols TLSv1.2;
 ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384;
 ssl_prefer_server_ciphers   on;
 ...

 But Firefox says (I translated it from my language..):

 A connection to the www.foo.com is interrupted

 and ssllabs ( https://www.ssllabs.com/ssltest/ ) says:

 Assessment failed: Failed to communicate with the secure server

 Question: How can we set GCM in nginx? Why couldn't a fresh Firefox connect
 via HTTPS to foo.com (ECDHE-RSA-AES256-GCM-SHA384,TLSv1.2)? It can connect
 to www.ssllabs.com via HTTPS (ECDHE-RSA-AES256-GCM-SHA384,TLSv1.2) so maybe
 it's not a client side problem..

 [user@localhost ~] openssl s_client -connect www.foo.com:443
 CONNECTED(0003)
 depth=0 C = HU, CN = www.foo.com
 verify error:num=18:self signed certificate
 verify return:1
 depth=0 C = HU, CN = www.foo.com
 verify return:1
 ---
 Certificate chain
  0 s:/C=HU/CN=www.foo.com
i:/C=HU/CN=www.foo.com
 ---
 Server certificate
 -BEGIN CERTIFICATE-
  here goes the cert..
 -END CERTIFICATE-
 subject=/C=HU/CN=www.foo.com
 issuer=/C=HU/CN=www.foo.com
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 2137 bytes and written 389 bytes
 ---
 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384

You've just proven that nginx is working with ECDHE-RSA-AES256-GCM-SHA384 
(assuming that www.foo.com is actually your server).

 Server public key is 4096 bit

Compared to ssllabs:

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit

I would suspect that your client (Firefox) issues are related to your server 
certificate/public key, rather than the cipher.

 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1.2
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: softeaid rebuild very slow

[Joel Sing]

On Sun, 13 Apr 2014, John Cox wrote:
 Hi

 I'm running OpenBSD 5.4 (dmesg below) with softraid in mirror mode.
 One of the drives failed so I replaced it - the first time that RAID
 has actually saved my data as opposed to simply making my life harder!
 Thank you softraid.

 They are 3T drives and it looks like the rebuild is going to take ~5
 days to do.  Is this expected?  Is there any config parameter that I
 should have set up to improve performance?  5 days = ~7MBytes / sec
 and I know the drives can run a lot faster than that.

The current code is designed to be robust rather than fast - it does a read 
from one of the online chunks (in this case you presumably only have one of 
those) and then does a write to all chunks (including both the online ones 
and the rebuilding one). In order to speed things up you want to read from 
one online chunk and only write to the chunk that needs rebuilding - the 
problem with this is that you need to prevent changes to the blocks that you 
are rebuilding until that write completes. Unfortunately that means some more 
restructing and additional code, plus a whole bunch of testing...

 Can I reboot the system during the rebuild or if I do will it start at
 the beginning again? I could try it but I'm now about 3 days in and
 don't wish to waste it.

The rebuild progress is stored in the softraid metadata - if you reboot (or 
even if the power goes out) it should pick up where it left off and complete 
the rebuild.

 #dmesg
 OpenBSD 5.4 (GENERIC.MP) #41: Tue Jul 30 15:30:02 MDT 2013
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 16973672448 (16187MB)
 avail mem = 16514109440 (15749MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec420 (81 entries)
 bios0: vendor Intel Corp. version MKQ7710H.86A.0065.2014.0318.1044
 date 03/18/2014
 bios0: Intel Corporation DQ77MK
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC FPDT TCPA MCFG HPET SSDT SSDT SSDT DMAR
 ASF!
 acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) P0P1(S4) USB1(S3)
 USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4)
 RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz, 2893.85 MHz
 cpu0:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,
VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 cpu0: apic clock running at 99MHz
 cpu1 at mainbus0: apid 2 (application processor)
 cpu1: Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz, 2893.43 MHz
 cpu1:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,
VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
 cpu2 at mainbus0: apid 1 (application processor)
 cpu2: Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz, 2893.43 MHz
 cpu2:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,
VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu2: 256KB 64b/line 8-way L2 cache
 cpu2: smt 1, core 0, package 0
 cpu3 at mainbus0: apid 3 (application processor)
 cpu3: Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz, 2893.43 MHz
 cpu3:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,
VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu3: 256KB 64b/line 8-way L2 cache
 cpu3: smt 1, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 3 (P0P1)
 acpiprt2 at acpi0: bus 1 (RP01)
 acpiprt3 at acpi0: bus -1 (RP02)
 acpiprt4 at acpi0: bus -1 (RP03)
 acpiprt5 at acpi0: bus -1 (RP04)
 acpiprt6 at acpi0: bus -1 (RP05)
 acpiprt7 at acpi0: bus -1 (RP06)
 acpiprt8 at acpi0: bus 2 (RP07)
 acpiprt9 at acpi0: bus -1 (RP08)
 acpiprt10 at acpi0: bus -1 (PEG0)
 acpiprt11 at acpi0: bus -1 (PEG1)
 acpiprt12 at acpi0: bus -1 (PEG2)
 acpiprt13 at acpi0: bus -1 (PEG3)
 acpiec0 at acpi0: Failed to read resource settings
 acpicpu0 at acpi0: C2, C1, PSS
 acpicpu1 at acpi0: C2, 

Re: Oddity with httpd/mod_ssl: missing HTTPS environment variable on non _default_ vhosts

[Joel Sing]

On Tue, 18 Feb 2014, Olivier Mehani wrote:
 Hi all,

 I have been battling with this issue for far too long, and I am at wits
 end.

 I have an OpenBSD 5.4 machine, with httpd serving pages successfully
 over both HTTP and HTTPS (with a CaCert-issued certificate).  I want to
 serve multiple sites on both protocols (the certificate has AltNames for
 the various sites).

 (Almost) everything works fine, and I do indeed manage to successfully
 access all sites over HTTPS as expected. However, the HTTPS environment
 variable, which should be set to 'on' for HTTPS sessions, is missing for
 all but the first VHost. This is problematic because multiple apps
 (mostly php-5.3.27, but also some CGI and Rewrites) inspect this
 variable and behave differently depending on whether it is set to 'on'
 or anything else.

 The relevant bits of my configuration file are as follows (diffed from
 the original src/usr.sbin/httpd/conf/httpd.conf from CVS on branch
 OPENBSD_5_4):
   938a939,940

NameVirtualHost *:80
NameVirtualHost *:443

   1024,1025c1026,1027
ServerName new.host.name
ServerAdmin you@your.address
   ---

#ServerName new.host.name
#ServerAdmin you@your.address

   1121a1124,1125

Include /srv/www/conf/sites.d

 The ServerName/ServerAdmin/... are all in the VirtualHost _default_:443
 group. The Include is at the very end of the file.

 I reduced my test case to /srv/www/conf/sites.d containing only one
 file:
 VirtualHost *:80 *:443
 ServerName www.domain2.tld
 ServerAdmin webmas...@domain.tld
 DocumentRoot /var/www/sites/domain2.tld/www
 /VirtualHost
 Directory /sites/domain2.tld/www
 Options MultiViews SymLinksIfOwnerMatch Includes
 AllowOverride FileInfo
 Order allow,deny
 Allow from all
 /Directory

 Neither /var/www/htdocs nor /var/www/sites/domain2.tld/www contain
 .htaccess files.

 This is a rather standard setup, and I've had this working on previous
 machines (=5.3). The HTTPD and SSL logs do not show any error nor
 warning. I have been trying many combinations of NameVirtualHost,
 VirtualHost and ServerName / ServerAlias.

 In all (working) cases, the first (_default_) VHost has HTTPS set to
 'on', and the other one simply hasn't anything set (as shown through a
 phpinfo() page). Swapping the ServerName of the _default_ VHost to
 another of the AltName'd names in the certificare sees that particular
 domain get the HTTPS variable, and none of the others.

 I'm not sure what to try next, if there is indeed anything else. Could
 anybody offer some insight/experience about this type of setups? I guess
 I'm missing something obvious, but searching the web for hours on end
 hasn't yielded anything helpful... Does anybody have any idea what the
 problem might be there?

Name-based virtual hosting and SSL is a can of worms. In short, without SNI 
(which AFAICT the base httpd does not support) the server does not know which 
virtual server is required until after the SSL session has already been 
established. To be honest I am somewhat surprised that this actually works as 
well as it does - seemingly once SSL has been negotiated with the 
_default_:443 virtual host it will then switch virtual hosts based on the 
Host: header (which is how non-SSL name-based virtual hosting works).

In this particular case the lack of HTTPS=on is due to the fact that you do 
not actually have SSL enabled in the /srv/www/conf/sites.d/ configuration 
snippet. Normally this would have (at minimum) SSLEngine, SSLCertificateFile 
and SSLCertificateKeyFile directives in the /srv/www/conf/sites.d/ 
VirtualHost configuration files (as an aside, if your hosting/application 
requires SSL, you probably should consider setting up :80 as a redirect to 
https, rather than configuring both *:80 and *:443 on the same virtual host).

Generally speaking, you will likely have fewer challenges if you configure 
each HTTPS virtual host using a dedicated IP address (or port). That way the 
virtual host selection is made prior to SSL negotitation occurring.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: ntfs with big files

[Joel Sing]

On Sat, 19 Oct 2013, David Vasek wrote:
 On Thu, 17 Oct 2013, David Vasek wrote:
  On Fri, 11 Oct 2013, Joel Sing wrote:
  On Thu, 10 Oct 2013, Manuel Giraud wrote:
  Hi,
 
  I have a ntfs partition with rather large (about 3GB) files on it. When
  I copy these files on a ffs partition they are corrupted. When I try to
  checksum them directly from the ntfs partition the checksum is not
  correct (compared to the same file on a fat32 partition copied with
  Windows).
 
  I tried this (with same behaviour) on i386 5.3 release and on i386 last
  week current. I'm willing to do some testing to fix this issue but
  don't really know where to start.
 
  See if you can isolate the smallest possible reproducable test case. If
  you create a 3GB file with known content (e.g. the same byte repeated),
  does the
  same issue occur? If so, how small do you need to go before the problem
  goes
  away? Also, what operating system (and version) was used to write the
  files to the NTFS volume?
 
  Hello, I encountered the same issue. Anything over the 2 GB limit is
  wrong. I mean, first exactly 2 GB of the file are read correctly,
  following that I get wrong data till the end of the file. It is
  reproducible with any file over 2 GB in size so far. Smells like int
  somewhere... I get the same wrong data with any release since at least
  5.0, didn't test anything older, but I bet it is the same.
 
  The filesystem is a Windows XP NTFS system disk, 32-bit, the files were
  copied there with explorer.exe.

 Some additional notes and findings:

 (1)
 The data I receive after first 2 GB are not part of the file, the data is
 from another file (from the same directory, if that fact could be
 important). The data is taken in uninterrupted sequence and the starting
 offset of that sequence is way less than 2 GB in the other file where the
 data belong.

 (2)
 While reading past 2 GB in larger blocks gives me just wrong data, reading
 in smaller blocks (2kB and less) gives me kernel panic in KASSERT
 immediately when I read past the 2 GB limit. It is 100% reproducible with
 any file larger than 2 GB so far.

Thanks for taking the time to dig into this further and provide some 
reproducable test cases.

There were two problems - the first was an off_t (64-bit integer) to integer 
conversion, which meant that attempting to read past a 2GB offset would have 
become negative. The second issue was an unsigned 64-bit to unsigned 32-bit 
truncation, which effectively wrapped the attribute data length at 4GB.

I've just committed fixes for both of these and I can now successfully 
read/checksum a 6.5GB file on NTFS.

 # mount -r /dev/wd0i /mnt

 # ls -lo /mnt/DATA/ntfs_2gb_test.bin
 -rwxr-xr-x  1 root  wheel  - 3054813184 Oct 17 22:11
 /mnt/DATA/ntfs_2gb_test.bin

 # cat /mnt/DATA//ntfs_2gb_test.bin  /dev/null

 # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=4k of=/dev/null
 745804+0 records in
 745804+0 records out
 3054813184 bytes transferred in 108.518 secs (28150083 bytes/sec)

 # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=2k count=1m of=/dev/null
 1048576+0 records in
 1048576+0 records out
 2147483648 bytes transferred in 78.783 secs (27258052 bytes/sec)

 # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=1k count=2m of=/dev/null
 2097152+0 records in
 2097152+0 records out
 2147483648 bytes transferred in 81.210 secs (26443280 bytes/sec)

 # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=4k skip=512k of=/dev/null
 221516+0 records in
 221516+0 records out
 907329536 bytes transferred in 32.314 secs (28077667 bytes/sec)

 # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=2k skip=1m of=/dev/null
 panic: kernel diagnostic assertion cl == 1  tocopy = ntfs_cntob(1)
 failed: file ../../../../ntfs/ntfs_subr.c, line 1556 Stopped at 
 Debugger+0x4:   popl%ebp
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb trace
 Debugger(d08fdcbc,f544fb88,d08dc500,f544fb88,200) at Debugger+0x4
 panic(d08dc500,d085fc0e,d08dfe60,d08e00b0,614) at panic+0x5d
 __assert(d085fc0e,d08e00b0,614,d08dfe60,8) at __assert+0x2e
 ntfs_readntvattr_plain(d1a2d200,d1a36200,d1a5bc00,8800,0) at
 ntfs_readntvat tr_plain+0x2e6
 ntfs_readattr_plain(d1a2d200,d1a36200,80,0,8800) at
 ntfs_readattr_plain+0x1 41
 ntfs_readattr(d1a2d200,d1a36200,80,0,8800) at ntfs_readattr+0x156
 ntfs_read(f544fddc,d64e5140,d6522a60,f544fea0,0) at ntfs_read+0xa8
 VOP_READ(d6522a60,f544fea0,0,d6599000,d64e5140) at VOP_READ+0x35
 vn_read(d65290a8,d65290c4,f544fea0,d6599000,0) at vn_read+0xb5
 dofilereadv(d65365d4,3,d65290a8,f544ff08,1) at dofilereadv+0x13a
 sys_read(d65365d4,f544ff64,f544ff84,106,d653f100) at sys_read+0x89
 syscall() at syscall+0x227
 --- syscall (number 0) ---
 0x2:
 ddb ps
 PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 *19967   9961  19967  0  7   0dd
9961  1   9961  0  30x88  pause sh
  14  0  0  0  3

Re: Does softraid RAID1 evenly distribute the read load?

[Joel Sing]

On Thu, 7 Nov 2013, Federico Giannici wrote:
 For a decision I have to do, I have to know if the RAID1 implementation
 in softraid evenly distributes the read load through all the disks.

Yes, reads are interleaved across all online chunks.

 So, for example: with a two identical disks RAID1 implementation, can we
 roughly assume that write speed is almost the same speed of a single
 disk while the read speed is almost the double?

As you note below, it is not this simple... if each disk is on a separate 
controller and there are no shared bottlenecks, this would be theoretically 
close. Also, since you can have more than two chunks in a softraid RAID1 
volume, you could theoretically increase the read speed by further 
distributing it across disks/controllers.

 I know that reality is not so simple, but it's only to have an ideal
 situation to understand the working of the system.

Right. Obviously benchmarking would be good starting point :)
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Softraid crypto questions

[Joel Sing]

On Tue, 5 Nov 2013, Jeff Clarke wrote:
 I've read that softraid crypto uses AES256-XTS for encryption.  Can the
 algorithm be changed?

Not currently.

 Also, how long can the passphrase be?  I've red the 
 faq and the manpages and didn't see anything.

A key is derived from the passphrase using pbkdf2. This effectively allows the 
passphrase to be as long as you want, although it is effectively capped at 
1024 characters due to bioctl.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Softraid crypto questions

[Joel Sing]

On Tue, 5 Nov 2013, Joel Sing wrote:
 On Tue, 5 Nov 2013, Jeff Clarke wrote:
  I've read that softraid crypto uses AES256-XTS for encryption.  Can the
  algorithm be changed?

 Not currently.

  Also, how long can the passphrase be?  I've red the
  faq and the manpages and didn't see anything.

 A key is derived from the passphrase using pbkdf2. This effectively allows
 the passphrase to be as long as you want, although it is effectively capped
 at 1024 characters due to bioctl.

s/pbkdf2/pkcs5_pbkdf2/
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: ntfs with big files

[Joel Sing]

On Thu, 10 Oct 2013, Manuel Giraud wrote:
 Hi,

 I have a ntfs partition with rather large (about 3GB) files on it. When
 I copy these files on a ffs partition they are corrupted. When I try to
 checksum them directly from the ntfs partition the checksum is not
 correct (compared to the same file on a fat32 partition copied with
 Windows).

 I tried this (with same behaviour) on i386 5.3 release and on i386 last
 week current. I'm willing to do some testing to fix this issue but don't
 really know where to start.

See if you can isolate the smallest possible reproducable test case. If you 
create a 3GB file with known content (e.g. the same byte repeated), does the 
same issue occur? If so, how small do you need to go before the problem goes 
away? Also, what operating system (and version) was used to write the files 
to the NTFS volume?
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Automatically direct to serial console BEFORE passphrase prompt on FDE (i386)

[Joel Sing]

On Sat, 20 Jul 2013, Erling Westenvik wrote:
 On Fri, Jul 19, 2013 at 01:16:44PM -0400, Kenneth R Westerback wrote:
  On Fri, Jul 19, 2013 at 06:15:49PM +0200, Erling Westenvik wrote:
   Maybe a stupid question, but is it possible to have a i386 machine
   configured with FDE to automatically direct to serial console BEFORE
   the passphrase prompt?
  
   The steps below require the machine to have an attached keyboard
   and monitor initially.
  
   If I hit Enter at the passphrase prompt, the boot prompt will
  
   appear and let me switch to serial console:
set tty com0
  
   From the serial console I can the type:
boot sr0a:/bsd
  
   which gives me the passphrase prompt again on the console machine.
  
   It would be really nice to be able to boot a headless FDE. Am I missing
   something? Is this design by intention?
  
   Cheers,
  
   Erling
 
  There's always boot.conf(5), into which you can put 'set tty com0' last
  I checked.

 Of course, but not on an fully encrypted disk where root, and hence
 /etc/boot.conf, won't get available until the passphrase is entered.

 Since it is possible to exit the passphrase prompt, enter set tty com0
 at the boot(8) prompt and then go back to the passphrase prompt again
 from serial console, it must be possible to compile this functionality
 into boot(8)? (I'm really way out of my league here..)

This can be easily achieved by creating a tiny 'a' partition, which contains 
nothing but an /etc/boot.conf file with:

 set tty com0
 boot sr0a:/bsd

That way once boot(8) loads, it reads hd0a:/etc/boot.conf, then switches to 
serial and starts booting from the encrypted softraid volume.

Otherwise you could use a modified boot(8), which defaulted to serial - see 
constab in sys/arch/i386/stand/boot/conf.c for example.
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Softraid performance: CRYPTO on top of RAID 1?

[Joel Sing]

On Thu, 4 Jul 2013, Jiri B wrote:
 On Thu, Jul 04, 2013 at 02:33:51AM +1000, Joel Sing wrote:
  [...snip...] FWIW one of my servers (handles mail, etc) is a Sun Fire
  V210 (sparc64) machine with 2x1GHz CPU, 2GB RAM and a pair of SCSI drives
  - it runs perfectly well in a similar CRYPTO on RAID 1 configuration.
  That said, you'd be best to set it up and measure the performance to
  ensure it will meet your needs.

 I'm confused. Is it possible to have RAID1 and CRYPTO on top of that as
 boot device? It did not work for me...

No, that will not work since the boot loader will not know how to handle the 
nested volumes - the OP said:

 I'm planning to use 3 x 1TB drives in RAID 1. No FDE since
 availability involves the possibility of unattended booting; like
 after a power outage while being abroad/out of town, in which case I'd
 have to ssh in to the box and bioctl(8) the encrypted volume.

And that will work, since you boot off RAID 1 and then bring up a CRYPTO 
volume manually. Once we do stacked properly we should have RAID1C and you 
would be able to boot from that...
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Softraid performance: CRYPTO on top of RAID 1?

[Joel Sing]

On Tue, 2 Jul 2013, Erling Westenvik wrote:
 Hi folks,

 Anyone having any experience with putting an softraid CRYPTO partition
 on top of a softraid RAID 1? In terms of performance?

 I'd like to build a file server that favors redundancy, availability and
 privacy over performance. The latter within limits though, hence my
 initial question. Private use only. Me, my family and ... friends.

 I'm planning to use 3 x 1TB drives in RAID 1. No FDE since
 availability involves the possibility of unattended booting; like
 after a power outage while being abroad/out of town, in which case I'd
 have to ssh in to the box and bioctl(8) the encrypted volume. Otherwise
 the PC is an old Pentium 4 3.40GHz with 3GB RAM which as of today runs
 fine as a file server with 2 x 500GB disks in softraid RAID 1.

You would get much better throughput with a CPU that supports AESNI, however 
unless you're wanting near-disk level performance, you shouldn't have any 
problems. FWIW one of my servers (handles mail, etc) is a Sun Fire V210 
(sparc64) machine with 2x1GHz CPU, 2GB RAM and a pair of SCSI drives - it 
runs perfectly well in a similar CRYPTO on RAID 1 configuration. That said, 
you'd be best to set it up and measure the performance to ensure it will meet 
your needs.

 Sorry if my question does not belong on @misc. I've done quite some
 homework but could not find information pertinent to my case and would
 like to hear any arguments for or against before I spend many hours on
 copying hundres of gigabytes to potentially no avail.

 Regards,

 Erling
-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Failure to upgrade 5.2 to 5.3 with softraid

[Joel Sing]

On Wed, 15 May 2013, tichodr...@free.fr wrote:
 Hello everyone.

 I failed to upgrade my server from 5.2 to 5.3, probably because of a
 bad answer to the 'Root filesystem?' question.

 Setup:
 - HP ProLiant MicroServer N40L server, amd64, GENERIC kernel
 - Two disks (sd0, sd1) in softraid (sd2)
 - I followed the 'Upgrading by install kernel' process, with the 5.3
 version of bsd.rd which I placed in /.
 - at the 'Root filesystem? [sd0]' question, instead of accepting the
 first physical disk detected, I answered 'sd2', thinking that I
 shouldn't indicate a particular disk among the two physical ones. I
 followed a similar advice found on a couple of blog pages [1, 2].

 Result:
 - At the end of the upgrade process, following message :
 Failed to install bootblocks.
 You will not be able to boot OpenBSD from sd2
 - Indeed, can't boot anymore, boot process stalled with the following
 message:
 Using drive 0, partition 3
 Loading...
 - Powered off the server.

 Questions :
 - did I break things irremediably, hense will have to reinstall
 everything from scratch and backups?

Nope, highly unlikely. The system will most likely boot, if not just repeat 
the upgrade. If it does boot you can manually update the boot blocks/boot 
loader:

  /usr/mdec/installboot -v /usr/mdec/boot /usr/mdec/biosboot sd2

It is just an error that occurred when installboot was run against the 
softraid volume. This is most likely due to missing device nodes for sd1 
(e.g. /dev/sd1*). There is a current discussion on bugs@ regarding the same 
issue - for some reason I thought the installer already handled this, however 
it appears that it does not currently.

As a work around, prior to starting the upgrade drop to a shell (for example, 
type '!' at the Root filesystem question) and ensure the device nodes 
exist:

# cd /dev
# sh MAKEDEV sd0 sd1 sd2
# exit

The upgrade should now complete normally.

 - alternatively, should I try something else like removing one disk or
 the other, then try to rebuild the RAID?

 Thanks in advance. I must confess that the first softraid building and
 5.2 install was a real pain for me, and I still do not fully grasp
 softraid, and the way it may interact with the upgrade process.

How can we make it clearer? I need to spend some time working on the softraid 
documentation (hopefully in the not too distant future) - what do you need to 
know?

 Olivier Debre

 Refs.
 [1]
 http://spiritedblowfish.wordpress.com/2012/07/19/installing-openbsd-5-1-amd
64-using-softraid/ [2]
 http://blog.cochard.me/2012/03/openbsd-51-installation-on-sofraid4.html



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: Failure to upgrade 5.2 to 5.3 with softraid

[Joel Sing]

On Thu, 16 May 2013, Joel Sing wrote:
 On Wed, 15 May 2013, tichodr...@free.fr wrote:
  Hello everyone.
 
  I failed to upgrade my server from 5.2 to 5.3, probably because of a
  bad answer to the 'Root filesystem?' question.
 
  Setup:
  - HP ProLiant MicroServer N40L server, amd64, GENERIC kernel
  - Two disks (sd0, sd1) in softraid (sd2)
  - I followed the 'Upgrading by install kernel' process, with the 5.3
  version of bsd.rd which I placed in /.
  - at the 'Root filesystem? [sd0]' question, instead of accepting the
  first physical disk detected, I answered 'sd2', thinking that I
  shouldn't indicate a particular disk among the two physical ones. I
  followed a similar advice found on a couple of blog pages [1, 2].
 
  Result:
  - At the end of the upgrade process, following message :
  Failed to install bootblocks.
  You will not be able to boot OpenBSD from sd2
  - Indeed, can't boot anymore, boot process stalled with the following
  message:
  Using drive 0, partition 3
  Loading...

Sorry, I missed this part. This is unexpected/unusual. This may indicate that 
it managed to update the boot loader (in the softraid boot area), even though 
it failed to update the boot block (I need to check which order this is done 
in to confirm). This would potentially cause this problem.

Which disk were you booting from and have you tried booting from the other 
disk? There is a good chance that you'll be able to boot from the second 
disk - failing that, repeat the upgrade process and make the missing device 
nodes as mentioned previously.

  - Powered off the server.
 
  Questions :
  - did I break things irremediably, hense will have to reinstall
  everything from scratch and backups?

 Nope, highly unlikely. The system will most likely boot, if not just repeat
 the upgrade. If it does boot you can manually update the boot blocks/boot
 loader:

   /usr/mdec/installboot -v /usr/mdec/boot /usr/mdec/biosboot sd2

 It is just an error that occurred when installboot was run against the
 softraid volume. This is most likely due to missing device nodes for sd1
 (e.g. /dev/sd1*). There is a current discussion on bugs@ regarding the same
 issue - for some reason I thought the installer already handled this,
 however it appears that it does not currently.

 As a work around, prior to starting the upgrade drop to a shell (for
 example, type '!' at the Root filesystem question) and ensure the device
 nodes exist:

 # cd /dev
 # sh MAKEDEV sd0 sd1 sd2
 # exit

 The upgrade should now complete normally.

  - alternatively, should I try something else like removing one disk or
  the other, then try to rebuild the RAID?
 
  Thanks in advance. I must confess that the first softraid building and
  5.2 install was a real pain for me, and I still do not fully grasp
  softraid, and the way it may interact with the upgrade process.

 How can we make it clearer? I need to spend some time working on the
 softraid documentation (hopefully in the not too distant future) - what do
 you need to know?

  Olivier Debre
 
  Refs.
  [1]
  http://spiritedblowfish.wordpress.com/2012/07/19/installing-openbsd-5-1-a
 md 64-using-softraid/ [2]
  http://blog.cochard.me/2012/03/openbsd-51-installation-on-sofraid4.html



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard

Re: OBSD Router FW's and Centos TCP DUP ACK issues

[Joel Sing]

On Tue, 23 Apr 2013, keith scott wrote:
 After changing the following line on our edge Firewalls PC.conf the Centos
 server that was unusable is now usable. I've done another tcp dump and
 there are still lot's of TCP ACT DUP's but not as many as there were
 before,

 match   on $ExtIf scrub (random-id min-ttl 64 set-tos lowdelay reassemble
 tcp max-mss 1472) label Scrubbing

 to...

 match   in on $ExtIf scrub (random-id min-ttl 64 set-tos lowdelay
 reassemble tcp max-mss 1472) label Scrubbing

 I will have to do some reading so see exactly why the above rule is causing
 issue with Centos VM's but for now everything seems back to normal :)

My guess is that you previously did not have reassemble tcp enabled. 
Generally speaking, you will not want to enable reassemble tcp if you're 
talking to certain non-RFC1323 compliant hosts since the PAWS checks will 
potentially result in stalled TCP connections.

 On Tue, Apr 23, 2013 at 12:11 AM, Keith ke...@scott-land.net wrote:
  Hi, we recently switched our squid server from a OBSD server on VMware a
  Centos server on XEN but there appears to be an issue somewhere between
  the centos server and our OBSD Routers (DMZ) or our external OBSD
  firewalls.
 
  If I log into the Centos server and run either wget or curl to an
  exnternal http server I get a kind of random 1 in 3 chance or it working
  or taking upto 30 seconds to complete. I've run tcpdump on the Centos box
  and on the router and have imported the results into wireshare and they
  both show lots of TCP Dup ACK's as shown below.
 
  We don't have any issues with any of our other servers that are also on
  the same lan as this squid server so I think it's either a Centos,
  Centos/Xen, or a OBSD issue. does anyone have any ideas what might be
  going on here ?
 
  This dump was captured on our OBSD router.
 
  No. TimeSourceDestination Protocol Length
  Info 3917 2.79731010.0.0.X   20.0.0.X   TCP 74
  35247
 
   http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=2936085
 
  TSecr=0 WS=64
 3922 2.79941110.0.0.X   20.0.0.X   TCP 66
  35247
 
   http [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSval=2936087 TSecr=0
 
 3923 2.79954310.0.0.X   20.0.0.X   HTTP 175GET
  / HTTP/1.0
 3926 2.80133110.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 3923#1] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2936089 TSecr=0
 3927 2.80133310.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 3923#2] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2936089 TSecr=0
 3930 2.80242310.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 3923#3] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2936090 TSecr=0
 3931 2.80242510.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 3923#4] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2936090 TSecr=0
 4140 3.00258510.0.0.X   20.0.0.X   HTTP 175   
  [TCP Retransmission] GET / HTTP/1.0
 4142 3.00339110.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 4140#1] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2936291 TSecr=0
 4663 3.41063210.0.0.X   20.0.0.X   HTTP 175   
  [TCP Retransmission] GET / HTTP/1.0
 4665 3.41145110.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 4663#1] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2936699 TSecr=0
 5538 4.22661110.0.0.X   20.0.0.X   HTTP 175   
  [TCP Retransmission] GET / HTTP/1.0
 5541 4.22744510.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 5538#1] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2937515 TSecr=0
 9846 5.84396110.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 5538#2] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2939132 TSecr=0
 9851 5.84481110.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 5538#3] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2939133 TSecr=0
 9861 5.85863310.0.0.X   20.0.0.X   HTTP 175   
  [TCP Retransmission] GET / HTTP/1.0
 9863 5.85943210.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 9861#1] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2939147 TSecr=0
14821 9.12271810.0.0.X   20.0.0.X   HTTP 175   
  [TCP Retransmission] GET / HTTP/1.0
14823 9.12352610.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 14821#1] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2942411 TSecr=0
17858 11.859699 10.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 14821#2] 35247  http [ACK] Seq=110 Ack=1 Win=14656 Len=0
  TSval=2945148 TSecr=0
17863 11.860531 10.0.0.X   20.0.0.X   TCP 66 [TCP
  Dup ACK 14821#3] 35247  http [ACK] Seq=110 Ack=1 

Re: Softraid 3TB Problems

[Joel Sing]

On Sun, 3 Mar 2013, Brandon Tanner wrote:
 Anyone else having trouble getting bioctl to see more than 2TB when
 creating softraid0?

 I've got 2 x 3TB drives, BIOS sees them fine.

 dmesg on bootup:

 sd1 at scsibus0 targ 3 lun 0: ATA, ST3000DM001-1CH1, CC24 SCSI3 0/direct
 fixed naa.5000c5005e0bcda5
 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
 sd2 at scsibus0 targ 4 lun 0: ATA, ST3000DM001-1CH1, CC24 SCSI3 0/direct
 fixed naa.5000c5005e15ec80
 sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors

 notice the correct # of sectors above.

 disklabel -E sd1

  p T

 OpenBSD area: 64-5860533168; size: 2.7T; free: 0.0T
 #size   offset  fstype [fsize bsize  cpg]
   a: 2.7T   64RAID
   c: 2.7T0  unused

 disklabel -E sd2

  p T

 OpenBSD area: 64-5860533168; size: 2.7T; free: 0.0T
 #size   offset  fstype [fsize bsize  cpg]
   a: 2.7T   64RAID
   c: 2.7T0  unused

 # bioctl -c 1 -l /dev/sd1a,/dev/sd2a softraid0
 softraid0: SR RAID 1 volume attached as sd3

This will assemble the volume from existing metadata if it exists. Any chance 
you created a 2TB 'a' partition to start with and created a softraid volume 
with it, then resized/recreated the disklabels? I'd certainly suggest zeroing 
the drives (via dd or similar), or using -C force (dd is more certain).

The size is read directly from the disklabel, but only when the metadata is 
first created (after the metadata exists, we read the size from the 
metadata). All of the variables involved appear to be 64-bit types so I do 
not think that 32-bit truncation is occurring, although there are some 
signed/unsigned issues that should be addressed at some point.

If zeroing and recreating the metadata fails to solve the issue, I can provide 
a diff that adds some debug info.

 sd3 at scsibus2 targ 1 lun 0: OPENBSD, SR RAID 1, 005 SCSI2 0/direct
 fixed sd3: 2097148MB, 512 bytes/sector, 4294961093 sectors

 Yet, bioctl only sees it for 4294961093 sectors :(

 # bioctl -h sd3
 Volume  Status   Size Device
 softraid0 0 Online   2.0T sd3 RAID1
   0 Online   2.0T 0:0.0   noencl sd1a
   1 Online   2.0T 0:1.0   noencl sd2a

 I have been troubleshooting this issue with the help of Scott McEachern
 extensively, and we are both stumped. He suggested I put this on misc to
 see if jsing might know anything. I have an Intel Desktop Motherboard model
 DP43TF. I can newfs the drives individually and mount them as 2.7TB, it's
 only when trying to make a softraid volume that it doesn't see more than
 2TB.

 I am using the Feb 21, 2013 snapshot of 5.3, and my dmesg is at:
 http://pastebin.com/jqnpSsnC

 Anyone else experiencing this?
 http://search.gmane.org/?author=Scott+McEachernsort=date


-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: Softraid 3TB Problems

[Joel Sing]

On Sun, 3 Mar 2013, Brandon Tanner wrote:
 By the way, does softraid on amd64 support 4096 bytes per sector?

No. There is a large amount of work required to fix this since everything in 
softraid was originally designed around 512-byte blocks. It is somewhere on 
my TODO list, however I do not currently even have the hardware for 
development/testing.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: softraid RAID1 + CRYPTO error writing metadata

[Joel Sing]

On Sat, 9 Feb 2013, Andy Bradford wrote:
 Thus said Joel Sing on Sat, 09 Feb 2013 16:44:11 +1100:
  umount via DUID  does not work currently - this  will be fixed shortly
  after the next release freeze has ended.

 Will that  also include shutdown  of softraid  via DUID? e.g.,

 bioctl -d DUID

 Or is this not even possible?

This is a separate problem, which is solveable, but a fair amount of work will 
likely be required to do it properly.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: softraid RAID1 + CRYPTO error writing metadata

[Joel Sing]

On Fri, 8 Feb 2013, Scott McEachern wrote:
 I get a rather curious error when shutting down a machine with a RAID 1
 setup that contains a crypto partition and a normal partition:

 syncing disks... done
 sd3 detached
 softraid0: I/O error 5 on dev 0x433 at block 16
 softraid0: could not write metadata to sd3d
 sd4 detached
 rebooting...

 When the machine starts up again, I see:
 softraid0: sd4 was not shutdown properly (twice)

 The funny thing is that everything works just fine.  No problems
 whatsoever.

 That said, the error message is more than a little unsettling and I'm
 worried that one day I'm going to access files on the crypto volume only
 to find the data isn't available.

 Any hints on what I did wrong when setting this up?

While stacked softraid volumes generally work, they are not officially 
supported (for a variety of reasons). The problem that you mention above is 
due to the way that softraid volumes are shutdown - the shutdown order is 
approximately the same as the order they are created. In your case this means 
that sd3 gets shutdown before sd4, hence sd4 is unable to write metadata to 
sd3. For the time being, in order to avoid the issue you should disassemble 
the CRYPTO volume (sd4) before the RAID 1 volume (sd3).

 Details:

 The RAID volume, sd3, is made up from two 3TB as sd0 and sd1:

 # disklabel -pg sd0
 # /dev/rsd0c:
 type: SCSI
 disk: SCSI disk
 label: ST3000DM001-1CH1
 duid: ec7586498efe98b8
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 364801
 total sectors: 5860533168 # total bytes: 2794.5G
 boundstart: 64
 boundend: 4294961685
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
a:  2794.5G   64RAID
c:  2794.5G0  unused

 # disklabel -pg sd1
 # /dev/rsd1c:
 type: SCSI
 disk: SCSI disk
 label: ST3000DM001-1CH1
 duid: 0372b77b79b2e168
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 364801
 total sectors: 5860533168 # total bytes: 2794.5G
 boundstart: 64
 boundend: 4294961685
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
a:  2794.5G   64RAID
c:  2794.5G0  unused

 Those two drives then become sd3: (sd2 is an SSD boot drive)

 # disklabel -pg sd3
 # /dev/rsd3c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 6ca0888211d57886
 flags:
 bytes/sector: 512
 sectors/track: 255
 tracks/cylinder: 511
 sectors/cylinder: 130305
 cylinders: 44975
 total sectors: 5860532576 # total bytes: 2794.5G
 boundstart: 0
 boundend: 5860532576
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
a:  1397.3G0  4.2BSD   8192 655361 # /st2
c:  2794.5G0  unused
d:  1397.3G   2930266240RAID

 from which a crypto volume was created, becoming sd4:

 # disklabel -pg sd4
 # /dev/rsd4c:
 type: SCSI
 disk: SCSI disk
 label: SR CRYPTO
 duid: 6c6e53ab843ef6c8
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 182400
 total sectors: 2930265808 # total bytes: 1397.3G
 boundstart: 0
 boundend: 2930265808
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
a:  1397.3G0  4.2BSD   8192 655361
c:  1397.3G0  unused


 I'm running a snapshot from Jan 21.  Full dmesg:

 OpenBSD 5.2-current (GENERIC.MP) #20: Mon Jan 21 17:23:23 MST 2013
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 12613910528 (12029MB)
 avail mem = 12255641600 (11687MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (68 entries)
 bios0: vendor American Megatrends Inc. version 2105 date 07/23/2010
 bios0: ASUSTeK Computer INC. M4A785TD-V EVO
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S1 S3 S4 S5
 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT
 acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4)
 PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4)
 UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4)
 UHC7(S4)
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD Phenom(tm) II X6 1100T Processor, 3300.74 MHz
 cpu0:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,
3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,I
TSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
 cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
 

Re: softraid RAID1 + CRYPTO error writing metadata

[Joel Sing]

On Sat, 9 Feb 2013, Jiri B wrote:
 On Sat, Feb 09, 2013 at 02:56:47AM +1100, Joel Sing wrote:
  While stacked softraid volumes generally work, they are not officially
  supported (for a variety of reasons). The problem that you mention above
  is due to the way that softraid volumes are shutdown - the shutdown order
  is approximately the same as the order they are created. In your case
  this means that sd3 gets shutdown before sd4, hence sd4 is unable to
  write metadata to sd3. For the time being, in order to avoid the issue
  you should disassemble the CRYPTO volume (sd4) before the RAID 1 volume
  (sd3).

 Would stackable softraid volumes work in near future or is it big
 problem as how softraid was designed?

Generally speaking they already work - there are just some caveats, 
primarily relating to assembly and shutdown. Most of the issues are fairly 
easily fixed or are at least solvable (the shutdown ordering should be 
simple - I just need to move it up the priority list). That said, longer term 
I would rather have disciplines such as RAID1C and RAID10 that handle the 
stacking internally and allow for better operation and management.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: softraid RAID1 + CRYPTO error writing metadata

[Joel Sing]

On Sat, 9 Feb 2013, Stuart Henderson wrote:
 On 2013-02-08, Paul de Weerd we...@weirdnet.nl wrote:
  On Fri, Feb 08, 2013 at 01:54:27PM -0500, Scott McEachern wrote:
 | What kind of hardware do you have powering those machines?  Besides,
 | I don't use the crypto partition too often and I really should make
 | it smaller (it's only at 17% capacity out of 1.4TB).
 
  Admittedly, these are pretty powerful machines.  And Antoine was
  right, it's amd64 (I don't have i386 in real day-to-day use anymore).
  But here are the dmesgs for my office workstation and my laptop:
 
  --- office workstation ---

 snip

  cpu0:
  FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
 FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-
 CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,
 DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,E
 RMS

 Seeing AES in this line is useful for a system using softraid crypto.

No, it is not currently - aesni(4) does not yet have support for AES XTS, so a 
CPU with AES instructions will not help any. This should change soon :)
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: softraid RAID1 + CRYPTO error writing metadata

[Joel Sing]

On Sat, 9 Feb 2013, Scott McEachern wrote:
 On 02/08/13 11:26, Joel Sing wrote:
  On Sat, 9 Feb 2013, Jiri B wrote:
  On Sat, Feb 09, 2013 at 02:56:47AM +1100, Joel Sing wrote:
  While stacked softraid volumes generally work, they are not officially
  supported (for a variety of reasons). The problem that you mention
  above is due to the way that softraid volumes are shutdown - the
  shutdown order is approximately the same as the order they are created.
  In your case this means that sd3 gets shutdown before sd4, hence sd4 is
  unable to write metadata to sd3. For the time being, in order to avoid
  the issue you should disassemble the CRYPTO volume (sd4) before the
  RAID 1 volume (sd3).

 Shit, I forgot to mention that I already gave that a whirl by putting:

 umount -f /st3 -- the mount point of the crypto volume

 in /etc/rc.shutdown.  It makes no difference; I still get that
 warning/error.

 I also tried:

 umount -f 6c6e53ab843ef6c8.a -- the DUID of the crypto volume

umount via DUID does not work currently - this will be fixed shortly after the 
next release freeze has ended.

 and, curiously, it says that it's not currently mounted.  (Yet that's
 exactly how I mount it with bioctl in rc.securelevel, where it prompts
 me for the password.)  I've also tried doing it by hand (vs.
 rc.shutdown) and it still doesn't matter.

 Any other suggestions?

 Also, as I said I haven't lost any data thus far and other than seeing
 that message it works just fine.  Am I 1) just lucky so far (and will
 eventually not be so lucky), 2) is it just cleaning up after itself on
 reboot (my rc.securelevel script runs an fsck -p on the volume before
 mounting it), or 3) is it actually working but just not very pretty?

Mostly (3) - if you are unmounting the file system then the actual chance of 
data loss is low (file systems should unmount on shutdown before the softraid 
volumes are torn down). On shutdown of a volume the metadata is updated and 
this is what is failing.

  Would stackable softraid volumes work in near future or is it big
  problem as how softraid was designed?
 
  Generally speaking they already work - there are just some caveats,
  primarily relating to assembly and shutdown. Most of the issues are
  fairly easily fixed or are at least solvable (the shutdown ordering
  should be simple - I just need to move it up the priority list). That
  said, longer term I would rather have disciplines such as RAID1C and
  RAID10 that handle the stacking internally and allow for better operation
  and management.

 With that approach (RAID1C) would that also work when the entire volume
 isn't encrypted, like in my case where only one partition of the HDD is
 crypto?

Since softraid works with partitions and not disks, you could turn sd0a/sd1a 
into a RAID1C volume and sd0d/sd1d into a pure RAID1 volume (rather than 
splitting up the RAID1 volume). The only real downside to this is that a 
physical disk failure then requires two separate rebuilds.

 Either way, it sounds fantastic and having smooth RAID (esp. crypto)
 operations, l think, would be a huge feather in OpenBSD's cap.  I
 haven't tried full disk encryption yet, maybe on a test box one day,
 because I just don't need that overhead for every disk access.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: Advice for handling softraid reporting i/o error

[Joel Sing]

On Mon, 4 Feb 2013, Erling Westenvik wrote:
 On Sun, Feb 03, 2013 at 11:11:17AM +0530, Girish Venkatachalam wrote:
  I hate to say it but I am sure your hard disk is dying. Replace it ASAP

 No no, that's all right. Death is an inevitable part of life. I know the
 disk is dying and I'm going to replace it (or just throw away the
 machine which is a piece of junk anyway) but I'd love to get out of it
 the amendments to it's last will before it passes out completely.

 When a NON-ENCRYPTED disk has damaged areas one may still be able to
 access the undamaged areas upon a reboot - possibly by mounting it as a
 secondary disk on a working system and using various recovery tools,
 etc.

 However: the last time I had an ENCRYPTED disk with damaged areas, the
 whole disk got rendered useless. It wouldn't respond to
 keydisk/passphrase and hence there was no way to access undamaged
 data.

 The machine is still powered on. It still return ping but not ssh. When
 typing on the keyboard, characters get echo'ed on the screen. Do I have
 any options besides rebooting and praying?

None. Well, aside from a custom kernel.

One of the current features with softraid (regardless of discipline) is that 
if a drive reports an I/O error, we mark the given chunk as being offline. In 
the case of disciplines that have redundant data, this is exactly what we 
want, since it should force failover to an online chunk. However, in the case 
of disciplines that do not have dedundancy, the single chunk failure results 
in the entire volume going offline.

I suspect this is what has happened. You have not mentioned how the crypto 
volume is used, however I'm going to guess that you either have your entire 
system on it, or at least some critical parts of your system. Since it has 
gone offline things have stopped working and there is no way to recover from 
this without rebooting.

I plan on changing softraid so that disciplines without redundant data simply 
pass the failure from the underlying chunk up to userland, but leave the 
volume state alone - after all, you can attempt to recover data from a online 
volume, which is much more useful than losing the lot in one hit.

  On Sun, Feb 3, 2013 at 5:43 AM, Erling Westenvik
 
  erling.westen...@gmail.com wrote:
   I have an old laptop configured with softraid encryption using a USB
   keydisk. The machine was never intended to be used for anything more
   than just testing. However, I started putting a few cvs repositories
   on it and slowly the machine became somewhat important.
  
   Today, when doing a cvs import of a little programming project on my
   web server, the ssh connection died in the middle of the transfer. I
   have not tried to restart it. This is whats on the screen right now.
  
   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
   3187832; cn 820 tn 230 sn 42), retrying
   wd0: transfer error, downgrading to Ultra-DMA mode 4
   wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
   wd0d: uncorrectable data error reading fsbn 6890352 of 6890352-6890479
   (wd0 bn 1 3187832; cn 820 tn 230 sn 42), retrying
   wd0d: uncorrectable data error reading fsbn 6890391 of 6890352-6890479
   (wd0 bn 1 3187871; cn 820 tn 231 sn 18), retrying
   wd0d: uncorrectable data error reading fsbn 6890391 of 6890352-6890479
   (wd0 bn 1 3187871; cn 820 tn 231 sn 18), retrying
   softraid0: i/o error on block 6890352
   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  
   Kind of self explaining: old machine with faulty disk! I do have
   backups but would like to have a copy of some recent commits.
  
   Switching console gives me a login prompt but after entering a user
   name and pressing enter the machine just hangs. The machine will answer
   to ping but not ssh.
  
   My question is:
  
   Do I have any options other than trying to reboot? Optionally into
   single user mode?
  
   Cheers,
  
   Erling



-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: vnd and softraid panic

[Joel Sing]

On Wed, 30 Jan 2013, Eivind Evensen wrote:
 On Wed, Jan 23, 2013 at 02:33:16AM +1100, Joel Sing wrote:
  On Thu, 3 Jan 2013, Eivind Evensen wrote:
   On Mon, Dec 31, 2012 at 07:21:08PM +1100, Joel Sing wrote:
On Mon, 31 Dec 2012, Eivind Evensen wrote:
 Hello.

 Trying to play around a bit with softraid using vnd reliably
 results in a panic when assembling the raid volume. I think the
 first time I tried this was around 4.9 so it's not something new.
  
   ...
 
  FWIW this should now be rectified in -current.

 I tried a snapshot downloaded on 21.th
 (OpenBSD 5.2-current (GENERIC) #17: Fri Jan 18 19:42:57 MST 2013)
 which produced the same results. I waited a few days in case the snapshot
 was too old and built from sources from yesterday, still giving
 the same results. I don't need such a setup so it's not a big deal, but
 here's output and dmesg in case it may be helpful:

Thanks for the report. For some reason I thought you had tried using softraid 
crypto on a vnd and overlooked the fact that you were trying to use RAID 5 
(and now RAID 1). To clarify, RAID 0, CONCAT and CRYPTO should all now work 
on top of a vnd - RAID 1, RAID 4 and RAID 5 will still break in the manner 
given below (panic related to active workunits). These disciplines require 
the same changes that I've made to the other three, however they're a little 
more complex and time consuming. I'll try to get to them fixed soon.

 root:skoeske dd if=/dev/zero of=disk1 bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 2.875 secs (36462177 bytes/sec)
 root:skoeske r disk1=disk2
 dd if=/dev/zero of=disk2 bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 3.219 secs (32567739 bytes/sec)
 root:skoeske r disk2=disk3
 dd if=/dev/zero of=disk3 bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 3.569 secs (29378164 bytes/sec)
 root:skoeske vnconfig vnd0 disk1
 root:skoeske vnconfig vnd1 disk2
 root:skoeske vnconfig vnd2 disk3
 root:skoeske fdisk -iy vnd0
 Warning CHS values out of bounds only saving LBA values
 Writing MBR at offset 0.
 root:skoeske fdisk -iy vnd1
 Warning CHS values out of bounds only saving LBA values
 Writing MBR at offset 0.
 root:skoeske fdisk -iy vnd2
 Warning CHS values out of bounds only saving LBA values
 Writing MBR at offset 0.
 root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd0
 Label editor (enter '?' for help at any prompt)

  partition: [a] offset: [128] size: [204672] FS type: [4.2BSD]   No
  label changes.

 root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd1
 Label editor (enter '?' for help at any prompt)

  partition: [a] offset: [128] size: [204672] FS type: [4.2BSD]   No
  label changes.

 root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd2
 Label editor (enter '?' for help at any prompt)

  partition: [a] offset: [128] size: [204672] FS type: [4.2BSD]   No
  label changes.

 root:skoeske bioctl -c 1 -l /dev/vnd0a,/dev/vnd1a,/dev/vnd2a softraid0
 sd0 at scsibus1 targ 1 lun 0: OPENBSD, SR RAID 1, 005 SCSI2 0/direct
 fixed sd0: 99MB, 512 bytes/sector, 204144 sectors
 softraid0: SR RAID 1 volume attached as sd0
 panic: softraid0: sr_wu_init got active wu
 Stopped at  Debugger+0x4:   popl%ebp
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb trace
 Debugger(d08fcddc,f2087de8,d08d0da4,f2087de8,d0a7e540) at Debugger+0x4
 panic(d08d0da4,d0f8c014,f2087dfc,d036ccf3,d0fedab8) at panic+0x5d
 sr_wu_init(d1055000,d0fedab8,f2087e3c,d1055a30,d1057f00) at sr_wu_init+0x73
 sr_wu_put(d1055000,d0fedab8,f2087e3c,f2087e3c,d02030dd) at sr_wu_put+0x2f
 scsi_io_put(d1055a30,d0fedab8,8000,d0fedab8,d0fedab8) at scsi_io_put+0x19
 scsi_xs_put(f2027000,f2027000,f2087e8c,d041de18,d1055000) at
 scsi_xs_put+0x37 sr_raid1_intr(d1065000,f1fabdc4,f17dc000,200,52000) at
 sr_raid1_intr+0x107 vndstrategy(d1065000,0,0,50,d1065000) at
 vndstrategy+0x70
 spec_strategy(f2087f48,0,f2087f6c,d03f2c28,d1053d90) at spec_strategy+0x3d
 VOP_STRATEGY(d1065000,0,0,0,d0fedaf8) at VOP_STRATEGY+0x2c
 sr_startwu_callback(d1055000,d0fedab8,d02008bf,d1053d80,d03f2c50) at
 sr_startwu _callback+0x39
 workq_thread(d1053d80) at workq_thread+0x36
 Bad frame pointer: 0xd0bc8ed8
 ddb ps
PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 *23369  0  0  0  70x100200srdis
  19292   1571   6315   1000  30x80  ttyin less
   1571   6315   6315   1000  30x88  pause sh
   6315  30722   6315   1000  30x80  wait  man
  30722  11048  30722   1000  30x88  pause ksh
  11048   2130   2130   1000  30x80  selectsshd
   2130   1703   2130  0  30x80  poll  sshd
   2513  1   2513  0  20x80ksh
  20983  1  20983  0  30x80  ttyin

Re: vnd and softraid panic

[Joel Sing]

On Thu, 3 Jan 2013, Eivind Evensen wrote:
 On Mon, Dec 31, 2012 at 07:21:08PM +1100, Joel Sing wrote:
  On Mon, 31 Dec 2012, Eivind Evensen wrote:
   Hello.
  
   Trying to play around a bit with softraid using vnd reliably results
   in a panic when assembling the raid volume. I think the first time I
   tried this was around 4.9 so it's not something new.

 ...

   ddb trace
   Debugger(d08fa43c,f2017e08,d08ce53b,f2017e08,0) at Debugger+0x4
   panic(d08ce53b,d0f8a014,f2017e3c,d105fa30,d105ce00) at panic+0x5d
   sr_wu_put(d105f000,d0ff12b8,f2017e3c,f2017e3c,d02030dd) at
   sr_wu_put+0x104 scsi_io_put(d105fa30,d0ff12b8,8000,d1068000,d1068000)
   at scsi_io_put+0x19
   scsi_xs_put(f1f4d000,d1068000,f2017e8c,d0418d98,f1f4d000) at
   scsi_xs_put+0x37 sr_raidp_intr(d1068000,f1e8601c,f11ec000,200,52000) at
   sr_raidp_intr+0x15b vndstrategy(d1068000,0,0,50,d1068000) at
   vndstrategy+0x70
   spec_strategy(f2017f48,0,f2017f6c,d03ee028,d1053f50) at
   spec_strategy+0x3d VOP_STRATEGY(d1068000,0,0,0,d0ff12f8) at
   VOP_STRATEGY+0x2c
   sr_startwu_callback(d105f000,d0ff12b8,d02008bf,d1053f40,d03ee050) at
   sr_startwu _callback+0x39
   workq_thread(d1053f40) at workq_thread+0x36
   Bad frame pointer: 0xd0bc6ed8
 
  Thanks - it is a known issue, which I hope to be able to finish
  addressing during the next hackathon.

 Nice to know. If it helps, I can test patches.

FWIW this should now be rectified in -current.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: do we have a Perl interface to sysctl(3)?

[Joel Sing]

On Tue, 15 Jan 2013, Jonathan Thornburg wrote:
 I wrote

 | FreeBSD has the BSD-Sysctl perl module available from CPAN, which would
 | be ideal for my purposes... except that it doesn't (yet) support OpenBSD.

 On Mon, 14 Jan 2013, Philip Guenther wrote:
  So, uh, what fails if you try to build it?

 % uname -a
 OpenBSD cobalt.astro.indiana.edu 5.1 GENERIC.MP#1 amd64
 % pwd
 /usr/local/perl-modules/BSD-Sysctl-0.10
 % head -13 README
 This file is the README for BSD::Sysctl version 0.10

 INSTALLATION

 perl Makefile.PL
 make
 make test
 make install

 Building this module requires a FreeBSD system and a C compiler.
 Support for OpenBSD and NetBSD will appear in future releases. In
 theory, this module should be able to handle any system that uses
 a sysctl interface to the kernel.
 % perl Makefile.PL
 OS unsupported (openbsd). Here's a nickel, go buy yourself a real OS.
 %

 Notes:
 * As of yesterday, 0.10 is the latest version of BSD::Sysctl on CPAN.
 * I'm well aware that OpenBSD 5.2 has been out for a while; I bought a
   CD.  If and when 5.1 proves inadequate for my needs, I'll reinstall.
   If not, I'll wait for 5.3.

 ciao,

I would have to look at the Perl module, however I am guessing that part of 
this may be due to how FreeBSD et al handle their sysctls - there is 
a magic sysctl that allows you to ask the kernel to give you the OID for a 
given name, then you can go back and request the OID (yes, you get the 
potentially racy behaviour for free). NetBSD does things differently again 
(you have to ask for parts of the MIB and then walk/parse that). With OpenBSD 
you currently have to know the OID number that you want.

You might be interested in checking out Go (golang.org and in ports), which 
has a functional and cross-platform sysctl mechanism:

package main

import (
fmt
syscall
)

func main() {
version, _ := syscall.Sysctl(kern.hostname)
ncpu, _ := syscall.SysctlUint32(hw.ncpu)

fmt.Printf(%s has %d CPU(s)\n, version, ncpu)
}

-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: openbsd 5.2 on soekris softraid boot error code 91

[Joel Sing]

On Tue, 15 Jan 2013, Martin Kjær Jørgensen wrote:
 Hi

 I've just installed OpenBSD 5.2 on my Soekris 6501. Im using two WDC
 WD2500BPVT-22JJ5T0 disks in RAID1.

 Installation goes well and the system boots fine the first time.
 After reboot I'm greeted with the following error:

 Using drive 0, partition 3.
 Loading...
 probing: pc0 com0 mem[620K 2046M a20=on]
 disk: hd0+ hd1+ sr0*

  OpenBSD/amd64 BOOT 3.20

 open(sr0a:/etc/boot.conf): Unknown error: code 91
 boot
 booting sr0a:/bsd: open sr0a:/bsd: Unknown error: code 91
  failed(91). will try /bsd
 boot
 booting sr0a:/bsd: open sr0a:/bsd: Unknown error: code 91
  failed(91). will try /bsd
 Turning timeout off.
 boot

 This error occurs everytime I reboot or press the reset-button on
 the back of the chassis.
 At first when I pulled the powerplug and pluged it in, it booted fine
 the first time, but now I cant even do that anymore.
 I fear its a hardware issue.

Are you saying that it does sometimes boot from sr0?

 Does anyone know what this is, or what error code 91 means?

man errno:

 91 ENOTSUP Not supported. The operation has requested an unsupported
 value.

The 'sr0*' means that it found the softraid volume and that it is marked as 
bootable. Are you certain that it is a RAID 1 partition? The main reason that 
it would return ENOTSUP is if it encountered a RAID level that is currently 
unsupported (e.g. RAID 0).
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: vnd and softraid panic

[Joel Sing]

On Mon, 31 Dec 2012, Eivind Evensen wrote:
 Hello.

 Trying to play around a bit with softraid using vnd reliably results
 in a panic when assembling the raid volume. I think the first time I
 tried this was around 4.9 so it's not something new.

 While the combination of vnd and softraid may not be useful for any
 real purpose, I noticed this while hoping to be able to fail a disk in
 a somewhat simpler to retry manner than the nailgun approach I read
 about here recently...

 I don't know if it's important, but also after the trace and ps listed
 below, boot reboot won't reboot the first time, but I can enter ddb
 again by sending a serial break and then get the machine to reboot by
 reexecuting the boot reboot command.

 Regards,
 Eivind

 root:skoeske dd if=/dev/zero of=disk1 bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 3.852 secs (27215650 bytes/sec)
 root:skoeske r disk1=disk2
 dd if=/dev/zero of=disk2 bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 2.569 secs (40802861 bytes/sec)
 root:skoeske r disk2=disk3
 dd if=/dev/zero of=disk3 bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 3.750 secs (27957919 bytes/sec)
 root:skoeske vnconfig vnd0 disk1
 root:skoeske vnconfig vnd1 disk2
 root:skoeske vnconfig vnd2 disk3
 root:skoeske fdisk -iy vnd0
 Warning CHS values out of bounds only saving LBA values
 Writing MBR at offset 0.
 root:skoeske fdisk -iy vnd1
 Warning CHS values out of bounds only saving LBA values
 Writing MBR at offset 0.
 root:skoeske fdisk -iy vnd2
 Warning CHS values out of bounds only saving LBA values
 Writing MBR at offset 0.
 root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd0
 Label editor (enter '?' for help at any prompt)

  partition: [a] offset: [128] size: [204672] FS type: [4.2BSD]   No
  label changes.

 root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd1
 Label editor (enter '?' for help at any prompt)

  partition: [a] offset: [128] size: [204672] FS type: [4.2BSD]   No
  label changes.

 root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd2
 Label editor (enter '?' for help at any prompt)

  partition: [a] offset: [128] size: [204672] FS type: [4.2BSD]   No
  label changes.

 root:skoeske bioctl -c 5 -l /dev/vnd0a,/dev/vnd1a,/dev/vnd2a softraid0
 sd0 at scsibus1 targ 1 lun 0: OPENBSD, SR RAID 5, 005 SCSI2 0/direct
 fixed sd0: 199MB, 512 bytes/sector, 408064 sectors
 softraid0: SR RAID 5 volume attached as sd0
 panic: softraid0: sr_wu_put got active wu
 Stopped at  Debugger+0x4:   popl%ebp
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb trace
 Debugger(d08fa43c,f2017e08,d08ce53b,f2017e08,0) at Debugger+0x4
 panic(d08ce53b,d0f8a014,f2017e3c,d105fa30,d105ce00) at panic+0x5d
 sr_wu_put(d105f000,d0ff12b8,f2017e3c,f2017e3c,d02030dd) at sr_wu_put+0x104
 scsi_io_put(d105fa30,d0ff12b8,8000,d1068000,d1068000) at scsi_io_put+0x19
 scsi_xs_put(f1f4d000,d1068000,f2017e8c,d0418d98,f1f4d000) at
 scsi_xs_put+0x37 sr_raidp_intr(d1068000,f1e8601c,f11ec000,200,52000) at
 sr_raidp_intr+0x15b vndstrategy(d1068000,0,0,50,d1068000) at
 vndstrategy+0x70
 spec_strategy(f2017f48,0,f2017f6c,d03ee028,d1053f50) at spec_strategy+0x3d
 VOP_STRATEGY(d1068000,0,0,0,d0ff12f8) at VOP_STRATEGY+0x2c
 sr_startwu_callback(d105f000,d0ff12b8,d02008bf,d1053f40,d03ee050) at
 sr_startwu _callback+0x39
 workq_thread(d1053f40) at workq_thread+0x36
 Bad frame pointer: 0xd0bc6ed8

Thanks - it is a known issue, which I hope to be able to finish addressing 
during the next hackathon.

 ddb ps
PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 * 4458  0  0  0  70x100200srdis
   9614   9263  31326   1000  30x80  ttyin less
   9263  31326  31326   1000  30x88  pause sh
  31326   8662  31326   1000  30x80  wait  man
   8662  24219   8662   1000  30x88  pause ksh
  24219   7388   7388   1000  30x80  selectsshd
   7388   1358   7388  0  30x80  poll  sshd
   8332  1   8332  0  20x80ksh
  21947  1  21947  0  30x80  ttyin getty
  28840  1  28840  0  30x80  ttyin getty
  32669  1  32669  0  30x80  ttyin getty
  25686  1  25686  0  30x80  ttyin getty
  19769  1  19769  0  30x80  ttyin getty
  10627  1  10627  0  30x80  selectcron
  14888  1  14888 99  30x80  poll  sndiod
   5483  1   5483  0  30x80  selectinetd
  27714  10979  10979 95  30x80  kqreadsmtpd
   9877  10979  10979 95  30x80  kqreadsmtpd
  31352  10979  10979 95  30x80  kqreadsmtpd
  17499 

Re: Watchdog timeout reset in 5.2 on intel nics

[Joel Sing]

On Thu, 22 Nov 2012, Kapetanakis Giannis wrote:
 Doing Per-Olov's advice on
 http://marc.info/?l=openbsd-miscm=133771632704741w=2
 and applying the following, fixes the problem.

 Should I stick with this or is there another reason it has not been
 included in current so far?

Yes - it is a work around for broken/incomplete emulation or incorrect 
interrupt routing. Always doing this would result in a performance hit on all 
systems. As shown in your dmesg, both em(4) devices are using the same IRQ:

em0 at pci0 dev 3 function 0 Intel PRO/1000MT (82540EM) rev 0x03: irq 11, 
address 52:54:00:25:e7:a8
em1 at pci0 dev 4 function 0 Intel PRO/1000MT (82540EM) rev 0x03: irq 11, 
address 52:54:00:8a:63:d6

With intr_shared_edge=0, we stop processing the interrupt chain once a device 
reports that it had work to do. If there are other devices that need to be 
serviced we expect the interrupt pin to still be asserted and a second 
interrupt to trigger. With intr_shared_edge=1 we always process the entire 
interrupt chain. In your case either the interrupt pin is not being asserted 
correctly or the first device is always reporting that it had work to do, 
even when it did not.

Do you see any difference if you use OpenBSD/amd64 instead? The interrupt 
handling will be the same, but you may get more useful interrupt allocation.

 Index: machdep.c
 ===
 RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
 retrieving revision 1.517
 diff -u -r1.517 machdep.c
 --- machdep.c   10 Nov 2012 09:45:05 -  1.517
 +++ machdep.c   22 Nov 2012 10:24:16 -
 @@ -3893,7 +3893,7 @@
* True if the system has any non-level interrupts which are shared
* on the same pin.
*/
 -intintr_shared_edge;
 +intintr_shared_edge=1;

   /*
* Software interrupt registration

 On 21/11/12 14:23, Kapetanakis Giannis wrote:
  Hi,
 
  It seems I come up on this
  http://marc.info/?l=openbsd-miscm=133651882630852w=2
 
  I've running latest -current i386 on KVM with mpbios disabled.
 
  Today I've enabled a new em(4) interface. Immediately when I enable
  the second interface and set an IP I get
  em1: watchdog timeout -- resetting
  em0: watchdog timeout -- resetting
 
  if I do ifconfig em1 down
  then the timeout stops and I have network on em0.
 
  regards,
 
  Giann
 
  OpenBSD 5.2-current (GENERIC) #87: Sat Nov 17 13:27:31 MST 2012
  dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
  cpu0: Intel Pentium II (GenuineIntel 686-class) 2.93 GHz
  cpu0:
  FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,PGE,CMOV,MMX,FXSR,SSE,SSE2,SSE3,POPCN
 T,PERF real mem  = 1073266688 (1023MB)
  avail mem = 1044770816 (996MB)
  mainbus0 at root
  bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @
  0xff046, SMBIOS rev. 2.4 @ 0x3ec0 (10 entries)
  bios0: vendor Seabios version 0.5.1 date 01/01/2007
  bios0: Red Hat KVM
  acpi0 at bios0: rev 0
  acpi0: sleep states S5
  acpi0: tables DSDT FACP SSDT APIC
  acpi0: wakeup devices
  acpitimer0 at acpi0: 3579545 Hz, 24 bits
  acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
  acpiprt0 at acpi0: bus 0 (PCI0)
  acpicpu0 at acpi0
  mpbios at bios0 function 0x0 not configured
  bios0: ROM list: 0xc/0x8c00 0xc9000/0x800 0xc9800/0x800
  0xca000/0x2200
  cpu0 at mainbus0: (uniprocessor)
  pci0 at mainbus0 bus 0: configuration mode 1 (bios)
  pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
  pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
  pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA,
  channel 0 wired to compatibility, channel 1 wired to compatibility
  wd0 at pciide0 channel 0 drive 0: QEMU HARDDISK
  wd0: 16-sector PIO, LBA48, 12288MB, 25165824 sectors
  wd0(pciide0:0:0): using PIO mode 0, DMA mode 2
  atapiscsi0 at pciide0 channel 1 drive 0
  scsibus0 at atapiscsi0: 2 targets
  cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 0.12 ATAPI 5/cdrom
  removable
  cd0(pciide0:1:0): using PIO mode 0
  uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: irq 11
  piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: irq 10
  iic0 at piixpm0
  iic0: addr 0x19 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words 00=
  01= 02= 03= 04= 05= 06= 07=
  iic0: addr 0x1b 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words 00=
  01= 02= 03= 04= 05= 06= 07=
  iic0: addr 0x1c 0f=00 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words
  00= 01= 02= 03= 04= 05= 06= 07=
  iic0: addr 0x1d 0f=00 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words
  00= 01= 02= 03= 04= 05= 06= 07=
  iic0: addr 0x1e 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words 00=
  01= 02= 03= 04= 05= 06= 07=
  iic0: addr 0x1f 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words 00=
  01= 02= 03= 04= 05= 06= 07=
  iic0: addr 0x29 00=d0 01=d0 02=d0 03=d0 04=d0 05=d0 06=d0 07=d0 08=d0
  

Re: crypto volume damaged after crash

[Joel Sing]

On Thu, 8 Nov 2012, Erling Westenvik wrote:
 I'm running current on a ThinkPad T500 with a fully encrypted disk (sd0)
 and using a usb keydisk (sd1) to assemble the crypto volume on sd2. Last
 snapshot upgrade was around 11th of October.

 Yesterday the machine suddenly stopped responding to keystrokes (even
 though xscreensaver was running fine). Pinging it from one of my other
 OpenBSD-machines worked, but when I tried to ssh into it, the connection
 just timed out. Finally, when I tried to switch console by hitting
 Ctrl-Alt-F2, it froze completely.

 No big deal, I thought. It had crashed numerous times before from empty
 battery. So I booted, plugged in the keydisk, but after entering the
 usual location for boot and swap partitions:

 root device (default sd0a): sd2a
 swap device (default sd2b): sd0b

 I got this: (I had to write this down by hand. FYI, in case of typos.)

 ---8---
 root on sd2a swap on sd0b dump on sd0b
 Automatic boot in process: starting file system check.
 /dev/sd2a (290d4f6dcbc2d7a7.a): file system is clean; not checking
 softraid0: i/o error on block 257269168

This is the biggest hint at the real issue - for some reason the I/O to the 
underlying device has failed, which has then been propagated to the softraid 
volume. Unfortunately, at this stage this is sufficient to force the softraid 
crypto volume offline, hence from here on in there will be nothing but I/O 
errors when reading or writing to the volume (hence fsck_ffs complaining).

If this is a hardware failure then it is not overly interesting, however if 
the underlying device is healthy then I would be interested in getting 
further details.

 CANNOT READ: BLK 183692704
 /dev/sd2k (290d4f6dcbc2d7a7.k): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. CANNOT READ: BLK 128
 /dev/sd2d (290d4f6dcbc2d7a7.d): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. CANNOT READ: BLK 128
 /dev/sd2f (290d4f6dcbc2d7a7.f): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. CANNOT READ: BLK 128
 /dev/sd2g (290d4f6dcbc2d7a7.g): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. CANNOT READ: BLK 128
 /dev/sd2h (290d4f6dcbc2d7a7.h): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. CANNOT READ: BLK 128
 /dev/sd2j (290d4f6dcbc2d7a7.j): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. CANNOT READ: BLK 128
 /dev/sd2i (290d4f6dcbc2d7a7.i): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. CANNOT READ: BLK 128
 /dev/sd2e (290d4f6dcbc2d7a7.e): UNEXPECTED INCONSISTENCY: RUN fsck_ffs
 MANUALLY. THE FOLLOWING FILE SYSTEMS HAD AN UNEXPECTED INCONSISTENSY:
 ffs: 290d4f6dcbc2d7a7.k (/home), ffs: 290d4f6dcbc2d7a7.d (/tmp),
 ffs: 29 0d4f6dcbc2d7a7.f (/usr), ffs: 290d4f6dcbc2d7a7.g (/usr/X11R6), ffs:
 290d4f6dcbc2 d7a7.h (/usr/local), ffs: 290d4f6dcbc2d7a7.j (/usr/obj), ffs:
 290d4f6dcbc2d7a7.i (/usr/src), ffs: 290d4f6dcbc2d7a7.e (/var)
 Automatic file system check failed; help!
 Nov  7 23:09:59 init: /etc/pwd.db: Input/output error
 Enter pathname of shell or RETURN for sh:
 # fsck_ffs 290d4f6dcbc2d7a7.k
 ** /dev/sd2k (290d4f6dcbc2d7a7.k )

 CANNOT READ: BLK 128
 CONTINUE? [Fyn?]

 THE FOLLOWING DISK SECTORS COULD NOT BE READ: 128, 129, 130, 131, 132, 133,
 134, 135, 136, 137, 138, 139, 140, 141, 142, 143

 LOOK FOR ALTERNATE SUPERBLOCKS? [Fyn?] _
 ---8---

 Pressing y just causes similar messages to pop up ad infitum.

 Any clues? I got everything backed up but would like to understand what
 is going on rather than just do a fresh install.

 Erling



-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: http/https timeouts with OpenBSD based firewall

[Joel Sing]

On Tue, 23 Oct 2012, Marcin wrote:
 Hi,

 I recently upgraded to 5.1, but I was able to reproduce the issue
 described below with 4.8, 5.0 and 5.2 snapshot.

 After the upgrade I discovered that workstations behind the OpenBSD
 firewall experience occasional timeouts
 while trying to access web servers running IIS 6.0 on Windows 2003
 Server. The firewall itself is not affected.
 The problem is rather intermittent and happens with 30%-50%
 requests.The workstations are running Windows 7,
 Windows XP and Linux.

 I was also able to reproduce the issue by installing Windows 2003 R2
 server in default configuration,
 setting up extremely basic PF rules to redirect port 80 and accessing
 the server from the Internet. I was unable to expose
 this issue in LAN, which suggests it might happen only on links slower
 than 100Mbit. However, it seems to
 be hardware independent (although all tests were run on i386 arch) as
 I achieve the same results on three
 different machines in three different geographic locations connected
 via independent ISPs.

 This is how the problem can be exposed with curl:

 #curl -vI http://www.startvbdotnet.com/
 * About to connect() to www.startvbdotnet.com port 80 (#0)
 *   Trying 64.79.160.13... connected

  HEAD / HTTP/1.1
  User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
  zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: www.startvbdotnet.com
  Accept: */*

 * Recv failure: Connection reset by peer
 * Closing connection #0
 curl: (56) Recv failure: Connection reset by peer

 I uploaded the tcpdump from machine running curl here:
 http://pastebin.com/AkqCeQwW

 As far as I can tell, the Win 2008 and Win 2012 are not affected.
 Also, the 4.5 seemed to be free from this problem.

 Thanks in advance for any suggestions / workarounds!

Unfortunately we have no idea what firewall rules you have configured, however 
I'm going to take random guess and say that you're using a scrub rule 
with 'reassemble tcp' - if this is the case you'll probably find that some 
TCP connections to Windows-based servers will fail, since they often violate 
RFC1323 by using a 0-value timestamp during the three-way handshake, then 
increase it by some value between 0 and 2^31 on the first data packet. Note 
the TS val fields in the first two packets from 64.79.160.13:

20:49:05.962419 IP (tos 0x0, ttl 117, id 20521, offset 0, flags [none], proto 
TCP (6), length 64)
64.79.160.13.80  192.168.1.20.51163: Flags [S.], cksum 0xd698 (correct), 
seq 2659727337, ack 77418264, win 16384, options [mss 1440,nop,wscale 
0,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
20:49:06.146338 IP (tos 0x0, ttl 117, id 14230, offset 0, flags [none], proto 
TCP (6), length 292)
64.79.160.13.80  192.168.1.20.51163: Flags [P.], cksum 0xd584 (correct), 
seq 1:241, ack 173, win 65363, options [nop,nop,TS val 2152972614 ecr 
1629278667], length 240

Combined with the way that PF handles timestamp modulation (there is a subtle 
and difficult to fix bug here), you can trigger the PAWS checks, which 
results in packets being dropped. IIRC these drops will be logged if you run 
with 'pfctl -x debug'. Removing 'reassemble tcp' should resolve the issue.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: nasm problem - Probably not.

[Joel Sing]

On Mon, 15 Oct 2012, Chris Bennett wrote:
 I went and tried files I had produced many months ago and I get same error!

 ./cat[1]: syntax error: `(' unexpected

 I don't think the problem is with nasm, but something else?

For some reason the kernel does not think it is a valid executable - can you 
provide `objdump -h` output for one of the binaries?
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: one keydisk to access multiple encrypted systems

[Joel Sing]

On Sat, Aug 25, 2012 at 05:08:31PM +0200, Erling Westenvik wrote:
 On Sat, Aug 25, 2012 at 07:03:42AM -0600, Aaron wrote:
  
  It is possible if you use different partitions on the same drive, however,
  you would have to run -P twice ( once for each volume ).
  
 
 Sorry for not mentioning that I'm aware about the possibility of having
 several mini partitions on the key disk, one for each encrypted machine. 
 Also, the -P switch in bioctl(4) has nothing to do with the creation of
 a key disk since the passphrase is generated automatically when invoking
 
   # bioctl -C force -c C -l /dev/wd0d -k /dev/sd0d softraid0
 
 What I'm looking for is a way to have only one key disk partition for
 multiple machines. (Perhaps also a way to manually specify a passphrase
 in case of a lost/forgotten key disk, or a way to create a new key disk
 in case of a corrupted image. But I may be way out on this one..)

There is no (easy) way of doing either of these things currently. Your
best option would be to create multiple partitions and have a keydisk
for each crypto volume, but on the same USB key/memory card.

Re: disklabel error in softraid crypto volume after updating to 5.0/5.1

[Joel Sing]

On Tuesday 22 May 2012, Rodolfo Gouveia wrote:
 Hi all,
 I was running 4.9 on this server and finally got it
 updated to 5.0 and right after to 5.1.
 But security(8) now gives me this:
   disklabel: partition a: partition extends past end of unit
 sd1 is a softraid crypto volume and running disklabel I can see the
 problem: # disklabel sd1
 # /dev/rsd1c:
 type: SCSI
 disk: SCSI disk
 label: SR CRYPTO
 duid: 
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 24136
 total sectors: 387758000
 boundstart: 0
 boundend: 387758000
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:3877580010  4.2BSD   2048 163841
   c:3877580000  unused
 disklabel: partition a: partition extends past end of unit

 So in fact it goes beyond the disk. This sd1a comes from sd0h:
 h:387758080 98568192RAID

 I can mount the partition and have been using it without any problems.
 So is this something to be worried about?

A significant amount of time ago, there was an off-by-one error in a size 
calculation used by softraid(4) (I'd have to go dumpster diving to find the 
exact commit that fixed it) - I suspect you've got an old softraid volume 
that was disklabelled with the incorrectly reported size. It is likely 
harmless and has probably been that way since it was created, however if you 
want to fix it you could follow Otto's instructions.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: ctrl+alt+backspace bypasses xlock and allows terminal access

[Joel Sing]

On Saturday 24 March 2012, Brett wrote:
 On Fri, 23 Mar 2012 22:30:40 -0400

 Nick Holland n...@holland-consulting.net wrote:
  On 03/23/12 22:02, Brett wrote:
   On Sat, 24 Mar 2012 02:43:53 +0100
  
   Henning Brauer lists-open...@bsws.de wrote:
   * Brett brett.ma...@gmx.com [2012-03-24 01:56]:
 its normal behaviour. from xorg.conf(5):

  Option DontZap  boolean
 This disallows the use of the Terminate_Server XKB action
 (usually on Ctrl+Alt+Backspace, depending on XKB options).
 This action is normally used to terminate the Xorg server.
 When this option is enabled, the action has no effect.  Default:
 off.
   
Would it make sense for this to be the secure by default default?
  
   how exactly is preventing yourself from killing your own X server
   increasing security again?
  
   By stopping anyone wandering by my desk (or the cat) from pressing a
   few buttons and getting into a console.
 
  IF you are logging in at the console, then starting X, yes.  There are a
  few ways to get back to the console.
 
  However, if you are relying on xlock to keep people off your system, you
  will want to use DontZap or use xdm to start X, rather than logging in,
  starting X and leaving a console running.
 
  Note that if you are leaving a console logged in then starting X, a
  CTRL-ALT-F1 (through F4) may take you somewhere you aren't expecting to
  be able to get, DontZap or no DontZap.
 
  Nick.

 Till now I falsely assumed that ctrl+alt+f1 behaved as ctrl+alt+{f2-f4},
 and went to a login: prompt. Sorry for the noise, DontZap on by default
 will not improve security. I always used startx, will try out xdm. And
 shutdown my computers more often!

Or:

$ startx  lock -np
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: Panic with degraded softraid RAID 5 array

[Joel Sing]

On Monday 23 January 2012, Matt Behrens wrote:
 Been playing with 5.1-beta (Jan. 21 build) in the interests of seeing
 what I need to get together to set up my next system.  I was hoping to
 do it with three drives, booting from a softraid RAID 5 volume.

From bioctl(8):

CAVEATS
 Use of the CRYPTO  RAID 4/5 disciplines are currently considered
 experimental.

(I probably should remove CRYPTO from that list though, since it is now pretty
stable :)

 When installed and rebooted, all works OK.  What I've been running into
 are panics when trying to run the softraid volume in degraded mode,
 i.e. if I disconnect a drive and start the system.

 I've seen similar issues with a RAID 5 volume mounted on just /home
 instead of on /.  RAID 1 appears to work fine, though.

 Here's one example.  Though the panic traces vary, they're all very easy
 to reproduce--just set up a three-drive RAID 5 array, then bring up the
 system with one drive missing.

That particular trace suggests that your file system is hosed. However, RAID 5
is not ready for prime-time yet - as far as I know it will work correctly
until you lose a disk, at which point it will support read-only access (e.g.
you should be able to keep your data), however any attempts to write will
result in a panic. Also, there is no support for scrubbing or rebuilding,
which makes it non-ideal for production.

  OpenBSD/i386 BOOT 3.17

 boot
 booting hd0a:/bsd: 8230716+1088904 [61+369072+354699]=0x9941dc
 entry point at 0x200120

 [ using 724248 bytes of bsd ELF symbol table ]
 Copyright (c) 1982, 1986, 1989, 1991, 1993
 The Regents of the University of California.  All rights reserved.
 Copyright (c) 1995-2012 OpenBSD. All rights reserved.
 http://www.OpenBSD.org

 OpenBSD 5.1-beta (GENERIC) #140: Sat Jan 21 00:40:23 MST 2012
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
 cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.79 GHz
 cpu0:
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
 LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
 real mem  = 1341124608 (1278MB)
 avail mem = 1309093888 (1248MB)
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 10/22/02, BIOS32 rev. 0 @ 0xffe90,
 SMBIOS rev. 2.3 @ 0xf0450 (90 entries)
 bios0: vendor Dell Computer Corporation version A01 date 10/22/2002
 bios0: Dell Computer Corporation Precision WorkStation 350
 acpi0 at bios0: rev 0
 acpi0: sleep states S0 S1 S3 S4 S5
 acpi0: tables DSDT FACP SSDT APIC BOOT ASF!
 acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) USB0(S3) USB1(S3) USB2(S3)
 USB3 (S3) KBD_(S3)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: apic clock running at 132MHz
 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 0, remapped to apid 1
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 2 (PCI1)
 acpicpu0 at acpi0
 acpibtn0 at acpi0: VBTN
 bios0: ROM list: 0xc/0xa800 0xca800/0x1800
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 pchb0 at pci0 dev 0 function 0 Intel 82850 Host rev 0x04
 intelagp0 at pchb0
 agp0 at intelagp0: aperture at 0xf000, size 0x800
 ppb0 at pci0 dev 1 function 0 Intel 82850/82860 AGP rev 0x04
 pci1 at ppb0 bus 1
 vga1 at pci1 dev 0 function 0 NVIDIA Vanta rev 0x15
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 ppb1 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x04
 pci2 at ppb1 bus 2
 uhci0 at pci2 dev 1 function 0 VIA VT83C572 USB rev 0x50: apic 1 int 19
 uhci1 at pci2 dev 1 function 1 VIA VT83C572 USB rev 0x50: apic 1 int 18
 ehci0 at pci2 dev 1 function 2 VIA VT6202 USB rev 0x51: apic 1 int 16
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 VIA EHCI root hub rev 2.00/1.00 addr 1
 uhci2 at pci2 dev 2 function 0 VIA VT83C572 USB rev 0x50: apic 1 int 18
 uhci3 at pci2 dev 2 function 1 VIA VT83C572 USB rev 0x50: apic 1 int 17
 ehci1 at pci2 dev 2 function 2 VIA VT6202 USB rev 0x51: apic 1 int 19
 usb1 at ehci1: USB revision 2.0
 uhub1 at usb1 VIA EHCI root hub rev 2.00/1.00 addr 1
 dc0 at pci2 dev 9 function 0 ADMtek AN983 rev 0x11: apic 1 int 18,
 address 00:06:25:08:1c:04 ukphy0 at dc0 phy 1: Generic IEEE 802.3u media
 interface, rev. 1: OUI 0x000749, model 0x0001 dc1 at pci2 dev 10 function 0
 ADMtek AN983 rev 0x11: apic 1 int 19, address 00:04:5a:7e:34:56 ukphy1 at
 dc1 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI 0x000749, model
 0x0001 em0 at pci2 dev 12 function 0 Intel PRO/1000MT (82540EM) rev 0x02:
 apic 1 int 18, address 00:07:e9:85:5d:be usb2 at uhci0: USB revision 1.0
 uhub2 at usb2 VIA UHCI root hub rev 1.00/1.00 addr 1
 usb3 at uhci1: USB revision 1.0
 uhub3 at usb3 VIA UHCI root hub rev 1.00/1.00 addr 1usb4 at uhci2: USB
 revision 1.0 uhub4 at usb4 VIA UHCI root hub rev 1.00/1.00 addr 1
 usb5 at uhci3: USB revision 1.0
 uhub5 at usb5 

Re: Softraid raid 5 throughput problem

[Joel Sing]

On Monday 16 January 2012, keith wrote:
 I built a storage server to run the Bacula storage daemon on.  My plan
 was to boot of a usb key then to use the four 2TB sata disks that are in
 the server as a softraid raid 5 volume. The server in question is a dell
 poweredge R310, i3 CPU 540 @ 3.07GHz with OBSD 5.0 amd64.

 I put the OS onto the usb key but the softraid 5 volume seemed realy
 slow. Sftping files over the local network to the servers softraid
 volume was taking ages. So as I was short of time I just rebuilt the
 server installing OBSD into one of the sata disks wd0

 Later I connect to the server and made a raid5 volume on the remaining
 three disks but the speed was really slow to I tried a raid1 on two of
 the disks and that works fine speed wise.

 I've tried to get some stats to figure out what's going on

 raid 5 (wd1, wd2,wd3) Time for newfs command to complete = 1 min 14 secs
 raid 5 (wd1, wd2,wd3) Time to copy 2.3G file from wd0 onto the softraid5
 disk = 5 mins ish

 raid 1 (wd1, wd2) = 1.8TB  Time for newfs command to complete = 4 secs
 raid 1 (wd1, wd2) copy 2.3G Time to copy 2.3G file from wd0 onto
 softraid disk = 25 secs

RAID 5 with softraid(4) is not ready for primetime - in particular it does not 
support scrub or rebuild. If you have a single disk failure you will get to 
keep your data, however you will need to dump/rebuild/restore.

I'm not specifically aware of performance issues, but I'm not entirely 
surprised either - I'll try to take a look at some point. RAID 5 writes will 
be slower, but not that much slower...

 As this point I though I'd try raid0 but the server went and hung for
 some reason.

 #bioctl -d sd0
 #bioctl -c 0 -l  /dev/wd2a,/dev/wd3a softraid0  It hung on this
 command Won't know what happed till I get to the datacenter.

I'm guessing that you did not clear the existing RAID 1 metadata first, in 
which case you'll probably have a divide by zero with a trace that ends in 
sr_raid1_assemble() - there is a bug there that I hit the other night.

 Idealy I wanted one large disk but if can't get a quick raid5 working I
 will just use two softraid raid 1 disks and work around it. Does anyone
 have any suggestions  ?

I'd stick with RAID 1 - you can use more than two disks, which will give you 
increased redundancy and should improve read throughput. Obviously you'll 
have less capacity though.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: Layered softraid

[Joel Sing]

On Thursday 15 December 2011, Jonathan Perkin wrote:
 I read a long time ago that layered softraid wasn't supported, and
 when looking recently I didn't read anything which suggested that had
 changed, however on the off-chance I tried it out and it seems to work
 ok - at least in limited testing with 4 disks in 0+1 configuration.

 Is this just waiting to die horribly or is layered now supported?

Stacked softraid(4) volumes are not officially supported, but in most cases it 
will work correctly. There are still a number of gotchas and potential 
issues, especially with autoconfiguration (you will have to always manually 
assemble the upper layers) and shutdown ordering.
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: softraid(4): how to reassemble a volume

[Joel Sing]

On Wednesday 30 November 2011, Mattieu Baptiste wrote:
 Hi all,

 I'm trying to reassemble a softraid(4) volume, created with the 'force'
 flag. When I'm trying:
 # bioctl -C force -c C -l /dev/sd1a softraid0
 softraid0: chunk sd1a already in use
 bioctl: ioctl: Invalid argument

 According to the manpage, '-c' flag only seems to create the volume,
 and not simply assemble it. I don't see anything else to reassemble a
 volume. What's the correct way, if any ? Is it supported ?

The -c flag creates a volume - if these are chunks have no metadata then it 
will create new metadata, otherwise it will reassemble the volume from the 
existing metadata.

DO NOT use -C force unless you want to completely reinitialise the metadata 
for the volume - in the case of a crypto volume you will generate new 
metadata with new disk keys, rendering your existing data unreadable.

The error message you are getting is telling you that sd1a is already in use - 
bioctl softraid0 will probably tell you where it is being used (your volume 
is either already assembled, or it is part of another volume).
-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand

Re: DUID base root device for kernel

[Joel Sing]

On Thursday 06 October 2011, Jiri B wrote:
 would be possible to tell kernel via `bsd -a' or with extended
 boot.conf configuration capabilities to use a root device defined
 with DUID?

Short answer, no.

 My intend is to boot from an external usb stick and to have root device
 in the box configured with softraid and keydisk.

Why do you want to boot from an external USB stick instead of booting from the 
hard disk? You can still use softraid crypto with a keydisk and it will now 
automatically select the softraid volume as your root device, if you run 
installboot on the softraid volume. See Josh Grosse's recent undeadly article 
for ideas:

  http://undeadly.org/cgi?action=articlesid=20111002154251

Or Stefan Sperling's older one article (with some minor tweaks - basically 
skip the GENERIC customisation with a hardcoded root device):

  http://www.undeadly.org/cgi?action=articlesid=20110530221728

-- 

Reason is not automatic. Those who deny it cannot be conquered by it.
 Do not count on them. Leave them alone. -- Ayn Rand