Re: Patch: cprng_fast performance - please review.
On Fri, Apr 18, 2014 at 08:23:11PM +0200, Markku-Juhani Olavi Saarinen wrote: > > Agreed. AES is worse if you don't have AES-NI. > > It has been there on all new systems purchased in some last 3 years, > so I would *guess* that it would be > 50% of systems fielded out > there. It hasn't been there on all new systems purchased in the last 3 years. My laptop is about 3 years old and doesn't have AES-NI. Neither does my file server (1.5 years old, AMD CPU, IIRC.) nor my mobile phone, iPad, last year's MacBook Air, etc. This is, of course, annecdotal evidence, but I do not think that I am an entirely atypical consumer and yet I do not think that I've ever owned a system with AES-NI. I do not think that it is nearly as prevalent as you believe. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: high load, no bottleneck
On Sat, Sep 28, 2013 at 05:56:50PM +1000, matthew green wrote: > > > ps: I had been meaning to rant like this for some time, your message just > > provided the incentive today! > > :-) > > i will note that i'm also a fan of using -o async FFS mounts in > the right place. i just wouldn't do it for a file server :-) I thought quite some time ago that it probably makes sense for us to make the installer mount everything async to extract the sets because, after all, if the install fails you are rather likely to simply re-install rather than manually figure out where it was and fix it. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: KNF and the C preprocessor
On Tue, Dec 11, 2012 at 08:28:51AM +, David Laight wrote:
>
> On Tue, Dec 11, 2012 at 06:10:09AM +, David Holland wrote:
> > On Tue, Dec 11, 2012 at 01:27:09AM +0000, Roland C. Dowdeswell wrote:
> > > As an example, I often define a macro when I am using Kerberos or
> > > GSSAPI that looks roughly like:
> > >
> > > #ifdef K5BAIL(x) do {
> > > ret = x;
> > > if (ret) {
> > > /* format error message and whatnot
> > > * in terms of #x.
> > > */
> > >
> > > goto bail;
> > > }
> > > } while (0)
> >
> > The code like this in src/sys/nfs is a reliably steady source of
> > problems, and I'd argue that macros of this form are not at all worth
> > the problems they cause.
>
> Absolutely, that is one construct I would ban.
> Encapsulating so you can do:
> if (K5BAIL(xxx(), "error text"))
> goto bail;
> Or even separating the function name (so it can be traced)
> at least leaves the flow control obvious.
> If you embed a goto (or return) in a #define you'd better have the
> defininition very close to the use.
Well, the theory is (whether you believe it or not) is that the
macro name is supposed to give the impression that it will ``bail''
which is commonly understood to mean jump to the cleanup code at
the bottom of the function. I would thus argue that it does more
or less leave the flow of control relatively obvious.
I do agree that the code in src/sys/nfs is not obvious but that
code already violate /usr/share/misc/style in many other ways,
such as not being capitalised, not being in a do { } while (0),
and so on.
All that said, I only really use this method when I'm using Kerberos
as pretty much every function can return an error and the code
otherwise tends to become less readable due to its length as each
function is mostly error handling which obscures what is actually
being done in the more likely successful case.
--
Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: KNF and the C preprocessor
On Mon, Dec 10, 2012 at 09:36:35AM -0600, David Young wrote:
>
> What do people think about setting stricter guidelines for using the
> C preprocessor than the guidelines from the past? Example guidelines:
>
> The C preprocessor MAY be used for
>
> 1 Lazy evaluation: ...
> 2 Lexical manipulation: ...
> 3 Generic programming: ...
> 4 Computed constants. ...
I would like to propose an additional, perhaps controversial, use.
5 Breaking the flow of control:
There are situations where I find that the error handling code
obsfucates the code substantially and that sometimes a quick macro
with a goto or return can render the code more readable. As long
as this method is used sparingly, it can go a long way to make code
more readable especially in the case where there is a lot of memory
management.
As an example, I often define a macro when I am using Kerberos or
GSSAPI that looks roughly like:
#ifdef K5BAIL(x) do {
ret = x;
if (ret) {
/* format error message and whatnot
* in terms of #x.
*/
goto bail;
}
} while (0)
This will allow me to write code like:
K5BAIL(krb5_cc_default(ctx, &cache));
K5BAIL(krb5_parse_name(ctx, princ, &server));
K5BAIL(krb5_get_creds_opt_alloc(ctx, &opt));
K5BAIL(krb5_get_creds(ctx, opt, cache, server, &out));
K5BAIL(krb5_verify_init_creds(ctx, out, server, kt, NULL, NULL));
which you can quickly see exactly what I am doing, rather than:
ret = krb5_cc_default(ctx, &cache);
if (ret) {
format error message;
return ret;
}
ret = krb5_parse_name(ctx, &cache);
if (ret) {
format error message;
krb5_cc_close(ctx, cache);
return ret;
}
etc.
You can't do this with an inline function, because it can't use
goto or return.
Again, though, this method needs to be used sparingly and obviously (that
is, it should be obvious that you are doing it.)
--
Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: core statement on fexecve, O_EXEC, and O_SEARCH
On Tue, Dec 04, 2012 at 11:42:04PM +0700, Robert Elz wrote: > > Even chroot isn't a problem, unless you're tempted to view it as some > kind of security mechanism. It really isn't - it is just namespace > modification. Sure, by modifying the filesystem namespace a bunch > of simple security attacks seem easy to avoid (and it does provide > some simple measure of protection) but as a true security mechanism > it really doesn't come close, and arguing against feature X or Y > because some tricky application of it can defeat chroot "security" > is just plain insane. Let's not lose sight of the fact that chroot can most certainly compromise security if used improperly even if you are only using it as a namespace mechanism, though. So, there are most definitely security considerations that must be taken into account even if you think that chroot is not a security mechanism. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: fexecve, round 3
On Sun, Nov 25, 2012 at 11:47:14PM +, David Laight wrote: > > On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote: > > > > > >> Does everyone agrees on this interpretation? If we do, next steps are > > >> - describe threats this introduce to chrooted processes > > Given a chrooted process would need a helping process outside the > chroot (to pass it the fd), why is allowing the chrooted proccess to > exec something any different from it arranging to get the helper > to do it? > > I think it can only matter if the uid of the chroot is root. > Even then you could (probably) do nothing you couldn;t do by > mmaping some anon space with exec permissions and writing code to it. This thread has been a little long so I am not sure if the setuid programs have been adequately addressed but certainly it is not necessarily safe to execute those in a chroot(2)ed environment as many of them will have assumptions about files such as /etc/spwd.db and so on. We should not just consider setuid programs that we ship but also designs that previously were safe that this model would make unsafe. Another example that I've seen people do is putting secret information such as passwds into programs and give them mode 111 so that it is not easy to read the information. Granted, it doesn't make it terribly difficult to get the information but it still might not be appropriate to allow chrooted applications to exec these programs as I don't think that even if passed an fd that they could mmap(2) and jump. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: disklabel problems on 3TB disc
On Sat, Jul 21, 2012 at 07:12:15PM +0200, Edgar Fuß wrote: > > I don't know whether this is a disklabel(8) or disklabel(5) or > disklabel(9) problem. You have to use gpt(8) for disks which have more than 2^32 sectors, I think, as the disklabel format does not allow them. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: kern/46494 (cgd on 4K sector disk)
On Thu, May 31, 2012 at 01:08:44PM +0200, Jan Danielsson wrote: > >If dd on the cgd device appears to be working fine, the drive is > perfectly usable if I use it without a cgd device -- what should I be > looking at? > >For completeness, "gpt create cgd3" returns: > >gpt: unable to open device 'rcgd3d': Invalid argument > >Pointers are welcome. I've checked in a bit of code recently that should make the gpts work on cgd. Please upgrade to a quite recent kernel to get that working. > Index: cgdvar.h > === > RCS file: /cvsroot/src/sys/dev/cgdvar.h,v > retrieving revision 1.14 > diff -u -r1.14 cgdvar.h > --- cgdvar.h 12 Jan 2010 21:08:09 - 1.14 > +++ cgdvar.h 31 May 2012 09:27:36 - > @@ -81,6 +81,7 @@ > struct cryptdata sc_cdata; /* crypto data */ > struct cryptfuncs *sc_cfuncs; /* encryption functions */ > struct simplelocksc_slock; /* our lock */ > + unsigned sc_secsize;/* sector size */ > }; > #endif We should use sector size from struct dk_softc, not duplicate it here. There's a reference to DEV_BSIZE in dksubr.c that likely needs to be fixed as well. > @@ -406,7 +406,7 @@ > return -1; > } > cgd_cipher(cs, newaddr, addr, bp->b_bcount, bn, > - DEV_BSIZE, CGD_CIPHER_ENCRYPT); > + cs->sc_secsize, CGD_CIPHER_ENCRYPT); > } This one is interesting. We probably do not want to use the physical disk sector size when we're enrypting the data in the general case as this would mean that if you change the sector size of a disk image, dd a cgd between disks with different sector sizes, etc. it would fail to decrypt properly (using some cipher modes, currently, well, all of them.) To generically solve this problem, we should likely do something like #define CGD_BSIZE 512 at the top and use that. We could make it configurable but this is actually problematic as if CGD is encrypting data in 4K chunks and writing to a disk with 512 byte sectors, you lose write atomicity which would lead to consistency issues on crashes. So, at the very least, if we make it configurable then we need to enforce the constraint that the sector size of the underlying disk >= the encryption sector size. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: O_NOACCESS?
On Sat, Feb 11, 2012 at 07:12:32PM -0500, Mouse wrote: > > > (Note that while there may be no use for #2 in userlevel code, unless > > perhaps if we add an fexecve() call, having it would be convenient in > > the kernel.) > > fexecve() makes a lot of sense too. So would an flink(), and indeed f* > versions of any other call which uses a path just to name an object > rather than as a relevant part of the syscall. We'd want to be a bit careful about adding these as there are permission checks that are implied by specifying a path which you do not get with the f* calls mentioned. Normally, these are not going to be terribly different but in the case of suid programs or chroot'ed programs, we'd want to analyse how we might change the security model. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: UFS and POSIX test suite
On Sun, Jan 01, 2012 at 07:05:06PM +0100, Emmanuel Dreyfus wrote: > > I intentend to use it to hunt bugs for NetBSD FUSE. Without any > surprise, there are a lot of failures, but I am a it surprised to see > that NetBSD UFS fails the same tests most of the time. > > To give an exaample, the script detects that when an unprivilegied user > attempts to set the setGID bit, it should be cleared, while NetBSD UFS > returns EPERM. > > And just clearing the bit indeed seems to be mandated by POSIX: > http://pubs.opengroup.org/onlinepubs/7908799/xsh/chmod.html) > > Opinions? Do we have bugs to fix here? Anyone already gave it a try? It seems to me that either behaviour complies with the language that you quote: If the calling process does not have appropriate privileges, and if the group ID of the file does not match the effective group ID or one of the supplementary group IDs and if the file is a regular file, bit S_ISGID (set-group-ID on execution) in the file's mode will be cleared upon successful return from chmod(). This does not specify that the call to chmod(2) return success if an unprivileged user attempts to set the setGID but it does specify that if success is returned then the bit should be cleared, if I am reading it correctly. This seems to indicate that both behaviours are valid. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: Adding linux_link(2) system call, second round
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote: > > On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote: > > Sure. But what does it actually do, such that if you have a symlink it > > doesn't work to copy the symlink instead of hardlink it? > > That would probably work for symlinks, since they cannot be updated. > But this would requires heavy changes in the way the code is written. > Basically a rename on a symlink would become a readlink/symlink/unlink. > This is not really a portability patch, it is a code rewrite which would > consume more time than I can afford here. I suspect glusterfs developpers > will have to do it if they want to support something else than Linux, but > I have no idea when, therefore it is not wise to hold our breath on it. > > llink(2) is a simple change, FreeBSD already went there with linkat(2), > and it makes everything simple. It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux as well as FreeBSD. It might be the more portable direction to go. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: Adding linux_link(2) system call, second round
On Sun, Jul 31, 2011 at 06:36:53PM +, Christos Zoulas wrote: > > Also perhaps just call it link2(from, to, flags) in the long tradition > of adding a number to existing syscalls when extending them ;-) Or perhaps llink(2) for symmetry with lchmod(2) and lstat(2). -- Roland Dowdeswell http://Imrryr.ORG/~elric/
