On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
The in libc the rc4 state is only initialized once at the first call of
arc4_stir() and then there are consecutive calls to arc4_addrandom() which
is the equivalent of rc4_crypt(). So, there is a difference in the
implementation.
On Wed, Dec 22, 2010 at 08:28:51AM +0300, Vadim Zhukov wrote:
On 21 December 2010 G. 22:59:22 Theo de Raadt wrote:
Go look at the function random_seed() in /usr/src/etc/rc
And it's definitely worth looking... Patch below.
Believe it or not, but this diff has been circling around developers
On Tue, Dec 21, 2010 at 05:59:33PM +0100, Kurt Knochner wrote:
Hi,
upfront: sorry for double posting!! Some people told me, that I should send
my findings directly to the list instead of a link. Sorry if I violated the
netiquette on the list!
So, here we go again (text from the forum
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
2010/12/21 Otto Moerbeek o...@drijf.net
So, there is a lot of effort in get_random_bytes() to get real random
data
for the buffer and then the value of nanotime() is prepended to the
buffer?
That does not look right
On Tue, Dec 21, 2010 at 08:36:35PM +0100, Kurt Knochner wrote:
2010/12/21 Otto Moerbeek o...@drijf.net:
get_random_bytes() calls extract_entropy() which is a a loop around nbytes,
thus get_random_bytes() will most certainly deliver enough entropy.
extract_entropy() does not guarantee
On Tue, Dec 21, 2010 at 11:08:29PM -0700, Anthony J. Bentley wrote:
Hi,
This looks like a typo, almost changes the meaning of the sentence:
Index: lib/libc/stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
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
On Tue, Nov 16, 2010 at 01:04:48PM +0300, Vadim Zhukov wrote:
2010/11/16 Vadim Zhukov persg...@gmail.com:
2010/11/16 Stuart Henderson s...@spacehopper.org:
On 2010/11/16 04:50, Vadim Zhukov wrote:
[..]
Great stuff, this has annoyed me for a while :) I can't test today but
will try
On Tue, Nov 09, 2010 at 08:17:59AM +0100, Markus Bergkvist wrote:
On 11/09/10 03:27, Philip Guenther wrote:
On Mon, Nov 8, 2010 at 4:10 PM, Christiano F. Haesbaert
haesba...@haesbaert.org wrote:
I must be doing something really silly but it seems waitpid ends up
returning -1 if WNOHANG is
Hi,
Make who(1) a tiny bit smarter and show more of the host part. Max
linewidth is 80.
-Otto
Index: who.c
===
RCS file: /cvs/src/usr.bin/who/who.c,v
retrieving revision 1.18
diff -u -p -r1.18 who.c
--- who.c 27 Oct
On Wed, Nov 03, 2010 at 01:18:51PM +0200, Alexey Suslikov wrote:
Hello t...@.
On OpenBSD/amd64, doing something like
char *buf = mmap(NULL, len + 1, PROT_READ | PROT_WRITE,
MAP_PRIVATE, some.fd, 0);
buf[len] = '\0';
causes segfault on buf[len] = '\0' assignment if len = 16384.
On Wed, Nov 03, 2010 at 01:12:20PM +0100, Otto Moerbeek wrote:
On Wed, Nov 03, 2010 at 01:18:51PM +0200, Alexey Suslikov wrote:
Hello t...@.
On OpenBSD/amd64, doing something like
char *buf = mmap(NULL, len + 1, PROT_READ | PROT_WRITE,
MAP_PRIVATE, some.fd, 0);
buf[len
;
}
So if ftell() returns value of l exactly at the end of file, accessing
l + 1 leads to segfault while mmaping l + 1 is ok, right?
Right. And if l is on a page boundary, you have a problem.
-Otto
On Wed, Nov 3, 2010 at 14:23, Otto Moerbeek o...@drijf.net wrote:
On Wed, Nov
fine and works for me.
Good, I'm committing a different version.
-Otto
On Wed, Oct 20, 2010 at 09:27:50AM +0200, Otto Moerbeek wrote:
Hi,
when feeding free(3) or realloc(3) a bogus or already free pointer, it
helps to see the actual pointer. So here's a diff to do
On Thu, Oct 21, 2010 at 10:06:23AM +0200, Otto Moerbeek wrote:
On Wed, Oct 20, 2010 at 07:59:27PM +0100, Nicholas Marriott wrote:
I like it a lot.
Although I don't see much point in NBBY :-).
Couldn't you print the failing pointer on the other realloc messages? I
guess it may
Hi,
when feeding free(3) or realloc(3) a bogus or already free pointer, it
helps to see the actual pointer. So here's a diff to do that.
Typical output:
a.out in free(): error: bogus pointer (double free?) 0x1234567890abcdef
Please test review,
-Otto
Index: stdlib/malloc.c
On Wed, Oct 20, 2010 at 09:27:50AM +0200, Otto Moerbeek wrote:
Hi,
when feeding free(3) or realloc(3) a bogus or already free pointer, it
helps to see the actual pointer. So here's a diff to do that.
Typical output:
a.out in free(): error: bogus pointer (double free
On Thu, Oct 14, 2010 at 11:33:19AM -0400, Randy Lewis wrote:
Using new 4.7 install with Dell Poweredge 850, Pentium-D, 1G Ram,
80GB root drive...works great.
Added 2nd SATA drive, 2TB size.
.
Fdisk -i - OK
Disklabel, a partition (offset 63, normal), maximum size selected, etc.
Tried
On Thu, Sep 23, 2010 at 06:14:10PM +, Thordur Bjornsson wrote:
On Thu, Sep 23, 2010 at 06:36:43PM +0059, Jason McIntyre wrote:
is there a reason why we don;t document FSTAB_RQ?
Not one that I can think of. If this works as intended
go ahead (it should).
I don't think getmntoptions()
On Wed, Aug 25, 2010 at 11:57:36AM +0300, Gregory Edigarov wrote:
On Mon, 23 Aug 2010 07:30:25 +0200
Jakob Schlyter ja...@openbsd.org wrote:
On 23 aug 2010, at 04.16, patrick keshishian wrote:
Is the idea to replace bind altogether from base? If so, my initial
searching shows NSD
On Fri, Aug 13, 2010 at 01:26:37PM +0200, Gabriel Linder wrote:
This diff implements history for bc(1) using editline(3).
History is not persistent, I can add this feature if needed.
el_init with stderr should not be a problem for an interactive program,
let me know otherwise.
This is
On Sun, Aug 08, 2010 at 09:11:46PM -0400, Brad wrote:
At the moment the malloc(3) page does not mention what malloc options
are actually being enabled if using the S option and it is a shortcut
to enable the 3 existing options.
Why document this? The idea is: just use S unless you have some
On Mon, Apr 19, 2010 at 02:34:55PM +0300, Gregory Edigarov wrote:
Hello,
This diff adds possibility for the network interfaces to have an arbitrary
names.
this is done via ifconfig oldname name newname
Please test.
Thank you.
--- /usr/src/sys/net/if.c.origSat Apr 17
On Wed, Apr 14, 2010 at 12:14:13PM +, Paul Stoeber wrote:
The command
cat /dev/zero | dd bs=1000 count=2
doesn't always produce the desired number of bytes.
Is this supposed to happen?
Yes, I think so. Reading from a pipe may turn up a block of data
smaller than requested. To
On Thu, Apr 01, 2010 at 09:56:19AM -0600, Bob Beck wrote:
stupid idea, perhaps, but would it be possible to recycle the idea of
having some sort of canaries at the end of *each* page, thus disposing
of the need to have guard pages? Or would that be too costly?
Oh sure, that'll work Ok,
Read http://www.openbsd.org/faq/current.html
-Otto
On Fri, Mar 26, 2010 at 03:11:24PM +0530, Amarendra Godbole wrote:
As indicated in /usr/src/Makefile, I am trying to take the obj
directory outside of the source. Quoting Makefile:
# 2) It is also recommended that you compile with
On Wed, Mar 03, 2010 at 01:17:17AM -0800, J.C. Roberts wrote:
Unfortunately, the following statement is not true:
If no file systems are given to fsck_ffs then a default list of
file sys- tems is read from the file /etc/fstab.
To test, boot single user and run
#
On Wed, Mar 03, 2010 at 02:59:23AM -0800, J.C. Roberts wrote:
On Wed, 3 Mar 2010 11:36:28 +0100 Otto Moerbeek o...@drijf.net wrote:
If fsck_ffs is *supposed* to read /etc/fstab like fsck does, then
the problem is in the code.
fsck_ffs is not supposed to read fstab, so this line
On Mon, Feb 08, 2010 at 09:06:21AM -0500, Sean Kennedy wrote:
Moving this to m...@...
Would part of this discussion usefully related to such issues like using 'dd'
for diskwipes/copies/reformatting and slow data movement speeds?
There are times when I am wiping (for reuse) hard disks
On Sun, Feb 07, 2010 at 01:59:33PM -0500, Brad Tilley wrote:
I wrote a small cpp application to generate randomish passwords. It compiles
and runs OK on OpenBSD, however, it does not seem to create random strings
(the first and last chars seldom ever change, etc). The same code compiles
On Sun, Feb 07, 2010 at 10:42:40PM +0300, Vadim Zhukov wrote:
On 7 February 2010 c. 21:59:33 Brad Tilley wrote:
I wrote a small cpp application to generate randomish passwords. It
compiles and runs OK on OpenBSD, however, it does not seem to create
random strings (the first and last chars
On Sun, Feb 07, 2010 at 12:26:43PM -0800, Philip Guenther wrote:
On Sunday, February 7, 2010, Otto Moerbeek wrote:
That is still wrong for this purpose. Although random(3) is a better
random number generator than rand, is still a cryptographic weak
generator.
Better use arc4random
On Sun, Feb 07, 2010 at 03:39:25PM -0500, Brad Tilley wrote:
On Sun, 07 Feb 2010 21:32 +0100, Otto Moerbeek o...@drijf.net wrote:
On Sun, Feb 07, 2010 at 12:26:43PM -0800, Philip Guenther wrote:
On Sunday, February 7, 2010, Otto Moerbeek wrote:
That is still wrong
On Fri, Feb 05, 2010 at 09:24:30PM -0500, Ted Unangst wrote:
Though for a program like cp, this may qualify as a big diff. :)
Continuing in my make IO suck less phase, cp would be a lot more
efficient if it didn't bounce the disk heads around so much. Instead of
using a tiny 64k buffer,
On Sat, Feb 06, 2010 at 12:58:21PM -0500, Ted Unangst wrote:
On Sat, Feb 6, 2010 at 9:53 AM, Otto Moerbeek o...@drijf.net wrote:
The buffer cache should ne smart enough to optmize read and writes in
such large chunks so that the seeking gets reduced. The problem with
How? cp reads 64k
On Thu, Jan 28, 2010 at 03:25:21AM -0500, Daniel Dickman wrote:
Note: the patch below is NOT recommended for 4.7 as this will change
the semantics of fts_open and will BREAK things like gzip - and
possibly other stuff.
Calls to fts_open should probably be audited first...
yes, this is
On Fri, Jan 15, 2010 at 10:21:15PM -0500, Ted Unangst wrote:
On Fri, Jan 15, 2010 at 1:21 PM, Denis Doroshenko
denis.doroshe...@gmail.com wrote:
I'd like to give some colleagues possibility to analyze and dump net
traffic to files, but it seems that in order to do that I need to
allow
On Mon, Dec 14, 2009 at 01:58:34PM +0100, Otto Moerbeek wrote:
On Mon, Dec 14, 2009 at 01:54:50PM +0100, Otto Moerbeek wrote:
On Mon, Dec 14, 2009 at 07:44:31AM -0500, Ted Unangst wrote:
On Mon, Dec 14, 2009 at 3:58 AM, Otto Moerbeek o...@drijf.net wrote:
apart from the random page
On Wed, Dec 02, 2009 at 10:38:10AM +0100, Otto Moerbeek wrote:
Hi,
apart from the random page addresses obtained form mmap(2) malloc(3)
itself also randomizes cache en chunk operations. It uses a nibble of
randomness per call, so optimize that to not waste half the random
bits.
Please
On Mon, Dec 14, 2009 at 07:44:31AM -0500, Ted Unangst wrote:
On Mon, Dec 14, 2009 at 3:58 AM, Otto Moerbeek o...@drijf.net wrote:
apart from the random page addresses obtained form mmap(2) malloc(3)
itself also randomizes cache en chunk operations. It uses a nibble of
randomness per call
On Wed, Dec 09, 2009 at 09:53:55AM +0100, Mark Kettenis wrote:
Date: Tue, 08 Dec 2009 23:27:01 -0700
From: Theo de Raadt dera...@cvs.openbsd.org
On Mon, Dec 07, 2009 at 12:50:33AM -0500, Ted Unangst wrote:
Fortunately, help is on the way. Patch below combines all cpu
states
Hi,
apart from the random page addresses obtained form mmap(2) malloc(3)
itself also randomizes cache en chunk operations. It uses a nibble of
randomness per call, so optimize that to not waste half the random
bits.
Please test, should be a bit faster.
-Otto
Index: malloc.c
On Thu, Nov 26, 2009 at 10:30:26AM +0100, Martin Hedenfalk wrote:
26 nov 2009 kl. 07.26 skrev Nick Guenther:
fts(3) says in the intro:
It is possible to walk the hierarchy ``logically'' (ignoring symbolic
links) or physically (visiting symbolic links), order the walk of the
Hi,
I've been working on a malloc diff after being prompted by Fabien
Romano and Jonathan Armani that there are cases where malloc's
performance is quite bad. These cases occur when freeing lots (and i
mean lots) of small allocation in random or reverse order they were
allocated, and gets worse
On Fri, Oct 23, 2009 at 12:05:20AM -0700, patrick keshishian wrote:
On Sun, Oct 18, 2009 at 03:50:17PM -0700, Philip Guenther wrote:
On Sun, Oct 18, 2009 at 12:49 AM, Matt Fisher mfisher...@maine.rr.com
wrote:
You're correct. I got started on this train of thought after reading
an old
On Sun, Oct 18, 2009 at 03:50:17PM -0700, Philip Guenther wrote:
On Sun, Oct 18, 2009 at 12:49 AM, Matt Fisher mfisher...@maine.rr.com wrote:
You're correct. I got started on this train of thought after reading
an old USENIX paper[1]. The line I suggested for deletion is identical
to what
On Mon, Oct 19, 2009 at 10:31:11AM +0200, Otto Moerbeek wrote:
On Sun, Oct 18, 2009 at 03:50:17PM -0700, Philip Guenther wrote:
On Sun, Oct 18, 2009 at 12:49 AM, Matt Fisher mfisher...@maine.rr.com
wrote:
You're correct. I got started on this train of thought after reading
an old
On Sat, Oct 17, 2009 at 08:45:39PM -0700, Philip Guenther wrote:
[snip]
If they lack research like this one, I don't want to see them either.
Thanks Philip, you just wrote what I was going to write.
Any diff, and signal diffs even more so, requires understanding of
what you are changing.
On Fri, Jun 12, 2009 at 07:23:29PM +0200, Artur Grabowski wrote:
Otto Moerbeek o...@drijf.net writes:
AFAIK the whole work was done to make the cache more sane. The current
version is just insane enough that Bob was crying, shouting and playing
with red wine bottles during c2k9
On Thu, Jun 11, 2009 at 03:51:12PM -0600, Bob Beck wrote:
I could use some assistance in testing this, particularly on some of
the more odd archetectures.
This diff makes a bunch of changes to the vfs name cache:
1) it gets rid of the global hash table and reverse hash
On Wed, May 13, 2009 at 02:16:49PM +0200, Mark Kettenis wrote:
Date: Wed, 13 May 2009 12:20:44 +0200
From: Otto Moerbeek o...@drijf.net
On Wed, May 13, 2009 at 12:11:35PM +0200, Peter J. Philipp wrote:
On Wed, May 13, 2009 at 10:40:13AM +0200, Otto Moerbeek wrote:
Come to think
On Wed, May 13, 2009 at 03:18:05PM +0200, Mark Kettenis wrote:
Date: Wed, 13 May 2009 14:28:06 +0200
From: Otto Moerbeek o...@drijf.net
On Wed, May 13, 2009 at 02:16:49PM +0200, Mark Kettenis wrote:
Date: Wed, 13 May 2009 12:20:44 +0200
From: Otto Moerbeek o...@drijf.net
801 - 852 of 852 matches
Mail list logo
