Re: usb wireless detach
I have been looking at doing somrhing similar because I have a usb
wlan that for some reason unplugs it self (the device seems to die, I
think it's broken or something).
I will try this diff when I get a chance.
BR
Dunceor
On Thu, Dec 23, 2010 at 1:36 AM, Jacob Meuser
wrote:
> no feedback yet. B anyone care to comment on this?
>
> On Thu, Dec 16, 2010 at 12:28:56AM +, Jacob Meuser wrote:
>> the following diff tries to make sure that no other processes/threads
>> are or will be using the drivers software context when the driver is
>> detached.
>>
>> this diff covers rum(4), run(4), ural(4) and urtw(4). B without the
>> diff, I can get the kernel to crash by starting a scan with
>> the deice, then ejecting it while the scan is running. B with this
>> diff, I cannot get a crash.
>>
>> normally, usb device detach happens in the usb_task thread. B the sole
>> exception is when the usb bus itself is being detached. B this happens
>> with cardbus devices, and in that case, the usb device detach happens
>> in the generic workq thread.
>>
>> this adds a simple reference counting/waiting mechanism. B this is
>> definitely needed for ioctl(2), which can sleep then start using the
>> driver again. B it may not be needed for timeout(9)s now, but maybe
>> someday it will. B another possible process using the device is the
>> usb_task thread. B in the normal case, this is the same process that
>> is detaching, so there is no concurrency issue. B there is already
>> usb_rem_wait_task() to deal with detaches from other processes,
>> because the bus driver needs it.
>>
>> this also adds more uses of usbd_is_dying() to check if the device
>> has been detached:
>> * before adding timeouts
>> * when entering timeouts, usb_tasks, and ioctl
>>
>> also of note is the order things are done in the detach routines:
>> 1) remove pending timeouts
>> 2) remove (and possibly wait for) pending usb_tasks
>> 3) wait for other processes
>> 4) detach from the network stack
>> 5) cleanup/free usb resources
>>
>> thoughts? B ok?
>>
>> --
>> jake...@sdf.lonestar.org
>> SDF Public Access UNIX System - http://sdf.lonestar.org
>>
>>
>> Index: if_ral.c
>> ===
>> RCS file: /cvs/src/sys/dev/usb/if_ral.c,v
>> retrieving revision 1.117
>> diff -u -p -r1.117 if_ral.c
>> --- if_ral.c B 6 Dec 2010 04:41:39 - B B B 1.117
>> +++ if_ral.c B 15 Dec 2010 02:58:35 -
>> @@ -363,17 +363,20 @@ ural_detach(struct device *self, int fla
>>
>> B B B s = splusb();
>>
>> - B B if (ifp->if_softc != NULL) {
>> - B B B B B B ieee80211_ifdetach(ifp); B B B B /* free all nodes
*/
>> - B B B B B B if_detach(ifp);
>> - B B }
>> -
>> - B B usb_rem_task(sc->sc_udev, &sc->sc_task);
>> B B B if (timeout_initialized(&sc->scan_to))
>> B B B B B B B timeout_del(&sc->scan_to);
>> B B B if (timeout_initialized(&sc->amrr_to))
>> B B B B B B B timeout_del(&sc->amrr_to);
>>
>> + B B usb_rem_wait_task(sc->sc_udev, &sc->sc_task);
>> +
>> + B B usbd_ref_wait(sc->sc_udev);
>> +
>> + B B if (ifp->if_softc != NULL) {
>> + B B B B B B ieee80211_ifdetach(ifp); B B B B /* free all nodes
*/
>> + B B B B B B if_detach(ifp);
>> + B B }
>> +
>> B B B if (sc->amrr_xfer != NULL) {
>> B B B B B B B usbd_free_xfer(sc->amrr_xfer);
>> B B B B B B B sc->amrr_xfer = NULL;
>> @@ -547,8 +550,15 @@ ural_next_scan(void *arg)
>> B B B struct ieee80211com *ic = &sc->sc_ic;
>> B B B struct ifnet *ifp = &ic->ic_if;
>>
>> + B B if (usbd_is_dying(sc->sc_udev))
>> + B B B B B B return;
>> +
>> + B B usbd_ref_incr(sc->sc_udev);
>> +
>> B B B if (ic->ic_state == IEEE80211_S_SCAN)
>> B B B B B B B ieee80211_next_scan(ifp);
>> +
>> + B B usbd_ref_decr(sc->sc_udev);
>> B }
>>
>> B void
>> @@ -559,6 +569,9 @@ ural_task(void *arg)
>> B B B enum ieee80211_state ostate;
>> B B B struct ieee80211_node *ni;
>>
>> + B B if (usbd_is_dying(sc->sc_udev))
>> + B B B B B B return;
>> +
>> B B B ostate = ic->ic_state;
>>
>> B B B switch (sc->sc_state) {
>> @@ -574,7 +587,8 @@ ural_task(void *arg)
>>
>> B B B case IEEE80211_S_SCAN:
>> B B B B B B B ural_set_chan(sc, ic->ic_bss->ni_chan);
>> - B B B B B B timeout_add_msec(&sc->scan_to, 200);
>> + B B B B B B if (!usbd_is_dying(sc->sc_udev))
>> + B B B B B B B B B B timeout_add_msec(&sc->scan_to, 200);
>> B B B B B B B break;
>>
>> B B B case IEEE80211_S_AUTH:
>> @@ -1324,6 +1338,11 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
>> B B B struct ifreq *ifr;
>> B B B int s, error = 0;
>>
>> + B B if (usbd_is_dying(sc->sc_udev))
>> + B B B B B B return ENXIO;
>> +
>> + B B usbd_ref_incr(sc->sc_udev);
>> +
>> B B B s = splnet();
>>
>> B B B switch (cmd) {
>> @@ -1387,6 +1406,8 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
>>
>> B B B splx(s);
>>
>> + B B usbd_ref_decr(sc->sc_udev);
>> +
>> B B B return error;
>> B }
>>
Re: New acpi challenges! New Dell XPS blows up in acpivideo!
Bad AML. Looks like it is trying to do an AML Load of a memory block, and that
is failing.
Usually that's because the checksum is incorrect. Look at dsdt.c:aml_load()
and put printf's at both goto fails', to see what is failing.
Not much I can do about it now as I am in Palau. :)
-jordan
> Date: Wed, 22 Dec 2010 18:04:06 -0600
> From: sl...@peereboom.us
> To: kwesterb...@rogers.com
> CC: tech@openbsd.org; jor...@openbsd.org; mlar...@openbsd.org;
ma...@openbsd.org; kette...@openbsd.org
> Subject: Re: New acpi challenges! New Dell XPS blows up in acpivideo!
>
> don't forget to send the amldump
>
> On Wed, Dec 22, 2010 at 04:08:54PM -0500, Kenneth R Westerback wrote:
> > Got a new Dell XPS 401 laptop today and booted amd64 -current bsd.mp
> > off of a usb stick. It immediately blew up in acpi. bsd.rd did not
> > blow up.
> >
> > There seems to be a minor (i.e. non ddb> causing) issue prior to
> > acpivideo:
> >
> > acpiec0 at acpi0
> > acpicpu0 at acpi0acpi0: unable to load \\_PR_.CSDT
> > : PSS
> > acpicpu1 at acpi0: PSS
> >
> >
> > Hand transcribed:
> >
> >
> > acpivideo at acpi0: GFX0
> > 0x801d6788 cnt:01 stk: 00 objref: 0x801c3c08
> > index: 0 opcode: Cond Ref
> > [\HDOS] 0x801c3c08 cnt: 04 stk: 00 method: 08
> > Could not convert 101 to 1
> > 6a58 Called: \_SB_.PCI0.GFX0._DOS
> > arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
> > 6a5c Called: \_SB_.PCI0.GFX0._DOS
> > arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
> > panic: aml_die aml_xconvert:2052
> >
> > ddb{0}> trace
> > _aml_die
> > aml_xconvert
> > aml_xstore
> > aml_xparse
> > aml_xeval
> > aml_evalnode
> > acpivideo_set_policy
> > acpivideo_attach
> > config_attach
> > acpi_foundvideo
> > aml_found_node
> > aml_found_node
> > aml_found_node
> > aml_found_node
> > aml_found_node
> > acpi_attach
> > config_attach
> > bios_attach
> > config_attach
> > mainbus_attach
> > config_attach
> > cpu_configure
> > main
> >
> > Disabling acpivideo via ukc makes bsd.mp boot.
> >
> > tar of acpidump files attached.
> >
> > Note that the NVidia 425M is only recognized because I added that
> > to pcidevs.
> >
> > Ken
> >
> > OpenBSD 4.8-current (GENERIC.MP) #3: Wed Dec 22 12:37:54 EST 2010
> > r...@tbay.westerback.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 3151962112 (3005MB)
> > avail mem = 3054088192 (2912MB)
> > User Kernel Config
> > UKC> disable acpivido\^H \^Hep\^H \^Ho
> > 351 acpivideo* disabled
> > UKC> quit
> > Continuing...
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb6d0 (56 entries)
> > bios0: vendor Dell Inc. version "A04" date 10/15/2010
> > bios0: Dell Inc. XPS L401X
> > acpi0 at bios0: rev 3
> > acpi0: sleep states S0 S1 S3 S4 S5
> > acpi0: tables DSDT FACP APIC SSDT MCFG SLIC HPET OSFR SSDT
> > acpi0: wakeup devices P0P1(S3) P0P2(S3) P0P3(S3) P0P4(S3) P0P5(S3)
BR20(S3) EUSB(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S4) USB4(S3)
USB5(S3) USB6(S3) PEX0(S3) PEX1(S3) PEX2(S3) PEX3(S3) PEX4(S3) PEX5(S3)
PEX6(S3) PEX7(S3) SLPB(S0) LID0(S3)
> > 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) i7 CPU Q 840 @ 1.87GHz, 1862.26 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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,S
SSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: apic clock running at 132MHz
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,S
SSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> > cpu1: 256KB 64b/line 8-way L2 cache
> > cpu2 at mainbus0: apid 4 (application processor)
> > cpu2: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> > cpu2:
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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,S
SSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> > cpu2: 256KB 64b/line 8-way L2 cache
> > cpu3 at mainbus0: apid 6 (application processor)
> > cpu3: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> > cpu3:
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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,S
SSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> > cpu3: 256KB 64b/line 8-way L2 cache
> > cpu4 at mainbus0: apid 1 (application processor)
> > cpu4: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> > cpu4:
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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,S
SSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCN
Re: Allegations regarding OpenBSD IPSEC
On 12/22/2010 03:49 PM, Clint Pachl wrote: Salvador Fandiqo wrote: Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, How is it different than any other installation file then? Now that it's amateur suggestion hour (no offense Salva), I'm going to take a shot. Would it be possible to use what randomness the system does have to seed some reader that pseudo-randomly reads arbitrary bits from the loaded kernel image in RAM? Well whatever you might read will fall into three classes: 1 Bits that are fixed in the kernel image. Obviously these don't count 2 Bits that can go for long periods without changing. 3 Bits that change frequently. You might as well read these directly. The challenge with (3) and especially (2) is quantifying how much entropy you have actually gathered. If you can't quantify it, it doesn't help you turn on the system faster. This is the main reason why high speed timers are so valuable: you at least expect them to change on a regular basis. Of course, they're so regular that you have to use the uncertainty of some other event to query the timer. So the timer is just a way to convert timing uncertainty into bytes, it's not a source of entropy itself. If only the universe had more than one time dimension, more entropy could be gathered at each event. But many CPUs actually do have more than one and they can vary more or less independently. For example, on i386 and amd64 there's a 'readtsc' instruction. It has a very fast rate (e.g. CPU frequency) and it varies along with CPU frequency scaling. Even better, it's notoriously hard to get consistent results on multicore platforms. Unfortunately, I just read the Wikipedia article and they indicate that Intel CPUs are standardizing on giving it a fixed relationship to wall clock time. This may differ per system, but doesn't uninitialized RAM start in an "unknown state?" If so, could that be added to the entropy pool if it is determined to be random (i.e. not initialized to zeros)? Sure. But it depends on all kinds of physical factors. How much did you get? Is it safe for the boot process to generate keys now? Answering those questions accurately is more important than gathering bonus entropy that you can't be sure of. - Marsh
$4997 Profit-Pulling Software
If you've never made a dime online before, imagine being able to create a profit-pulling machine in just 7 clicks of your mouse... Start Now : http://business-page.us/4997-profit-pulling-software.html
Re: usb wireless detach
On Thu, Dec 23, 2010 at 12:36:26AM +, Jacob Meuser wrote:
> no feedback yet. anyone care to comment on this?
Sounds good to me. I can get odd things to happen when I unplug
my ural AP, I just haven't had a chance to test this to see if
it helps. I will try. It's Christmas after all. :-).
Ken
>
> On Thu, Dec 16, 2010 at 12:28:56AM +, Jacob Meuser wrote:
> > the following diff tries to make sure that no other processes/threads
> > are or will be using the drivers software context when the driver is
> > detached.
> >
> > this diff covers rum(4), run(4), ural(4) and urtw(4). without the
> > diff, I can get the kernel to crash by starting a scan with
> > the deice, then ejecting it while the scan is running. with this
> > diff, I cannot get a crash.
> >
> > normally, usb device detach happens in the usb_task thread. the sole
> > exception is when the usb bus itself is being detached. this happens
> > with cardbus devices, and in that case, the usb device detach happens
> > in the generic workq thread.
> >
> > this adds a simple reference counting/waiting mechanism. this is
> > definitely needed for ioctl(2), which can sleep then start using the
> > driver again. it may not be needed for timeout(9)s now, but maybe
> > someday it will. another possible process using the device is the
> > usb_task thread. in the normal case, this is the same process that
> > is detaching, so there is no concurrency issue. there is already
> > usb_rem_wait_task() to deal with detaches from other processes,
> > because the bus driver needs it.
> >
> > this also adds more uses of usbd_is_dying() to check if the device
> > has been detached:
> > * before adding timeouts
> > * when entering timeouts, usb_tasks, and ioctl
> >
> > also of note is the order things are done in the detach routines:
> > 1) remove pending timeouts
> > 2) remove (and possibly wait for) pending usb_tasks
> > 3) wait for other processes
> > 4) detach from the network stack
> > 5) cleanup/free usb resources
> >
> > thoughts? ok?
> >
> > --
> > jake...@sdf.lonestar.org
> > SDF Public Access UNIX System - http://sdf.lonestar.org
> >
> >
> > Index: if_ral.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/if_ral.c,v
> > retrieving revision 1.117
> > diff -u -p -r1.117 if_ral.c
> > --- if_ral.c6 Dec 2010 04:41:39 - 1.117
> > +++ if_ral.c15 Dec 2010 02:58:35 -
> > @@ -363,17 +363,20 @@ ural_detach(struct device *self, int fla
> >
> > s = splusb();
> >
> > - if (ifp->if_softc != NULL) {
> > - ieee80211_ifdetach(ifp);/* free all nodes */
> > - if_detach(ifp);
> > - }
> > -
> > - usb_rem_task(sc->sc_udev, &sc->sc_task);
> > if (timeout_initialized(&sc->scan_to))
> > timeout_del(&sc->scan_to);
> > if (timeout_initialized(&sc->amrr_to))
> > timeout_del(&sc->amrr_to);
> >
> > + usb_rem_wait_task(sc->sc_udev, &sc->sc_task);
> > +
> > + usbd_ref_wait(sc->sc_udev);
> > +
> > + if (ifp->if_softc != NULL) {
> > + ieee80211_ifdetach(ifp);/* free all nodes */
> > + if_detach(ifp);
> > + }
> > +
> > if (sc->amrr_xfer != NULL) {
> > usbd_free_xfer(sc->amrr_xfer);
> > sc->amrr_xfer = NULL;
> > @@ -547,8 +550,15 @@ ural_next_scan(void *arg)
> > struct ieee80211com *ic = &sc->sc_ic;
> > struct ifnet *ifp = &ic->ic_if;
> >
> > + if (usbd_is_dying(sc->sc_udev))
> > + return;
> > +
> > + usbd_ref_incr(sc->sc_udev);
> > +
> > if (ic->ic_state == IEEE80211_S_SCAN)
> > ieee80211_next_scan(ifp);
> > +
> > + usbd_ref_decr(sc->sc_udev);
> > }
> >
> > void
> > @@ -559,6 +569,9 @@ ural_task(void *arg)
> > enum ieee80211_state ostate;
> > struct ieee80211_node *ni;
> >
> > + if (usbd_is_dying(sc->sc_udev))
> > + return;
> > +
> > ostate = ic->ic_state;
> >
> > switch (sc->sc_state) {
> > @@ -574,7 +587,8 @@ ural_task(void *arg)
> >
> > case IEEE80211_S_SCAN:
> > ural_set_chan(sc, ic->ic_bss->ni_chan);
> > - timeout_add_msec(&sc->scan_to, 200);
> > + if (!usbd_is_dying(sc->sc_udev))
> > + timeout_add_msec(&sc->scan_to, 200);
> > break;
> >
> > case IEEE80211_S_AUTH:
> > @@ -1324,6 +1338,11 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
> > struct ifreq *ifr;
> > int s, error = 0;
> >
> > + if (usbd_is_dying(sc->sc_udev))
> > + return ENXIO;
> > +
> > + usbd_ref_incr(sc->sc_udev);
> > +
> > s = splnet();
> >
> > switch (cmd) {
> > @@ -1387,6 +1406,8 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
> >
> > splx(s);
> >
> > + usbd_ref_decr(sc->sc_udev);
> > +
> > return error;
> > }
> >
> > @@ -2147,7 +2168,8 @@ ural_amrr_start(struct ural_softc *sc, s
> > i--);
> > ni->ni_txrate = i;
> >
> > - timeout_add_sec(&sc->amrr_to, 1);
> >
Re: usb wireless detach
no feedback yet. anyone care to comment on this?
On Thu, Dec 16, 2010 at 12:28:56AM +, Jacob Meuser wrote:
> the following diff tries to make sure that no other processes/threads
> are or will be using the drivers software context when the driver is
> detached.
>
> this diff covers rum(4), run(4), ural(4) and urtw(4). without the
> diff, I can get the kernel to crash by starting a scan with
> the deice, then ejecting it while the scan is running. with this
> diff, I cannot get a crash.
>
> normally, usb device detach happens in the usb_task thread. the sole
> exception is when the usb bus itself is being detached. this happens
> with cardbus devices, and in that case, the usb device detach happens
> in the generic workq thread.
>
> this adds a simple reference counting/waiting mechanism. this is
> definitely needed for ioctl(2), which can sleep then start using the
> driver again. it may not be needed for timeout(9)s now, but maybe
> someday it will. another possible process using the device is the
> usb_task thread. in the normal case, this is the same process that
> is detaching, so there is no concurrency issue. there is already
> usb_rem_wait_task() to deal with detaches from other processes,
> because the bus driver needs it.
>
> this also adds more uses of usbd_is_dying() to check if the device
> has been detached:
> * before adding timeouts
> * when entering timeouts, usb_tasks, and ioctl
>
> also of note is the order things are done in the detach routines:
> 1) remove pending timeouts
> 2) remove (and possibly wait for) pending usb_tasks
> 3) wait for other processes
> 4) detach from the network stack
> 5) cleanup/free usb resources
>
> thoughts? ok?
>
> --
> jake...@sdf.lonestar.org
> SDF Public Access UNIX System - http://sdf.lonestar.org
>
>
> Index: if_ral.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_ral.c,v
> retrieving revision 1.117
> diff -u -p -r1.117 if_ral.c
> --- if_ral.c 6 Dec 2010 04:41:39 - 1.117
> +++ if_ral.c 15 Dec 2010 02:58:35 -
> @@ -363,17 +363,20 @@ ural_detach(struct device *self, int fla
>
> s = splusb();
>
> - if (ifp->if_softc != NULL) {
> - ieee80211_ifdetach(ifp);/* free all nodes */
> - if_detach(ifp);
> - }
> -
> - usb_rem_task(sc->sc_udev, &sc->sc_task);
> if (timeout_initialized(&sc->scan_to))
> timeout_del(&sc->scan_to);
> if (timeout_initialized(&sc->amrr_to))
> timeout_del(&sc->amrr_to);
>
> + usb_rem_wait_task(sc->sc_udev, &sc->sc_task);
> +
> + usbd_ref_wait(sc->sc_udev);
> +
> + if (ifp->if_softc != NULL) {
> + ieee80211_ifdetach(ifp);/* free all nodes */
> + if_detach(ifp);
> + }
> +
> if (sc->amrr_xfer != NULL) {
> usbd_free_xfer(sc->amrr_xfer);
> sc->amrr_xfer = NULL;
> @@ -547,8 +550,15 @@ ural_next_scan(void *arg)
> struct ieee80211com *ic = &sc->sc_ic;
> struct ifnet *ifp = &ic->ic_if;
>
> + if (usbd_is_dying(sc->sc_udev))
> + return;
> +
> + usbd_ref_incr(sc->sc_udev);
> +
> if (ic->ic_state == IEEE80211_S_SCAN)
> ieee80211_next_scan(ifp);
> +
> + usbd_ref_decr(sc->sc_udev);
> }
>
> void
> @@ -559,6 +569,9 @@ ural_task(void *arg)
> enum ieee80211_state ostate;
> struct ieee80211_node *ni;
>
> + if (usbd_is_dying(sc->sc_udev))
> + return;
> +
> ostate = ic->ic_state;
>
> switch (sc->sc_state) {
> @@ -574,7 +587,8 @@ ural_task(void *arg)
>
> case IEEE80211_S_SCAN:
> ural_set_chan(sc, ic->ic_bss->ni_chan);
> - timeout_add_msec(&sc->scan_to, 200);
> + if (!usbd_is_dying(sc->sc_udev))
> + timeout_add_msec(&sc->scan_to, 200);
> break;
>
> case IEEE80211_S_AUTH:
> @@ -1324,6 +1338,11 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
> struct ifreq *ifr;
> int s, error = 0;
>
> + if (usbd_is_dying(sc->sc_udev))
> + return ENXIO;
> +
> + usbd_ref_incr(sc->sc_udev);
> +
> s = splnet();
>
> switch (cmd) {
> @@ -1387,6 +1406,8 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
>
> splx(s);
>
> + usbd_ref_decr(sc->sc_udev);
> +
> return error;
> }
>
> @@ -2147,7 +2168,8 @@ ural_amrr_start(struct ural_softc *sc, s
>i--);
> ni->ni_txrate = i;
>
> - timeout_add_sec(&sc->amrr_to, 1);
> + if (!usbd_is_dying(sc->sc_udev))
> + timeout_add_sec(&sc->amrr_to, 1);
> }
>
> void
> @@ -2157,6 +2179,11 @@ ural_amrr_timeout(void *arg)
> usb_device_request_t req;
> int s;
>
> + if (usbd_is_dying(sc->sc_udev))
> + return;
> +
> + usbd_ref_incr(sc->sc_udev);
> +
> s = splusb();
>
> /*
> @@ -2174,6 +2201,8 @@ ural_amrr_timeout(void *arg)
> (void)usbd_transfer(sc->a
Re: New acpi challenges! New Dell XPS blows up in acpivideo!
don't forget to send the amldump
On Wed, Dec 22, 2010 at 04:08:54PM -0500, Kenneth R Westerback wrote:
> Got a new Dell XPS 401 laptop today and booted amd64 -current bsd.mp
> off of a usb stick. It immediately blew up in acpi. bsd.rd did not
> blow up.
>
> There seems to be a minor (i.e. non ddb> causing) issue prior to
> acpivideo:
>
> acpiec0 at acpi0
> acpicpu0 at acpi0acpi0: unable to load \\_PR_.CSDT
> : PSS
> acpicpu1 at acpi0: PSS
>
>
> Hand transcribed:
>
>
> acpivideo at acpi0: GFX0
> 0x801d6788 cnt:01 stk: 00 objref: 0x801c3c08
> index: 0 opcode: Cond Ref
> [\HDOS] 0x801c3c08 cnt: 04 stk: 00 method: 08
> Could not convert 101 to 1
> 6a58 Called: \_SB_.PCI0.GFX0._DOS
> arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
> 6a5c Called: \_SB_.PCI0.GFX0._DOS
> arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
> panic: aml_die aml_xconvert:2052
>
> ddb{0}> trace
> _aml_die
> aml_xconvert
> aml_xstore
> aml_xparse
> aml_xeval
> aml_evalnode
> acpivideo_set_policy
> acpivideo_attach
> config_attach
> acpi_foundvideo
> aml_found_node
> aml_found_node
> aml_found_node
> aml_found_node
> aml_found_node
> acpi_attach
> config_attach
> bios_attach
> config_attach
> mainbus_attach
> config_attach
> cpu_configure
> main
>
> Disabling acpivideo via ukc makes bsd.mp boot.
>
> tar of acpidump files attached.
>
> Note that the NVidia 425M is only recognized because I added that
> to pcidevs.
>
> Ken
>
> OpenBSD 4.8-current (GENERIC.MP) #3: Wed Dec 22 12:37:54 EST 2010
> r...@tbay.westerback.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3151962112 (3005MB)
> avail mem = 3054088192 (2912MB)
> User Kernel Config
> UKC> disable acpivido\^H \^Hep\^H \^Ho
> 351 acpivideo* disabled
> UKC> quit
> Continuing...
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb6d0 (56 entries)
> bios0: vendor Dell Inc. version "A04" date 10/15/2010
> bios0: Dell Inc. XPS L401X
> acpi0 at bios0: rev 3
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC SSDT MCFG SLIC HPET OSFR SSDT
> acpi0: wakeup devices P0P1(S3) P0P2(S3) P0P3(S3) P0P4(S3) P0P5(S3) BR20(S3)
> EUSB(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S4) USB4(S3) USB5(S3)
> USB6(S3) PEX0(S3) PEX1(S3) PEX2(S3) PEX3(S3) PEX4(S3) PEX5(S3) PEX6(S3)
> PEX7(S3) SLPB(S0) LID0(S3)
> 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) i7 CPU Q 840 @ 1.87GHz, 1862.26 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: apic clock running at 132MHz
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu4:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu5 at mainbus0: apid 3 (application processor)
> cpu5: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu5:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu5: 256KB 64b/line 8-way L2 cache
> cpu6 at mainbus0: apid 5 (application processor)
> cpu6: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu6:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LO
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 22, 2010 at 4:49 PM, Clint Pachl wrote: > Would it be possible to use what randomness the system does have to seed > some reader that pseudo-randomly reads arbitrary bits from the loaded kernel > image in RAM? > > This may differ per system, but doesn't uninitialized RAM start in an > "unknown state?" If so, could that be added to the entropy pool if it is > determined to be random (i.e. not initialized to zeros)? I think we'd much rather just have a good random generator, than rely on one of uncertain quality. If the system really, really, really needs random numbers before entropy is available, then we should fix that problem, not try to magic up some entropy.
Re: Allegations regarding OpenBSD IPSEC
Salvador Fandiqo wrote: On 12/22/2010 01:46 AM, Theo de Raadt wrote: 2010/12/21 Theo de Raadt: HANG ON. Go look at the function random_seed() in /usr/src/etc/rc Then look at when it is called. so, the current state of the PRNG will be preserved during reboots. That statement is false. Good. No. You misread the code. That gives some information about system entropy, which will be "good" at all times, except for the very first boot of an installation. See : rnd.c: randomwrite() -> add_entropy_words(); That part is true. But what you said earlier is false. However, arc4_stir will still be called once after every reboot. During its first call, the value of nanotime() will be placed at the beginning of buf, which is then beeing used to init the rc4 context. What else do you think we should use? Where do we invent entropy from when the kernel has only been running for 0.01 of a second? Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, but from the outside, specially considered that machines are not rebooted so often (and when they are, it is usually for updating them), it would look like real random data. Now that it's amateur suggestion hour (no offense Salva), I'm going to take a shot. Would it be possible to use what randomness the system does have to seed some reader that pseudo-randomly reads arbitrary bits from the loaded kernel image in RAM? This may differ per system, but doesn't uninitialized RAM start in an "unknown state?" If so, could that be added to the entropy pool if it is determined to be random (i.e. not initialized to zeros)?
Re: Allegations regarding OpenBSD's PRNG
On Wed, Dec 22, 2010 at 12:24 PM, Marsh Ray wrote: > On 12/22/2010 11:44 AM, Kjell Wooding wrote: > >> Can you please stop wasting time asking questions before you bother to >> read >> about what you are asking? >> > > Consider the possibility that I have, in fact, read a little bit about it > and am asking some of these questions because I suspect you don't actually > have a good answer for them. People who are deeply convinced of their > correctness usually aren't able to reflect on it objectively. > Perhaps that's why you seem unwilling to listen to what you are being told. Which is why I'm wondering what exactly, this 'multi-consumer' design > feature is all about. Is it simply that more userland stuff is pinging the > kernel at unpredictable times resulting in more timestamps feeding into the > central entropy pool? It seems like you could accomplish that with any > syscall. Or is there some other effect being claimed? Can you please stop wasting time asking questions before you bother to read about what you are asking? You have flipped the bozo bit. You're on your own until you bother doing some of your homework. -kj
New acpi challenges! New Dell XPS blows up in acpivideo!
Got a new Dell XPS 401 laptop today and booted amd64 -current bsd.mp
off of a usb stick. It immediately blew up in acpi. bsd.rd did not
blow up.
There seems to be a minor (i.e. non ddb> causing) issue prior to
acpivideo:
acpiec0 at acpi0
acpicpu0 at acpi0acpi0: unable to load \\_PR_.CSDT
: PSS
acpicpu1 at acpi0: PSS
Hand transcribed:
acpivideo at acpi0: GFX0
0x801d6788 cnt:01 stk: 00 objref: 0x801c3c08
index: 0 opcode: Cond Ref
[\HDOS] 0x801c3c08 cnt: 04 stk: 00 method: 08
Could not convert 101 to 1
6a58 Called: \_SB_.PCI0.GFX0._DOS
arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
6a5c Called: \_SB_.PCI0.GFX0._DOS
arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
panic: aml_die aml_xconvert:2052
ddb{0}> trace
_aml_die
aml_xconvert
aml_xstore
aml_xparse
aml_xeval
aml_evalnode
acpivideo_set_policy
acpivideo_attach
config_attach
acpi_foundvideo
aml_found_node
aml_found_node
aml_found_node
aml_found_node
aml_found_node
acpi_attach
config_attach
bios_attach
config_attach
mainbus_attach
config_attach
cpu_configure
main
Disabling acpivideo via ukc makes bsd.mp boot.
tar of acpidump files attached.
Note that the NVidia 425M is only recognized because I added that
to pcidevs.
Ken
OpenBSD 4.8-current (GENERIC.MP) #3: Wed Dec 22 12:37:54 EST 2010
r...@tbay.westerback.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3151962112 (3005MB)
avail mem = 3054088192 (2912MB)
User Kernel Config
UKC> disable acpivido\^H \^Hep\^H \^Ho
351 acpivideo* disabled
UKC> quit
Continuing...
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb6d0 (56 entries)
bios0: vendor Dell Inc. version "A04" date 10/15/2010
bios0: Dell Inc. XPS L401X
acpi0 at bios0: rev 3
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG SLIC HPET OSFR SSDT
acpi0: wakeup devices P0P1(S3) P0P2(S3) P0P3(S3) P0P4(S3) P0P5(S3) BR20(S3)
EUSB(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S4) USB4(S3) USB5(S3)
USB6(S3) PEX0(S3) PEX1(S3) PEX2(S3) PEX3(S3) PEX4(S3) PEX5(S3) PEX6(S3)
PEX7(S3) SLPB(S0) LID0(S3)
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) i7 CPU Q 840 @ 1.87GHz, 1862.26 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 132MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu3: 256KB 64b/line 8-way L2 cache
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
cpu4:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu4: 256KB 64b/line 8-way L2 cache
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
cpu5:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu5: 256KB 64b/line 8-way L2 cache
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
cpu6:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu6: 256KB 64b/line 8-way L2 cache
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
cpu7:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE
Re: pf debug states: ioctl interface and state names.
On Wed, 22 Dec 2010 09:03:57 +0100 Henning Brauer wrote: > * Thomas Pfaff [2010-12-21 22:19]: [...] > > 2) pf.conf(5) says "set debug" can be one of loud, misc, none, or urgent > > but if you "set debug loud" in pf.conf and load it the pfctl -sa output > > will say "Debug: debug", or if you "set debug misc" it will say "Debug: > > notice". It does not say what you set in pf.conf. > > > > 3) pfctl(8) -x option lets you set one of emerg, alert, crit, err, > > warning, notice, info, or debug. These will show up by their correct > > name in pfctl -sa output. They're also valid names in pf.conf so > > should they not also be mentioned in pf.conf(5)? > > yes. ryan cleaned that up big time to use syslog-like levels (i. e. > your case 3). apparently we missed a few cases of the old ones (misc, > loud etc). > So the names in 2) should be removed from the pf.conf man page and the names in 3) should be added, then? How about something like this (text is mostly a copy of that in the pfctl man page for the -x option): Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.482 diff -u -p -r1.482 pf.conf.5 --- pf.conf.5 15 Dec 2010 14:06:05 - 1.482 +++ pf.conf.5 22 Dec 2010 20:48:49 - @@ -981,20 +981,12 @@ an ICMP UNREACHABLE is returned for bloc and all other packets are silently dropped. .El .It Ar set debug -Set the debug -.Ar level -to one of the following: -.Pp -.Bl -tag -width -compact -.It Ar loud -Generate debug messages for common conditions. -.It Ar misc -Generate debug messages for various errors. -.It Ar none -Don't generate debug messages. -.It Ar urgent -Generate debug messages only for serious errors. -.El +Set the debug level which limits the severity of log messages printed by pf(4). +This should be a keyword from the following ordered list (highest to lowest): +emerg, alert, crit, err, warning, notice, info, and debug. +The last keyword, debug, must be quoted. +These keywords correspond to the similar (LOG_) values specified to the +syslog(3) library routine, and may be abbreviated. .It Ar set fingerprints Load fingerprints of known operating systems from the given filename. By default fingerprints of known operating systems are automatically
Re: Allegations regarding OpenBSD's PRNG
> Which is why I'm wondering what exactly, this 'multi-consumer' design > feature is all about. Is it simply that more userland stuff is pinging > the kernel at unpredictable times resulting in more timestamps feeding > into the central entropy pool? It seems like you could accomplish that > with any syscall. Or is there some other effect being claimed? Holy cow, you are dense. I am going to throw out estimates here because (a) it has been a long time since we tested, and (b) so much can vary machine to machine. Without a hardware RNG device, a typical i386 desktop machine can provide (based on interrupt sources) around 1800 bytes of base entropy to the MD5 thrasher -- per minute. Meanwhile, OpenBSD is consuming about 80 KB of arc4random output per minute. How do you convert 1800 bytes of input to 81920 bytes of output, while giving references out to papers that don't solve this problem. And how do you make it fast. Because all those papers try to solve the problem by making it SERIOUSLY SLOWER. While all this is going on, each userland application is using random data out of it's own libc arc4random for many purposes, including per malloc() and free() amongst many others, and are re-seeding their libc generators from the kernel as required, putting even more pressure on the kernel. You don't know what you are talking about, and you don't seem to have the ability to wrap your mind around all the parts that are involved. I am not reading your mails again.
Re: Allegations regarding OpenBSD's PRNG
On 12/22/2010 01:42 PM, Ted Unangst wrote: This distinguisher works by looking at the probability of pairs of bytes being repeated (2 to 5 times) within a certain number of rounds (having a gap 'g' between them). Fig 3 shows their results for gaps from 0 to 60. It looks like the data collection cost incurred by a reseeding would comparable to the amount recommended to skip after initialization: 256 bytes. I'm not sure how you arrived at this result. The new stream is unrelated to the old one. Otherwise, why not just treat all RC4 streams as the same? Yes, they very nearly are. To a man with a memory of 30 minutes or so, every new year is unrelated to the old one. To a statistical test that only looks back on the last 30 bytes or so of history for a low-probability event, something that changes every few MB won't affect it. This distinguisher works on samples of any four bytes of output from any RC4 stream regardless of keying. (But it needs less data if you're give it slightly longer sequences.) Which is the key property of an RNG: every output value is the same until you look at it. Which is why I'm wondering what exactly, this 'multi-consumer' design feature is all about. Is it simply that more userland stuff is pinging the kernel at unpredictable times resulting in more timestamps feeding into the central entropy pool? It seems like you could accomplish that with any syscall. Or is there some other effect being claimed? - Marsh
Re: Allegations regarding OpenBSD's PRNG
On Wed, Dec 22, 2010 at 10:44:48AM -0700, Kjell Wooding wrote: > Oh good grief. Yes, ARC4 is being used to stretch a random source. Feel free > to hunt for the distinguisher in the OpenBSD multi-consumer model. There's a > good paper in there. If you can show a distinguisher (even without > reseedings) with an equivalent number of consumers randomly pulling data > from the stream, then you might be able to tell us how long we should go > between reseeding. I agree that there's a good paper in this, I would love to see the entropy added by the multi-consumer model quantified, or even an upper bound placed on it. In the past when I've given my talk on randomness in the OpenBSD network stack, I've discussed this and I always ask for someone to come forward with such a paper. Unfortunately I don't get the impression that the amateur cryptographers questioning the OpenBSD PRNG are qualified to produce such a paper (if they were, they wouldn't be mailing here, they'd be submitting it to real cryptographers for peer review)
Re: Allegations regarding OpenBSD's PRNG
On Wed, Dec 22, 2010 at 2:24 PM, Marsh Ray wrote: > This one does it in 2^26 bytes: > http://www.iacr.org/cryptodb/data/paper.php?pubkey=2597 > > Let's see, (libc)arc4random.c says: >> arc4_count = 160; > > That's about 2^20 so you'd get 41 reseedings generating that much input > data. But how much would these reseedings disrupt the statistics process? > > This distinguisher works by looking at the probability of pairs of bytes > being repeated (2 to 5 times) within a certain number of rounds (having a > gap 'g' between them). Fig 3 shows their results for gaps from 0 to 60. It > looks like the data collection cost incurred by a reseeding would comparable > to the amount recommended to skip after initialization: 256 bytes. I'm not sure how you arrived at this result. The new stream is unrelated to the old one. Otherwise, why not just treat all RC4 streams as the same?
Re: Allegations regarding OpenBSD's PRNG
On 12/22/2010 11:44 AM, Kjell Wooding wrote: Can you please stop wasting time asking questions before you bother to read about what you are asking? Consider the possibility that I have, in fact, read a little bit about it and am asking some of these questions because I suspect you don't actually have a good answer for them. People who are deeply convinced of their correctness usually aren't able to reflect on it objectively. On Wed, Dec 22, 2010 at 10:00 AM, Marsh Raywrote: How is this different, except for perhaps the intermediate arc4 cipher. What does that add, other than crappiness? (RC4 is known to be distinguishable from a good random source.) Oh good grief. Yes, ARC4 is being used to stretch a random source. Feel free to hunt for the distinguisher in the OpenBSD multi-consumer model. This one does it in 2^26 bytes: http://www.iacr.org/cryptodb/data/paper.php?pubkey=2597 Let's see, (libc)arc4random.c says: > arc4_count = 160; That's about 2^20 so you'd get 41 reseedings generating that much input data. But how much would these reseedings disrupt the statistics process? This distinguisher works by looking at the probability of pairs of bytes being repeated (2 to 5 times) within a certain number of rounds (having a gap 'g' between them). Fig 3 shows their results for gaps from 0 to 60. It looks like the data collection cost incurred by a reseeding would comparable to the amount recommended to skip after initialization: 256 bytes. So the current reseeding regimen on libc's arc4random probably requires this distinguisher to consume something like 0.02% more data to reach the same success rate. There's a good paper in there. If you can show a distinguisher (even without reseedings) with an equivalent number of consumers randomly pulling data from the stream, then you might be able to tell us how long we should go between reseeding. Don't take my word for it. RC4 doesn't even meet the minimum standards for the payment card industry (PCI). I would be (very?) surprised if you have time to see a bias under the current model (multi-consumer, rapid reseeding), though that doesn't mean it isn't possible. They wouldn't let you encrypt a MasterCard number with it, why would you use it for nonce and key generation on a supposedly "strong crypto"-oriented OS? The problem is you are asking boneheaded questions without taking the time to understand what you are asking about. You are all noise, and no signal. Was that an example of a boneheaded question? - Marsh
Re: Allegations regarding OpenBSD's PRNG
Can you please stop wasting time asking questions before you bother to read about what you are asking? On Wed, Dec 22, 2010 at 10:00 AM, Marsh Ray wrote: > How is this different, except for perhaps the intermediate arc4 cipher. > What does that add, other than crappiness? (RC4 is known to be > distinguishable from a good random source.) > Oh good grief. Yes, ARC4 is being used to stretch a random source. Feel free to hunt for the distinguisher in the OpenBSD multi-consumer model. There's a good paper in there. If you can show a distinguisher (even without reseedings) with an equivalent number of consumers randomly pulling data from the stream, then you might be able to tell us how long we should go between reseeding. I would be (very?) surprised if you have time to see a bias under the current model (multi-consumer, rapid reseeding), though that doesn't mean it isn't possible. The problem is you are asking boneheaded questions without taking the time to understand what you are asking about. You are all noise, and no signal. -kj
Re: Allegations regarding OpenBSD IPSEC
On 12/22/2010 09:29 AM, Kurt Knochner wrote: Do you have a hint, how I could emit the random values from arc4random in a "clever" way? I thought of using an internal buffer and accessing that through sysctl or another device, e.g. /dev/randstream. You should definitely check out this page if you hadn't already: http://www.phy.duke.edu/~rgb/General/dieharder.php The dieharder test suite already comes with input modules for reading from system devices and lots of other sources. The later looks more complicated, but will certainly teach me more about openbsd internals. Well if that's your goal, I think you probably need to patch the kernel to DMA the stuff into video RAM and offload the processing of it there. :-) Or something else, be creative. Try to write a backdoor In any case, generic statistical tests might detect really horrible brokenness but they're are not the thing to certify CSRNGs with. Somehow people managed to run them on RC4 for years before anyone noticed that the second byte of output was zero twice as often as it should be. What could be really useful would be better models of the effective entropy contributed by kernel event classes going into the pool. - Marsh
Re: Allegations regarding OpenBSD's PRNG
On Wed, 22 Dec 2010 11:00:43 -0600 Marsh Ray wrote: > But a typical box doesn't have "hundreds and hundreds" of processes or > unpredictable event sources. There are 300 or so references in the > source tree, but most of them are in code that doesn't run on any given > machine. > > A special-purpose box (e.g. a IPsec VPN gateway) may have very few other > than network events, which are known to an outside observer to a > significant degree. Well I would have thought it's certainly better, though I'm not in the crypto internals know and haven't been studying very closely, so I can't comment. Cron, Mail server, web server, relays all create many processes and you should be monitoring any important system too. The unix philosophy of many small programs means a high number of processes is rather likely. The daily script itself uses many, though admittedly in this case only once a day. Isn't the stream used for random pids e.g. all processes?
Re: Allegations regarding OpenBSD's PRNG
On 12/22/2010 06:57 AM, Kevin Chadwick wrote: On Wed, 22 Dec 2010 05:08:56 -0600 Marsh Ray wrote: Let's say I could sample the output of the RNG in every process and from every network device in the system. As much as I wanted. How could I tell the difference between "one prng per purpose" and "data-slicing one prng with all consumers"? There was a thread "called how to use /dev/srandom" where theo sent this, which may be relevant? It's relevant, but not precisely the question I was trying to ask. For those who don't want to go read the code, the algorith on the very back end is roughly this: (a) collect entropy until there is a big enough buffer (b) fold it into the srandom buffer, eventually That is just like the past. But the front end is different. From the kernel side: (1) grab a srandom buffer and start a arc4 stream cipher on it (discarding the first bit, of course) (2) now the kernel starts taking data from this on every packet it sends, to modulate this, to modulate that, who knows. (3) lots of other subsystems get small chunks of random from the stream; deeply unpredictable when (4) on very interrupt, based on quality, the kernel injects something into (a) (5) re-seed the buffer as stated in (1) when needed How is this different, except for perhaps the intermediate arc4 cipher. What does that add, other than crappiness? (RC4 is known to be distinguishable from a good random source.) Simultaneously, userland programs need random data: (i) libc does a sysctl to get a chunk from the rc4 buffer (ii) starts a arc4 buffer of it's own, in that program (iii) feeds data to the program, and re-seeds the buffer when needed The arc4 stream ciphers get new entropy when they need. Looking at lib/libc/crypt/arc4random.c it would appear that happens once on startup or fork and then again after about every 1.6MB of random data consumed. Probably most processes will not consume that much. But the really neat architecture here is that a single stream cipher is *unpredictably* having entropy taken out of it, by hundreds of consumers. How is that noticeably different than any other system where processes are reading from /dev/(u)random and kernel events are mixing in a high-resolution timer? In regular unix operating systems, there are only a few entropy consumers. In OpenBSD there are hundreds and hundreds. But a typical box doesn't have "hundreds and hundreds" of processes or unpredictable event sources. There are 300 or so references in the source tree, but most of them are in code that doesn't run on any given machine. A special-purpose box (e.g. a IPsec VPN gateway) may have very few other than network events, which are known to an outside observer to a significant degree. The entire system is full of random number readers, at every level. That is why this works so well. How do you know it works well? How is it observably different? - Marsh
Vacante si proprietati
Daca aveti probleme cu vizionarea acestui email dati [click aici] pentru a vizualiza varianta online! [IMAGE] [IMAGE] Newsletter 21.12.2010 [IMAGE] CaseFaraIntermediari.roUrmariti-ne pe Facebook!Urmariti-ne pe Twitter!Urmariti-ne pe Blogger! Ultimele anunturi adaugate Vezi toate anunturile [IMAGE] [IMAGE] Apartament 4 camere - Dorobanti, Bucuresti Apartament 4 camere - Dorobanti, Bucuresti 105.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Casa si teren - Cetatuia, Giurgiu Casa si teren - Cetatuia, Giurgiu 100.000 RON VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Vila 6 camere - Corbeanca-Petresti Vila 6 camere - Corbeanca-Petresti 169.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Apartament 3 camere - Bucurestii Noi Apartament 3 camere - Bucurestii Noi 270.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Apartament 3 camere - Giulesti, Bucuresti Apartament 3 camere - Giulesti, Bucuresti 59.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] Publica si tu un anunt! [IMAGE] Stiri Imobiliare Vezi toate stirile [IMAGE] [IMAGE] Pretul garsonierelor, inapoi in anul 2004 Pretul garsonierelor, inapoi in anul 2004 Cea mai ieftina garsoniera din Bucuresti costa 8.300 de euro, este situata in cartierul Giulesti, iar pretul este cu doar 800 de euro mai mare decat o locuinta similara in Targu-Mures. Vanzarile slabe pe segmentul rezidential, cauzate de puterea de cumparare tot mai scazuta a romanilor, au adus ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Boc: Peste 1.000 de locuinte ANL si 983 de locuinte sociale vor fi finalizate in 2011 Boc: Peste 1.000 de locuinte ANL si 983 de locuinte sociale vor fi finalizate in 2011 Peste o mie de locuinte ANL vor fi finalizate in 2011, prin programul dezvoltarii nationale, precum si 983 de locuinte sociale si aproape 1.500 de apartamente destinate chiriasilor evacuati din casele nationalizate, a declarat, luni, primul ministru Emil Boc, in debutul dezbaterilor la proiectul ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Magazinul Cocor, la 2 luni de la redeschidere: Numarul vizitatorilor, pe sfert fata de inainte de modernizare Magazinul Cocor, la 2 luni de la redeschidere: Numarul vizitatorilor, pe sfert fata de inainte de modernizare Numarul mediu de vizitatori ai magazinului este de 5.000 pe zi, jumatate fata de estimarile initiale, a spus, pentru DailyBusiness.ro, Dan Barbulescu (foto), presedintele consiliului de administratie al Cocor SA. Numarul de vizitatori reprezinta doar un sfert din numarul de vizitatori mediu ...[CITESTE TOT] [IMAGE] [IMAGE] Oferte turistice Vezi toate ofertele [IMAGE] [IMAGE] Pensiunea Vila Predelut - Bran Pensiunea Vila Predelut - Bran negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Luminita - Bran-Moieciu Pensiunea Luminita - Bran-Moieciu negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Inima Bucegilor - Moieciu Pensiunea Inima Bucegilor - Moieciu negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Pestera - sat Pestera, Brasov Pensiunea Pestera - sat Pestera, Brasov negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Bell Monte - Sambata de Sus Pensiunea Bell Monte - Sambata de Sus negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] Publica si tu un anunt! Stiri economice Vezi toate stirile [IMAGE] [IMAGE] Cum vrea statul roman sa ne indatoreze pe sest Cum vrea statul roman sa ne indatoreze pe sest Intr-o economie cu functionare normala, bancile, ca principali intermediari ai circulatiei banilor, au rolul de a face selectia riguroasa a proiectelor de investitii care solicita finantare, printr-o evaluare stricta a riscurilor si a sanselor de profitabilitate ale acestora, astfel incat sa ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Mos Craciun le aduce romanilor in special dulciuri si imbracaminte Mos Craciun le aduce romanilor in special dulciuri si imbracaminte Un studiu realizat online de firma de cercetare GfK Romania arata ca 84% dintre romanii care ofera cadouri de Craciun aleg dulciurile, iar peste trei sferturi dintre cei care au raspuns cumpara obiectele de imbracaminte si accesoriile vestimentare. Romanii mai ofera d! e Craciun produse si servicii ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Studiourile MGM au iesit din faliment Studiourile MGM au iesit din faliment Noii sefi ai MGM, Gary Barber si Roger Birnbaum, fondatorii Spyglass Entertainment, au anuntat, luni, intr-un comunicat comun, ca planul de restructurare, aprobat la inceputul lunii decembrie de justitie, a devenit efectiv si studiourile vor putea sa-si relanseze productia de filme, informeaza ...[CITESTE TOT] [IMAGE] [IMAGE] Scoala romaneasca Vezi toate scolile [IMAGE] [IMAGE] Scoala Nr, 205 Scoala Nr, 205 Aleea Compozitorilor DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] G
Re: Allegations regarding OpenBSD IPSEC
-Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Joachim Schipper Subject: Re: Allegations regarding OpenBSD IPSEC > On Wed, Dec 22, 2010 at 04:29:59PM +0100, Kurt Knochner wrote: > > > > > Do you have a hint, how I could emit the random values from arc4random > > in a "clever" way? > > This isn't even remotely clever, but printf() and some base64 encoding > should work fine for a one-off experiment. There *is* a limit to how > much you can print before you fill up the dmesg; if insufficient, try > compiling with a CONFIG.MP_LARGEBUF like this: > > --- > include "arch/amd64/conf/GENERIC.MP" > > option MSGBUFSIZE=131072 > --- > > You may wish to look at misc/ent. > > Joachim or use syslog(3) to output to your destination of choice.
Re: keynote.{1,3,4,5}: fix IEEE conference name
On Wed, Dec 22, 2010 at 09:51:22AM -0500, Lawrence Teo wrote:
> The keynote.{1,3,4,5} man pages reference a paper entitled
> "Decentralized Trust Management" by M. Blaze, J. Feigenbaum, and J.
> Lacy, but the name of the conference is incorrect.
>
> That paper was presented at the IEEE Symposium on Security and
> Privacy [1, 2], and not the "IEEE Conference on Privacy and
> Security."
>
> [1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=502679
>
> [2] http://www.crypto.com/papers/
>
> The following diff fixes the conference name.
>
> Lawrence
>
fixed, thanks.
jmc
>
> Index: keynote.1
> ===
> RCS file: /cvs/src/lib/libkeynote/keynote.1,v
> retrieving revision 1.31
> diff -u -p -r1.31 keynote.1
> --- keynote.1 3 Aug 2007 08:09:37 - 1.31
> +++ keynote.1 19 Dec 2010 03:15:06 -
> @@ -262,7 +262,7 @@ exits with code \-1 if there was an erro
> .%A J. Feigenbaum
> .%A J. Lacy
> .%T Decentralized Trust Management
> -.%J IEEE Conference on Privacy and Security
> +.%J IEEE Symposium on Security and Privacy
> .%D 1996
> .Re
> .Rs
> Index: keynote.3
> ===
> RCS file: /cvs/src/lib/libkeynote/keynote.3,v
> retrieving revision 1.41
> diff -u -p -r1.41 keynote.3
> --- keynote.3 19 Sep 2010 22:22:13 - 1.41
> +++ keynote.3 19 Dec 2010 03:15:07 -
> @@ -885,7 +885,7 @@ function description above.
> .%A J. Feigenbaum
> .%A J. Lacy
> .%T Decentralized Trust Management
> -.%J IEEE Conference on Privacy and Security
> +.%J IEEE Symposium on Security and Privacy
> .%D 1996
> .Re
> .Rs
> Index: keynote.4
> ===
> RCS file: /cvs/src/lib/libkeynote/keynote.4,v
> retrieving revision 1.27
> diff -u -p -r1.27 keynote.4
> --- keynote.4 3 Aug 2007 08:09:37 - 1.27
> +++ keynote.4 19 Dec 2010 03:15:07 -
> @@ -881,7 +881,7 @@ However, the following return "Reject" (
> .%A J. Feigenbaum
> .%A J. Lacy
> .%T Decentralized Trust Management
> -.%J IEEE Conference on Privacy and Security
> +.%J IEEE Symposium on Security and Privacy
> .%D 1996
> .Re
> .Rs
> Index: keynote.5
> ===
> RCS file: /cvs/src/lib/libkeynote/keynote.5,v
> retrieving revision 1.18
> diff -u -p -r1.18 keynote.5
> --- keynote.5 26 Mar 2010 19:30:40 - 1.18
> +++ keynote.5 19 Dec 2010 03:15:07 -
> @@ -681,7 +681,7 @@ the interest of readability.
> .%A J. Feigenbaum
> .%A J. Lacy
> .%T Decentralized Trust Management
> -.%J IEEE Conference on Privacy and Security
> +.%J IEEE Symposium on Security and Privacy
> .%D 1996
> .Re
> .Rs
Re: allow bioctl to read passphrase from stdin
On Tue, Dec 21, 2010 at 02:22:37PM +0100, Jiri B. wrote: > On Mon, Nov 29, 2010 at 02:22:35PM -0800, Chris Kuethe wrote: > >Currently bioctl invokes readpassphrase(3) with RPP_REQUIRE_TTY, which > >means that there must be a controlling tty to read the password from. > >This diff adds an option (-s) to force bioctl to read the passphrase > >from stdin. Without this option existing behavior is maintained. > > Hello, > > little improvement of bioctl(8), when using stdin it cannot be used > for inital creation of the crypt volume. (there's same info for passfile.) > > jirib > fixed, thanks. jmc > Index: bioctl.8 > === > RCS file: /cvs/src/sbin/bioctl/bioctl.8,v > retrieving revision 1.83 > diff -u -p -r1.83 bioctl.8 > --- bioctl.8 1 Dec 2010 19:40:18 - 1.83 > +++ bioctl.8 21 Dec 2010 13:20:39 - > @@ -240,6 +240,7 @@ Read the passphrase for the selected cry > .Pa /dev/stdin > rather than > .Pa /dev/tty . > +It cannot be used during the initial creation of the crypto volume. > .El > .Sh EXAMPLES > The following command, executed from the command line, would configure
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 22, 2010 at 04:29:59PM +0100, Kurt Knochner wrote: > 2010/12/22 Theo de Raadt : > > Go ahead, do a FIPS check on it. You will be doing a FIPS check on > > 4096 bytes here, then a gap of unknown length, then 4096 bytes here, > > then a gap of unknown length, then 4096 bytes here, then a gap of > > unknown length, > Do you have a hint, how I could emit the random values from arc4random > in a "clever" way? This isn't even remotely clever, but printf() and some base64 encoding should work fine for a one-off experiment. There *is* a limit to how much you can print before you fill up the dmesg; if insufficient, try compiling with a CONFIG.MP_LARGEBUF like this: --- include "arch/amd64/conf/GENERIC.MP" option MSGBUFSIZE=131072 --- You may wish to look at misc/ent. Joachim
Re: Allegations regarding OpenBSD IPSEC
2010/12/22 Theo de Raadt : > Go ahead, do a FIPS check on it. You will be doing a FIPS check on > 4096 bytes here, then a gap of unknown length, then 4096 bytes here, > then a gap of unknown length, then 4096 bytes here, then a gap of > unknown length, that's true, if one uses just /dev/arandom (as other consumers will call arc4random() in the "background" as well). However if one changes the code of arc4random() and arc4random_buf() to emit all generated random values, we will get the whole sequence, from the very first byte, no matter what "consumer" requestes data. Reading from /dev/arandom will then generate the required amount of random values for the statistic tests, while we can still record all values. I'll see if I'll be able to do that, just for the sake of learning something about the internals of openbsd. Do you have a hint, how I could emit the random values from arc4random in a "clever" way? I thought of using an internal buffer and accessing that through sysctl or another device, e.g. /dev/randstream. The later looks more complicated, but will certainly teach me more about openbsd internals. Regards Kurt Knochner http://knochner.com/
keynote.{1,3,4,5}: fix IEEE conference name
The keynote.{1,3,4,5} man pages reference a paper entitled
"Decentralized Trust Management" by M. Blaze, J. Feigenbaum, and J.
Lacy, but the name of the conference is incorrect.
That paper was presented at the IEEE Symposium on Security and
Privacy [1, 2], and not the "IEEE Conference on Privacy and
Security."
[1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=502679
[2] http://www.crypto.com/papers/
The following diff fixes the conference name.
Lawrence
Index: keynote.1
===
RCS file: /cvs/src/lib/libkeynote/keynote.1,v
retrieving revision 1.31
diff -u -p -r1.31 keynote.1
--- keynote.1 3 Aug 2007 08:09:37 - 1.31
+++ keynote.1 19 Dec 2010 03:15:06 -
@@ -262,7 +262,7 @@ exits with code \-1 if there was an erro
.%A J. Feigenbaum
.%A J. Lacy
.%T Decentralized Trust Management
-.%J IEEE Conference on Privacy and Security
+.%J IEEE Symposium on Security and Privacy
.%D 1996
.Re
.Rs
Index: keynote.3
===
RCS file: /cvs/src/lib/libkeynote/keynote.3,v
retrieving revision 1.41
diff -u -p -r1.41 keynote.3
--- keynote.3 19 Sep 2010 22:22:13 - 1.41
+++ keynote.3 19 Dec 2010 03:15:07 -
@@ -885,7 +885,7 @@ function description above.
.%A J. Feigenbaum
.%A J. Lacy
.%T Decentralized Trust Management
-.%J IEEE Conference on Privacy and Security
+.%J IEEE Symposium on Security and Privacy
.%D 1996
.Re
.Rs
Index: keynote.4
===
RCS file: /cvs/src/lib/libkeynote/keynote.4,v
retrieving revision 1.27
diff -u -p -r1.27 keynote.4
--- keynote.4 3 Aug 2007 08:09:37 - 1.27
+++ keynote.4 19 Dec 2010 03:15:07 -
@@ -881,7 +881,7 @@ However, the following return "Reject" (
.%A J. Feigenbaum
.%A J. Lacy
.%T Decentralized Trust Management
-.%J IEEE Conference on Privacy and Security
+.%J IEEE Symposium on Security and Privacy
.%D 1996
.Re
.Rs
Index: keynote.5
===
RCS file: /cvs/src/lib/libkeynote/keynote.5,v
retrieving revision 1.18
diff -u -p -r1.18 keynote.5
--- keynote.5 26 Mar 2010 19:30:40 - 1.18
+++ keynote.5 19 Dec 2010 03:15:07 -
@@ -681,7 +681,7 @@ the interest of readability.
.%A J. Feigenbaum
.%A J. Lacy
.%T Decentralized Trust Management
-.%J IEEE Conference on Privacy and Security
+.%J IEEE Symposium on Security and Privacy
.%D 1996
.Re
.Rs
Re: Allegations regarding OpenBSD's PRNG
On Wed, 22 Dec 2010 05:08:56 -0600 Marsh Ray wrote: > Let's say I could sample the output of the RNG in every process and from > every network device in the system. As much as I wanted. How could I > tell the difference between "one prng per purpose" and "data-slicing one > prng with all consumers"? There was a thread "called how to use /dev/srandom" where theo sent this, which may be relevant? === For those who don't want to go read the code, the algorith on the very back end is roughly this: (a) collect entropy until there is a big enough buffer (b) fold it into the srandom buffer, eventually That is just like the past. But the front end is different. From the kernel side: (1) grab a srandom buffer and start a arc4 stream cipher on it (discarding the first bit, of course) (2) now the kernel starts taking data from this on every packet it sends, to modulate this, to modulate that, who knows. (3) lots of other subsystems get small chunks of random from the stream; deeply unpredictable when (4) on very interrupt, based on quality, the kernel injects something into (a) (5) re-seed the buffer as stated in (1) when needed Simultaneously, userland programs need random data: (i) libc does a sysctl to get a chunk from the rc4 buffer (ii) starts a arc4 buffer of it's own, in that program (iii) feeds data to the program, and re-seeds the buffer when needed The arc4 stream ciphers get new entropy when they need. But the really neat architecture here is that a single stream cipher is *unpredictably* having entropy taken out of it, by hundreds of consumers. In regular unix operating systems, there are only a few entropy consumers. In OpenBSD there are hundreds and hundreds. The entire system is full of random number readers, at every level. That is why this works so well.
Re: Allegations regarding OpenBSD's PRNG
On 12/21/2010 09:26 PM, Theo de Raadt wrote:
Wow. You really are not reading the same code, are you.
Haha, yeah I have been reading all over the map. My comments are
out-of-order too.
BTW, the nanotime in arc4_stir looks like it's redundant anyway since
get_random_bytes calls extract_entropy which calls add_timer_randomness.
* An unauthenticated attacker may be able to sample an almost arbitrary
amount of output from your PRNG by making new IPsec connections.
Really? Prove it.
http://tools.ietf.org/html/rfc2405
The payload field, as defined in [ESP], is broken down according to
the following diagram:
+---+---+---+---+
| |
+ Initialization Vector (IV) +
| |
+---+---+---+---+
| |
~ Encrypted Payload (variable length) ~
| |
+---+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
http://code.bsd64.org/cvsweb/openbsd/src/sys/arch/amd64/amd64/aesni.c?rev=1.17
Bring CBC oracle attack countermeasure from r1.32 of cryptosoft.c to
the hardware crypto accelerator land. This fixes aes-ni, via xcrypt,
glxsb(4), hifn(4), safe(4) and ubsec(4) drivers.
Original commit message by angelos:
Don't keep the last blocksize-bytes of ciphertext for use as the next
plaintext's IV, in CBC mode. Use arc4random() to acquire fresh IVs per
message.
with and ok deraadt, ok markus, djm
@@ -343,7 +340,7 @@ aesni_encdec(struct cryptop *crp, struct
if (crd->crd_flags & CRD_F_IV_EXPLICIT)
bcopy(crd->crd_iv, iv, ivlen);
else
- bcopy(ses->ses_iv, iv, ivlen);
+ arc4random_buf(iv, ivlen);
/* Do we need to write the IV */
if ((crd->crd_flags & CRD_F_IV_PRESENT) == 0) {
Just a hunch. Worth following up on IMHO.
As I
understand it, each now sends 128 bits or so of output as plaintext over
the wire in the IV. :-)
Four days ago, if you were using a particular set of hardware drivers,
then yes. But the software ipsec stack was fixed for this NINE YEARS
AGO.
What you just said was utterly careless.
*shrug*
* How much of nanotime() is truly unpredictable to an attacker sitting
directly on your local network cable? Maybe the bottom 10 bits, at best?
No. The upper bits are 'more known'. The lower bits are 'less known'.
Right, the unpredictable ones are near the bottom.
How did you come to your conclusion?
I wasn't drawing conclusions and tried to indicate that with the use of
key words and phrases like "may" and "I don't know...but" and
punctuation like '?'.
Except we don't do what you suggest at all.
Excellent!
* Unless you persist entropy across reboots, you are starting from a
known state at boot.
We don't save entropy over boots. You are speaking of one specific way
of solving this, and we don't do that. You can read the code in /etc/rc
and /etc/rc.shutdown.
At shutdown, we save a block of OUTPUT from the PRNG.
At boot, right after some extremely early system setup, we load that
block in as ENTROPY.
Let me be exact: We do not save 'raw entropy'.
Oh, ok.
* One reason you would want to XOR entropy into the pool is so that any
nonrandom bits don't obliterate any randomness that they land on top of
(assuming they're independent). Better still, use something like a hash
^
function (or the compression function from one).
Moments later, a hash function is indeed used. It is called MD5.
I'd been reading in the thread something about XORing vs prepending
nanotime() and wanted to pitch in an answer this question. I do see now
that the random_bytes are coming from MD5. But this was more about where
they were going:
XOR it? Why?
Please provide a citation regarding the benefit of XOR'ing feed data
before passing it into MD5 for the purpose of PRNG folding.
This paper covers the topic pretty thoroughly:
http://eprint.iacr.org/2010/264.pdf
It somehow manages to be both down-to-Earth and theoretical at the same
time (if that makes any sense). It even has a section on "Applications
to System RNGs"!
Obviously prepending vs clobbering vs XORing will each result in
differing amounts of entropy flowing into the input side. But the output
side of MD5 maxes out at 128 bits. So it depends on the input widths
involved and other things that may be happening with that same data
whether or not it makes a real difference in theory (if that makes any
Re: allow bioctl to read passphrase from stdin
On Wed, Dec 22, 2010 at 11:58:50AM +0001, Jason McIntyre wrote: > On Tue, Dec 21, 2010 at 02:22:37PM +0100, Jiri B. wrote: > > On Mon, Nov 29, 2010 at 02:22:35PM -0800, Chris Kuethe wrote: > > >Currently bioctl invokes readpassphrase(3) with RPP_REQUIRE_TTY, which > > >means that there must be a controlling tty to read the password from. > > >This diff adds an option (-s) to force bioctl to read the passphrase > > >from stdin. Without this option existing behavior is maintained. > > > > Hello, > > > > little improvement of bioctl(8), when using stdin it cannot be used > > for inital creation of the crypt volume. (there's same info for passfile.) > > > > jirib > > > > i think this is reasonable, though i'd maybe change the "It" to "This > option" (both here and -p). > > anyone else agree? > jmc Yes. I agree. Ken > > > Index: bioctl.8 > > === > > RCS file: /cvs/src/sbin/bioctl/bioctl.8,v > > retrieving revision 1.83 > > diff -u -p -r1.83 bioctl.8 > > --- bioctl.81 Dec 2010 19:40:18 - 1.83 > > +++ bioctl.821 Dec 2010 13:20:39 - > > @@ -240,6 +240,7 @@ Read the passphrase for the selected cry > > .Pa /dev/stdin > > rather than > > .Pa /dev/tty . > > +It cannot be used during the initial creation of the crypto volume. > > .El > > .Sh EXAMPLES > > The following command, executed from the command line, would configure
Re: allow bioctl to read passphrase from stdin
On Tue, Dec 21, 2010 at 02:22:37PM +0100, Jiri B. wrote: > On Mon, Nov 29, 2010 at 02:22:35PM -0800, Chris Kuethe wrote: > >Currently bioctl invokes readpassphrase(3) with RPP_REQUIRE_TTY, which > >means that there must be a controlling tty to read the password from. > >This diff adds an option (-s) to force bioctl to read the passphrase > >from stdin. Without this option existing behavior is maintained. > > Hello, > > little improvement of bioctl(8), when using stdin it cannot be used > for inital creation of the crypt volume. (there's same info for passfile.) > > jirib > i think this is reasonable, though i'd maybe change the "It" to "This option" (both here and -p). anyone else agree? jmc > Index: bioctl.8 > === > RCS file: /cvs/src/sbin/bioctl/bioctl.8,v > retrieving revision 1.83 > diff -u -p -r1.83 bioctl.8 > --- bioctl.8 1 Dec 2010 19:40:18 - 1.83 > +++ bioctl.8 21 Dec 2010 13:20:39 - > @@ -240,6 +240,7 @@ Read the passphrase for the selected cry > .Pa /dev/stdin > rather than > .Pa /dev/tty . > +It cannot be used during the initial creation of the crypto volume. > .El > .Sh EXAMPLES > The following command, executed from the command line, would configure
Re: Allegations regarding OpenBSD IPSEC
On 12/22/2010 01:46 AM, Theo de Raadt wrote: 2010/12/21 Theo de Raadt: HANG ON. Go look at the function random_seed() in /usr/src/etc/rc Then look at when it is called. so, the current state of the PRNG will be preserved during reboots. That statement is false. Good. No. You misread the code. That gives some information about system entropy, which will be "good" at all times, except for the very first boot of an installation. See : rnd.c: randomwrite() -> add_entropy_words(); That part is true. But what you said earlier is false. However, arc4_stir will still be called once after every reboot. During its first call, the value of nanotime() will be placed at the beginning of buf, which is then beeing used to init the rc4 context. What else do you think we should use? Where do we invent entropy from when the kernel has only been running for 0.01 of a second? Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, but from the outside, specially considered that machines are not rebooted so often (and when they are, it is usually for updating them), it would look like real random data. - Salva
fsck and mount handling in bsd.rd
As noted by Peter Miller, the fsck and mount procedures in bsd.rd
differ from /etc/rc. Specifically, he had issues with usb disks that
were not always present at boot. While /etc/rc would not fsck
those (since fs_passno == 0) and ignore any issues with mount -a,
the upgrade process was a bit more picky and bailed out.
This diff aims to resolve such situation by doing the following:
- Do not run fsck for fstab entries with zero or empty fs_passno
- Ask for permission to continue upgrade if one or more mounts failed
Testing and OK's wanted.
/Alexander
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.631
diff -u -p -r1.631 install.sub
--- install.sub 22 Nov 2010 14:10:42 - 1.631
+++ install.sub 22 Dec 2010 09:30:53 -
@@ -1638,7 +1638,6 @@ install_sets() {
# 2) mount non-ffs filesystems read only,
# 3) prepend '/mnt' to all mount points,
# 4) delete any trailing '/' from the mount point (e.g. root),
-# 5) leave out fs_freq and fs_passno fields.
#
# If no /etc/fstab is created, do not proceed with install/upgrade.
munge_fstab() {
@@ -1666,8 +1665,7 @@ munge_fstab() {
# Write fs entry in fstab.
# 1) prepend '/mnt' to the mount point.
# 2) remove a trailing '/' from the mount point (e.g. root).
- # 3) leave out fs_freq and fs_passno fields (i.e. $_rest).
- echo $_dev /mnt${_mp%/} $_fstype $_opt
+ echo $_dev /mnt${_mp%/} $_fstype $_opt $_rest
done /etc/fstab
@@ -1681,28 +1679,27 @@ munge_fstab() {
# Must mount filesystems manually, one at a time, so we can make
# sure the mount points exist.
mount_fs() {
- local _async=$1 _dev _mp _fstype _opt _rest _err _msg
+ local _async=$1 _dev _mp _fstype _opt _rest _msg _fail
while read _dev _mp _fstype _opt _rest; do
# If not the root filesystem, make sure the mount
# point is present.
[ "$_mp" = "/mnt" ] || mkdir -p $_mp
- # Mount the filesystem. If the mount fails, exit.
- _msg=$(mount -v -t $_fstype $_async -o $_opt $_dev $_mp)
- _err=$?
+ # Mount the filesystem. Remember any failure.
+ _msg=$(mount -v -t $_fstype $_async -o $_opt $_dev $_mp) ||
+ _fail="$_fail\n$_mp ($_dev)"
echo $_msg | sed -e 's/, ctime=[^,)]*//'
- if [ $_err != 0 ]; then
- # In addition to the error message displayed by mount
...
- cat <<__EOT
-
-FATAL ERROR: Cannot mount filesystems. Double-check your configuration
- and restart the $MODE.
+ done 0, showing individual results, but skipping $ROOTDEV. This was
+# already fsck'ed successfully.
#
# Exit if any fsck's fail (but do them all before exiting!).
check_fs() {
- local _dev _mp _fstype _rest _fail _f
+ local _dev _mp _fstype _rest _fail _f _passno
ask_yn "Force checking of non-root filesystems?" yes
[[ $resp == y ]] && _f=f
- while read _dev _mp _fstype _rest; do
+ while read _dev _mp _fstype _rest _rest _passno _rest; do
[ "$_dev" != /dev/"$ROOTDEV" ] || continue
[ -f "/sbin/fsck_$_fstype" ] || continue
# Make sure device exists before fsck'ing it.
makedev "$(getdevname "$_dev")" || continue
+ [[ $_passno > 0 ]] || continue
echo -n "fsck -${_f}p $_dev..."
if ! fsck -${_f}p $_dev >/dev/null 2>&1; then
echo "FAILED. You must fsck $_dev manually."
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 22, 2010 at 08:28:51AM +0300, Vadim Zhukov wrote:
> On 21 December 2010 G. 22:59:22 Theo de Raadt wrote:
> > Go look at the function random_seed() in /usr/src/etc/rc
>
> And it's definitely worth looking... Patch below.
Believe it or not, but this diff has been circling around developers
already a few days ago.
-Otto
>
> --
> Best wishes,
> Vadim Zhukov
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
> Index: rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.345
> diff -u -p -r1.345 rc
> --- rc8 Nov 2010 19:44:36 - 1.345
> +++ rc22 Dec 2010 05:25:37 -
> @@ -102,14 +102,12 @@ wsconsctl_conf()
> random_seed()
> {
> if [ -f /var/db/host.random -a "X$random_seed_done" = "X" ]; then
> - dd if=/var/db/host.random of=/dev/urandom bs=1024 count=64 \
> - > /dev/null 2>&1
> dd if=/var/db/host.random of=/dev/arandom bs=1024 count=64 \
> > /dev/null 2>&1
>
> # reset seed file, so that if a shutdown-less reboot occurs,
> # the next seed is not a repeat
> - dd if=/dev/urandom of=/var/db/host.random bs=1024 count=64 \
> + dd if=/dev/arandom of=/var/db/host.random bs=1024 count=64 \
> > /dev/null 2>&1
>
> random_seed_done=1
> @@ -312,7 +310,7 @@ mount -s /var >/dev/null 2>&1
>
> # if there's no /var/db/host.random, make one through /dev/urandom
> if [ ! -f /var/db/host.random ]; then
> - dd if=/dev/urandom of=/var/db/host.random bs=1024 count=64 \
> + dd if=/dev/arandom of=/var/db/host.random bs=1024 count=64 \
> >/dev/null 2>&1
> chmod 600 /var/db/host.random >/dev/null 2>&1
> else
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote: > The in libc the rc4 state is only initialized once at the first call of > arc4_stir() and then there are consecutive calls to arc4_addrandom() which > is the equivalent of rc4_crypt(). So, there is a difference in the > implementation. May this is just due to different authors. There's also a different purpose. See below. > > First question: Which one is the 'correct' implementation, as proposed in > Applied Cryptography (hint in libc -> arc4random.c)? > Second question: Does it matter if the implementation is different than the > one in Applied Cryptography? Applied Cryptography only has a sketch. Details have to be filled in. In summary, the kernel arc4 is reseeded completely with bytes from the entropy pool periodically, while the libc arc4 is seeded once with bytes form the kernel arc4 at first use after process startup and then stirred with a sequence of random bytes obtained from the kernel after every x bytes produced. I can maybe guess why it is this way, but I'd like knowledgeable person to comment on this. Note that the userland arc4 IS reseeded after an exec and stirred extra in the child on fork, probably to avoid leaking key state to new processes. -Otto
團購銷售課程
e h3e-8e!ei g(g62h7/e h3f4e$i g(e h3d;#g"http://elearn.airnet.com.tw/%E5%9C%98%E8%B3%BC%E8%AA%B2%E7%A8%8B-12-31/> | ef6h(i1o< http://edm.01-10.com/lists/?p=unsubscribe&uid=579765d5c0ff9a136cbf4f5badb25cb6 | f4f0h(-e.o< http://edm.01-10.com/lists/?p=preferences&uid=579765d5c0ff9a136cbf4f5badb25cb6 | h=e/d?!d;6g5&f e http://edm.01-10.com/lists/?p=forward&uid=579765d5c0ff9a136cbf4f5badb25cb6&mid=159
Re: pf debug states: ioctl interface and state names.
* Thomas Pfaff [2010-12-21 22:19]:
> A few things that has me confused ...
>
> 1) pf(4) says DIOCSETDEBUG has enum { PF_DEBUG_NONE, PF_DEBUG_URGENT, ...
> but these names are not in pfvar.h nor anywhere else in the source tree
> (AFAICT). What should the legal values (or names) be?
>
> 2) pf.conf(5) says "set debug" can be one of loud, misc, none, or urgent
> but if you "set debug loud" in pf.conf and load it the pfctl -sa output
> will say "Debug: debug", or if you "set debug misc" it will say "Debug:
> notice". It does not say what you set in pf.conf.
>
> 3) pfctl(8) -x option lets you set one of emerg, alert, crit, err,
> warning, notice, info, or debug. These will show up by their correct
> name in pfctl -sa output. They're also valid names in pf.conf so
> should they not also be mentioned in pf.conf(5)?
yes. ryan cleaned that up big time to use syslog-like levels (i. e.
your case 3). apparently we missed a few cases of the old ones (misc,
loud etc).
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
