Re: Passwd cipher for YP

[Theo de Raadt]

> On Thu, Nov 19, 2015 at 03:36:43PM -0700, Theo de Raadt wrote:
> > > I am rather late to this thread...
> > > 
> > > On Thursday 15 October 2015 15:46:47, Raimo Niskanen wrote:
> > > > > > Are there more password ciphers planned for the future e.g
> > > > > > sha256 and sha512?>
> > > > > 
> > > > >
> > > > > No, we will not be adding those.
> > > > >
> > > > > 
> > > > >
> > > > > Those simple hashes do not provide the future-proof,
> > > > > high-cost-to-crack features of bcrypt, which has made it
> > > > > successful as industry staple. The dumb hashes even arrived years
> > > > > after bcrypt, seems likely the result of choosing ideas "not
> > > > > invented by openbsd"
> > > > 
> > > > Ouch!  And I have not seen any other upcoming ciphers
> > > > mentioned.  These seem to be state of the art in the Linux world :/
> > > 
> > > ... but if anyone wants to add their voice to 
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=16814 , maybe glibc 
> > > could be made to reconsider bcrypt. AFAIK, glibc upstream is mostly 
> > > different people now than when they added sha2 password hashes.
> > 
> > Good luck -- a lot of 'IBO' resistance runs in those circles.
> 
> What means 'IBO'?

modern version of NIH.

Re: serious watchdog timeout issues with em driver

[Martin Pieuchot]

On 19/11/15(Thu) 17:54, Sonic wrote:
> Have serious problems for over 7 weeks now with em driver,
> specifically any rev of if_em.c >  1.305. Starting with rev 1.306,
> released on 2015/09/30 and continuing to -current, watchdog timeouts
> rue the day. Unfortunately rev 1.305 no longer builds with -current as
> it appears the patch in rev 1.309 would be necessary.

I just committed a revert to 1.305 keeping the API changes needed for
the driver to build.

This should bring your stability back, please let us know if that's not
the case.

I'm sorry for your troubles.

Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same?

[Tinker]

Ah, and maybe equally importantly, what are the security ramifications 
of changing password/keydisk vs. wiping and installing from scratch with 
a new password/keydisk?



Say that you would change password/keydisk today, and then next week 
someone gets a copy of your encrypted disk, and of your previous 
password/keydisk.


Would they be able to extract any part of the disk information then, if 
not why?



On 2015-11-20 21:58, Tinker wrote:

"bioctl -P" is to change passphrase without wiping the encrypted
partition's contents. How do you generate a new keydisk without wiping
the same?

I.e. I have an encrypted partition /dev/sd0a which is encrypted using
the keydisk /dev/sd1a . Say /dev/sd1a's contents were compromised. How
do you generate a new one without needing to wipe /dev/sd0a .

I.e. exactly the same as "-P" but for the keydisk usecase.

(Of course the old keydisk/password is needed at replacement time.)

Thanks,
Tinker

"bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same?

[Tinker]

"bioctl -P" is to change passphrase without wiping the encrypted 
partition's contents. How do you generate a new keydisk without wiping 
the same?


I.e. I have an encrypted partition /dev/sd0a which is encrypted using 
the keydisk /dev/sd1a . Say /dev/sd1a's contents were compromised. How 
do you generate a new one without needing to wipe /dev/sd0a .


I.e. exactly the same as "-P" but for the keydisk usecase.

(Of course the old keydisk/password is needed at replacement time.)

Thanks,
Tinker

Re: serious watchdog timeout issues with em driver

[Sonic]

On Fri, Nov 20, 2015 at 8:12 AM, Martin Pieuchot  wrote:
> I just committed a revert to 1.305 keeping the API changes needed for
> the driver to build.
>
> This should bring your stability back, please let us know if that's not
> the case.

The kernel/driver builds with those changes but crashes on startup
(hadn't rebuilt userland yet). Couldn't see much when it happened, I
believe it was just after starting the network, and there was some
Xsoft... error and then what I would describe as a core dump to the
console. No footprints seem to be left after a power reset and booting
into obsd.

Thanks,

Chris

Re: EFI: Booting from other (not the first) GPT partition possible? How? It's an Apple :-O

[Gonzalo L. Rodriguez]

Oh yes, so then on 8,2 still you can boot legacy, on 12,1 you don't :(

Enviado desde mi tostadora de mano

> El 19 nov 2015, a las 15:53, Marc  escribió:
>
> Thank you Gonzalo.
>
> Just to make sure we are talking about the same thing:
>
> I was already able to boot OpenBSD in BIOS legacy mode.
>
> What I want to achieve is booting OpenBSD current with the new EFI OpenBSD
boot loader.
>
> Are you sure that following the tutorial you mentioned can be of any help to
do this?
>
> I will be happy to get enlightened if I am just missing the point. :)
>
> Regards
> Marcel
>
>> Hello,
>>
>> I'm kinda at the same step, but in a macbookpro12,1
>>
>> I resize my OSX partition, burn a install58.fs on a usb stick, boot
>> holding ALT, install OpenBSD on the part of resize partition, and then
>> follow jcs@ tutorial:
>>
>> https://gist.github.com/jcs/5573685
>>
>> Now, "El Capitan" have like a 'Secure Level' thing that you can do the
>> step Mac OS X Encryption -> 3-6. So, you need to boot on Rescue Mode and
>> disable this new protection from the console on rescue mode:
>>
>> # csrutil disable
>>
>> Then reboot, and try the "Mac OS X Encryption" step. Install refind and
>> cross your fingers :)
>>
>>
>> On 16/11, Marcel Timm wrote:
>> ; Hi there,
>> ;
>> ; one thing I would like to try is to boot from created OpenBSD EFI USB
stick
>> ; with
>> ;
>> ; boot -a
>> ;
>> ; and enter the OpenBSD's root partition on the HD.
>> ;
>> ; Unfortunately neither the MacBook Pro 8,2 's integrated
>> ; nor an external USB keyboard work at the prompt where to enter the
>> ; root device's location. :(
>> ;
>> ; Is there another way of telling the kernel which root device to use
>> ; (maybe at boot's prompt - although I haven't found anything in man
page..)?
>> ;
>> ; If this seems to be a XY question to you, I am happy about other
proposals.
>> ;
>> ; Greetings
>> ; Marcel
>> ;
>> ; On 11.11.2015 16:01, Marcel Timm wrote:
>> ; >Hello!
>> ; >
>> ; >My computer is a MacBook Pro 8,2.
>> ; >
>> ; >There is a GPT on the HD (big surprise!) with four partitions,
>> ; >the last one being of type OpenBSD.
>> ; >
>> ; >I managed to put a recent OpenBSD 5.8 snapshot there
>> ; >by booting and installing from an USB stick via EFI created like that
(in
>> ; >OSX):
>> ; >
>> ; >dd if=~/install58.fs of=/dev/rdisk2 bs=1m
>> ; >
>> ; >After installing rEFInd 0.9.2 and putting OpenBSD 5.8 snapshot's
>> ; >BOOTX64.EFI file
>> ; >to the MacBook's EFI partition the rEFInd boot manager shows the
OpenBSD
>> ; >EFI option.
>> ; >
>> ; >Selecting that OpenBSD entry starts the boot programm showing hd0 hd1
hd2
>> ; >and hd3.
>> ; >
>> ; >Is it possible to boot my "EFI OpenBSD installation" from here?
>> ; >If so, how to proceed?
>> ; >
>> ; >I already played with
>> ; >
>> ; >set device hd0d
>> ; >
>> ; >etc. - but it did not work.
>> ; >
>> ; >I will gladly share more details, if of any help.
>> ; >
>> ; >Thanks in advance!
>> ; >
>> ; >Marcel
>> ;
>>
>> --
>> Sending from my toaster.

Re: Passwd cipher for YP

[Артур Истомин]

On Thu, Nov 19, 2015 at 03:36:43PM -0700, Theo de Raadt wrote:
> > I am rather late to this thread...
> > 
> > On Thursday 15 October 2015 15:46:47, Raimo Niskanen wrote:
> > > > > Are there more password ciphers planned for the future e.g
> > > > > sha256 and sha512?>
> > > > 
> > > >
> > > > No, we will not be adding those.
> > > >
> > > > 
> > > >
> > > > Those simple hashes do not provide the future-proof,
> > > > high-cost-to-crack features of bcrypt, which has made it
> > > > successful as industry staple. The dumb hashes even arrived years
> > > > after bcrypt, seems likely the result of choosing ideas "not
> > > > invented by openbsd"
> > > 
> > > Ouch!  And I have not seen any other upcoming ciphers
> > > mentioned.  These seem to be state of the art in the Linux world :/
> > 
> > ... but if anyone wants to add their voice to 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=16814 , maybe glibc 
> > could be made to reconsider bcrypt. AFAIK, glibc upstream is mostly 
> > different people now than when they added sha2 password hashes.
> 
> Good luck -- a lot of 'IBO' resistance runs in those circles.

What means 'IBO'?

support new

[Mehdi Badreddine]

0
C FR
P Paris
T Aubervilliers
Z 93300
O Mehdi BADREDDINE
I Mehdi BADREDDINE
A 6 rue louis aragon
M mehdi.badredd...@gmail.com
U
B +33(0) 6 73 55 27 28
X FAX
N Consulting on *BSD systems, especially network-oriented issues and
appliance design using OpenBSD. BSDA Certified.

ePDFView was coming back!

[freeunix]

ePDFView was removed on ports.

now, ePDFView was coming back!
http://www.linuxfromscratch.org/blfs/view/svn/pst/epdfview.html
http://anduin.linuxfromscratch.org/BLFS/epdfview/epdfview-0.1.8.tar.bz2

Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same?

[szs]

I was wondering the exact same thing. Looking forward to finding out.

 Original Message 
Subject: Re: "bioctl -P" is to change passphrase without wiping the encrypted 
partition's contents. How do you generate a new keydisk without wiping the same?
Local Time: November 20 2015 2:13 pm
UTC Time: November 20 2015 2:13 pm
From: ti...@openmailbox.org
To: misc@openbsd.org
CC: owner-m...@openbsd.org

Ah, and maybe equally importantly, what are the security ramifications
of changing password/keydisk vs. wiping and installing from scratch with
a new password/keydisk?


Say that you would change password/keydisk today, and then next week
someone gets a copy of your encrypted disk, and of your previous
password/keydisk.

Would they be able to extract any part of the disk information then, if
not why?


On 2015-11-20 21:58, Tinker wrote:
> "bioctl -P" is to change passphrase without wiping the encrypted
> partition's contents. How do you generate a new keydisk without wiping
> the same?
>
> I.e. I have an encrypted partition /dev/sd0a which is encrypted using
> the keydisk /dev/sd1a . Say /dev/sd1a's contents were compromised. How
> do you generate a new one without needing to wipe /dev/sd0a .
>
> I.e. exactly the same as "-P" but for the keydisk usecase.
>
> (Of course the old keydisk/password is needed at replacement time.)
>
> Thanks,
> Tinker

Re: Unix::Pledge perl module

[David Coppa]

On Thu, Nov 19, 2015 at 10:30 PM, Andrew Fresh  wrote:
> On Thu, Nov 19, 2015 at 04:19:19PM -0500, Richard Farr wrote:
>> I've put together a simple CPAN module that allows you to use pledge(2)
>> in your Perl programs.  Of course it will only work on -current.
>
> Way cool!  I too have been working on this a bit.  Sorry that I got
> distracted from actually putting it someplace public.
>
> https://github.com/afresh1/OpenBSD-Pledge
>
> One benefit of mine is that OpenBSD-Pledge.t is a bit further fleshed
> out.  I do need to do a fair amount of work on the docs still, but I
> will be looking for OKs to import it into base before long.

Very nice!

Pledges for pkg_* tools anyone? ;)

ciao,
David

No USB 3.0 on 5.8 -current Broadwell

[edward wandasiewicz]

If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
USB 3.1 Type C port, nothing gets registered via dmesg, even if I add

option USB_DEBUG
option UMASS_DEBUG
option XHCI_DEBUG

and compile a kernel. No dmesg output upon attachment of USB 3.0 devices.

If I try, via config(8)

 UKC> disable xhci

I get no USB 2.0 support at all.

The USB 3.0 devices can only get recognised if I attach them via a USB
2.0 cable, and plug this cable into the USB 3.0 or USB 3.1 Type C
port.

I've attached

1. usbdevs via USB 2.0 with USB 3.0 device attached
2. usbdevs via USB 3.0, with USB 3.0 device attached
3. pcidump
4. and dmesg

via USB 2.0 cable


$ usbdevs -vd

Controller /dev/usb0:
addr 1: super speed, self powered, config 1, xHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub0
 port 1 addr 4: high speed, power 224 mA, config 1, Ultra Fit(0x5583),
SanDisk(0x0781), rev 1.00, iSerialNumber 4C530147300909108282
   umass0
 port 2 disabled
 port 3 disabled
 port 4 disabled
 port 5 disabled
 port 6 disabled
 port 7 addr 2: high speed, power 500 mA, config 1, NCM-G102(0x6001),
NMGAAI00010200253N01253(0x2232), rev 0.02
   uvideo0
 port 8 addr 3: full speed, self powered, config 1, product
0x07dc(0x07dc), Intel(0x8087), rev 0.01
   ugen0
 port 9 disabled
 port 10 disabled
 port 11 disabled
 port 12 disabled
 port 13 disabled
 port 14 disabled
 port 15 disabled

direct to USB 3.0 port
*

$ usbdevs -vd

Controller /dev/usb0:
addr 1: super speed, self powered, config 1, xHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub0
 port 1 disabled
 port 2 disabled
 port 3 disabled
 port 4 disabled
 port 5 disabled
 port 6 disabled
 port 7 addr 2: high speed, power 500 mA, config 1, NCM-G102(0x6001),
NMGAAI00010200253N01253(0x2232), rev 0.02
   uvideo0
 port 8 addr 3: full speed, self powered, config 1, product
0x07dc(0x07dc), Intel(0x8087), rev 0.01
   ugen0
 port 9 disabled
 port 10 disabled
 port 11 disabled
 port 12 disabled
 port 13 disabled
 port 14 disabled
 port 15 disabled

pcidump
**

$ pcidump -v 0:20:0

0:20:0: Intel 9 Series xHCI
0x: Vendor ID: 8086 Product ID: 9cb1
0x0004: Command: 0106 Status: 0290
0x0008: Class: 0c Subclass: 03 Interface: 30 Revision: 03
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR mem 64bit addr: 0xe120/0x0001
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 8086 Product ID: 9cb1
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 8b Min Gnt: 00 Max Lat: 00
0x0070: Capability 0x01: Power Management
0x0080: Capability 0x05: Message Signaled Interrupts (MSI)

dmesg with XHCI_DEBUG
***

OpenBSD 5.8-current (GENERIC.MP) #3: Fri Nov 20 15:50:27 UTC 2015
char...@mousse.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17094049792 (16302MB)
avail mem = 16571830272 (15804MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7ce42020 (9 entries)
bios0: vendor coreboot version "(null)" date 04/02/2015
bios0: GOOGLE Samus
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S2 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG SSDT
acpi0: wakeup devices HDEF(S3) WLAN(S3) EHCI(S3) XHCI(S3) ATPA(S3)
CODC(S3) LID0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2400.74 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2893.30 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 3 (application processor)
cpu2: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2893.30 MHz
cpu2:

Re: Who teach the true message about the true free software?

[Rick Hanson]

> Who teach the true message about the true free software?
>
> I ask this because I not want be deceived by hypocritical liars that teach
> falsely about free software.

This explains it.

https://www.youtube.com/watch?v=krb2OdQksMc=1m47s

Re: No USB 3.0 on 5.8 -current Broadwell

[edward wandasiewicz]

On 20 Nov 2015 5:54 p.m., "Martin Pieuchot"  wrote:
>
> On 20/11/15(Fri) 17:32, edward wandasiewicz wrote:
> > If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> > USB 3.1 Type C port, nothing gets registered via dmesg, even if I add
>
> This issue seems to be occurring only after a warm reboot as found by
> jcs@.
>
> Could you tell me if your USB 3 devices are detected after the 1st cold
> boot?

They aren't detected after a 1st cold boot.

If the umass device has a bootable softraid, it does get flagged and recognised

I get sr0* for the main SSD and sr1* for the USB 3.0 device

However, upon booting the USB 3.0 device, I get

ugen0 at uhubo port 8 "Intel product 0x07dc" rev 2.00/0.01 addr 3
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
panic: root device (90480fed822a4f03) not found
Stopped at Debugger +0x9: leave
TID  PID  UID  PRFLAGSPFLAGS
 CPU COMMAND
* 0 0  0 0x1
   0x2000 swapper
Debugger at Debugger+0x9
panic() at panic+0xfe
setroot() at setroot+0xa59
diskconf() at diskconf+0
main() at main+0x565
end trace frame: 0x0, count: 10
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}>

No USB 3.0 ethernet devices get recognised either.

>
> >  UKC> disable xhci
> >
> > I get no USB 2.0 support at all.
>
> Because you don't seem to have any ehci hardware.

Re: No USB 3.0 on 5.8 -current Broadwell

[Ted Unangst]

edward wandasiewicz wrote:
> On 20 Nov 2015 5:54 p.m., "Martin Pieuchot"  wrote:
> >
> > On 20/11/15(Fri) 17:32, edward wandasiewicz wrote:
> > > If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> > > USB 3.1 Type C port, nothing gets registered via dmesg, even if I add
> >
> > This issue seems to be occurring only after a warm reboot as found by
> > jcs@.
> >
> > Could you tell me if your USB 3 devices are detected after the 1st cold
> > boot?
> 
> They aren't detected after a 1st cold boot.
> 
> If the umass device has a bootable softraid, it does get flagged and 
> recognised
> 
> I get sr0* for the main SSD and sr1* for the USB 3.0 device

Those are "bios" disks, using the bios USB emulation stack. Once the kernel
loads, it doesn't use bios functionality, so it can't see them anymore.

Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping thesame?

[Ted Unangst]

Tinker wrote:
> Ah, and maybe equally importantly, what are the security ramifications 
> of changing password/keydisk vs. wiping and installing from scratch with 
> a new password/keydisk?

The master key, which the data on disk is encrypted with, is masked with your
password. The master key never changes. But if you change your password, the
mask changes. The master key is not recoverable with the old password.

> Say that you would change password/keydisk today, and then next week 
> someone gets a copy of your encrypted disk, and of your previous 
> password/keydisk.
> 
> Would they be able to extract any part of the disk information then, if 
> not why?

However, if somebody has a copy of your disk today (with old password) and
they later, next month, learn your old password, they can decrypt that disk.
That should be obvious.

But they also now have a copy of the master key. So if they get your new disk,
they can also decrypt that.

Changing passwords is convenient, but if you have somehow lost control of
either the password or the disk, it would be safer to start over.

Re: azalia audio works, then stutters until reboot

[luke350]

On 11/20/15 02:12, Alexandre Ratchov wrote:

On Thu, Nov 19, 2015 at 12:48:08PM -0700, luke call wrote:

$cat sndiod-log
snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
listen(/tmp/aucat/aucat0|ini): created


this is very strange, sndiod would have logged all the audio
traffic.  Could you check that this is the right file or that
programs are not bypassing sndiod for any reason ?





It's the right file, or at least it was created at that time,
evidently as a direct result of the -ddd switch.  I'm not aware
of what else could have created it.

Could sndiod have got into a state where it quits logging
(maybe somehow related to the audio looping w/ the same beep
for a long time)? Or, needs a poke to flush a log buffer
to disk?  or more -d's?

Is the error message from timidity (midi-playing client)
relevant?:
 io_open() failed
 Couldn't open sndio mode (`s')

How would I determine if
something bypasses sndiod?  E.g., would some other
client program give more helpful info, at least about what
it's trying to do and how it's trying it, like aucat or
something?  Should I be running something akin to
linux's strace to really dig at some angle? (I'm
not remembering the openbsd equivalent.)




the surprising part is the length of the sndiod-log file.
You could try to start sndiod in one window:

doas pkill sndiod
doas sndiod -ddd

then play silence with aucat in another window:

aucat -i /dev/zero

you should see a lot of messages output by sndiod:

snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
listen(/tmp/aucat/aucat0|ini): created
ignored huge clock delta
sock(sock|ini): created
sock,rmsg,widl: AUTH message
sock,rmsg,widl: HELLO message
sock,rmsg,widl: hello from , mode = 1, ver 7
sock,rmsg,widl: using snd0 pst=cfg.default, mode = 1
aucat0: overwritten slot 0
snd0 pst=cfg: device requested
sio(rsnd/0|ini): created
snd0 pst=ini: 48000Hz, s16le, play 0:1, rec 0:1, 8 blocks of 960 frames
...
...

they indicate whan aucat is doing with the sound device.  If I run
timidity, I get similar messages.  I'll look at what timidity does;
meanwhile could you try to make programs not bypass sndiod?

This could be caused by, an AUDIODEVICE environment variable, or
deleted /tmp/aucat/ directory (or bad permissions) or multiple
sndiod processes running

on my machine:

$ pgrep -x sndiod
7941

$ /bin/ls -al /tmp/aucat/
total 8
drwxr-xr-x  2 root  wheel  512 Nov 20 10:08 .
drwxrwxrwt  8 root  wheel  512 Nov 20 10:03 ..
srw-rw-rw-  1 root  wheel0 Nov 20 10:08 aucat0

and I've no AUDIODEVICE environment variable.  Could there some
timidity configuration files or environment variables that force
tell it to bypass sndiod.



Here's what I get. This output shows the switching between the two users 
(root and a regular user) who are running the commands:

#pkill sndiod
#sndiod -ddd 2>&1 | tee /tmp/sndiod.log
snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
listen(/tmp/aucat/aucat0|ini): created
[and that's all until i killed it after doing the next audio cmds as 
other user]


$aucat -i /dev/zero
[wait several seconds]
^C
$echo $AUDIODEVICE

$ls -ltrd /tmp/aucat
drwx--  2 root  wheel   512B Nov 20 09:39 /tmp/aucat/
$ls -ltr /tmp/aucat
ls: aucat: Permission denied
[and timidity playing a .mid file was working]
[then i killed sndiod with ^C.]


#ls -ltr /tmp/aucat
total 0
srw-rw-rw-  1 root  wheel  0 Nov 20 09:39 aucat0
#ls -ltrd /tmp/aucat
drwx--  2 root  wheel  512 Nov 20 09:39 /tmp/aucat
#ps aux|grep -i sndiod
root 22835  0.0  0.0   304   704 p1  R+ 9:47AM0:00.00 grep 
-i sndiod

#umask
0077
#sndiod -ddd 2>&1 | tee /tmp/sndiod.log
snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
listen(/tmp/aucat/aucat0|ini): created

^Z
[1]+  Stopped sndiod -ddd 2>&1 | tee /tmp/sndiod.log
#bg
[1]+ sndiod -ddd 2>&1 | tee /tmp/sndiod.log &
#ps aux|grep -i sndiod
_sndio   30197  0.0  0.0   416  1368 p1  S< 9:52AM0:00.00 sndiod 
-ddd

#ktrace -aid -p 30197
#echo $?
0
#l *out
-rw---  1 root  wheel  63.1K Nov 20 09:53 ktrace.out

$aucat -i /dev/zero
[wait several seconds.]
^C
$timidity *mid
Playing aislean.mid
MIDI file: aislean.mid
Format: 1  Tracks: 3  Divisions: 240
^CTerminated sig=0x02
[the above cmd did play music]

#ktrace -C
#l *out
-rw---  1 root  wheel  63.1K Nov 20 09:53 ktrace.out
#l /tmp/*log
-rw---  1 root  wheel92B Nov 20 09:53 /tmp/sndiod.log
#cat /tmp/*log
snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
listen(/tmp/aucat/aucat0|ini): created
#



Could the root umask of 0077 be a problem?  my /tmp/aucat directory
has different permissions than yours.  I set that umask for all
users to avoid forgetfully
bleeding information between accounts.  (I've found that the umask
cannot have that restrictive setting for reliably running pkg_add, so
I have a script that sets it back to the default for that purpose when 
needed, though it seems like it would be better for packages to

reliably set the permissions they need and not depend on the root

Re: No USB 3.0 on 5.8 -current Broadwell

[edward wandasiewicz]

I also get no dmesg or /var/log/messages output when I detach the USB
3.0 device from the USB 3.0 port or Type C port.

If I attach and / or detach the USB 3.0 device, it's like it's not
recognised at all.

I do however, get an "indicator light on" the device when it's plugged
in, for what it's worth.

Edward.

On Fri, Nov 20, 2015 at 5:32 PM, edward wandasiewicz <0.w3...@gmail.com>
wrote:
> If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> USB 3.1 Type C port, nothing gets registered via dmesg, even if I add
>
> option USB_DEBUG
> option UMASS_DEBUG
> option XHCI_DEBUG
>
> and compile a kernel. No dmesg output upon attachment of USB 3.0 devices.
>
> If I try, via config(8)
>
>  UKC> disable xhci
>
> I get no USB 2.0 support at all.
>
> The USB 3.0 devices can only get recognised if I attach them via a USB
> 2.0 cable, and plug this cable into the USB 3.0 or USB 3.1 Type C
> port.
>
> I've attached
>
> 1. usbdevs via USB 2.0 with USB 3.0 device attached
> 2. usbdevs via USB 3.0, with USB 3.0 device attached
> 3. pcidump
> 4. and dmesg
>
> via USB 2.0 cable
> 
>
> $ usbdevs -vd
>
> Controller /dev/usb0:
> addr 1: super speed, self powered, config 1, xHCI root hub(0x),
> Intel(0x8086), rev 1.00
>   uhub0
>  port 1 addr 4: high speed, power 224 mA, config 1, Ultra Fit(0x5583),
> SanDisk(0x0781), rev 1.00, iSerialNumber 4C530147300909108282
>umass0
>  port 2 disabled
>  port 3 disabled
>  port 4 disabled
>  port 5 disabled
>  port 6 disabled
>  port 7 addr 2: high speed, power 500 mA, config 1, NCM-G102(0x6001),
> NMGAAI00010200253N01253(0x2232), rev 0.02
>uvideo0
>  port 8 addr 3: full speed, self powered, config 1, product
> 0x07dc(0x07dc), Intel(0x8087), rev 0.01
>ugen0
>  port 9 disabled
>  port 10 disabled
>  port 11 disabled
>  port 12 disabled
>  port 13 disabled
>  port 14 disabled
>  port 15 disabled
>
> direct to USB 3.0 port
> *
>
> $ usbdevs -vd
>
> Controller /dev/usb0:
> addr 1: super speed, self powered, config 1, xHCI root hub(0x),
> Intel(0x8086), rev 1.00
>   uhub0
>  port 1 disabled
>  port 2 disabled
>  port 3 disabled
>  port 4 disabled
>  port 5 disabled
>  port 6 disabled
>  port 7 addr 2: high speed, power 500 mA, config 1, NCM-G102(0x6001),
> NMGAAI00010200253N01253(0x2232), rev 0.02
>uvideo0
>  port 8 addr 3: full speed, self powered, config 1, product
> 0x07dc(0x07dc), Intel(0x8087), rev 0.01
>ugen0
>  port 9 disabled
>  port 10 disabled
>  port 11 disabled
>  port 12 disabled
>  port 13 disabled
>  port 14 disabled
>  port 15 disabled
>
> pcidump
> **
>
> $ pcidump -v 0:20:0
>
> 0:20:0: Intel 9 Series xHCI
> 0x: Vendor ID: 8086 Product ID: 9cb1
> 0x0004: Command: 0106 Status: 0290
> 0x0008: Class: 0c Subclass: 03 Interface: 30 Revision: 03
> 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
> 0x0010: BAR mem 64bit addr: 0xe120/0x0001
> 0x0018: BAR empty ()
> 0x001c: BAR empty ()
> 0x0020: BAR empty ()
> 0x0024: BAR empty ()
> 0x0028: Cardbus CIS: 
> 0x002c: Subsystem Vendor ID: 8086 Product ID: 9cb1
> 0x0030: Expansion ROM Base Address: 
> 0x0038: 
> 0x003c: Interrupt Pin: 01 Line: 8b Min Gnt: 00 Max Lat: 00
> 0x0070: Capability 0x01: Power Management
> 0x0080: Capability 0x05: Message Signaled Interrupts (MSI)
>
> dmesg with XHCI_DEBUG
> ***
>
> OpenBSD 5.8-current (GENERIC.MP) #3: Fri Nov 20 15:50:27 UTC 2015
> char...@mousse.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17094049792 (16302MB)
> avail mem = 16571830272 (15804MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7ce42020 (9 entries)
> bios0: vendor coreboot version "(null)" date 04/02/2015
> bios0: GOOGLE Samus
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S2 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC MCFG SSDT
> acpi0: wakeup devices HDEF(S3) WLAN(S3) EHCI(S3) XHCI(S3) ATPA(S3)
> CODC(S3) LID0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2400.74 MHz
> cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: 

Who teach the true message about the true free software?

[français]

Please excuse me because I have posted on OpenBSD lists and other lists.

Who teach the true message about the true free software?

I ask this because I not want be deceived by hypocritical liars that teach
falsely about free software.

Hardcore OpenBSD user community, please, for avoid flames, answer me using
message private.




--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/Who-teach-the-true-message-about-the-true-free-software-tp283358.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: No USB 3.0 on 5.8 -current Broadwell

[Martin Pieuchot]

On 20/11/15(Fri) 17:32, edward wandasiewicz wrote:
> If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> USB 3.1 Type C port, nothing gets registered via dmesg, even if I add

This issue seems to be occurring only after a warm reboot as found by
jcs@.

Could you tell me if your USB 3 devices are detected after the 1st cold
boot?

>  UKC> disable xhci
> 
> I get no USB 2.0 support at all.

Because you don't seem to have any ehci hardware. 

Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping thesame?

[Tinker]

Aha.

*Is* the keydisk the master key, and hence can't be changed?


Very low priority topic:

What about implementing some routine for regenerating the master key, 
even if that would imply reprocessing *all* of the disk's contents?


That could be beneficial in a place where you don't have the space to 
backup 100% of the disk as to start over.



On 2015-11-21 02:45, Ted Unangst wrote:

Tinker wrote:

Ah, and maybe equally importantly, what are the security ramifications
of changing password/keydisk vs. wiping and installing from scratch 
with

a new password/keydisk?


The master key, which the data on disk is encrypted with, is masked 
with your
password. The master key never changes. But if you change your 
password, the

mask changes. The master key is not recoverable with the old password.


Say that you would change password/keydisk today, and then next week
someone gets a copy of your encrypted disk, and of your previous
password/keydisk.

Would they be able to extract any part of the disk information then, 
if

not why?


However, if somebody has a copy of your disk today (with old password) 
and
they later, next month, learn your old password, they can decrypt that 
disk.

That should be obvious.

But they also now have a copy of the master key. So if they get your 
new disk,

they can also decrypt that.

Changing passwords is convenient, but if you have somehow lost control 
of

either the password or the disk, it would be safer to start over.

Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame?

[szs]

I think it would make sense to be able to do this. I have a scenario where I 
would like to install OpenBSD on a remote machine with a customized bsd.rd in 
order to automatically set it all up, feeding a password into the stdin of 
bioctl..

Now, bioctl doesn't allow hashed password to be fed into it (as opposed to the 
encrypt command which does for user logins and auto_install)
This leaves me with only one choice, to feed a password into bioctl in order to 
set up the fully encrypted drive, and then change the password with bioctl -P 
afterwards.. Only problem with that is just what was said.. the original 
password could still be used to decrypt the partitions as the keydisk hasn't 
changed.

 Original Message 
Subject: Re: "bioctl -P" is to change passphrase without wiping the encrypted 
partition's contents. How do you generate a new keydisk without wipingthesame?
Local Time: November 20 2015 7:03 pm
UTC Time: November 20 2015 7:03 pm
From: t...@tedunangst.com
To: ti...@openmailbox.org
CC: misc@openbsd.org,owner-m...@openbsd.org

Tinker wrote:
> Aha.
>
> *Is* the keydisk the master key, and hence can't be changed?

The keydisk is the mask for the master key. It can (in theory) be changed like
changing a password. Really, the key disk is just a prehashed password.

>
>
> Very low priority topic:
>
> What about implementing some routine for regenerating the master key,
> even if that would imply reprocessing *all* of the disk's contents?
>
> That could be beneficial in a place where you don't have the space to
> backup 100% of the disk as to start over.

You could, but you'd be really screwed if you crashed halfway. I don't think
the kernel can/should do this, but it is not impossible for a userland utility
to manipulate softraid partitions.

Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame?

[Tinker]

Aha.

*Is* the keydisk the master key, and hence can't be changed?


Very low priority topic:

What about implementing some routine for regenerating the master key, 
even if that would imply reprocessing *all* of the disk's contents?


That could be beneficial in a place where you don't have the space to 
backup 100% of the disk as to start over.


On 2015-11-21 03:03, Ted Unangst wrote:

Tinker wrote:

Aha.

*Is* the keydisk the master key, and hence can't be changed?


The keydisk is the mask for the master key. It can (in theory) be 
changed like

changing a password. Really, the key disk is just a prehashed password.




Very low priority topic:

What about implementing some routine for regenerating the master key,
even if that would imply reprocessing *all* of the disk's contents?

That could be beneficial in a place where you don't have the space to
backup 100% of the disk as to start over.


You could, but you'd be really screwed if you crashed halfway. I don't 
think
the kernel can/should do this, but it is not impossible for a userland 
utility

to manipulate softraid partitions.

Re: serious watchdog timeout issues with em driver

[Mark Kettenis]

> Date: Fri, 20 Nov 2015 14:12:52 +0100
> From: Martin Pieuchot 
> 
> On 19/11/15(Thu) 17:54, Sonic wrote:
> > Have serious problems for over 7 weeks now with em driver,
> > specifically any rev of if_em.c >  1.305. Starting with rev 1.306,
> > released on 2015/09/30 and continuing to -current, watchdog timeouts
> > rue the day. Unfortunately rev 1.305 no longer builds with -current as
> > it appears the patch in rev 1.309 would be necessary.
> 
> I just committed a revert to 1.305 keeping the API changes needed for
> the driver to build.

Thanks Martin.  I didn't have the time in the last few weeks to do the
backout.

Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame?

[Ted Unangst]

Tinker wrote:
> Aha.
> 
> *Is* the keydisk the master key, and hence can't be changed?

The keydisk is the mask for the master key. It can (in theory) be changed like
changing a password. Really, the key disk is just a prehashed password.

> 
> 
> Very low priority topic:
> 
> What about implementing some routine for regenerating the master key, 
> even if that would imply reprocessing *all* of the disk's contents?
> 
> That could be beneficial in a place where you don't have the space to 
> backup 100% of the disk as to start over.

You could, but you'd be really screwed if you crashed halfway. I don't think
the kernel can/should do this, but it is not impossible for a userland utility
to manipulate softraid partitions.

Re: serious watchdog timeout issues with em driver

[Sonic]

On Fri, Nov 20, 2015 at 12:37 PM, Mark Kettenis  wrote:
> Thanks Martin.

All is fine now. System booted with no errors and no watchdog timeouts.

Thanks to all.

Chris

Remove the mirrored site at openbsd.das.ufsc.br

[Tae Wong]

I want the mirrored site to be removed at the following location:
openbsd.das.ufsc.br

The archived site is last updated in 2010.

Re: inteldrm(4) display corruption on MacBook

[Bryan Vyhmeister]

I just tested a 2015 MacBook Air (HD 6000 graphics) and still see the
same display corruption. This seems to happen on all Intel Graphics Macs
at least from HD 4000 and up and specifically your system, the 12-inch
Retina MacBook, 2013 MacBook Air, and 2015 MacBook Air. Hopefully
kettenis@ will have time to look at this eventually but he is very busy
at the moment.

Bryan