Re: new OpenSSL flaws
On Sat, 7 Jun 2014 14:19:33 +0400 Solar Designer so...@openwall.com wrote: On Sat, Jun 07, 2014 at 09:13:36AM +0200, Francois Ambrosini wrote: On Sat, 7 Jun 2014 07:04:47 +0400 Solar Designer so...@openwall.com wrote: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects. You and others may want to know that ??? since yesterday ??? the OpenSSL wiki says otherwise. Quoting: If you would like advanced notice of vulnerabilities before they are released to the general public, then please join [http://oss-security.openwall.org/wiki/mailing-lists/distros Operating system distribution security contact lists] at OpenWall's OSS Security http://wiki.openssl.org/index.php?title=Security_Advisoriesdiff=1700oldid=1697 Thanks for letting me know. I wasn't aware of this. I don't know whether this wiki edit is authoritative for the OpenSSL project, but if it is it means that there's greater assurance those on distros list will continue to receive advance notification, and indeed it's simpler for the OpenSSL project to be able to notify more distro vendors at once. I don't see it as contradictory to what I wrote (quoted above): it doesn't say that those who haven't joined will definitely not be notified. I guess OpenSSL will maintain an additional list of who to notify, besides the distros list. As I said before, I can't speak for the OpenSSL project, though - so these are just guesses. My personal opinion is that if OpenBSD doesn't join the distros list, yet wants LibreSSL to be notified of OpenSSL security issues, OpenSSL should be notifying LibreSSL directly. I think it'd be helpful if LibreSSL nominates specific contact persons for that, along with PGP keys to use, and informs the OpenSSL project of that. (Use of PGP was mandatory in the recent advance notification offered to distros list.) Once that has been done, you'd have (more) reason to complain if you're not notified next time (but I hope you will be). Alexander I am a mere user who happened to spot an inconsistency and wanted to inform all parties. I will not comment on your guesses and opinions with information I do not have. I'll just state that I find your interpretation of the quote from the OpenSSL wiki rather optimistic, and give you the additional hint that a public statement from Mark Cox on Google+ goes against it (check the timeline post). I humbly think it was (and is) not the right time for guesses and I must confess my surprise at your response. I would have thought that, with the new responsibility given to the distro list, you would want to check with the OpenSSL people first.
Re: new OpenSSL flaws
On Sat, 7 Jun 2014 07:04:47 +0400 Solar Designer so...@openwall.com wrote: To clarify and for the record: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects. You and others may want to know that – since yesterday – the OpenSSL wiki says otherwise. Quoting: If you would like advanced notice of vulnerabilities before they are released to the general public, then please join [http://oss-security.openwall.org/wiki/mailing-lists/distros Operating system distribution security contact lists] at OpenWall's OSS Security http://wiki.openssl.org/index.php?title=Security_Advisoriesdiff=1700oldid=1697
Re: Watchdog timeout with MSI and Realtek 8101E on Dell Inspiron 3521 (amd64)
On Fri, 30 Aug 2013 11:48:12 -0700 patrick keshishian pkesh...@gmail.com wrote: On 8/30/13, Alexey E. Suslikov alexey.susli...@gmail.com wrote: Chris Cappuccio chris at nmedia.net writes: Mark Kettenis just posted a patch to disable (and later re-enable) interrupts at some point in the driver. It's on the openbsd-tech list, dated Aug 21. Try and and see if it fixes your issue, as it appears nobody else has done so yet. could you drop marc or gmane link for that? http://marc.info/?l=openbsd-techm=137711518130141w=2 http://article.gmane.org/gmane.os.openbsd.tech/33395 I just applied this patch to my now-less-used-netbook, and the re0 timeouts I saw earlier this week during cvs updating, I no longer see. But my uptime is about 34min right now. so status may change :) --patrick This re0 at pci1 dev 0 function 0 Realtek 8101E rev 0x05: RTL8105E (0x4080), msi, address e0:db:55:d1:d7:f4 rlphy0 at re0 phy 7: RTL8201E 10/100 PHY, rev. 2 now works with the aforementioned patch. I have been running it and testing re0 for the last eight hours, and saw no watchdog timeout. Thanks !
Watchdog timeout with MSI and Realtek 8101E on Dell Inspiron 3521 (amd64)
After upgrading from the July 25 to the August 24 snapshot (amd64), I started getting re0: watchdog timeout messages from the system when sending files via re0. This seems to be caused by MSI being enabled in sys/dev/pci/if_re_pci.c beginning of August. Upgrading the BIOS to the latest version (A09) did not solve the issue. As a quick fix I am currently running a GENERIC.MP kernel (CVS from two days ago) with the following patch, disabling MSI for the device. The re0 interface behaves properly again. --- sys/dev/pci/if_re_pci.c.origThu Aug 29 21:46:24 2013 +++ sys/dev/pci/if_re_pci.c Thu Aug 29 21:59:21 2013 @@ -135,10 +135,7 @@ re_pci_attach(struct device *parent, struct device *se pci_intr_handle_t ih; const char *intrstr = NULL; - /* Only enable MSI on RT810xE for now. */ - if (PCI_VENDOR(pa-pa_id) != PCI_VENDOR_REALTEK || - PCI_PRODUCT(pa-pa_id) != PCI_PRODUCT_REALTEK_RT8101E) - pa-pa_flags = ~PCI_FLAGS_MSI_ENABLED; + pa-pa_flags = ~PCI_FLAGS_MSI_ENABLED; pci_set_powerstate(pa-pa_pc, pa-pa_tag, PCI_PMCSR_STATE_D0); I only have one computer of this model, and no other with the Realtek 8101E, so I cannot confirm that my hardware is not partly broken. Has anyone experienced this problem with this computer model / chipset? Below some more information: # details about the timeouts # dmesg for July 25 snapshot # dmesg for August 24 snapshot # pcidump # details about the timeouts The timeouts messages coincide with a period of unavailability of the network - roughly 5 to 7 seconds - and occur when data is sent to the network (e.g. uploading files to a remote host). For the same quantity of data being sent, tests indicate that the number of watchdog timeouts increases with the transfer speed. Some figures: 3165 MB file @ 8MB/s : avg. 14 watchdog timeouts 3165 MB file @ 1MB/s : avg. 3 watchdog timeouts 3165 MB file @ 128KB/s : no timeout (yet) So far I have not seen such timeout occurring when receiving files, regardless of the quantity of data or the transfer speed. # dmesg for July 25 snapshot OpenBSD 5.4 (GENERIC.MP) #37: Thu Jul 25 18:51:42 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4147896320 (3955MB) avail mem = 4029747200 (3843MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6c00 (70 entries) bios0: vendor Dell Inc. version A04 date 11/21/2012 bios0: Dell Inc. Inspiron 3521 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC UEFI ASF! HPET APIC MCFG SLIC SSDT BOOT ASPT DBGP FPDT MSDM SSDT SSDT acpi0: wakeup devices P0P1(S0) EHC1(S0) XHC_(S0) RP01(S3) RP02(S0) PEG0(S4) PEGP(S4) PEG1(S4) PEG2(S4) PEG3(S4) LID0(S3) 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) i3-3217U CPU @ 1.80GHz, 1696.41 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz, 1696.15 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz, 1696.15 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz, 1696.15 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0:
