| Mark Kettenis | Re: increase i386 data size
You mean, in the kernel? There the limits are stored in rlim_t, which
is a 64-bit type on all our architectures. There is one comparison in
uvm_mmap.c that had me worried for a bit:
if (size >
(p->p_rlimit[RLIMIT_DATA].rlim_cur - ptoa(p->p_vmspace->vm_dused))) {
but this is safe since ptoa() casts to paddr_t, which is unsigned long.
There is also 'struct orlimit' in <sys/resource.h>, which is used for
BSD4.3 compat code in compat/common/kern_resource_43.c. But
RLIMIT_DATA ...
| Dec 24, 3:50 pm 2010 |
| Ted Unangst | increase i386 data size
increase the hard limit on i386 max data size to 2GB-1. This will allow
memory hungry processes to potentially use more RAM if you increase data
limits appropriately.
Index: vmparam.h
===================================================================
RCS file: /home/tedu/cvs/src/sys/arch/i386/include/vmparam.h,v
retrieving revision 1.45
diff -u -r1.45 vmparam.h
--- vmparam.h 15 Dec 2010 05:30:19 -0000 1.45
+++ vmparam.h 24 Dec 2010 21:52:07 -0000
@@ -63,7 +63,7 @@
...
| Dec 24, 2:54 pm 2010 |
| Ted Unangst | Re: increase i386 data size
On Fri, Dec 24, 2010 at 5:02 PM, Mark Kettenis <mark.kettenis@xs4all.nl>
Anyone who stores the limit in a signed int (or long). Do I know of
any such software? No. Am I willing to risk the possibility of such
existing to squeeze out a few more bytes? No.
I will happily set it to straight 2GB, or even higher if we don't care
about possible trouble, so long as everybody promises not to complain
if an issue is found. :)
| Dec 24, 3:14 pm 2010 |
| Ted Unangst | Re: increase i386 data size
To phrase it another way, I was actually hoping that by avoiding the
"what about overflow?" worries, we could move forward faster. If
that's not a worry, great, I just didn't want to get tied down.
| Dec 24, 3:17 pm 2010 |
| Mark Kettenis |
| Dec 24, 3:02 pm 2010 |
| Ted Unangst | Re: compat_bsdos leftover
On Fri, Dec 24, 2010 at 12:10 PM, Vladimir Kirillov <proger@uaoug.org.ua>
Thanks, I removed it. I left NLDT at 17, though, because there
doesn't appear to be much benefit in shrinking that vs whatever weird
| Dec 24, 1:27 pm 2010 |
| Vladimir Kirillov | compat_bsdos leftover
Hi!
I guess the following is the leftover.
Index: include/segments.h
===================================================================
RCS file: /cvs/src/sys/arch/i386/include/segments.h,v
retrieving revision 1.17
diff -u -p -r1.17 segments.h
--- include/segments.h 1 Jul 2010 17:30:27 -0000 1.17
+++ include/segments.h 24 Dec 2010 17:09:07 -0000
@@ -228,7 +228,6 @@ void idt_vec_free(int);
/*
* Entries in the Local Descriptor Table (LDT)
*/
-#define LBSDICALLS_SEL 16 /* BSDI system ...
| Dec 24, 10:10 am 2010 |
| Ted Unangst | Re: compat_bsdos leftover
From a brief look, eliminating the default entirely just makes things more
complicated, but we can shrink it down to 1. I switched things over to
using malloc instead of uvm_km_alloc because there's no reason to allocate
full pages for tiny things.
This will need more testing, of course.
Index: i386/machdep.c
===================================================================
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.485
diff -u -r1.485 machdep.c
--- ...
| Dec 24, 2:41 pm 2010 |
| Mark Kettenis | Re: compat_bsdos leftover
Well, changing NLDT to 17 should defenitely be tested, but leaving it
at 17 is a bit odd. I'm actually wondering whether the default LDT is
necessary at all now that LBSDICALLS_SEL is gone. Then NLDT can go
completely.
| Dec 24, 1:45 pm 2010 |
| Luis Useche | pkg_delete recursive uninstall option
Hi Guys,
I implemented this option for the pkg_delete that remove all the 'non-used'
dependencies of all packages you are deleting. It first check that the
package is not a dependency of another installed package and it was not
installed manually.
I sent an email about this a long time ago but I guess it didn't have too
much attention. At some point @espie ask me to hold it for some time and
re-submit later. This is the discussion:
http://marc.info/?l=openbsd-misc&m=124939917102094&w=2
I ...
| Dec 24, 9:43 am 2010 |
| Vladimir Kirillov | cleanup i386 pmap_fork()
Hello tech@!
I guess there's no need to acquire pmap locks when there's nothing
to do (USER_LDT unset). s/if defined/ifdef/ for consistency.
Index: pmap.c
===================================================================
RCS file: /cvs/src/sys/arch/i386/i386/pmap.c,v
retrieving revision 1.151
diff -u -p -r1.151 pmap.c
--- pmap.c 30 Nov 2010 19:28:59 -0000 1.151
+++ pmap.c 24 Dec 2010 16:40:47 -0000
@@ -1567,7 +1567,7 @@ pmap_reference(struct pmap *pmap)
...
| Dec 24, 9:42 am 2010 |
| Ted Unangst | Re: cleanup i386 pmap_fork()
PMAP_FORK and USER_LDT are only ever set together, and the
simple_locks don't do anything anyway. I guess we could just delete
the USERLDT checks if we wanted to clean it up.
| Dec 24, 2:45 pm 2010 |
| Mark Kettenis |
| Dec 24, 3:00 pm 2010 |
| Philip Guenther | Re: cleanup i386 pmap_fork()
On Fri, Dec 24, 2010 at 2:00 PM, Mark Kettenis <mark.kettenis@xs4all.nl>
I agree with Mark. If something is going to be deleted, it should be
those misleading simple_locks.
Philip
| Dec 24, 4:52 pm 2010 |
| Henri Kemppainen | Add back-to-indentation (M-m) for mg
This adds the command that moves the dot to the first non-whitespace
character on the line.
Index: src/usr.bin/mg/def.h
===================================================================
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.113
diff -u -p -r1.113 def.h
--- src/usr.bin/mg/def.h 30 Jun 2010 19:12:54 -0000 1.113
+++ src/usr.bin/mg/def.h 22 Dec 2010 16:12:15 -0000
@@ -511,6 +511,7 @@ int indent(int, int);
int forwdel(int, int);
int backdel(int, int);
int ...
| Dec 24, 6:28 am 2010 |
| Stefan Sperling |
| Dec 24, 4:43 am 2010 |
| Kenneth R Westerback | Re: upgrade and fsck
I like the question. ok krw@ for that. I also always type 'n' to
that question, but I go back and forth on changing the default.
| Dec 24, 9:10 am 2010 |
| Otto Moerbeek | upgrade and fsck
Hi,
It has been a looooong time since a saw an incosistent fs with the clean
flag set. So default to no and rephrase a litle to make it clearer.
-Otto
Index: install.sub
===================================================================
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.631
diff -u -p -r1.631 install.sub
--- install.sub 22 Nov 2010 14:10:42 -0000 1.631
+++ install.sub 24 Dec 2010 09:03:12 -0000
@@ -1727,7 +1727,7 @@ getdevname() {
check_fs() {
...
| Dec 24, 2:05 am 2010 |
| David Gwynne | timeout io on mpii(4)
i can reliably produce a situation where an io on a disk attached
to mpii(4) never completes. this implements timeouts on scsi io so
we can recover from this situation.
ok?
Index: mpii.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/mpii.c,v
retrieving revision 1.35
diff -u -p -r1.35 mpii.c
--- mpii.c 23 Aug 2010 00:53:36 -0000 1.35
+++ mpii.c 24 Dec 2010 06:04:38 -0000
@@ -1757,7 +1757,8 @@ struct mpii_ccb {
volatile enum {
...
| Dec 23, 11:09 pm 2010 |
| Marco Peereboom |
| Dec 24, 8:07 am 2010 |
| David Gwynne | working hotplug for busy devices on mpii(4)
hi guys,
this makes mpii properly detach devices, which helps a lot if they
have commands in flight. to relevant changes are:
- call the activate(DVACT_DEACTIVATE) function against all the luns
on the target that is going away.
- issue the target reset BEFORE detaching the children devices.
this is needed now tha the midlayer will sleep until all outstanding
commands on a device come back from the adapter before calling the
child devices attach routine.
i have tested this on straight ...
| Dec 23, 11:01 pm 2010 |
| Kenneth R Westerback |
| Dec 24, 9:44 am 2010 |
| Mallena | Merry XxXMass
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
This offer is reserved to adults.
By clicking on any of the links in this mail, you certify that you are
over 18.
| Dec 23, 6:12 pm 2010 |
| martin tarb | Re: Allegations regarding OpenBSD IPSEC
Actually, when I would design such a backdoor, I wouldn't go for the item
getting highest attention and most difficult to crack. And because the crypto
stuff is getting most attention, it's highly likely it'll be replaced every now
and then with something "better": Backdoor gone.
I would do a "social engineering". Challenge the IPSec stack to tell me what I
want to know.
How:
- Try to setup a connection with the server you want to have the keys from.
- Make a "failure" with this ...
| Dec 24, 12:27 pm 2010 |
| martin tarb | Re: Allegations regarding OpenBSD IPSEC
Yep, I did see that one, though that one does focus on (intentional) bugs in the
the main crypto stuff, and my suggestion is that's not the location where to
look for backdoors.
To obvious, to complicated, to much coding required to realize something
usefull, etc.
There is no need to "break" the crypto stuff, if you can convince the IPSec
stack to send you the keys. When you do have the keys, the only thing you have
to do is decode the recorded crypted stream. When you are the FBI, ...
| Dec 24, 12:53 pm 2010 |
| Otto Moerbeek | Re: Allegations regarding OpenBSD IPSEC
Huh, I quote:
"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:"
What you describe above is one of the ways Damien mentions (as I read
it): "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 "
Note the reuse of mbus will have the effect of sending key material to
the ...
| Dec 24, 1:09 pm 2010 |
| martin tarb | Re: Allegations regarding OpenBSD IPSEC
Yeah, the words network stack and crafted packet are there, though the rest is
significantly different. It's all network stack and the ICMP thing does focus on
randomly probing for a potentially not-cleared buffer, ie intentional failures
in the encryption.
What I try to make clear: Don't focus on the encryption stuff, no need to
break that, nor focus on the used buffers, etc. Just look what the STATE
MACHINE in the IPSEC network stack (or if you want: What the state machine in
the ...
| Dec 24, 1:56 pm 2010 |
| Otto Moerbeek |
| Dec 24, 12:38 pm 2010 |
