Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior to hotplugopen() [Was: hotplugd(8) ignoring devices attached before boot]
On Mon, Dec 13, 2010 at 09:27:51PM +0100, Mark Kettenis wrote: From: Ted Unangst ted.unan...@gmail.com On Mon, Dec 13, 2010 at 7:41 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: (...) I don't really agree with Tedu that the changed behaviour is an improvement. Say I have configured hotplugd(8) such that it automatically mounts things when I plug in my camera. Now I reboot my machine, without unplugging the camera. Previously hotplugd(8) would remount things upon boot. Now suddenly it doesn't and I have to unplug and replug the camera. I think the solution to that is to make adding the duid to fstab work. At boot, if the duid exists, it's mounted. If it doesn't, it doesn't mount but also doesn't error out. This may already work even, I haven't tried it. Sorry, but a FAT-formatted USB device (which most cameras effectively are) will never have a duid. FAT has volume labels; I'm not saying that too much hackery would be desirable, but it's not impossible to abuse these as a kind-of-duid. Joachim
Re: bugfixes for dc(4)
Date: Mon, 13 Dec 2010 23:24:52 -0500 (EST)
From: logana...@devio.us (Loganaden Velvindron)
Hi, I separated the mclgeti part from the bugfixes for PNIC. Give it a try.
What does this actually fix?
Index: src/sys/dev/ic/dc.c
===
RCS file: /cvs/src/sys/dev/ic/dc.c,v
retrieving revision 1.121
diff -u -p -r1.121 dc.c
--- src/sys/dev/ic/dc.c 7 Sep 2010 16:21:42 - 1.121
+++ src/sys/dev/ic/dc.c 14 Dec 2010 04:18:50 -
@@ -1224,7 +1224,7 @@ dc_setcfg(struct dc_softc *sc, int media
}
if (i == DC_TIMEOUT) {
- if (!(isr DC_ISR_TX_IDLE) !DC_IS_ASIX(sc))
+ if (!(isr DC_ISR_TX_IDLE) !DC_IS_ASIX(sc)
!DC_IS_PNIC(sc))
printf(%s: failed to force tx to idle state\n,
sc-sc_dev.dv_xname);
if (!((isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED ||
@@ -1792,9 +1792,11 @@ hasmac:
ifmedia_add(sc-sc_mii.mii_media, IFM_ETHER|IFM_NONE, 0, NULL);
ifmedia_set(sc-sc_mii.mii_media, IFM_ETHER|IFM_NONE);
printf(%s: MII without any PHY!\n, sc-sc_dev.dv_xname);
- } else if (sc-dc_type == DC_TYPE_21145) {
+ } else if (sc-dc_type == DC_TYPE_21145)
ifmedia_set(sc-sc_mii.mii_media, IFM_ETHER|IFM_10_T);
- } else
+ else if (sc-dc_type == DC_TYPE_PNIC)
+ ifmedia_set(sc-sc_mii.mii_media, IFM_ETHER|IFM_10_T);
+ else
ifmedia_set(sc-sc_mii.mii_media, IFM_ETHER|IFM_AUTO);
if (DC_IS_DAVICOM(sc) sc-dc_revision = DC_REVISION_DM9102A)
Re: bugfixes for dc(4)
Hi, It fixes the idle timeout messages (which is not an issue on PNIC) and sets the speed to 10BaseTX, since autonegociation is broken on PNIC. //Logan C-x-C-c
Get a Dental Cleaning and Give Children Toys
To: Olde Fort Inn tech@openbsd.org b Christmas Toy Driveb For $ 49.00, help 10 children receive toys for Christmas, and you will get X-Rays TWO Free Dental Exams as well as TWO Teeth Cleanings (One now, and one in six month) (Reg. Price $390) Expires: Dec. 31st Important Note: Even IF you are insured and your insurance would pay for these exams, x-rays and cleanings, you MUST remember that BECAUSE your Insurance now will NOT get billed for $ 390, you will have a $ 390 credit for additional dental work. Because you are not using your insurance for these x-rays, exams and cleanings, you can use the $ 390 credit later for fillings, gum disease treatment, etc.!! Yes, even IF you are insured, this will give you a $ 390 advantage AND help 10 children receive toys for Christmas!J J J To learn more, go to: www.dentistinyonkersny.com/index.php/category/community/ I, Dr. William Limongelli will give you an X-ray and two free dental cleanings and exams for donating $ 49.00 to help 10 children receive toys for Christmas. Letbs face it. We are fortunate enough to have money to buy not only necessities but luxury items like toys for our children. Some less fortunate children and orphans do not have the luxury of owning even one toy to play with. Why not put a smile on a childbs face with the gift of their first toy? We canbt solve all the problems in the world b I know b but what about starting somewhere? (For more details on how we will be collecting toys, Click Here.) This is why I started a b Christmas Toy Driveb campaign This program greatly rewards the donator. P.S.: You can give the $ 49.00 special gift (x-rays, dental cleanings and exams) to anyone you like, but no more than five gifts per person will be accepted. Expires: Dec. 31st Also, churches and non-profit organizations can use this as a fundraiser for their own organization. Furthermore, the first cleaning might be delayed by a few weeks due to a large volume of responses. Thank you for your patience. Wishing you a happy and prosperous holiday, W. A. Limongelli, D.D.S. 12 Warburton Ave. Yonkers, NY 10701 (914)969-2727 www.dentistinyonkersny.com/index.php/category/community/ You recieve this email because you have subscribed for our newsletters on via IP If you do not want to receive more emails, please reply to this email with the Subject header changed to REMOVE
Re: *hci dying flag
On Tue, Dec 14, 2010 at 01:52:01AM +, Jacob Meuser wrote: this make *hci use the dying flag in struct usbd_bus instead of one in their own softc. struct usbd_bus is required to be the first member of *hci_softc. the bus' dying flag is checked in usbd_is_dying(), which is used to let the usb stack know if the hardware is a usable. ok? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org Seems pointless to have two dying flags. ok k...@. Ken
Re: bugfixes for dc(4)
On Tue, 14 Dec 2010 04:16:46 -0500 (EST) logana...@devio.us (Loganaden Velvindron) wrote: Hi, It fixes the idle timeout messages (which is not an issue on PNIC) and sets the speed to 10BaseTX, since autonegociation is broken on PNIC. //Logan C-x-C-c I had a dc with timeout messages during boot and trouble getting it to then work. I think?? I had to fix it with a hostname.dc0 config and it worked for over a year, but after a reinstall, I had lost track of what I had done previously to fix it and so just swapped the nic. dc seems to get some praise in the man page too.
usb: don't wait if dying
ok?
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.75
diff -u -p usb_subr.c
--- usb_subr.c 6 Dec 2010 04:30:57 - 1.75
+++ usb_subr.c 14 Dec 2010 16:16:32 -
@@ -351,6 +351,9 @@ usb_delay_ms(usbd_bus_handle bus, u_int ms)
void
usbd_delay_ms(usbd_device_handle dev, u_int ms)
{
+ if (usbd_is_dying(dev))
+ return;
+
usb_delay_ms(dev-bus, ms);
}
MCLGETI for tl(4)
Hi, with further encouragement, I decided to give tl(4) a try.
It's a very interesting ethernet chip, and even under heavy tcpbench
the mbuf usage is at most 6. As usual, feedback and comments are welcomed.
//Logan
C-x-C-c
Index: src/sys/dev/pci/if_tl.c
===
RCS file: /cvs/src/sys/dev/pci/if_tl.c,v
retrieving revision 1.50
diff -u -p -r1.50 if_tl.c
--- src/sys/dev/pci/if_tl.c 19 May 2010 15:27:35 - 1.50
+++ src/sys/dev/pci/if_tl.c 14 Dec 2010 19:15:28 -
@@ -252,8 +252,8 @@ int tl_intvec_rxeof(void *, u_int32_t);
int tl_intvec_adchk(void *, u_int32_t);
int tl_intvec_netsts(void *, u_int32_t);
-int tl_newbuf(struct tl_softc *,
- struct tl_chain_onefrag *);
+int tl_newbuf(struct tl_softc *, struct tl_chain_onefrag *);
+void tl_fill_rx_ring(struct tl_softc *);
void tl_stats_update(void *);
int tl_encap(struct tl_softc *, struct tl_chain *,
struct mbuf *);
@@ -1034,8 +1034,6 @@ int tl_list_rx_init(sc)
for (i = 0; i TL_RX_LIST_CNT; i++) {
cd-tl_rx_chain[i].tl_ptr =
(struct tl_list_onefrag *)ld-tl_rx_list[i];
- if (tl_newbuf(sc, cd-tl_rx_chain[i]) == ENOBUFS)
- return(ENOBUFS);
if (i == (TL_RX_LIST_CNT - 1)) {
cd-tl_rx_chain[i].tl_next = NULL;
ld-tl_rx_list[i].tlist_fptr = 0;
@@ -1047,34 +1045,45 @@ int tl_list_rx_init(sc)
}
cd-tl_rx_head = cd-tl_rx_chain[0];
+ cd-tl_rx_cons = cd-tl_rx_chain[0];
cd-tl_rx_tail = cd-tl_rx_chain[TL_RX_LIST_CNT - 1];
-
+ cd-tl_rx_cnt = 0;
+ tl_fill_rx_ring(sc);
return(0);
}
+void tl_fill_rx_ring(sc)
+ struct tl_softc *sc;
+{
+ struct tl_list_data *ld;
+ struct tl_chain_data*cd;
+
+ cd = sc-tl_cdata;
+ ld = sc-tl_ldata;
+
+ while (cd-tl_rx_cnt TL_RX_LIST_CNT) {
+ if(tl_newbuf(sc, cd-tl_rx_head) == ENOBUFS)
+ break;
+ cd-tl_rx_head = cd-tl_rx_head-tl_next;
+ cd-tl_rx_cnt++;
+ }
+}
+
int tl_newbuf(sc, c)
struct tl_softc *sc;
struct tl_chain_onefrag *c;
{
struct mbuf *m_new = NULL;
- MGETHDR(m_new, M_DONTWAIT, MT_DATA);
- if (m_new == NULL) {
+ m_new = MCLGETI(NULL, M_DONTWAIT, sc-arpcom.ac_if, MCLBYTES);
+ if (!m_new)
return(ENOBUFS);
- }
-
- MCLGET(m_new, M_DONTWAIT);
- if (!(m_new-m_flags M_EXT)) {
- m_freem(m_new);
- return(ENOBUFS);
- }
#ifdef __alpha__
m_new-m_data += 2;
#endif
c-tl_mbuf = m_new;
- c-tl_next = NULL;
c-tl_ptr-tlist_frsize = MCLBYTES;
c-tl_ptr-tlist_fptr = 0;
c-tl_ptr-tl_frag.tlist_dadr = VTOPHYS(mtod(m_new, caddr_t));
@@ -1120,23 +1129,17 @@ int tl_intvec_rxeof(xsc, type)
sc = xsc;
ifp = sc-arpcom.ac_if;
- while(sc-tl_cdata.tl_rx_head != NULL) {
- cur_rx = sc-tl_cdata.tl_rx_head;
+ while(sc-tl_cdata.tl_rx_cnt 0) {
+ cur_rx = sc-tl_cdata.tl_rx_cons;
if (!(cur_rx-tl_ptr-tlist_cstat TL_CSTAT_FRAMECMP))
break;
r++;
- sc-tl_cdata.tl_rx_head = cur_rx-tl_next;
+ sc-tl_cdata.tl_rx_cons = cur_rx-tl_next;
m = cur_rx-tl_mbuf;
+ cur_rx-tl_mbuf = NULL;
+ sc-tl_cdata.tl_rx_cnt--;
total_len = cur_rx-tl_ptr-tlist_frsize;
- if (tl_newbuf(sc, cur_rx) == ENOBUFS) {
- ifp-if_ierrors++;
- cur_rx-tl_ptr-tlist_frsize = MCLBYTES;
- cur_rx-tl_ptr-tlist_cstat = TL_CSTAT_READY;
- cur_rx-tl_ptr-tl_frag.tlist_dcnt = MCLBYTES;
- continue;
- }
-
sc-tl_cdata.tl_rx_tail-tl_ptr-tlist_fptr =
VTOPHYS(cur_rx-tl_ptr);
sc-tl_cdata.tl_rx_tail-tl_next = cur_rx;
@@ -1175,7 +1178,7 @@ int tl_intvec_rxeof(xsc, type)
/* pass it on. */
ether_input_mbuf(ifp, m);
}
-
+ tl_fill_rx_ring(sc);
return(r);
}
@@ -1201,9 +1204,7 @@ int tl_intvec_rxeoc(xsc, type)
r = tl_intvec_rxeof(xsc, type);
CMD_PUT(sc, TL_CMD_ACK | r | (type ~(0x0010)));
r = 1;
- cd-tl_rx_head = cd-tl_rx_chain[0];
- cd-tl_rx_tail = cd-tl_rx_chain[TL_RX_LIST_CNT - 1];
- CSR_WRITE_4(sc, TL_CH_PARM, VTOPHYS(sc-tl_cdata.tl_rx_head-tl_ptr));
+ CSR_WRITE_4(sc, TL_CH_PARM, VTOPHYS(sc-tl_cdata.tl_rx_cons-tl_ptr));
r |= (TL_CMD_GO|TL_CMD_RT);
return(r);
}
@@ -2130,6 +2131,7 @@ tl_attach(parent, self, aux)
Fix for broken autonegociation for tl(4)
Hi, autonegociation is broken on tl(4). For some reason 10BaseTX doesn't work. The lowest value that does work is 100BaseTX. As usual, feedback and comments are welcomed. //Logan C-x-C-c Index: src/sys/dev/pci/if_tl.c === RCS file: /cvs/src/sys/dev/pci/if_tl.c,v retrieving revision 1.50 diff -u -p -r1.50 if_tl.c --- src/sys/dev/pci/if_tl.c 19 May 2010 15:27:35 - 1.50 +++ src/sys/dev/pci/if_tl.c 14 Dec 2010 19:43:38 - @@ -2167,7 +2167,7 @@ tl_attach(parent, self, aux) ifm-ifm_media = ifm-ifm_cur-ifm_media; tl_ifmedia_upd(ifp); } else - ifmedia_set(sc-sc_mii.mii_media, IFM_ETHER|IFM_AUTO); + ifmedia_set(sc-sc_mii.mii_media, IFM_ETHER|IFM_100_TX); /* * Attach us everywhere.
Re: Fix for broken autonegociation for tl(4)
autonegociation is broken on tl(4). For some reason 10BaseTX doesn't work. The lowest value that does work is 100BaseTX. As usual, feedback and comments are welcomed. How can this diff work for tl devices which are connected to a 10Mbit/s only PHY? Miod
Re: Fix for broken autonegociation for tl(4)
It can't negociate for 10Mbit/s. This only sets the default value to 100Mbit/s. It can adjusted through ifconfig and /etc/hostname.tl0 at startup. My adapter is OC2-2336. Do you have another tl(4) device ? Perhaps it might be an issue specific to mine. //Logan C-x-C-c
Re: Fix for broken autonegociation for tl(4)
It can't negociate for 10Mbit/s. This only sets the default value to 100Mbit/s. It can adjusted through ifconfig and /etc/hostname.tl0 at startup. My adapter is OC2-2336. Do you have another tl(4) device ? Perhaps it might be an issue specific to mine. I don't have a tl(4) device. It just happens that some of them are fitted with 10Mbit/s-only PHY. And your change would likely break them. Miod
Re: Fix for broken autonegociation for tl(4)
In this case, perhaps a better solution would be to mention that autonegociation is broken, and therefore speeds need to be adjusted manually in the man page. Does that look better to you ? //Logan C-x-C-c
Re: Fix for broken autonegociation for tl(4)
In this case, perhaps a better solution would be to mention that autonegociation is broken, and therefore speeds need to be adjusted manually in the man page. Does that look better to you ? It would be better to know first if other tl(4) users are experiencing the same problem. Hard to know since this card has almost completely faded away from dmesg reports. Also we have no idea about your particular PHY setup. There are several flavours: tl0 at pci0 dev 16 function 0 Compaq Embedded Netelligent 10/100 TX rev 0x10: irq 11 address whatever lxtphy0 at tl0 phy 1: LXT970 10/100 media interface, rev. 0 ukphy0 at tl0 phy 31: Generic IEEE 802.3u media interface ukphy0: OUI 0x100014, model 0x0001, rev. 6 tl0 at pci0 dev 12 function 0 Compaq Netelligent 10 T rev 0x10: irq 10 address whatever ukphy0 at tl0 phy 31: Generic IEEE 802.3u media interface ukphy0: OUI 0x100014, model 0x0001, rev. 4 (this one is a 10Mbit/s only model) tl0 at pci1 dev 11 function 0 Compaq ProLiant Netelligent 10/100 TX rev 0x10: irq 4 address whatever nsphy0 at tl0 phy 1: DP83840 10/100 media interface, rev. 1 ukphy0 at tl0 phy 31: Generic IEEE 802.3u media interface ukphy0: OUI 0x100014, model 0x0001, rev. 5 The problem you are encountering could actually be a bug in one of the phy drivers, or (more likely) in the interface between tl(4) and the mii(4) layer. Miod
Re: usb: don't wait if dying
On Tue, Dec 14, 2010 at 04:41:43PM +, Jacob Meuser wrote:
ok?
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.75
diff -u -p usb_subr.c
--- usb_subr.c6 Dec 2010 04:30:57 - 1.75
+++ usb_subr.c14 Dec 2010 16:16:32 -
@@ -351,6 +351,9 @@ usb_delay_ms(usbd_bus_handle bus, u_int ms)
void
usbd_delay_ms(usbd_device_handle dev, u_int ms)
{
+ if (usbd_is_dying(dev))
+ return;
+
usb_delay_ms(dev-bus, ms);
}
ok krw@
Ken
Re: usb: don't wait if dying
This makes a lot of sense.
Penned by Jacob Meuser on 20101214 10:41.43, we have:
| ok?
|
| --
| jake...@sdf.lonestar.org
| SDF Public Access UNIX System - http://sdf.lonestar.org
|
| Index: usb_subr.c
| ===
| RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
| retrieving revision 1.75
| diff -u -p usb_subr.c
| --- usb_subr.c6 Dec 2010 04:30:57 - 1.75
| +++ usb_subr.c14 Dec 2010 16:16:32 -
| @@ -351,6 +351,9 @@ usb_delay_ms(usbd_bus_handle bus, u_int ms)
| void
| usbd_delay_ms(usbd_device_handle dev, u_int ms)
| {
| + if (usbd_is_dying(dev))
| + return;
| +
| usb_delay_ms(dev-bus, ms);
| }
--
Todd Fries .. t...@fries.net
_
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net
| ..in support of free software solutions. \ sip:4052279...@ekiga.net
\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
Allegations regarding OpenBSD IPSEC
I have received a mail regarding the early development of the OpenBSD IPSEC stack. It is alleged that some ex-developers (and the company they worked for) accepted US government money to put backdoors into our network stack, in particular the IPSEC stack. Around 2000-2001. Since we had the first IPSEC stack available for free, large parts of the code are now found in many other projects/products. Over 10 years, the IPSEC code has gone through many changes and fixes, so it is unclear what the true impact of these allegations are. The mail came in privately from a person I have not talked to for nearly 10 years. I refuse to become part of such a conspiracy, and will not be talking to Gregory Perry about this. Therefore I am making it public so that (a) those who use the code can audit it for these problems, (b) those that are angry at the story can take other actions, (c) if it is not true, those who are being accused can defend themselves. Of course I don't like it when my private mail is forwarded. However the little ethic of a private mail being forwarded is much smaller than the big ethic of government paying companies to pay open source developers (a member of a community-of-friends) to insert privacy-invading holes in software. From: Gregory Perry gregory.pe...@govirtual.tv To: dera...@openbsd.org dera...@openbsd.org Subject: OpenBSD Crypto Framework Thread-Topic: OpenBSD Crypto Framework Thread-Index: AcuZjuF6cT4gcSmqQv+Fo3/+2m80eg== Date: Sat, 11 Dec 2010 23:55:25 + Message-ID: 8d3222f9eb68474da381831a120b1023019ac...@mbx021-e2-nj-5.exch021.domain.local Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Status: RO Hello Theo, Long time no talk. If you will recall, a while back I was the CTO at NETSEC and arranged funding and donations for the OpenBSD Crypto Framework. At that same time I also did some consulting for the FBI, for their GSA Technical Support Center, which was a cryptologic reverse engineering project aimed at backdooring and implementing key escrow mechanisms for smart card and other hardware-based computing technologies. My NDA with the FBI has recently expired, and I wanted to make you aware of the fact that the FBI implemented a number of backdoors and side channel key leaking mechanisms into the OCF, for the express purpose of monitoring the site to site VPN encryption system implemented by EOUSA, the parent organization to the FBI. Jason Wright and several other developers were responsible for those backdoors, and you would be well advised to review any and all code commits by Wright as well as the other developers he worked with originating from NETSEC. This is also probably the reason why you lost your DARPA funding, they more than likely caught wind of the fact that those backdoors were present and didn't want to create any derivative products based upon the same. This is also why several inside FBI folks have been recently advocating the use of OpenBSD for VPN and firewalling implementations in virtualized environments, for example Scott Lowe is a well respected author in virtualization circles who also happens top be on the FBI payroll, and who has also recently published several tutorials for the use of OpenBSD VMs in enterprise VMware vSphere deployments. Merry Christmas... Gregory Perry Chief Executive Officer GoVirtual Education VMware Training Products Services 540-645-6955 x111 (local) 866-354-7369 x111 (toll free) 540-931-9099 (mobile) 877-648-0555 (fax) http://www.facebook.com/GregoryVPerry http://www.facebook.com/GoVirtual
Re: Allegations regarding OpenBSD IPSEC
I wonder a lot about the motives of the original sender sending that message. Is it simply a way to spread FUD and discredit openbsd? Is it a personal gripe with the accused? Is it an attempt to manipulate what is used in the market? Is it outright lies Is it outright truth and genuine altruism? While I suspect we'll never know completely for sure, it makes an interesting point. Is it genuine? partially genuine? how much truth is in there? if it's true how much of this mattered and has it since been fixed? (as that code when through a lot of fixes since that time) Of course in these days of binary only blob drivers, I don't think the government need resort to this sort of tactic these days. Those nice binary-only drivers everyone loves running for video and wireless will ensure that there are nice places in your favorite Open Source project that can be coopted quietly by government organizations and have access to your entire kernel. No need to be subtle.
Re: Allegations regarding OpenBSD IPSEC
On Tue, 14 Dec 2010, Bob Beck wrote: I wonder a lot about the motives of the original sender sending that message. Ignoring motive, and looking at opportunity: We have never allowed US citizens or foreign citizens working in the US to hack on crypto code (Niels Provos used to make trips to Canada to develop OpenSSH for this reason), so direct interference in the crypto code is unlikely. It would also be fairly obvious - the crypto code works as pretty basic block transform API, and there aren't many places where one could smuggle key bytes out. We always used arcrandom() for generating random numbers when we needed them, so deliberate biases of key material, etc would be quite visible. So a subverted developer would probably need to work on the network stack. I can think of a few obvious ways that they could leak plaintext or key material: 1. Ensure that key bytes somehow wind up as padding. This would be pretty obvious, since current IPsec standards require deterministic padding. Our legacy random padding uses arc4random_buf(). 2. Arrange for particular structures to be adjacent to interesting data, like raw or scheduled keys and accidentally copy too much. 3. Arrange for mbufs that previously contained plaintext or other interesting material to be accidentally reused. This seems to me the most likely avenue, and there have been bugs of this type found before. It's a pretty common mistake, so it is attractive for deniability, but it seems difficult to make this a reliable exploit. If I was doing it, I'd try to make the reuse happen on something like ICMP errors, so I could send error-inducing probe packets at times I thought were interesting :) 4. Introduce timing side-channel leaks. These weren't widely talked about back in 2000 (at least not in the public domain), but have been well researched in the years since then. We have already introduced countermeasures against the obvious memcmp() leaks using timingsafe_bcmp(), but more subtle leaks could still remain. If anyone is concerned that a backdoor may exist and is keen to audit the network stack, then these are the places I'd recommend starting from. -d
Re: Fix for broken autonegociation for tl(4)
Hi Miod, Here's the relevant part of the dmesg: l0 at pci0 dev 16 function 0 Olicom OC2326 rev 0x01: irq 10 address 00:00:24: 27:ca:61 ukphy0 at tl0 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 0x00, model 0x ukphy1 at tl0 phy 31: Generic IEEE 802.3u media interface, rev. 5: OUI 0x100014, model 0x0001 //Logan C-x-C-c
Re: Allegations regarding OpenBSD IPSEC
If this type of thing really did happen and this actually is going on something as simple as systrace or dtrace would have found it correct? Surely folks have monitored and audited the actual function and traffic that goes across the wire... conversely amd has a debugger that'll get you access to more goodies than you could imagine and just recently I discovered a similar debugger on the wifi chip on my phone. Guess its better it doesn't work anyhow ;) Brandon On Dec 14, 2010 8:33 PM, Damien Miller d...@mindrot.org wrote: On Tue, 14 Dec 2010, Bob Beck wrote: I wonder a lot about the motives of the original sender sending that message. Ignoring motive, and looking at opportunity: We have never allowed US citizens or foreign citizens working in the US to hack on crypto code (Niels Provos used to make trips to Canada to develop OpenSSH for this reason), so direct interference in the crypto code is unlikely. It would also be fairly obvious - the crypto code works as pretty basic block transform API, and there aren't many places where one could smuggle key bytes out. We always used arcrandom() for generating random numbers when we needed them, so deliberate biases of key material, etc would be quite visible. So a subverted developer would probably need to work on the network stack. I can think of a few obvious ways that they could leak plaintext or key material: 1. Ensure that key bytes somehow wind up as padding. This would be pretty obvious, since current IPsec standards require deterministic padding. Our legacy random padding uses arc4random_buf(). 2. Arrange for particular structures to be adjacent to interesting data, like raw or scheduled keys and accidentally copy too much. 3. Arrange for mbufs that previously contained plaintext or other interesting material to be accidentally reused. This seems to me the most likely avenue, and there have been bugs of this type found before. It's a pretty common mistake, so it is attractive for deniability, but it seems difficult to make this a reliable exploit. If I was doing it, I'd try to make the reuse happen on something like ICMP errors, so I could send error-inducing probe packets at times I thought were interesting :) 4. Introduce timing side-channel leaks. These weren't widely talked about back in 2000 (at least not in the public domain), but have been well researched in the years since then. We have already introduced countermeasures against the obvious memcmp() leaks using timingsafe_bcmp(), but more subtle leaks could still remain. If anyone is concerned that a backdoor may exist and is keen to audit the network stack, then these are the places I'd recommend starting from. -d
Llevate tu notebook de vacaciones !
PcDiscount - Diciembre (*)Bases y Condiciones. Oferta valida unicamente para nuestros clientes compradores de equipos Notebooks y Desktop durante el periodo del 01/11 al 31/12. Servicio brindado en forma gratuita hasta el 31 de Diciembre del 2010 con una duracion de 20 minutos por cada sesion de asistencia remota en los dias y horarios convenidos de lunes a vienes de 10Hs a 18Hs. img src=file:///C|/Documents and Settings/user/Escritorio/distribuidores/TECHTURN.COM_files/open.htm width=1 height=1
small drm uvm diff
there is no reason for drm_bufs to be poking inside the vmspace on its
own, this is what the uvm_map_hint function is for.
Index: drm_bufs.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_bufs.c,v
retrieving revision 1.46
diff -u -r1.46 drm_bufs.c
--- drm_bufs.c 15 Dec 2010 04:59:52 - 1.46
+++ drm_bufs.c 15 Dec 2010 05:04:30 -
@@ -922,7 +922,6 @@
{
struct drm_device_dma *dma = dev-dma;
struct drm_buf_map *request = data;
- struct vmspace *vms;
struct vnode*vn;
vaddr_t address, vaddr;
voff_t foff;
@@ -933,8 +932,6 @@
if (!vfinddev(file_priv-kdev, VCHR, vn))
return EINVAL;
- vms = curproc-p_vmspace;
-
rw_enter_write(dma-dma_lock);
dev-dma-buf_use++;/* Can't allocate more after this call */
rw_exit_write(dma-dma_lock);
@@ -960,8 +957,8 @@
foff = 0;
}
- vaddr = round_page((vaddr_t)vms-vm_daddr + BRKSIZ);
- retcode = uvm_mmap(vms-vm_map, vaddr, size,
+ vaddr = uvm_map_hint(curproc, VM_PROT_READ | VM_PROT_WRITE);
+ retcode = uvm_mmap(curproc-p_vmspace-vm_map, vaddr, size,
UVM_PROT_READ | UVM_PROT_WRITE, UVM_PROT_ALL, MAP_SHARED,
(caddr_t)vn, foff, curproc-p_rlimit[RLIMIT_MEMLOCK].rlim_cur,
curproc);
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote: If this type of thing really did happen and this actually is going on something as simple as systrace or dtrace would have found it correct? Surely folks have monitored and audited the actual function and traffic that goes across the wire... conversely amd has a debugger that'll get you access to more goodies than you could imagine and just recently I discovered a similar debugger on the wifi chip on my phone. Guess its better it doesn't work anyhow ;) It's generally impossible to see from a datastream if it leaks key data. It can be pretty damn hard to verify code to show it does not leak key data -Otto Brandon On Dec 14, 2010 8:33 PM, Damien Miller d...@mindrot.org wrote: On Tue, 14 Dec 2010, Bob Beck wrote: I wonder a lot about the motives of the original sender sending that message. Ignoring motive, and looking at opportunity: We have never allowed US citizens or foreign citizens working in the US to hack on crypto code (Niels Provos used to make trips to Canada to develop OpenSSH for this reason), so direct interference in the crypto code is unlikely. It would also be fairly obvious - the crypto code works as pretty basic block transform API, and there aren't many places where one could smuggle key bytes out. We always used arcrandom() for generating random numbers when we needed them, so deliberate biases of key material, etc would be quite visible. So a subverted developer would probably need to work on the network stack. I can think of a few obvious ways that they could leak plaintext or key material: 1. Ensure that key bytes somehow wind up as padding. This would be pretty obvious, since current IPsec standards require deterministic padding. Our legacy random padding uses arc4random_buf(). 2. Arrange for particular structures to be adjacent to interesting data, like raw or scheduled keys and accidentally copy too much. 3. Arrange for mbufs that previously contained plaintext or other interesting material to be accidentally reused. This seems to me the most likely avenue, and there have been bugs of this type found before. It's a pretty common mistake, so it is attractive for deniability, but it seems difficult to make this a reliable exploit. If I was doing it, I'd try to make the reuse happen on something like ICMP errors, so I could send error-inducing probe packets at times I thought were interesting :) 4. Introduce timing side-channel leaks. These weren't widely talked about back in 2000 (at least not in the public domain), but have been well researched in the years since then. We have already introduced countermeasures against the obvious memcmp() leaks using timingsafe_bcmp(), but more subtle leaks could still remain. If anyone is concerned that a backdoor may exist and is keen to audit the network stack, then these are the places I'd recommend starting from. -d
