Re: CVS commit: src/sys/arch/sparc64
On Mon, Jun 24, 2013 at 10:41:11AM +0900, Takeshi Nakayama wrote: > It seems sparc64's MD codes don't treat about kpreempt, so I didn't > care about kpreempt. Yet - but this will change. Martin
Re: CVS commit: src/lib/libc/string
Oops, that was silly of me -- the libc symbols actually have a double- underscore prefix, presumably meaning `these are internal; do not use'. Should I move the man pages to section 9, or do we want these exposed in libc, presumably requiring some weak aliasing cruft? Discuss on tech-userlevel? (Now it seems I am railroading ahead with these changes, sorry...)
Re: CVS commit: src/lib/libc/string
Date: Mon, 24 Jun 2013 01:36:29 + (UTC) From: chris...@astron.com (Christos Zoulas) I've objected many times railroading those in and casting the into stone by adding man pages and making them part of a formal release. I give up :-( Sorry, I didn't mean to stonewall or railroad anything; I just didn't want to volunteer to go through the whole tree and replace every reference and break all the builds with my inevitable mistakes in the process. But OK -- I'll see whether I can sed my way through this tonight without breaking too much.
Re: CVS commit: src/sys/arch/sparc64
>>> matthew green wrote > > i'm curious - what were you going to trigger this problem? Discussion about bge driver in last month's port-sparc64. I have known this method since I was adding a cardbus support to sparc64 a decade ago. But I adopted the method checking a OFW's node instead of it. I've been meaning to implement it if I have a chance. > > Module Name:src > > Committed By: nakayama > > Date: Fri Jun 21 20:09:59 UTC 2013 > > > > Modified Files: > > src/sys/arch/sparc64/dev: psycho.c pyro.c schizo.c > > src/sys/arch/sparc64/include: cpu.h > > src/sys/arch/sparc64/sparc64: trap.c > > > > Log Message: > > Avoid data_access_error trap panic when reading unused PCI > > configuration space. > > > > This method is described in UltraSPARC IIi User's Manual "16.2.1 > > Probing PCI during boot using deferred errors", and refer to the > > implementation of OpenBSD. > > hmmm, i wonder if kpreempt_disable()/enable() should go > around these calls now. we don't want these accesses > to migrate to another cpu in the middle .. > > i don't think there's any reason pci_conf_* have to be > called in a context that has kpreempt already disabled. It seems sparc64's MD codes don't treat about kpreempt, so I didn't care about kpreempt. Thanks, -- Takeshi Nakayama
Re: CVS commit: src/lib/libc/string
In article <20130623164406.d678...@cvs.netbsd.org>, Taylor R Campbell wrote: >-=-=-=-=-=- I've objected many times railroading those in and casting the into stone by adding man pages and making them part of a formal release. I give up :-( christos
Re: CVS commit: src
On Jun 23, 4:14pm, riastr...@netbsd.org (Taylor R Campbell) wrote: -- Subject: Re: CVS commit: src | I don't care if we rename them to consttime_memeq and explicit_memzero | instead, but these are absolutely the operations that real crypto | applications need. consttime_memcmp and explicit_memset are not, and | are needlessly complicated. Only memcmp, memset to a value is easy. How about consttime_memequal() and explicit_memset()? | How do the attached man pages look? We ought to add cross-references | in memcmp(3) and memset(3) too, perhaps. The attached pages look fine, but still refer to interfaces I'd rather not add. christos
Re: CVS commit: src
On Sun, Jun 23, 2013 at 04:14:32PM +, Taylor R Campbell wrote: > How do the attached man pages look? We ought to add cross-references > in memcmp(3) and memset(3) too, perhaps. They look fine. And please do add the cross references too. Thanks for writing these! Thomas
Re: CVS commit: src
Date: Sun, 23 Jun 2013 14:31:25 + (UTC)
From: chris...@astron.com (Christos Zoulas)
In article <20130623142023.6e4c760...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>We ought to have a man page for explicit_bzero and consttime_bcmp.
>I didn't realize we lacked one since they were added last year.
We should not be creating new interfaces based on obsolete ones. I'd
rather we have consttime_memcmp() and explicit_memset().
I don't care if we rename them to consttime_memeq and explicit_memzero
instead, but these are absolutely the operations that real crypto
applications need. consttime_memcmp and explicit_memset are not, and
are needlessly complicated.
How do the attached man pages look? We ought to add cross-references
in memcmp(3) and memset(3) too, perhaps.
.\" $NetBSD$
.\"
.\" Copyright (c) 2013 The NetBSD Foundation, Inc.
.\" All rights reserved.
.\"
.\" This documentation is derived from text contributed to The NetBSD
.\" Foundation by Taylor R. Campbell.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"notice, this list of conditions and the following disclaimer in the
.\"documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
.\" POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd June 23, 2013
.Dt EXPLICIT_BZERO 3
.Os
.Sh NAME
.Nm explicit_bzero
.Nd guarantee zeroing a buffer in memory
.Sh LIBRARY
.Lb libc
.Sh SYNOPSIS
.In string.h
.Ft void
.Fn explicit_bzero "void *ptr" "size_t len"
.Sh DESCRIPTION
The
.Fn explicit_bzero
function writes
.Fa len
zeros to the memory pointed to by
.Fa ptr .
It is guaranteed not to be optimized away by the compiler even if
.Fa ptr
is no longer used and is about to be freed or go out of scope.
.Sh EXAMPLES
Create a buffer on the stack for a secret key, use it, and then zero it
in memory before throwing it away.
.Bd -literal -offset indent
void
f(void)
{
uint8_t key[32];
crypto_random(key, sizeof(key));
do_crypto_stuff(key, sizeof(key));
\&...
explicit_bzero(key, sizeof(key));
}
.Ed
.Sh SEE ALSO
.Xr consttime_bcmp 3 ,
.Xr memset 3
.Sh HISTORY
The
.Fn explicit_bzero
function appeared in
.Nx 7.0 .
.\" $NetBSD$
.\"
.\" Copyright (c) 2013 The NetBSD Foundation, Inc.
.\" All rights reserved.
.\"
.\" This documentation is derived from text contributed to The NetBSD
.\" Foundation by Taylor R. Campbell.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"notice, this list of conditions and the following disclaimer in the
.\"documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
.\" POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd June 23, 2013
.Dt CONSTTIME_BCMP 3
.Os
.Sh NAME
.Nm consttime_bcmp
.Nd compare byte strings for equality without timing leaks
.Sh LIBRARY
.Lb libc
.Sh SYNOPSIS
.In string.h
.Ft int
.Fn consttime_bc
Re: CVS commit: src
In article <20130623142023.6e4c760...@jupiter.mumble.net>, Taylor R Campbell wrote: > Date: Sun, 23 Jun 2013 10:22:12 +0200 > From: Thomas Klausner > > On Sun, Jun 23, 2013 at 02:35:24AM +, Taylor R Campbell wrote: > > rndsink(9): > > - Simplify API. > > - Simplify locking scheme. > > - Add a man page. > > mdoclint says: > rndsink.9:125: trailing Xref to explicit_bzero(3) > > I didn't find such a page either. Should this be added to bzero(3)? > >We ought to have a man page for explicit_bzero and consttime_bcmp. >I didn't realize we lacked one since they were added last year. We should not be creating new interfaces based on obsolete ones. I'd rather we have consttime_memcmp() and explicit_memset(). christos
Re: CVS commit: src
Date: Sun, 23 Jun 2013 10:22:12 +0200 From: Thomas Klausner On Sun, Jun 23, 2013 at 02:35:24AM +, Taylor R Campbell wrote: > rndsink(9): > - Simplify API. > - Simplify locking scheme. > - Add a man page. mdoclint says: rndsink.9:125: trailing Xref to explicit_bzero(3) I didn't find such a page either. Should this be added to bzero(3)? We ought to have a man page for explicit_bzero and consttime_bcmp. I didn't realize we lacked one since they were added last year.
Re: CVS commit: src
On Sun, Jun 23, 2013 at 02:35:24AM +, Taylor R Campbell wrote: > Module Name: src > Committed By: riastradh > Date: Sun Jun 23 02:35:24 UTC 2013 > > Modified Files: > src/sys/conf: files > src/sys/dev: rndpseudo.c > src/sys/kern: kern_rndq.c subr_cprng.c > src/sys/lib/libkern: arc4random.c > src/sys/rump/librump/rumpkern: Makefile.rumpkern cprng_stub.c > src/sys/sys: cprng.h rnd.h > src/usr.bin/fstat: misc.c > Added Files: > src/share/man/man9: rndsink.9 > src/sys/kern: kern_rndsink.c > src/sys/sys: rndsink.h > > Log Message: > Rework rndsink(9) abstraction and adapt arc4random(9) and cprng(9). > > rndsink(9): > - Simplify API. > - Simplify locking scheme. > - Add a man page. mdoclint says: rndsink.9:125: trailing Xref to explicit_bzero(3) I didn't find such a page either. Should this be added to bzero(3)? Thomas
