Re: nvi diff fixing a display glitch leading to crash
No comment/interest?
I am assuming this is the right list to send this sort
of crap to. Correct me if I am wrong.
If the fix is incorrect I would appreciate pointers.
Thanks,
--patrick
On Tue, Dec 07, 2010 at 11:58:39PM -0800, patrick keshishian wrote:
Hello,
I work with a lot of sources that have strange formatting
(as do you no doubt). I noticed that sometimes changing the
tabstop value in search of a reasonable display vi would
crash.
Took me a bit to figure out the reproducible steps to be
able to come up with a fix.
Steps to reproduce the crash. Reproducible on i386, amd64,
and macppc:
1. Imagine a file edited with a small tabstop value (say 2
or 3) containing lines long enough so they wrap in default
tabstop (8), but possibly not in the smaller tabstop values.
2. While tabstop set to 8, position one of the wrapping lines
such that the beginning of said line is off screen and the
tail end of the wrapped portion is the first line on the
screen with the cursor positioned on same first line.
3. Change tabstop to 2 (or 3).
Assuming there were more lines below the line your cursor
is on, you will notice a drawing glitch where only the
top line is redrawn and the rest of the screen is blanked
out.
4. If at this point you press ^B (page backwards) vi will
core dump.
A visual of what I experience (series of five screen-shots):
http://sidster.com/scratch/nvi/
The patch below resets the HMAP-soff (screen offset of line)
to 1 if the number of lines HMAP-lno spans has changed and is
now less than HMAP-soff. This essentially forces the entire
line to be redrawn at the top of the screen, avoids the redraw
glitch and eventual crash.
Comments?
--patrick
Index: vi/vs_smap.c
===
RCS file: /cvs/obsd/src/usr.bin/vi/vi/vs_smap.c,v
retrieving revision 1.7
diff -u -p vi/vs_smap.c
--- vi/vs_smap.c 27 Oct 2009 23:59:49 - 1.7
+++ vi/vs_smap.c 8 Dec 2010 06:22:09 -
@@ -224,6 +224,17 @@ top: HMAP-lno = lno;
HMAP-coff = 0;
HMAP-soff = 1;
}
+ else {
+ /*
+ * If number of lines HMAP-lno (top line) spans
+ * changed due to, say reformatting, and now is
+ * fewer than HMAP-soff, reset so the line is
+ * redrawn at the top of the screen.
+ */
+ cnt = vs_screens(sp, HMAP-lno, NULL);
+ if (cnt HMAP-soff)
+ HMAP-soff = 1;
+ }
/* If we fail, just punt. */
for (p = HMAP, cnt = sp-t_rows; --cnt; ++p)
if (vs_sm_next(sp, p, p + 1))
Re: Allegations regarding OpenBSD IPSEC
On Wed, 15 Dec 2010 07:48:46 +0100 Otto Moerbeek o...@drijf.net wrote: 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 I think if it leaks data, it must leak data somewhere, i.e. there must be a server somewhere, and this server must have an ip. so if you look at your traffic, and you will find an ip other then ip of your server, you will know where the leak goes. just my 0.5 cents -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 -- With best regards, Gregory Edigarov
Re: Allegations regarding OpenBSD IPSEC
Unless of course someone was capturing the entire stream as it traversed the internet and then simply extracted the keys later on. On Dec 15, 2010 5:22 AM, Gregory Edigarov g...@bestnet.kharkov.ua wrote: On Wed, 15 Dec 2010 07:48:46 +0100 Otto Moerbeek o...@drijf.net wrote: 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 I think if it leaks data, it must leak data somewhere, i.e. there must be a server somewhere, and this server must have an ip. so if you look at your traffic, and you will find an ip other then ip of your server, you will know where the leak goes. just my 0.5 cents -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 -- With best regards, Gregory Edigarov
Re: Allegations regarding OpenBSD IPSEC
On 2010/12/15 12:20, Gregory Edigarov wrote: On Wed, 15 Dec 2010 07:48:46 +0100 Otto Moerbeek o...@drijf.net wrote: 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 I think you misunderstand what systrace does. 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 I think if it leaks data, it must leak data somewhere, i.e. there must be a server somewhere, and this server must have an ip. so if you look at your traffic, and you will find an ip other then ip of your server, you will know where the leak goes. just my 0.5 cents That's not necessary, key data can be leaked in or alongside the encrypted datastream itself, there's no need to send it anywhere. And it doesn't have to be a whole key, just something that makes things cryptanalysis simpler. *If there's something there*. Remember these are still just allegations at this stage.
Re: nvi diff fixing a display glitch leading to crash
On Wed, Dec 15, 2010 at 02:13:55AM -0800, patrick keshishian wrote:
No comment/interest?
I am assuming this is the right list to send this sort
of crap to. Correct me if I am wrong.
If the fix is incorrect I would appreciate pointers.
Thanks,
--patrick
Right list for commentary. If your intent was to submit a bug report
then this is the wrong way.
While I was unable to reproduce with a file I tried to create, I was
able to reproduce with your test file. On various size xterms at
least.
Unfortunately I have no understanding of the nvi code so I can't say
if your diff is the optimal way to address the problem.
Ken
On Tue, Dec 07, 2010 at 11:58:39PM -0800, patrick keshishian wrote:
Hello,
I work with a lot of sources that have strange formatting
(as do you no doubt). I noticed that sometimes changing the
tabstop value in search of a reasonable display vi would
crash.
Took me a bit to figure out the reproducible steps to be
able to come up with a fix.
Steps to reproduce the crash. Reproducible on i386, amd64,
and macppc:
1. Imagine a file edited with a small tabstop value (say 2
or 3) containing lines long enough so they wrap in default
tabstop (8), but possibly not in the smaller tabstop values.
2. While tabstop set to 8, position one of the wrapping lines
such that the beginning of said line is off screen and the
tail end of the wrapped portion is the first line on the
screen with the cursor positioned on same first line.
3. Change tabstop to 2 (or 3).
Assuming there were more lines below the line your cursor
is on, you will notice a drawing glitch where only the
top line is redrawn and the rest of the screen is blanked
out.
4. If at this point you press ^B (page backwards) vi will
core dump.
A visual of what I experience (series of five screen-shots):
http://sidster.com/scratch/nvi/
The patch below resets the HMAP-soff (screen offset of line)
to 1 if the number of lines HMAP-lno spans has changed and is
now less than HMAP-soff. This essentially forces the entire
line to be redrawn at the top of the screen, avoids the redraw
glitch and eventual crash.
Comments?
--patrick
Index: vi/vs_smap.c
===
RCS file: /cvs/obsd/src/usr.bin/vi/vi/vs_smap.c,v
retrieving revision 1.7
diff -u -p vi/vs_smap.c
--- vi/vs_smap.c27 Oct 2009 23:59:49 - 1.7
+++ vi/vs_smap.c8 Dec 2010 06:22:09 -
@@ -224,6 +224,17 @@ top: HMAP-lno = lno;
HMAP-coff = 0;
HMAP-soff = 1;
}
+ else {
+ /*
+* If number of lines HMAP-lno (top line) spans
+* changed due to, say reformatting, and now is
+* fewer than HMAP-soff, reset so the line is
+* redrawn at the top of the screen.
+*/
+ cnt = vs_screens(sp, HMAP-lno, NULL);
+ if (cnt HMAP-soff)
+ HMAP-soff = 1;
+ }
/* If we fail, just punt. */
for (p = HMAP, cnt = sp-t_rows; --cnt; ++p)
if (vs_sm_next(sp, p, p + 1))
Re: nvi diff fixing a display glitch leading to crash
On Tue, 07 Dec 2010 23:58:39 PST, patrick keshishian wrote: The patch below resets the HMAP-soff (screen offset of line) to 1 if the number of lines HMAP-lno spans has changed and is now less than HMAP-soff. This essentially forces the entire line to be redrawn at the top of the screen, avoids the redraw glitch and eventual crash. That fixes the issue for me and seems like a reasonable approach. The bug also exists in newer development versions of nvi. - todd
dhclient-script and resolv.conf
This made me go nuts for a long time. As soon as you have two interfaces
running dhclient those two will start fighting over /etc/resolv.conf
which is realy bad when short lease times are used and one interface is
not getting new leases.
This diff extends the dhclient-script in such a way that dhclient will
only restore the old resolv.conf file if it actually is in charge of the
current file. With this the fighting does not stop but is less
noticable.
--
:wq Claudio
Index: dhclient-script
===
RCS file: /cvs/src/sbin/dhclient/dhclient-script,v
retrieving revision 1.17
diff -u -p -r1.17 dhclient-script
--- dhclient-script 2 Jun 2010 09:57:16 - 1.17
+++ dhclient-script 4 Nov 2010 11:18:59 -
@@ -111,21 +111,21 @@ add_new_resolv_conf() {
# $new_domain_name are provided. As reported in PR#3135, some ISPs
# provide only $new_domain_name_servers.
- rm -f /etc/resolv.conf.std
+ rm -f /etc/resolv.conf.$interface.std
if [ -n $new_domain_name ]; then
- echo search $new_domain_name /etc/resolv.conf.std
+ echo search $new_domain_name /etc/resolv.conf.$interface.std
fi
if [ -n $new_domain_name_servers ]; then
for nameserver in $new_domain_name_servers; do
- echo nameserver $nameserver /etc/resolv.conf.std
+ echo nameserver $nameserver
/etc/resolv.conf.$interface.std
done
fi
- if [ -f /etc/resolv.conf.std ]; then
+ if [ -f /etc/resolv.conf.$interface.std ]; then
if [ -f /etc/resolv.conf.tail ]; then
- cat /etc/resolv.conf.tail /etc/resolv.conf.std
+ cat /etc/resolv.conf.tail
/etc/resolv.conf.$interface.std
fi
# In case (e.g. during OpenBSD installs) /etc/resolv.conf
@@ -133,10 +133,9 @@ add_new_resolv_conf() {
# the new data in the correct location.
if [ -f /etc/resolv.conf ]; then
- cat /etc/resolv.conf /etc/resolv.conf.save
+ cat /etc/resolv.conf /etc/resolv.conf.$interface.save
fi
- cat /etc/resolv.conf.std /etc/resolv.conf
- rm -f /etc/resolv.conf.std
+ cat /etc/resolv.conf.$interface.std /etc/resolv.conf
# Try to ensure correct ownership and permissions.
chown -RL root:wheel /etc/resolv.conf
@@ -152,21 +151,21 @@ ip6_add_new_resolv_conf() {
# Create resolv.conf when either $new_dhcp6_name_servers or
# $new_dhcp6_domain_search are provided.
- rm -f /etc/resolv.conf.std6
+ rm -f /etc/resolv.conf.$interface.std6
if [ -n $new_dhcp6_domain_search ]; then
- echo search $new_dhcp6_domain_search /etc/resolv.conf.std6
+ echo search $new_dhcp6_domain_search
/etc/resolv.conf.$interface.std6
fi
if [ -n $new_dhcp6_name_servers ]; then
for nameserver in $new_dhcp6_name_servers; do
- echo nameserver $nameserver /etc/resolv.conf.std6
+ echo nameserver $nameserver
/etc/resolv.conf.$interface.std6
done
fi
- if [ -f /etc/resolv.conf.std6 ]; then
+ if [ -f /etc/resolv.conf.$interface.std6 ]; then
if [ -f /etc/resolv.conf.tail ]; then
- cat /etc/resolv.conf.tail /etc/resolv.conf.std6
+ cat /etc/resolv.conf.tail
/etc/resolv.conf.$interface.std6
fi
# In case (e.g. during OpenBSD installs) /etc/resolv.conf
@@ -174,10 +173,9 @@ ip6_add_new_resolv_conf() {
# the new data in the correct location.
if [ -f /etc/resolv.conf ]; then
- cat /etc/resolv.conf /etc/resolv.conf.save
+ cat /etc/resolv.conf /etc/resolv.conf.$interface.save
fi
- cat /etc/resolv.conf.std6 /etc/resolv.conf
- rm -f /etc/resolv.conf.std6
+ cat /etc/resolv.conf.$interface.std6 /etc/resolv.conf
# Try to ensure correct ownership and permissions.
chown -RL root:wheel /etc/resolv.conf
@@ -256,8 +254,13 @@ EXPIRE|FAIL)
fi
# XXX Why add alias we just deleted above?
add_new_alias
- if [ -f /etc/resolv.conf.save ]; then
- cat /etc/resolv.conf.save /etc/resolv.conf
+ if [ -f /etc/resolv.conf.$interface.std ]; then
+ cmp -s /etc/resolv.conf /etc/resolv.conf.$interface.std
+ if [ $? -eq 0 -a -f /etc/resolv.conf.$interface.save ]; then
+ cat /etc/resolv.conf.$interface.save /etc/resolv.conf
+ fi
+ rm -f /etc/resolv.conf.$interface.save
+ rm -f
Re: small drm uvm diff
On Wed, Dec 15, 2010 at 12:05:31AM -0500, Ted Unangst wrote:
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.
Yup, that's fine.
This was in place in this initial import of this code, suprised i've not
noticed and cleaned it up yet.
Please do put it in.
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.c15 Dec 2010 04:59:52 - 1.46
+++ drm_bufs.c15 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);
--
In Pocataligo, Georgia, it is a violation for a woman over 200 pounds
and attired in shorts to pilot or ride in an airplane.
Fw: cwm: xev_reconfig - xu_reconfig
I sent the diff below to a few guys found in the cwm cvs log about a month
ago but no love, so I'm posting here.
The diff is not that important but here it is anyway. It came about when
looking through the cwm code trying to fix a few bugs that I've uncovered
(though I've been unsuccessful so far). More diffs like this to come, if
anyone cares.
BTW, who should I send things like this to, if not this list?
Begin forwarded message:
[...]
Move xev_reconfig from xevents.c to xutil.c and rename to xu_reconfig as
per XXX in calmwm.h. While here, sort xu_* prototypes in calmwm.h to match
the order of definition in xutil.c.
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.118
diff -u -p -r1.118 calmwm.h
--- calmwm.h22 May 2010 22:10:31 - 1.118
+++ calmwm.h17 Nov 2010 10:38:15 -
@@ -384,29 +384,27 @@ struct menu *menu_filter(struct scree
void (*)(struct menu *, int));
voidmenu_init(struct screen_ctx *);
-/* XXX should be xu_ */
-void xev_reconfig(struct client_ctx *);
-
voidxev_loop(void);
-voidxu_getatoms(void);
int xu_ptr_grab(Window, int, Cursor);
-voidxu_btn_grab(Window, int, u_int);
int xu_ptr_regrab(int, Cursor);
-voidxu_btn_ungrab(Window, int, u_int);
voidxu_ptr_ungrab(void);
-voidxu_ptr_setpos(Window, int, int);
+voidxu_btn_grab(Window, int, u_int);
+voidxu_btn_ungrab(Window, int, u_int);
voidxu_ptr_getpos(Window, int *, int *);
+voidxu_ptr_setpos(Window, int, int);
voidxu_key_grab(Window, int, int);
voidxu_key_ungrab(Window, int, int);
+voidxu_reconfig(struct client_ctx *);
voidxu_sendmsg(Window, Atom, long);
int xu_getprop(Window, Atom, Atom, long, u_char **);
int xu_getstrprop(Window, Atom, char **);
-voidxu_setstate(struct client_ctx *, int);
int xu_getstate(struct client_ctx *, int *);
+voidxu_setstate(struct client_ctx *, int);
+voidxu_getatoms(void);
+voidxu_setwmname(struct screen_ctx *);
unsigned long xu_getcolor(struct screen_ctx *, char *);
voidxu_freecolor(struct screen_ctx *, unsigned long);
-voidxu_setwmname(struct screen_ctx *);
int u_spawn(char *);
voidu_exec(char *);
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.76
diff -u -p -r1.76 client.c
--- client.c22 May 2010 22:10:31 - 1.76
+++ client.c17 Nov 2010 10:38:15 -
@@ -114,7 +114,7 @@ client_new(Window win, struct screen_ctx
XAddToSaveSet(X_Dpy, cc-win);
/* Notify client of its configuration. */
- xev_reconfig(cc);
+ xu_reconfig(cc);
(state == IconicState) ? client_hide(cc) : client_unhide(cc);
xu_setstate(cc, cc-state);
@@ -390,14 +390,14 @@ client_resize(struct client_ctx *cc)
XMoveResizeWindow(X_Dpy, cc-win, cc-geom.x,
cc-geom.y, cc-geom.width, cc-geom.height);
- xev_reconfig(cc);
+ xu_reconfig(cc);
}
void
client_move(struct client_ctx *cc)
{
XMoveWindow(X_Dpy, cc-win, cc-geom.x, cc-geom.y);
- xev_reconfig(cc);
+ xu_reconfig(cc);
}
void
Index: xevents.c
===
RCS file: /cvs/xenocara/app/cwm/xevents.c,v
retrieving revision 1.50
diff -u -p -r1.50 xevents.c
--- xevents.c 25 Sep 2010 20:04:55 - 1.50
+++ xevents.c 17 Nov 2010 10:38:15 -
@@ -52,7 +52,6 @@ static voidxev_handle_clientmessage(XE
static void xev_handle_randr(XEvent *);
static void xev_handle_mappingnotify(XEvent *);
-
void (*xev_handlers[LASTEvent])(XEvent *) = {
[MapRequest] = xev_handle_maprequest,
[UnmapNotify] = xev_handle_unmapnotify,
@@ -166,7 +165,7 @@ xev_handle_configurerequest(XEvent *ee)
wc.border_width = cc-bwidth;
XConfigureWindow(X_Dpy, cc-win, e-value_mask, wc);
- xev_reconfig(cc);
+ xu_reconfig(cc);
} else {
/* let it do what it wants, it'll be ours when we map it. */
wc.x = e-x;
@@ -211,25 +210,6 @@ test:
group_update_names(sc);
}
-}
-
-void
-xev_reconfig(struct client_ctx *cc)
-{
- XConfigureEvent ce;
-
- ce.type = ConfigureNotify;
- ce.event = cc-win;
-
Re: Fw: cwm: xev_reconfig - xu_reconfig
On Wed 2010.12.15 at 18:33 +0100, Thomas Pfaff wrote:
I sent the diff below to a few guys found in the cwm cvs log about a month
ago but no love, so I'm posting here.
Hi Thomas,
There are a few clean-up diffs floating around the guys in the logs,
some of which has some of the stuff you have below. The clean-ups have
not been forgotten.
Cheers,
Okan
The diff is not that important but here it is anyway. It came about when
looking through the cwm code trying to fix a few bugs that I've uncovered
(though I've been unsuccessful so far). More diffs like this to come, if
anyone cares.
BTW, who should I send things like this to, if not this list?
Begin forwarded message:
[...]
Move xev_reconfig from xevents.c to xutil.c and rename to xu_reconfig as
per XXX in calmwm.h. While here, sort xu_* prototypes in calmwm.h to match
the order of definition in xutil.c.
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.118
diff -u -p -r1.118 calmwm.h
--- calmwm.h 22 May 2010 22:10:31 - 1.118
+++ calmwm.h 17 Nov 2010 10:38:15 -
@@ -384,29 +384,27 @@ struct menu *menu_filter(struct scree
void (*)(struct menu *, int));
void menu_init(struct screen_ctx *);
-/* XXX should be xu_ */
-void xev_reconfig(struct client_ctx *);
-
void xev_loop(void);
-void xu_getatoms(void);
int xu_ptr_grab(Window, int, Cursor);
-void xu_btn_grab(Window, int, u_int);
int xu_ptr_regrab(int, Cursor);
-void xu_btn_ungrab(Window, int, u_int);
void xu_ptr_ungrab(void);
-void xu_ptr_setpos(Window, int, int);
+void xu_btn_grab(Window, int, u_int);
+void xu_btn_ungrab(Window, int, u_int);
void xu_ptr_getpos(Window, int *, int *);
+void xu_ptr_setpos(Window, int, int);
void xu_key_grab(Window, int, int);
void xu_key_ungrab(Window, int, int);
+void xu_reconfig(struct client_ctx *);
void xu_sendmsg(Window, Atom, long);
int xu_getprop(Window, Atom, Atom, long, u_char **);
int xu_getstrprop(Window, Atom, char **);
-void xu_setstate(struct client_ctx *, int);
int xu_getstate(struct client_ctx *, int *);
+void xu_setstate(struct client_ctx *, int);
+void xu_getatoms(void);
+void xu_setwmname(struct screen_ctx *);
unsigned long xu_getcolor(struct screen_ctx *, char *);
void xu_freecolor(struct screen_ctx *, unsigned long);
-void xu_setwmname(struct screen_ctx *);
int u_spawn(char *);
void u_exec(char *);
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.76
diff -u -p -r1.76 client.c
--- client.c 22 May 2010 22:10:31 - 1.76
+++ client.c 17 Nov 2010 10:38:15 -
@@ -114,7 +114,7 @@ client_new(Window win, struct screen_ctx
XAddToSaveSet(X_Dpy, cc-win);
/* Notify client of its configuration. */
- xev_reconfig(cc);
+ xu_reconfig(cc);
(state == IconicState) ? client_hide(cc) : client_unhide(cc);
xu_setstate(cc, cc-state);
@@ -390,14 +390,14 @@ client_resize(struct client_ctx *cc)
XMoveResizeWindow(X_Dpy, cc-win, cc-geom.x,
cc-geom.y, cc-geom.width, cc-geom.height);
- xev_reconfig(cc);
+ xu_reconfig(cc);
}
void
client_move(struct client_ctx *cc)
{
XMoveWindow(X_Dpy, cc-win, cc-geom.x, cc-geom.y);
- xev_reconfig(cc);
+ xu_reconfig(cc);
}
void
Index: xevents.c
===
RCS file: /cvs/xenocara/app/cwm/xevents.c,v
retrieving revision 1.50
diff -u -p -r1.50 xevents.c
--- xevents.c 25 Sep 2010 20:04:55 - 1.50
+++ xevents.c 17 Nov 2010 10:38:15 -
@@ -52,7 +52,6 @@ static void xev_handle_clientmessage(XE
static void xev_handle_randr(XEvent *);
static void xev_handle_mappingnotify(XEvent *);
-
void (*xev_handlers[LASTEvent])(XEvent *) = {
[MapRequest] = xev_handle_maprequest,
[UnmapNotify] = xev_handle_unmapnotify,
@@ -166,7 +165,7 @@ xev_handle_configurerequest(XEvent *ee)
wc.border_width = cc-bwidth;
XConfigureWindow(X_Dpy, cc-win, e-value_mask, wc);
- xev_reconfig(cc);
+ xu_reconfig(cc);
} else {
/* let it do what it wants, it'll be ours when we map it. */
wc.x =
RAVIE DE FAIRE TA CONNAISSANCE
This is a MIME-encoded message that mnasskdj sent through Multiply. To read it, you need a HTML-capable mail client.
Re: Allegations regarding OpenBSD IPSEC
Subject: Allegations regarding OpenBSD IPSEC Every urban lengend is made more real by the inclusion of real names, dates, and times. Gregory Perry's email falls into this category. I cannot fathom his motivation for writing such falsehood (delusions of grandeur or a self-promotion attempt perhaps?) I will state clearly that I did not add backdoors to the OpenBSD operating system or the OpenBSD crypto framework (OCF). The code I touched during that work relates mostly to device drivers to support the framework. I don't believe I ever touched isakmpd or photurisd (userland key management programs), and I rarely touched the ipsec internals (cryptodev and cryptosoft, yes). However, I welcome an audit of everything I committed to OpenBSD's tree. I demand an apology from Greg Perry (cc'd) for this accusation. Do not use my name to add credibility to your cloak and dagger fairy tales. I will point out that Greg did not even work at NETSEC while the OCF development was going on. Before January of 2000 Greg had left NETSEC. The timeline for my involvement with IPSec can be clearly demonstrated by looking at the revision history of: src/sys/dev/pci/hifn7751.c (Dec 15, 1999) src/sys/crypto/cryptosoft.c (March 2000) The real work on OCF did not begin in earnest until February 2000. Theo, a bit of warning would have been nice (an hour even... especially since you had the allegations on Dec 11, 2010 and did not post them until Dec 14, 2010). The first notice I got was an email from a friend at 6pm (MST) on Dec 14, 2010 with a link to the already posted message. So, keep my name out of the rumor mill. It is a baseless accusation the reason for which I cannot understand. --Jason L. Wright
Re: nvi diff fixing a display glitch leading to crash
On Wed, Dec 15, 2010 at 09:43:47AM -0500, Todd C. Miller wrote: On Tue, 07 Dec 2010 23:58:39 PST, patrick keshishian wrote: The patch below resets the HMAP-soff (screen offset of line) to 1 if the number of lines HMAP-lno spans has changed and is now less than HMAP-soff. This essentially forces the entire line to be redrawn at the top of the screen, avoids the redraw glitch and eventual crash. That fixes the issue for me and seems like a reasonable approach. The bug also exists in newer development versions of nvi. Is it reasonable to assume the patch will be accepted? Thanks for looking, --patrick
Re: Allegations regarding OpenBSD IPSEC
The IPSEC allegations have produced a flurry of blog posts and suchlike, mostly just rehashing the contents of Theo's original message. However, I've found two followups that are interesting for their own separate reasons: in http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd , there appears to be some additional veribage from Gregory Perry, but IMHO it does not really add much in the way of useful information. The other item, http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html is quite a bit more interesting, since it's a public challenge (with a cash bounty) to come up with actual evidence of backdoor code in the relevant parts of OpenBSD. There have been offers to match original 3 * USD 100 bounty, so with a little more circulation the bounty could turn into a good amount. I would say the second post here deserves more attention; if you agree, please make that URL visible via whatever news sites you can think of (yup, it's in the /. submissions queue). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 15, 2010 at 11:33 AM, Peter N. M. Hansteen pe...@bsdly.net wrote: The IPSEC allegations have produced a flurry of blog posts and suchlike, mostly just rehashing the contents of Theo's original message. However, I've found two followups that are interesting for their own separate reasons: in http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd , there appears to be some additional veribage from Gregory Perry, but IMHO it does not really add much in the way of useful information. The other item, http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-al legations.html is quite a bit more interesting, since it's a public challenge (with a cash bounty) to come up with actual evidence of backdoor code in the relevant parts of OpenBSD. There have been offers to match original 3 * USD 100 bounty, so with a little more circulation the bounty could turn into a good amount. It is easy to shoot one's mouth off like that about bounty offered, given the ridiculously constrained conditions the bounty is offered under. He might as well offered a million USD. No one will be able to prove this under these restrictions. --patrick
Re: Allegations regarding OpenBSD IPSEC
patrick keshishian pkesh...@gmail.com writes: It is easy to shoot one's mouth off like that about bounty offered, given the ridiculously constrained conditions the bounty is offered under. He might as well offered a million USD. No one will be able to prove this under these restrictions. I won't get into a discussion about DES' stated requirements, but I do think it's a good-faith effort. Then again, as Jason Dixon points out in his blog http://obfuscurity.com/2010/12/Updates-on-the-OpenBSD-IPsec-Gossip , making a donation to the OpenBSD project is likely to give you more bang for the buck. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 15, 2010 at 3:36 PM, Damien Miller d...@mindrot.org wrote: On Wed, 15 Dec 2010, patrick keshishian wrote: It is easy to shoot one's mouth off like that about bounty offered, given the ridiculously constrained conditions the bounty is offered under. He might as well offered a million USD. No one will be able to prove this under these restrictions. His conditions aren't ridiculously constrained, they seem to be pretty much approproiate for the allegations. The requirement that the bug still be exploitable in the current code is a little much. A hidden side channel might possibly be quite fragile and easily disarmed by accident without fixing the underlying flaw, but that wouldn't invalidate the allegation. That part did read a lot like hedging the bet. An exploit like this that only worked pre-4.4 (to pick a random older release for example) would still be very valuable.
Re: Allegations regarding OpenBSD IPSEC
On Wed, 15 Dec 2010 10:27:31 -0800 Jason L. Wright ja...@thought.net wrote: I cannot fathom his motivation for writing such falsehood (delusions of grandeur or a self-promotion attempt perhaps?) Perhaps, Promote his domains rank in google or the facebook link? (Does anyone know if he always puts facebook links in mails) Wants IPSEC audited for some reason? Divert devs attention from something else? If it's one of these reasons or any other alterior motive then that's just dispicible. However, NDAs often last for 10 years which either adds weight to the well thought urban myth theory or to the possibility that it may be the truth. The real work on OCF did not begin in earnest until February 2000. I can't see how this gives you credibility but maybe the people who worked with you at the time can understand how your evidence supports what you say.
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 15, 2010 at 12:36 PM, Damien Miller d...@mindrot.org wrote: On Wed, 15 Dec 2010, patrick keshishian wrote: It is easy to shoot one's mouth off like that about bounty offered, given the ridiculously constrained conditions the bounty is offered under. He might as well offered a million USD. No one will be able to prove this under these restrictions. His conditions aren't ridiculously constrained, they seem to be pretty much approproiate for the allegations. seriously? # - that the OpenBSD Crypto Framework contains vulnerabilities # which can be exploited by an eavesdropper to recover plaintext # from an IPSec stream, There is a big assumption about the alleged backdoor or leak; i.e., that it is used to directly extract plaintext out of an IPSEC stream. OK. Maybe reasonable. # - that these vulnerabilities can be traced directly to code # submitted by Jason Wright and / or other developers linked # to Perry, and Do they really have to be linked back to Perry? Is that really the important factor in the alleged backdoor's existence? # - that the nature of these vulnerabilities is such that there # is reason to suspect, independently of Perry's allegations, # that they were inserted intentionally-for instance, if the # surrounding code is unnecessarily awkward or obfuscated and # the obvious and straightforward alternative would either not # be vulnerable or be immediately recognizable as vulnerable Oh, so the alleged backdoor if present _must_ be in the form of obfuscated code. Okay... # - Finally, I pledge USD 100 to the first person to present # convincing evidence showing that a government agency # successfully planted a backdoor in a security-critical # portion of the Linux kernel. So not only one has to find the alleged backdoor, but also link its author to a government agency .. via how I wonder, payroll stub, signed contract, confession? OK, Maybe not too unreasonable, but it still gives a nice loophole for blogger to recant on his bounty. # - In all three cases, the vulnerability must still be present # and exploitable when the evidence is assembled and presented # to the affected parties. Allowances will be made for the # responsible disclosure process. Must still exist? So proving that at some point the alleged backdoor existed and was placed in there by an FBI/NSA pawn isn't good enough, but the alleged backdoor must still exist. Nice... # - Exploitability must be demonstrated, not theorized. Ahh... must be demonstrated. So not only you need to show there is an alleged leak but also you must know the means by which the NSA or FBI intended to use the alleged leak. But OK. --patrick
Re: Allegations regarding OpenBSD IPSEC
On Wednesday, December 15, Kevin Chadwick wrote: The real work on OCF did not begin in earnest until February 2000. I can't see how this gives you credibility but maybe the people who worked with you at the time can understand how your evidence supports what you say. I've known Jason for quite a while, and nothing has ever let me believe that I should question his character, motives or otherwise make me believe he was not a straightforward and honest person. I think even in the USA a person is INNOCENT, until PROVEN guilty. So in this case, you're the one that is out of line. You're the one the onus of proof is on. Jason has no need to give you evidence. Quite frankly, dragging Jason (or anyone else) through the mud in this fashion is completely disgusting, deplorable, and stinks. This will be the last I say on this subject. --Toby.
Re: Allegations regarding OpenBSD IPSEC
On Wed, 15 Dec 2010 14:57:24 -0700 Tobias Weingartner weing...@tepid.org wrote: So in this case, you're the one that is out of line. If your talking to me then I tried to make it clear that I was sitting on the fence. I was going to go further but then figured that would be leaning in one direction. I certainly wouldn't want to offend anyone I don't know but I'm not going to defend them or help their case if I don't know whether they're guilty or not either. If your putting evidence forward, then logic dictates that the same reasoning applies in that it doesn't clear you unquestionably unless it proves something which is why I asked if it did. Don't get me started about law, because it's more about money than justice and please don't read between my lines. For what it's worth, my opinion which is irrelevant on the basis of next to no evidence was that Jason is likely the one telling the truth and I'm sure the people in the community that count to him will have a better idea than me. My intention was not to drag anyone through the mud but only help people get to the truth, sorry if it also seemed like that to anyone else. If he's wrongly accused for financial gain then that is truly terrible.
Read-only sd(4) devices -- good idea?
USB. Need I say more? :-)
I now have a USB device in hand which has a 'READONLY' physical switch on
the top. If set to READONLY, this device spews error messages when
writes are attempted. And the device freaks out so that ALL subsequent
i/o's fail.
I saw this:
http://lists.wpkg.org/pipermail/stgt/2010-March/003569.html
and hacked together the diff below to record the WRITE PROTECT info
that dev_spec provides. I unified the sd and st cases to use the same
flag.
The USB device is now silent. This is still a bit of a puzzle since
I expect the 'dd if=/dev/zero of=/dev/sd2c count=1' command to fail
with an error. But it simply reports that all is well.
Respecting the WRITE PROTECT bit seems like a good idea
Thoughts? Anybody with 'real' SCSI specs to check up on when dev_spec
started supplying this info?
Ken
Index: scsi_all.h
===
RCS file: /cvs/src/sys/scsi/scsi_all.h,v
retrieving revision 1.51
diff -u -p -r1.51 scsi_all.h
--- scsi_all.h 2 Sep 2010 11:54:44 - 1.51
+++ scsi_all.h 5 Dec 2010 01:18:25 -
@@ -431,6 +431,9 @@ struct scsi_mode_header_big {
u_int8_t blk_desc_len[2];
};
+/* Both disks and tapes use dev_spec to report READONLY status. */
+#defineSMH_DSP_WRITE_PROT 0x80
+
union scsi_mode_sense_buf {
struct scsi_mode_header hdr;
struct scsi_mode_header_big hdr_big;
Index: scsi_tape.h
===
RCS file: /cvs/src/sys/scsi/scsi_tape.h,v
retrieving revision 1.7
diff -u -p -r1.7 scsi_tape.h
--- scsi_tape.h 7 Jan 1998 17:28:38 - 1.7
+++ scsi_tape.h 5 Dec 2010 01:18:25 -
@@ -173,7 +173,6 @@ struct scsi_tape_dev_conf_page {
#defineSMH_DSP_BUFF_MODE_OFF 0x00
#defineSMH_DSP_BUFF_MODE_ON0x10
#defineSMH_DSP_BUFF_MODE_MLTI 0x20
-#defineSMH_DSP_WRITE_PROT 0x80
/* A special for the CIPHER ST150S(old drive) */
struct block_desc_cipher {
Index: scsiconf.h
===
RCS file: /cvs/src/sys/scsi/scsiconf.h,v
retrieving revision 1.141
diff -u -p -r1.141 scsiconf.h
--- scsiconf.h 12 Oct 2010 00:53:32 - 1.141
+++ scsiconf.h 5 Dec 2010 01:18:26 -
@@ -367,6 +367,7 @@ struct scsi_link {
u_int16_t flags;/* flags that all devices have */
#defineSDEV_REMOVABLE 0x0001 /* media is removable */
#defineSDEV_MEDIA_LOADED 0x0002 /* device figures are still
valid */
+#defineSDEV_READONLY 0x0004 /* device is read-only */
#defineSDEV_OPEN 0x0008 /* at least 1 open session */
#defineSDEV_DBX0x00f0 /* debugging flags
(scsi_debug.h) */
#defineSDEV_EJECTING 0x0100 /* eject on device close */
Index: sd.c
===
RCS file: /cvs/src/sys/scsi/sd.c,v
retrieving revision 1.218
diff -u -p -r1.218 sd.c
--- sd.c24 Sep 2010 01:41:34 - 1.218
+++ sd.c5 Dec 2010 01:18:26 -
@@ -539,6 +539,11 @@ sdstrategy(struct buf *bp)
bp-b_error = ENXIO;
goto bad;
}
+ if (!ISSET(bp-b_flags, B_READ) ISSET(sc-sc_link-flags,
+ SDEV_READONLY)) {
+ bp-b_error = EIO;
+ goto bad;
+ }
SC_DEBUG(sc-sc_link, SDEV_DB2, (sdstrategy: %ld bytes @ blk %d\n,
bp-b_bcount, bp-b_blkno));
@@ -1403,21 +1408,37 @@ sd_get_parms(struct sd_softc *sc, struct
struct page_rigid_geometry *rigid = NULL;
struct page_flex_geometry *flex = NULL;
struct page_reduced_geometry *reduced = NULL;
+ u_char *page0 = NULL;
u_int32_t heads = 0, sectors = 0, cyls = 0, secsize = 0, sssecsize;
- int err = 0;
+ int err = 0, big;
dp-disksize = scsi_size(sc-sc_link, flags, sssecsize);
+ buf = malloc(sizeof(*buf), M_TEMP, M_NOWAIT);
+ if (buf == NULL)
+ goto validate;
+
+ /*
+* Ask for page 0 (vendor specific) mode sense data to find
+* READONLY info. The only thing USB devices will ask for.
+*/
+ err = scsi_do_mode_sense(sc-sc_link, 0, buf, (void **)page0,
+ NULL, NULL, NULL, 1, flags | SCSI_SILENT, big);
+ if (err == 0) {
+ if (big buf-hdr_big.dev_spec SMH_DSP_WRITE_PROT)
+ SET(sc-sc_link-flags, SDEV_READONLY);
+ else if (!big buf-hdr.dev_spec SMH_DSP_WRITE_PROT)
+ SET(sc-sc_link-flags, SDEV_READONLY);
+ else
+ CLR(sc-sc_link-flags, SDEV_READONLY);
+ }
+
/*
* Many UMASS devices choke when asked about their geometry. Most
* don't have a meaningful geometry anyway, so just fake it if
* scsi_size() worked.
*/
if ((sc-sc_link-flags SDEV_UMASS)
diff to bsearch the autoconf vendor/product match tables
Hello, t...@!
The pci/usb (and others) known_{products,vendors} generated from
{pci,usb}devs are really big and scanning them is not so efficient.
I took the reyk@'s bsearch() implementation found in ieee80211 code
and moved it to libkern.
To sort tables I've rewritten the devlist2h from awk to perl, since
it can sort :). Imho, this implementation is a bit cleaner and
does not have that big license header.
Since usb/pci is only supported so far, I hope if you like it I can
continue replacing the rest of autoconf matching goo to bsearch
What do you think?
Index: conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.504
diff -u -p -r1.504 files
--- conf/files 6 Oct 2010 22:19:20 - 1.504
+++ conf/files 16 Dec 2010 00:12:53 -
@@ -1085,6 +1085,7 @@ file lib/libkern/mcount.c gprof
file lib/libkern/getsn.c
file lib/libkern/random.c
file lib/libkern/timingsafe_bcmp.c
+file lib/libkern/bsearch.c
file lib/libkern/arch/${MACHINE_ARCH}/strchr.S | lib/libkern/strchr.c
file lib/libkern/arch/${MACHINE_ARCH}/strrchr.S | lib/libkern/strrchr.c
file lib/libkern/arch/${MACHINE_ARCH}/__main.S | lib/libkern/__main.c
Index: dev/pci/Makefile
===
RCS file: /cvs/src/sys/dev/pci/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- dev/pci/Makefile14 Oct 1996 09:01:34 - 1.4
+++ dev/pci/Makefile16 Dec 2010 00:12:53 -
@@ -1,8 +1,6 @@
# $OpenBSD: Makefile,v 1.4 1996/10/14 09:01:34 deraadt Exp $
-# $NetBSD: Makefile,v 1.1 1995/06/18 01:07:04 cgd Exp $
-AWK= awk
+PERL?= perl
-pcidevs.h pcidevs_data.h: pcidevs devlist2h.awk
- /bin/rm -f pcidevs.h pcidevs_data.h
- ${AWK} -f devlist2h.awk pcidevs
+pcidevs.h pcidevs_data.h: pcidevs devlist2h.pl
+ ${PERL} devlist2h.pl pcidevs
Index: dev/pci/devlist2h.pl
===
RCS file: dev/pci/devlist2h.pl
diff -N dev/pci/devlist2h.pl
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/pci/devlist2h.pl16 Dec 2010 00:12:53 -
@@ -0,0 +1,167 @@
+#!/usr/bin/perl -w
+use strict;
+
+my $hfile = pcidevs.h;
+my $dfile = pcidevs_data.h;
+
+open HFILE, $hfile;
+open DFILE, $dfile;
+sub header {
+ my ($file, $version) = @_;
+ chomp $version;
+
+ print {$file} __END;
+/*
+ * THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT.
+ *
+ * generated from:
+ * $version
+ */
+__END
+}
+
+my $version = readline;
+header \*HFILE, $version;
+header \*DFILE, $version;
+
+my %vendorhash;
+my @vendors;
+my @products;
+
+my $commentmode = 0;
+my @commentbuf;
+my $leadblank = 0;
+
+while () {
+ chomp;
+ if ($commentmode) {
+ push @commentbuf, $_;
+ if (/\*\/\s*$/) {
+ $commentmode = 0;
+ }
+ next;
+ }
+
+ if (/^vendor/) {
+ my @data = split /[ \t]+/;
+ my ($k, $vendor, $id) = splice @data, 0, 3;
+ my $descr = join ' ', @data;
+
+ my @copy = @commentbuf;
+ my %new = (
+ vendor = $vendor,
+ id = $id,
+ descr = $descr,
+
+ lblank = $leadblank,
+ comment = \...@copy,
+ );
+ push @vendors, \%new;
+ $vendorhash{$vendor} = \%new;
+
+ $leadblank = 0;
+ @commentbuf = ();
+ } elsif (/^product/) {
+ my @data = split /[ \t]+/;
+ my ($k, $vendor, $product, $id) = splice @data, 0, 4;
+ my $descr = join ' ', @data;
+
+ my @copy = @commentbuf;
+ my %new = (
+ vendor = $vendor,
+ product = $product,
+ id = $id,
+ descr = $descr,
+
+ lblank = $leadblank,
+ comment = \...@copy,
+ );
+ push @products, \%new;
+
+ $leadblank = 0;
+ @commentbuf = ();
+ } elsif (/^$/) {
+ $leadblank = 1;
+ } elsif (/^\s*\/\*.*\*\/$/) { # oneline comment
+ push @commentbuf, $_;
+ } elsif (/^\s*\/\*/) {
+ $commentmode = 1;
+ push @commentbuf, $_;
+ }
+}
+die invalid syntax\n if $commentmode;
+
+sub prologue {
+ my $h = shift;
+ print HFILE \n if $h-{lblank};
+ if (@{$h-{comment}}) {
+ print HFILE join(\n, @{$h-{comment}});
+ print HFILE \n;
+ }
+}
+
+foreach my $v (@vendors) {
+ prologue $v;
+ print HFILE __END;
+#define PCI_VENDOR_$v-{vendor}$v-{id} /* $v-{descr} */
+__END
+}
+
+foreach my $p (@products) {
+ prologue $p;
+ print HFILE
Re: diff to bsearch the autoconf vendor/product match tables
On 02:39 Thu 16 Dec, Vladimir Kirillov wrote:
+foreach my $v (sort { hex($a-{id}) = hex($b-{id}) } @vendors) {
Please also note that this won't fail on usbdevs if you replace 0X
hex prefixes with 0x.
slower logins
These values have not marched forward with the progress of time. For perspective, the last increase in bcrypt rounds was around the time we considered Monica Lewinsky a big scandal. If processing power really doubles every 2 years, we should increase by 6, but that means 5 second root logins even on a fast machine. I know I know, no pain no gain, but let's build up our atrophied muscles slowly. Increasing by 3 also means root goes to 11. Slow machines will, of course, get slower, but: 1. You don't have to upgrade to the new numbers 2. You can dial down the pain if necessary 3. We can call the added delay The Gawker Memorial Second Index: login.conf.in === RCS file: /home/tedu/cvs/src/etc/login.conf.in,v retrieving revision 1.2 diff -u -r1.2 login.conf.in --- login.conf.in 9 Jan 2007 10:20:12 - 1.2 +++ login.conf.in 16 Dec 2010 03:21:23 - @@ -46,7 +46,7 @@ :maxproc-c...@def_maxproc_cur@:\ :openfiles-c...@def_openfiles_cur@:\ :stacksize-cur=4M:\ - :localcipher=blowfish,6:\ + :localcipher=blowfish,9:\ :ypcipher=old:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: @@ -62,7 +62,7 @@ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ - :localcipher=blowfish,8:\ + :localcipher=blowfish,11:\ :tc=default: #
more mem p2
this is a broken out piece of the previous more memory diff, revised.
as before, the idea is to allow uvm_map_hint to optionally select some of
the reserved heap space if we have run out of room in the normal mmap
space.
changes are that i'm using a macro now, to avoid changing code all over
the kernel. that should make things easier to adapt if we make this code
smarter. no need to expose allocation policy guts all over the kernel.
the only consumer of the new hint is at the bottom of uvm_mmap, where if
we failed, we'll give it one more chance.
i'd like some test reports, on various archs. the effects of reaching
into the heap should be minimal, given:
1. nothing uses the heap anymore
2. it only allocates there if all the rest is used up
but I've rarely seen a uvm diff that didn't do something weirder than
promised.
Index: uvm_map.c
===
RCS file: /home/tedu/cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.130
diff -u -r1.130 uvm_map.c
--- uvm_map.c 15 Dec 2010 04:59:52 - 1.130
+++ uvm_map.c 16 Dec 2010 02:36:15 -
@@ -1241,7 +1241,7 @@
* creating a new mapping with prot protection.
*/
vaddr_t
-uvm_map_hint(struct proc *p, vm_prot_t prot)
+uvm_map_hint1(struct proc *p, vm_prot_t prot, int skipheap)
{
vaddr_t addr;
@@ -1258,7 +1258,9 @@
}
#endif
/* start malloc/mmap after the brk */
- addr = (vaddr_t)p-p_vmspace-vm_daddr + BRKSIZ;
+ addr = (vaddr_t)p-p_vmspace-vm_daddr;
+ if (skipheap)
+ addr += BRKSIZ;
#if !defined(__vax__)
addr += arc4random() (MIN((256 * 1024 * 1024), BRKSIZ) - 1);
#endif
Index: uvm_map.h
===
RCS file: /home/tedu/cvs/src/sys/uvm/uvm_map.h,v
retrieving revision 1.43
diff -u -r1.43 uvm_map.h
--- uvm_map.h 20 Apr 2010 22:05:44 - 1.43
+++ uvm_map.h 16 Dec 2010 02:34:08 -
@@ -287,7 +287,8 @@
vm_map_entry_t uvm_map_findspace(vm_map_t, vaddr_t, vsize_t, vaddr_t *,
struct uvm_object *, voff_t, vsize_t, int);
vaddr_tuvm_map_pie(vaddr_t);
-vaddr_tuvm_map_hint(struct proc *, vm_prot_t);
+#defineuvm_map_hint(p, prot) uvm_map_hint1(p, prot, 1)
+vaddr_tuvm_map_hint1(struct proc *, vm_prot_t, int);
intuvm_map_inherit(vm_map_t, vaddr_t, vaddr_t, vm_inherit_t);
intuvm_map_advice(vm_map_t, vaddr_t, vaddr_t, int);
void uvm_map_init(void);
Index: uvm_mmap.c
===
RCS file: /home/tedu/cvs/src/sys/uvm/uvm_mmap.c,v
retrieving revision 1.81
diff -u -r1.81 uvm_mmap.c
--- uvm_mmap.c 15 Dec 2010 04:59:53 - 1.81
+++ uvm_mmap.c 16 Dec 2010 02:44:37 -
@@ -604,6 +604,13 @@
error = uvm_mmap(p-p_vmspace-vm_map, addr, size, prot, maxprot,
flags, handle, pos, p-p_rlimit[RLIMIT_MEMLOCK].rlim_cur, p);
+ if (error == ENOMEM !(flags (MAP_FIXED | MAP_TRYFIXED))) {
+ /* once more, with feeling */
+ addr = uvm_map_hint1(p, prot, 0);
+ error = uvm_mmap(p-p_vmspace-vm_map, addr, size, prot,
+ maxprot, flags, handle, pos,
+ p-p_rlimit[RLIMIT_MEMLOCK].rlim_cur, p);
+ }
if (error == 0)
/* remember to add offset */
Re: uvm(9) clarifications wrt. uvm_km_alloc() / uvm_km_free()
On Fri, Dec 10, 2010 at 02:04:17PM +0100, Wouter Coene wrote: According to Ariane van der Steldt (ari...@stack.nl): On Thu, Dec 09, 2010 at 10:32:57PM +0100, Wouter Coene wrote: + addr = uvm_km_kmemalloc(kernel_map, NULL, PAGE_SIZE, + UVM_KMF_CANFAIL | UVM_KMF_ZERO); If you specify NULL as your object, you'll be given intr-safe memory. You want to use kernel object instead: Ah, now it makes sense. How about this diff: Index: uvm.9 === RCS file: /cvs/openbsd/src/share/man/man9/uvm.9,v retrieving revision 1.42 diff -u -a -r1.42 uvm.9 --- uvm.9 9 Nov 2010 16:03:38 - 1.42 +++ uvm.9 10 Dec 2010 13:00:05 - @@ -534,7 +534,12 @@ .Fa size bytes of wired memory in the kernel map, zeroing the memory if the .Fa zeroit -argument is non-zero. +argument is non-zero. Unless called on an interrupt-safe map, if memory is +currently unavailable, +.Fn uvm_km_alloc1 +may sleep to wait for resources to be released by other processes. If not +enough memory is available, this function returns +.Dv NULL . uvm_km_alloc1 may not be called with an intr-safe map. Only kmemalloc is capable of understanding them. And valloc can handle any map type, since it only allocates space, no backing store (physical pages) for the allocation. More on this matter below. .Pp The .Fn uvm_km_kmemalloc @@ -542,6 +547,10 @@ .Fa size bytes of wired kernel memory into .Fa obj . +.Fa obj +can only be +.Dv NULL +when allocating from an interrupt-safe map. That is correct. The flags can be any of: .Bd -literal #define UVM_KMF_NOWAIT 0x1 /* matches M_NOWAIT */ @@ -608,9 +617,9 @@ bytes of memory in the kernel map, starting at address .Fa addr . .Fn uvm_km_free_wakeup -calls -.Fn thread_wakeup -on the map before unlocking the map. +wakes up any processes waiting for memory on the map (via +.Fn thread_wakeup ) +before unlocking the map. That is also correct. .Sh ALLOCATION OF PHYSICAL MEMORY .nr nS 1 .Ft struct vm_page * Also, maybe a stupid question, but why doesn't the irq-safety of the allocation depend on the VM_MAP_INTRSAFE flag, like for uvm_km_free()? It should. In fact, I don't think there is more than 1 kernel object, but I'd have to verify. Strictly speaking, uvm_km should do: [1] allocation and freeing of kernel memory [2] submap management [3] support the intr-safe mapping of single pages (which is special because some archs are pmap_direct archs). [4] initialize kernel memory Task 4 is implemented in uvm_km_init. Task 3 is managed by uvm_km_getpage, uvm_km_putpage. This works well and is clean. Non-pmap-direct archs get a lot of support code to create the correct behaviour. Task 2 is trivial and lives in uvm_km_suballoc. After splitting off these functions, you get, for task 1, uvm_km_free* for freeing (2 functions), page management (uvm_km_pgremove*) and allocators... uvm_km_kmemalloc (via a define in uvm/uvm_extern.h) uvm_km_kmemalloc_pla uvm_km_alloc1 uvm_km_valloc uvm_km_valloc_try uvm_km_valloc_align uvm_km_valloc_prefer_wait uvm_km_valloc_wait uvm_km_zalloc (via a define in uvm/uvm_extern.h) uvm_km_alloc (via a define in uvm/uvm_extern.h) This gives you 10 ways of allocating kernel memory. uvm_km_kmemalloc is the most versatile. The only special case are the _wait allocation functions: uvm_km_kmemalloc would need an additional flag to duplicate their behaviour. There's too many allocation functions and it's too easy to get confused. They need to be reduced (point 3 on my todo list). Only uvm_km_kmemalloc can handle intr-safe maps. Wired memory simply means that the memory will be there during interrupts, but only intr-safe maps can be used to allocate from during interrupt time. And the reason the intr-safe map is safe is because the caller protects the map against other cpus and interrupts. I hope this help you, -- Ariane
Re: slower logins
I don't mind this if the eventual goal is to think about diddling with
it per arch..
I certainly do NOT want a 2^11 blowfish password when logging into my sparc
On 15 December 2010 21:33, Ted Unangst ted.unan...@gmail.com wrote:
On Wed, 15 Dec 2010, Ted Unangst wrote:
These values have not marched forward with the progress of time. For
perspective, the last increase in bcrypt rounds was around the time we
considered Monica Lewinsky a big scandal.
OK, so let's table what the right values and just make the values
configurable. Then we can discuss moving up (or even down).
Index: login.conf.in
===
RCS file: /home/tedu/cvs/src/etc/login.conf.in,v
retrieving revision 1.2
diff -u -r1.2 login.conf.in
--- login.conf.in 9 Jan 2007 10:20:12 - 1.2
+++ login.conf.in 16 Dec 2010 04:28:42 -
@@ -46,7 +46,7 @@
:maxproc-c...@def_maxproc_cur@:\
:openfiles-c...@def_openfiles_cur@:\
:stacksize-cur=4M:\
- :localcipher=blowfish,6:\
+ :localcipher=blowfish,@DEF_BLOWFISH_RNDS@:\
:ypcipher=old:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:
@@ -62,7 +62,7 @@
:maxproc=infinity:\
:openfiles-cur=128:\
:stacksize-cur=8M:\
- :localcipher=blowfish,8:\
+ :localcipher=blowfish,@ROOT_BLOWFISH_RNDS@:\
:tc=default:
#
Index: mklogin.conf
===
RCS file: /home/tedu/cvs/src/etc/mklogin.conf,v
retrieving revision 1.4
diff -u -r1.4 mklogin.conf
--- mklogin.conf24 Mar 2009 20:34:51 - 1.4
+++ mklogin.conf16 Dec 2010 04:30:28 -
@@ -19,6 +19,8 @@
values[STAFF_MAXPROC_MAX]=512
values[STAFF_MAXPROC_CUR]=128
values[STAFF_OPENFILES_CUR]=128
+ values[DEF_BLOWFISH_RNDS]=6
+ values[ROOT_BLOWFISH_RNDS]=8
# Optional overrides
if (ARGC 1) {
