Re: Sound problem
[EMAIL PROTECTED] wrote: > I am using FreeBSD 5.4. I have installed sound modules from > kernel and everything work OK. But then I installed mplayer > and when I play movie sound is weird. I know how actors should > sound and they don't sound as they should. If I play same file > under Win, then the sound is ok. Has anybody same problem, and > where could problem lay? You may want to set the kernel variable hw.snd.pcm0.vchans to 0 and tune other hw.snd.* kernel variables with sysctl(8). In the future you may also want to include more details (like the output of `cat /dev/sndstat`) and consider posting to a more appropriate list (like freebsd-questions) first. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sound problem
[EMAIL PROTECTED] wrote: > I am using FreeBSD 5.4. I have installed sound modules from > kernel and everything work OK. But then I installed mplayer and > when I play movie sound is weird. I know how actors should sound > and they don't sound as they should. If I play same file under Win, > then the sound is ok. Has anybody same problem, and where could > problem lay? You may want to set the kernel variable hw.snd.pcm0.vchans to 0 and tune other hw.snd.* variables with sysctl(8). In the future you may want to include more details (like the output of `cat /dev/sndstat`) and consider posting to a more appropriate list (such as freebsd-questions) first. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pointers for understanding vfs/buffer/filesystem architecture
Eric Anderson wrote: > I've very interested in learning about FreeBSD's implementation > of vfs/buffer cache/fs archicture. You may want to download the following graphical overview of the UFS/FFS filesystem that was made by Poul-Henning Kamp earlier this year, it's very useful: http://phk.freebsd.dk/misc/ufs.pdf If you want to print it out you'll need 18 sheets of paper. You may also want to use something like doxygen (devel/doxygen in the ports tree) to generate source code graphs and make browsing through source code easier. Another resource that you may find helpful is Robert Watson's FXR site: http://fxr.watson.org ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ProPolice: best way to fill canary
[EMAIL PROTECTED] wrote: > I was meaning random length fixed value... That may be what you meant, but that's definitely not what you said. > and unless the attacker wants to set the return address to 0x0... You may want to read the paper "Four different tricks to bypass StackShield and StackGuard protection" before making more comments. http://www.coresecurity.com/files/files/11/StackguardPaper.pdf ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ProPolice: best way to fill canary
[EMAIL PROTECTED] wrote: > On Fri, 8 Jul 2005, Jeremie Le Hen wrote: > > > Hello hackers, > > > > I'm going to disturb you once again with ProPolice. The > > original ProPolice patch, as well as most of FreeBSD variants > > and Linux one, uses /dev/urandom to fill the "canary" with > > random data (the canary is what is going to be put between > > buffer and return address in the stack). OTOH, OpenBSD uses > > kern.arnd sysctl to achieve this (this is a sysctl front-end > > to the arc4random() function). > > Just one question, why does the canary have to be filled with > random data? Why not just zero it? sure you get a single random > value to find out how many zero's to use, but why waste that much > good-quality random data (and of course if there isn't enough in > urandom, you would have to make it loop till there is enough unless > you make it just leave the rest as-is) > > IMHO there is no advantages (well, that i can see) of having it > random data rather than just NULL... > > Feel free to correct me if i'm wrong... You're wrong, when the canary value is fixed and known (such as in terminator canaries), there are cases where an attacker could manage to reset the canary to the expected value and circumvent the protection mechanism. That chance doesn't exist with random canaries. AFAIK, ProPolice supports both terminator and random canaries. As for the original topic, I would prefer the sysctl front-end, IMO it's more consistent with other BSDs and more clean and direct while extending open(2) would only appear transparent at the expense of needlessly increasing the complexity of open(2). ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ext2 drives under 5.3 not umounting on reboots
[EMAIL PROTECTED] wrote:
> I've had the same problem on 5.3.
> now on my FreeBSD 5.4-RC2 #0: Fri Apr 15 11:28:48 EEST 2005 i386
> it seems that problem gone.
>
> On Sunday 17 April 2005 00:07, c0ldbyte wrote:
> > On Sat, 16 Apr 2005, M. Parsons wrote:
> >
> > > I have a ext2 linux partition mounted under /linux via the
> > > fstab line:
> > >
> > > /dev/ad2s1 /linux ext2fs rw 1 2
> > >
> > > It will automount on bootup, but if I do a reboot or shutdown
> > > -h now, it doesnt get umounted properly. In fact, if this /linux
> > > is mounted, then /, /usr, /var, and /tmp (all seperate ufs slices
> > > on another hard drive) also get tainted during a reboot.
A couple of weeks ago I saw what I believe to be the same problem, but
on 4.10-STABLE. My attempt to umount an ext2 volume resulted in failure
with the "unknown mount type" error message. I then resorted to using
umount -t ext2fs /linux and the volume was unmounted properly,
so as a workaround you could specify umount -t ext2fs explicitly
in rc.shutdown or similar.
I checked the sources in an attempt to find the cause and here is what
I found out:
In src/sbin/umount.c:
RELENG_5:
In umountall():
/* Ignore unknown file system types. */
if (getvfsbyname(fs->fs_vfstype, &vfc) == -1)
continue;
if (checkvfsname(fs->fs_vfstype, typelist))
continue;
...
rval = umountall(typelist);
rval = checkname(cp, typelist) || rval;
free(cp);
return (rval);
} while ((fs = getfsent()) != NULL);
return (0);
}
In checkname():
if (sfs == NULL) {
warnx("%s: unknown file system", name);
return (1);
}
if (checkvfsname(sfs->f_fstypename, typelist))
return (1);
return (umountfs(sfs));
}
RELENG4:
In umountall():
/* If an unknown file system type, complain. */
if (getvfsbyname(fs->fs_vfstype, &vfc) == -1) {
warnx("%s: unknown mount type", fs->fs_vfstype);
continue;
}
if (checkvfsname(fs->fs_vfstype, typelist))
continue;
...
rval = umountall(typelist);
rval = umountfs(cp, typelist) || rval;
free(cp);
return (rval);
} while ((fs = getfsent()) != NULL);
return (0);
}
As you can see, the RELENG_5 code was changed to call a separate
function named checkname() instead of checking and reporting name
problems directly, but in that process a new check is introduced
in a way that makes it possible for umount(8) to fail without
reporting the reason for failure.
Neither getvfsbyname(3) in src/lib/libc/gen/getvfsbyname.c nor
checkvfsname() in src/sbin/mount/vfslist.c have changed in
significant ways that would indicate they could be at fault,
however there might be a problem with keeping track of filesystem
modules, specifically, fs_vfstype (struct fstab) on RELENG_{4,5}
and/or f_fstypename (struct statfs) on RELENG_5. Any clues?
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MDELAY()
[EMAIL PROTECTED] wrote: > DELAY() in FreeBSD uses a busy loop . I am looking for something > like sleep_on_timeout() call in Linux . (dont' want to waste the CPU > cycles by DELAY'ing) You may want to check out timeout(9) / untimeout(9), see man 9 timeout for details. > As I am pretty new to programming with Free BSD , can you help > me with some details about equivalent implementation(wait queues > etc) in Free BSD . Reading the man pages for asleep(9) / wakeup(9) should give you a good introduction. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: imminent disk failure ?
[EMAIL PROTECTED] wrote: > /kernel: ad0: READ command timeout tag=0 serv=0 - resetting > > Could this message mean this disk is giving its last breaths ? Check to see if some part of the system is not overheating due to a failed fan somewhere. Also check the cabling and the SMART status of the drive. There were some issues with DMA and UDMA133 mode, so you may want to try to rule out those as possible causes first by putting hw.ata.ata_dma=0 into /boot/loader.conf and forcing UDMA100 mode with atacontrol(8) (see man 8 atacontrol for details). BTW, you may want to consider posting such questions to freebsd-questions@freebsd.org in the future as this is not the most appropriate list for such questions. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel killing processes when out of swap
[EMAIL PROTECTED] wrote: > That makes sense. Me trying to connect to see what was going > on would hence cause sshd to be killed ( not good ). > It would seem that we could do with doing something to prevent > this. > We have had a few suggestions so far. > 1. Using madvise, requires code changes per app > 2. Using a sysctl to name processes which shouldn't be killed. > 3. Changing how the choice of process to kill is made. > > I don't like the idea of having to make code changes so would > vote against #1. #3 I would imagine could be quite complex > and error fraught so #2 seems like the best option so far. > > What do others think? Go with Marc's idea? I would go with #3 and add a new process flag like P_KILLLAST and then update vm_pageout_scan() to honour that flag and make sure to kill processes without that flag first before moving to processes which have that flag set. It would require minimum changes and you would only need a way to set this flag on a process. No change in existing applications would be required because they would be oblivious to this feature. IMHO this would be preferable to having something like SIGDANGER where every program has to have a special signal handler in order to benefit from this feature. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel killing processes when out of swap
[EMAIL PROTECTED] wrote: > On Tue, Apr 12, 2005 at 06:46:45PM +0200, Dag-Erling Smrgrav > wrote: > > There is no "large process detection". The first process that > > tries to fault in a new page after the system runs out of swap > > gets killed. > > Are you suggesting that vm_pageout_pmap_collect() is no longer in > use ? > > That has a FOREACH_PROC_IN_SYSTEM(p) ... find biggest unlocked > ... > kill-kill-kill... The largest process gets killed in vm_pageout_scan() according to the latest sources: http://fxr.watson.org/fxr/source/vm/vm_pageout.c#L1168 1168 /* 1169 * If we are critically low on one of RAM or swap and low on 1170 * the other, kill the largest process. However, we avoid 1171 * doing this on the first pass in order to give ourselves a 1172 * chance to flush out dirty vnode-backed pages and to allow 1173 * active pages to be moved to the inactive queue and reclaimed. 1174 * 1175 * We keep the process bigproc locked once we find it to keep anyone 1176 * from messing with it; however, there is a possibility of 1177 * deadlock if process B is bigproc and one of it's child processes 1178 * attempts to propagate a signal to B while we are waiting for A's 1179 * lock while walking this list. To avoid this, we don't block on 1180 * the process lock but just skip a process if it is already locked. 1181 */ http://fxr.watson.org/fxr/source/vm/vm_pageout.c?v=RELENG4#L1112 1112 /* 1113 * If we are out of swap and were not able to reach our paging 1114 * target, kill the largest process. 1115 */ ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] GBDE memory allocations bugs and mlockall(2) [Was Re: kernel killing processes when out of swap]
[EMAIL PROTECTED] wrote:
> It would be more appropriate if such processes use the mlockall(2) call
> for the time being.
Speaking of mlockall(2), almost two weeks ago when I posted here about
CGD (and GBDE) memory allocation bugs I sent the attached patch for
src/sbin/gbde/gbde.c to PHK, but since he never got back to me on that
I would like to ask you guys to review the patch and commit it as
appropriate, hopefully before the next release.
The patch addresses memory allocation bugs where memory is used without
checking first if allocation was successful. In one case this could lead
to a segment violation with the core dump containing the sensitive info
required to decrypt the GBDE volume. The patch also disables core dumping
by using setrlimit(2)) and prevents paging by using mlockall(2).
I have patched several similar memory allocation bugs in libgeom, so if
anyone would like to see these bugs fixed let me know and I'll post that
patch as well. Right now I get the feeling that due to memory overcommit
in FreeBSD some people might think that these checks are not absolutely
necessary since another larger process would be more likely to get killed
before malloc(3) would return NULL, but I believe that one should not rely
on that.
ALeine
___
WebMail FREE http://mail.austrosearch.net --- src/sbin/gbde/gbde.c.oldWed Mar 30 14:18:37 2005
+++ src/sbin/gbde/gbde.cWed Mar 30 15:11:15 2005
@@ -85,7 +85,10 @@
#include
#include
#include
+#include
+#include
#include
+#include
#include
#define GBDEMOD "geom_bde"
@@ -145,6 +148,19 @@
exit (1);
}
+static void
+disable_core_dumping(void)
+{
+ struct rlimit rl;
+ int error;
+
+ rl.rlim_cur = 0;
+ rl.rlim_max = 0;
+ error = setrlimit(RLIMIT_CORE, &rl);
+ if (error)
+ err(1, "setrlimit() failed to set core size to 0");
+}
+
void *
g_read_data(struct g_consumer *cp, off_t offset, off_t length, int *error)
{
@@ -355,7 +371,10 @@
u_char *sbuf;
off_t offset, offset2;
+ /* Allocate a sectorbuffer immediately and zero it */
sbuf = malloc(gl->sectorsize);
+ if (sbuf == NULL)
+ err(1, "malloc");
memset(sbuf, 0, gl->sectorsize);
offset = (gl->lsector[key] & ~(gl->sectorsize - 1));
offset2 = lseek(dfd, offset, SEEK_SET);
@@ -377,7 +396,10 @@
u_char *sbuf, *q;
off_t offset, offset2;
+ /* Allocate a sectorbuffer */
sbuf = malloc(gl->sectorsize);
+ if (sbuf == NULL)
+ err(1, "malloc");
/*
* Find the byte-offset in the lock sector where we will put the lock
* data structure. We can put it any random place as long as the
@@ -422,9 +444,7 @@
errx(1, "No -L option and no space in sector 0 for lockfile");
}
- /* Allocate a sectorbuffer and fill it with random junk */
- if (sbuf == NULL)
- err(1, "malloc");
+ /* Fill sectorbuffer with random junk */
random_bits(sbuf, gl->sectorsize);
/* Fill random bits in the spare field */
@@ -722,12 +742,17 @@
if (argc < 3)
usage("Too few arguments\n");
- if ((i = modfind("g_bde")) < 0) {
- /* need to load the gbde module */
- if (kldload(GBDEMOD) < 0 || modfind("g_bde") < 0) {
- usage(GBDEMOD ": Kernel module not available\n");
- }
- }
+ if ((i = modfind("g_bde")) < 0) {
+ /* need to load the gbde module */
+ if (kldload(GBDEMOD) < 0 || modfind("g_bde") < 0) {
+ usage(GBDEMOD ": Kernel module not available\n");
+ }
+ }
+
+ disable_core_dumping();
+ if (mlockall(MCL_FUTURE))
+ err(1, "mlockall() failed to lock all memory");
+
doopen = 0;
if (!strcmp(argv[1], "attach")) {
action = ACT_ATTACH;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel killing processes when out of swap
[EMAIL PROTECTED] wrote: > Just had a problem with a box where it looks like it ran out of > swap due to a problem process, not a problem. The problem was that it > seems the kernel on detecting this starts killing off seeming random > processes, the first one being sshd hence making the machine inaccessible. > > So the question is: Does the kernel kill random processes when > out of swap or does it kill any processes that require more memory when > out of swap? Which leads to the question would it not be more > sensible to kill off the largest process first as its more than likely that > it is responsible for the problem? This procedure is not random, it indeed looks for the largest process and then kills it. It keeps repeating this procedure until the memory starvation problem is solved. You obviously are not running X on that machine, otherwise you would see that X would get killed before sshd. When you're out of swap, you're also out of luck if sshd is among the largest processes on your machine. Having a flag to tag processes as vital to prevent them from getting killed (or to give them lower next-to-be-killed priority so that all non-vital processes get killed first) when you run out of swap would be a useful feature, what do you guys think? ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA security commands, bug in atacontrol
[EMAIL PROTECTED] wrote: > And while travelling, someone pickpockets you and takes the > flash drive where you stored the key. I never said you would store the password on the USB flash drive, that drive is meant to serve mainly for booting FreeBSD. Secure password storage is another issue altogether, but it is obvious that relying on the USB flash drive alone for password storage would create a single point of failure with a very serious impact as you could end up not being able to use the drive(s) yourself. If one were to store the password there, it would be advisable to encrypt it first and to also store a (possibly fragmented) copy in other locations, such as your own memory, remote machines, etc. But let's assume that you did store the unencrypted password on the USB flash drive. The pickpocket would have no use for the password unless you also stored your full name, address and a detailed description of what the password is for along with the password. :-) Even in that case it would be unlikely that a total stranger would travel all the way to your house (assuming you do not vacation locally) just to steal your drives. If you believe there are people who are so determined to get to your data (and not just your drives) that they have the resources and the determination to follow you on vacation and steal your USB flash drive, then it would be safe to assume that you would also take precautions to encrypt your drive(s) with GBDE or similar beforehand and that you would also not store sensitive GBDE information (passphrase, lock sectors, ...) on the same USB flash disk where you decided to store a copy of the disk password(s). ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA security commands, bug in atacontrol
[EMAIL PROTECTED] wrote:
> Um, wouldn't setting the password on a system in which the BIOS
> offers no ATA security support render the system unbootable? The BIOS
> would be unable to read the boot sector without first unlocking the
> disk...
Correct, if BIOS is configured to try to boot only off the drive you
just password protected. The feature I proposed is not meant to be a
replacement for the kind of functionality that should be provided
by BIOS, it's meant to provide a way to issue ATA security
{set,unlock,disable} password and other commands to drives other
than the bootable drive from FreeBSD. For example, imagine that you
are about to go on vacation and you want to set the password on the
drives that will stay in your home unsupervised. You could then boot
FreeBSD into single user mode from a USB flash drive (with the
appropriate sysctl variable set beforehand in loader.conf in order
to prevent FreeBSD from issuing the freeze lock command on startup)
and then set the password(s) on your hard disk drive(s). You would
then take the USB flash drive with you and after returning home you
would repeat the procedure (assuming your drives were not stolen :->),
only issuing unlock and disable password commands. Another reboot and
you could boot off your drive(s).
> Since compliant BIOSes have already frozen the config by the time
> the OS boots anyway, the only reason I can think of for atacontrol to
> have security support would be if you're booting from some other
> media, i.e. floppy, CDROM, network, USB...
>
> It might also be somewhat useful for secondary (non-boot drives).
> *BUT* that would probably only work on machines where the BIOS doesn't
> freeze all the drives on startup.
A BIOS that has the ATA security features implemented correctly sends
the ATA security freeze lock command on drive identification, but such
a BIOS also provides a user interface to the ATA security settings, so
the feature I proposed is clearly not meant for such cases, the single
user mode requirement also makes it obvious it is not meant to be a
replacement for such BIOS functionality, but a workaround that prevents
potential abuse while also offering a limited way to issue AT security
commands. Most BIOS manufacturers (Award especially) are not likely to
do anything about this issue any time soon (if at all), so at the very
least FreeBSD should issue the freeze lock command if the feature I
described would not be seen as worthwhile.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA security commands, bug in atacontrol
[EMAIL PROTECTED] wrote:
> Right, I did see that article but I've not settled on how if at
> all to deal with it. The by far most secure method would be to
> have ATA issue the freeze command ASAP in the probe/attach code,
> thats about one line of code :)
>
> At any rate atacontrol is not the place to put it if we want this
> to up security...
There are some people who would want to be able to issue ATA security
{set,unlock,disable} password and other commands, but have no BIOS user
interface to change any of the ATA security settings. This functionality
clearly belongs in BIOS and issuing the ATA security freeze lock
command automatically like you suggested would indeed protect the
disk from unauthorized ATA security changes, but it would also make it
impossible for users to use the ATA security features from FreeBSD.
Perhaps there could be a kernel sysctl variable such as
hw.ata.security.issue_freeze_lock_command_on_boot which would be set
to 1 by default. Users who know what they are doing could still be able
to override it by placing hw.ata.security.issue_freeze_lock_on_boot=0
into /boot/loader.conf. This override would then be honoured only in
single user mode to prevent a simple reboot from rendering a disk
unusable in case of system compromise. How does that sound to you? :-)
The ATA security commands could then be added to atacontrol for those
who need them and in any case I believe more detailed ATA security
info should be reported by atacontrol.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATA security commands, bug in atacontrol
Recent c't magazine article "At Your Disservice - How ATA security functions
jeopardize your data", which you can find at the URL below, warns about the
dangers of ATA security commands. Specifically, a malicious attacker with
sufficient access could render a disk useless to the legitimate owner of
the disk by setting the 32 byte user and master passwords using the ATA
security command 0xf1.
http://www.heise.de/ct/english/05/08/172/
To prevent such attacks in case of compromise one can issue the ATA security
freeze lock command 0xf5, which disables further ATA security commands until
the next cold boot. Software for issuing the ATA security freeze lock command
has been made available at the URL below.
http://www.heise.de/ct/ftp/projekte/atasecurity/
There is a patched version of the Linux hdparm utility there, but the c't
guys seem to have neglected the BSD world, they have not even mentioned the
fact that OpenBSD's atactl(8) already supports this command as well as all
the other ATA security commands, as can be seen at the URL below.
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/atactl/
Currently FreeBSD's atacontrol(8) has no support for ATA security commands,
so I would like to know if adding the ATA security features is a priority
on the TODO list. I would like to see these features implemented and I would
also be willing to port the code from OpenBSD if there are some more
experienced kernel developers who would be willing to review my code and
commit it? Let me know.
One more thing: while browsing through src/sbin/atacontrol.c I noticed a
copy & paste bug in the RELENG_4 version where the SMART feature info is
reported instead of the security feature info (by atacontrol cap). I attached
the appropriate patch for this bug, please review it and commit the fix as
appropriate.
ALeine
___
WebMail FREE http://mail.austrosearch.net --- src/sbin/atacontrol.c.old Sun Apr 3 14:41:32 2005
+++ src/sbin/atacontrol.c Sun Apr 3 14:41:50 2005
@@ -158,8 +158,8 @@
parm->enabled.microcode ? "yes" : "no");
printf("security %s %s\n",
- parm->support.smart ? "yes" : "no",
- parm->enabled.smart ? "yes" : "no");
+ parm->support.security ? "yes" : "no",
+ parm->enabled.security ? "yes" : "no");
printf("power management %s %s\n",
parm->support.power_mngt ? "yes" : "no",
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: subtracting days from localtime problem
I attached an example which shows the DST related changes
this year. I just couldn't resist writing something where
I get to use rare values such as 1112345678 and 1131131131
in a meaningful way. :-)
ALeine
___
WebMail FREE http://mail.austrosearch.net /*-
* Copyright (c) 2005 ALeine <[EMAIL PROTECTED]>
* All rights reserved.
*
* Imported into CVS repository at exactly 1112345678 seconds
* since the Epoch.
*
* $Id: dst_2005.c,v 1.1.1.1 2005/04/01 08:54:38 aleine Exp $
*
*/
#include
#include
void get_date_string_x_days_from_time(char *, size_t, int, time_t);
void get_date_string_x_days_before_time(char *, size_t, int, time_t);
int
main(void)
{
time_t now;
int last_day;
int day_offset;
chardate_string[32];
now = time(NULL);
/* Uncomment the following line to see what happens on 01-Apr-2005 */
/* now = 1112345678; */
/* Uncomment the following line to see what happens on 04-Nov-2005 */
/* now = 1131131131; */
fprintf(stderr, "Reference date and time: %s\n", ctime(&now));
last_day = 32;
for (day_offset = 1; day_offset < last_day; day_offset++) {
get_date_string_x_days_before_time(date_string,
sizeof(date_string),
day_offset,
now);
printf("%3d day%c before reference date: %s\n",
day_offset,
(day_offset > 1 ? 's' : ' '),
date_string);
}
return 0;
}
void
get_date_string_x_days_before_time(char *date_string,
size_t size,
int day_offset,
time_t time)
{
get_date_string_x_days_from_time(date_string, size, -day_offset, time);
}
void
get_date_string_x_days_from_time(char *date_string,
size_t size,
int day_offset,
time_t time)
{
struct tm *tm_p;
tm_p = localtime(&time);
tm_p->tm_mday += day_offset;
tm_p->tm_hour = tm_p->tm_min = tm_p->tm_sec = 0;
/* make mktime(3) figure out whether DST is in effect */
tm_p->tm_isdst = -1;
time = mktime(tm_p);
if (time == ((time_t) - 1))
printf("mktime(3) failed\n");
snprintf(date_string, size, "%d-%.2d-%.2d [DST: %d]",
tm_p->tm_year + 1900,
tm_p->tm_mon + 1,
tm_p->tm_mday,
tm_p->tm_isdst);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: subtracting days from localtime problem
[EMAIL PROTECTED] wrote: > One more question, what will happen next time when > time goes back in October? > Does following line correct it as same as now? > > /* make mktime(3) figure out whether DST is in effect */ > t->tm_isdst = -1; Yes, it will work correctly. You can see what happens by setting now to 1131131131 (where you currently have now = time(NULL)). It's not an April Fools' Day joke, that just happens to be an appropriate time in November. :-) I also noticed a number of bugs in your code that you may want to fix: - memory leak: you are allocating memory with my_alloc(), but then you neither free(3) it nor keep track of it. You should remove my_alloc() and just create a buffer in main() and then pass it by reference to functions that need to modify its contents. - with my_alloc() you basically reinvented strdup(3), see man 3 strdup for details. You do not need strdup(3) for what you want to achieve, just pass the buffer from main() by reference and then use snprintf(3) to modify its contents. - snprintf(3) handles the size argument correctly, meaning that you should specify the full size of the string since at most size-1 characters are written with guaranteed NULL termination, see man 3 snprintf for details. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: subtracting days from localtime problem
[EMAIL PROTECTED] wrote:
> I have problem subtracting days from current date using test
> program. We have daylight saving occured on 2AM of March 26, 2005.
> As you can see below, there is missing March 26th line from
> program output.
>
> And all lines after 27th March are wrong.
> Instead of 25th March it should be 26th March, 24th March should
> be 25th March and so on.
>
> Can somebody tell me why is this happening? How can I correct
> this problem?
You should set the tm_isdst to -1 before making the call to
mktime(3) in order to make mktime(3) try to figure out whether
Daylight Savings Time is in effect or not. See man 3 mktime for
details.
So, your getDate() function should look something like this:
char *
getDate(int day)
{
struct tm *t;
time_t now;
char date[12];
char *localdate;
time_t p;
now = time(NULL);
t = localtime(&now);
t->tm_mday -= day;
t->tm_hour = t->tm_min = t->tm_sec = 0;
/* make mktime(3) figure out whether DST is in effect */
t->tm_isdst = -1;
p = mktime(t);
if (p == (time_t)-1)
printf ("mktime failed\n");
snprintf(date,11,"%d-%.2d-%.2d", t->tm_year + 1900,
t->tm_mon + 1,
t->tm_mday);
if ((localdate=my_alloc(date)) == NULL) {
fprintf(stderr, "Allocation error!\n");
exit(2);
}
printf("Date: %s\n",localdate);
return localdate;
}
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A bunch of memory allocation bugs in CGD
[EMAIL PROTECTED] wrote: > Having a quick read it looks like the call to cmd_nuke() is > preceded by a cmd_open(). cmd_open() loads the decrypted decoded > contents of the lock sector into memory which contain all of the > information needed to decrypt the disk. In cmd_nuke(), the malloc is > followed immediately by a memset(3) which could core dump. You're right on both counts, I apologize for the confusion, I have several versions of GBDE files around and just before I made that comment about segmentation violation not being possible I took a look at the malloc(3) line in my patched version by mistake. In that version I replaced the malloc(3) and memset(3) calls in cmd_nuke() with a single malloc(3) call with the M_ZERO flag set. Using mlockall(2) to prevent paging and setrlimit(2) to prevent core from being dumped would also be an improvement for both CGD and GBDE. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A bunch of memory allocation bugs in CGD
[EMAIL PROTECTED] wrote: > Thanks for having a look at that. I have checked in a fix. Thanks for responding so quickly. > I presume that you have addressed the cases in GBDE where > malloc's return code has not been checked? If so, perhaps > cvsweb is a little behind. It looks to me like 2 or 4 mallocs > can use a buffer without checking the return code. There are two malloc bugs in GBDE, but both are minor and have no security implications. Both bugs are in src/sbin/gbde/gbde.c: - the first bug is in cmd_nuke() and could not be seen as much of a bug because cmd_nuke() is used to destroy lock sectors. If this fails due to memory starvation no sensitive information is leaked, only a write(2) call fails and gbde terminates correctly upon catching and reporting the write error. - the second bug is in cmd_write(), where a buffer is allocated and checked, but not immediately, so there is a case where it can be used before it gets checked. However, even if this happens, only a read(2) call fails and gbde terminates correctly upon catching and reporting the read error. In src/sys/geom/bde/g_bde.c there is also a g_malloc() allocated buffer which is unchecked, but since the allocation is done with the M_WAITOK flag it's safe. This means there are no malloc bugs in GBDE which could cause a segmentation violation. I have sent the patch for the minor malloc bugs I described above to Poul-Henning, so I expect him to review it and commit the appropriate fix in the near future. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A bunch of memory allocation bugs in CGD
[EMAIL PROTECTED] wrote: > This has nothing to do with FreeBSD development, take it > elsewhere. What's your intention, start another flamefest > like the endless CGD vs GBDE thread? Please. This may come as a surprise to you, but there are people on the freebsd-hackers mailing list who are not on the relevant NetBSD mailing lists, but who are still interested in CGD and who are likely candidates to do a 3rd party audit of CGD. Developers from BSD communities share code and ideas and they do peer reviews and audits from which everyone in the BSD communities benefits. There might be some heated discussions at times, but that's normal and as long as some good comes out of such discussions they can't be all bad, they make people work harder and focus more attention on issues that need to be improved. The fact that you posted inflammatory comments after falsely assuming that my motivation was the same as yours when replying to my post is more than ironic. > If you've found flaws in CGD contact the NetBSD developers and > send patches or shut up (TM). I notified the author and other people in BSD communities who are most likely to be interested in knowing about this and improving CGD. You may want to start paying attention and reading before you post or you could just apply a patch and take your own (TM) advice. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
A bunch of memory allocation bugs in CGD
I took a quick look at the latest NetBSD CGD code and found
out that out of 19 memory allocation operations 11 (almost 60%)
are done in a way that could lead to a segmentation violation
which would leave behind a core dump full of sensitive
information that could be used to compromise a CGD encrypted
disk. While this attack is not very practical since it requires
the attacker to be able to cause resource starvation at a
specific time when cgdconfig is used, it is still possible.
Here are the details...
Memory allocation operations in files in src/sbin/cgdconfig:
params.c1 wrong, 1 correct
pkcs5_pbkdf2.c 1 wrong, 1 correct
utils.c 9 wrong, 6 correct
params.c:90:p = malloc(sizeof(*p));
params.c-91-params_init(p);
params.c-92-return p;
params.c-93-}
params.c-94-
params.c-95-static void
params.c-96-params_init(struct params *p)
params.c-97-{
params.c-98-
params.c-99-p->algorithm = NULL;
--
pkcs5_pbkdf2.c:103: data = malloc(Slen + 4);
pkcs5_pbkdf2.c-104- memcpy(data, S, Slen);
--
utils.c:94: ret = malloc((nwords+1) * sizeof(char *));
utils.c-95- tmp1 = tmp = strdup(line);
utils.c-96- while ((cur = strsep_getnext(&tmp, " \t")) != NULL)
utils.c-97- ret[i++] = strdup(cur);
--
utils.c:150:out = malloc(sizeof(*out));
utils.c-151-out->length = inlength;
utils.c:152:out->text = malloc(out->length + 1);
utils.c-153-memcpy(out->text, intext, out->length);
utils.c-154-out->text[out->length] = '\0';
--
utils.c:188:sum = malloc(sizeof(*sum));
utils.c-189-sum->length = a1->length + a2->length;
utils.c:190:sum->text = malloc(sum->length + 1);
utils.c-191-memcpy(sum->text, a1->text, a1->length);
--
utils.c-255-/* XXX do some level of error checking here */
utils.c:256:b = malloc(sizeof(*b));
utils.c-257-b->length = len;
utils.c:258:b->text = malloc(BITS2BYTES(b->length));
utils.c-259-memcpy(b->text, buf, BITS2BYTES(b->length));
--
utils.c-323-/* XXX do some level of error checking here */
utils.c:324:b = malloc(sizeof(*b));
utils.c-325-b->length = MAX(x1->length, x2->length);
utils.c:326:b->text = calloc(1, BITS2BYTES(b->length));
utils.c-327-for (i=0; i < BITS2BYTES(MIN(x1->length, x2->length)); i++)
utils.c-328-b->text[i] = x1->text[i] ^ x2->text[i];
Also, using free_notnull() is pointless, that function should be removed
and all calls to that function should be replaced with calls to free(3),
since free(3) takes no action if the pointer is NULL.
utils.c:171:free_notnull(s->text);
utils.c:276:free_notnull(b->text);
utils.c:411:free_notnull(tmp);
utils.c:412:free_notnull(out);
--
utils.c-495-void
utils.c:496:free_notnull(void *b)
utils.c-497-{
utils.c-498-
utils.c-499-if (b)
utils.c-500-free(b);
utils.c-501-}
I find it alarming that this kind of sloppy programming can be found in
a piece of software that is supposedly designed to be secure and provide
security. I believe the CGD code should be seriously audited before
anyone considers using it in a production environment.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
[EMAIL PROTECTED] wrote: > You've proven my point exactly: Some folks want to see i386 moved to > arch/i386, others think it is stupid to do that. Discussion isn't > possible here, so nothing will happen since there's no compelling > reason to do anything, just a weak argument about how things might be > nicer. If such a layout change were to happen I think the least time wasting procedure would go something like this: - issue a request for new layout propositions - for a week accept proposition submissions (web based) - have the FreeBSD community vote on the proposed layouts (web based) - assign a deadline by which a decision has to be made and then discuss the most popular layouts and try to get the Core Team and the committers to reach a consensus No consensus, no change. In any case, a lot of time and energy would be spent discussing this change, it's more of a bike shed issue than some might think, it's just not worth even starting this process in the near future. > The fact that we even consider cvsup load when discussing this means > that clearly it is a weak idea: if we have to worry about the impact > on how we distribute the sources for a change, isn't that really a > weird criteria to use? It does not prove that the idea itself is weak, it's a criterion that proves that CVS is not well suited to such changes. The thing is that even if such a change would be trivial to implement with no additional overhead, the process of deciding which new layout to adopt would take too much time and energy compared to the benefits gained by adopting a new layout, at least at this stage of development. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
[EMAIL PROTECTED] wrote: >And the worts of all is that You are both right to some extent. The > new developers want the source tree arranged in the way mohamed says it > should be. Not some device drivers live in pci/ other in dev/ and things > like that. And on the other hand experienced kernel hackers who want > things to stay as they are so it is easy for them to navigate in know > waters. IMHO mohamed is a bit "more" right. If you are really dedicated to studying the kernel sources at that level issues such as learning the layout are really nonissues, the time a new developer initially spends hunting around for files because they are not familiar with the layout is insignificant compared to the time experienced developers would lose as a result of a new layout being introduced, especially during a critical development stage. Once all the major changes are finished and we move to micro optimization a new, more consistent and logical layout would be an option, but until then, IMHO, things should stay the way they are. Also, the benefit of such a reorganization at this time does not justify the work needed to make it happen. It Would Be Nice (TM), but it's not practical. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > On Mon, Mar 07, 2005 at 09:43:13AM -0700, [EMAIL PROTECTED] wrote: > > > > > I also believe that it would be beneficial to implement regular rewriting > > > of randomly picked lock sector(s) at random times during a user specified > > > interval (up to x rewrites within n seconds) in order to further obscure > > > the write pattern and provide additional protection for lock sectors. > > > > I agree. > > I don't. Hiding the lock sector is pointless for hot disk attacks. A > malicious SAN administrator (and other intermediaries, if transport > encryption is not used) can identify the lock sector trivially, > because gbde decrypts its location and tells you: it goes straight > there on startup. The idea I proposed is not meant to address the protection of hot disks, it is mainly meant to address the protection of lock sectors on cold disks that can be accessed at regular intervals for differential analysis. The improved hot disk protection in terms of obscuring write patterns as a result of this mechanism is just a beneficial side-effect and not the main goal. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > > >I agree. I would also add random reads (or specially designed, combined > > >random reads and writes) to make traffic analysis and differential attacks > > >a real PITA for the hacker (although this idea may not be very effective > > >against a highly motivated and determined attacker, such as some > > > government, for instance). > > > > If you want to do something like this, you want to do sectorrenaming > > and journaling since that means you can only see that something > > was written but not what it was that was written. Hot disk protection is something that should not to be implemented as an afterthought, it should be a known and well understood and analyzed requirement before any design can take place. I believe there is no need to use journaling to obscure the write pattern in order to better protect the lock sectors. An attacker who can regularly copy and analyze the disk for sectors which have been written could, over time, use that knowledge to locate the lock sectors basing the analysis on the assumption that lock sectors are not rewritten. That is why I believe adding such rewriting would be beneficial, but under the assumption that it would be done carefully, meaning that one would never rewrite just the lock sector but a much larger randomly sized block which would be picked in such a way that the lock sector would be at a random offset inside that block. One would also not rewrite the block if there were no disk writing taking place within a certain sector range in order not to reveal the location of a lock sector located on some remote part of the disk that does not get any write activity at all. For this reason I believe that lock sector rewrites should tag along with write operations occuring near lock sectors. If one were to then employ this mechanism to randomly rewrite other parts of the disk one could prevent an attacker from assuming that rewritten but unchanged blocks contain at least one of the lock sectors. These rewrites would not pose a threat to data integrity since the same data would be written to the same locations, but they would cause a slight performance drop. I say slight because the random rewrites of sectors other than lock sectors could be done at times of low disk activity and their frequency could be set by the user. > Speaking of user protection, how did you implement the procedure of > erasing keys? Did you account for the properties of magnetic media > and RAM that make data recovery possible? You already got the short answer: no. You can find the reasoning behind that decision in the section 4.1 of PHK's paper, but to summarize: this approach is mainly based on the assumptions that one would need to be able to destroy the keys quickly and that one would be able to provide positive proof that the keys had been destroyed. There are currently two destruction operations available: - destroy: destroys one lock sector by blanking the following fields with zeros: - sector0: byte offset of the 1st byte used - sectorN: byte offset of the 1st byte not used - keyoffset: byte offset by which the image is skewed - flags - the master key itself The fields containing offsets (lsector[G_BDE_MAXKEYS]) of all the other lock sectors are overwritten with ones (bitwise). Everything else (the salt, etc.) is left intact. Only one write takes place. - nuke: destroys all copies of the master key by completely overwriting all lock sectors with zeros. One write per lock sector takes place. The last time I checked the gbde(8) man page appeared to be missing info on the nuke operation. Should this be updated or will the update be done after the changes are finalized (I see some mention of the blast operation in the source code)? I also believe it would be a good idea to scrub the lock sector(s) with random garbage first and then as the last step perform the kind of blanking described above. Perhaps there could be an option for regular and emergency destruction. In an emergency you cannot afford to do the random garbage rewriting, but otherwise one could choose to scrub the lock sectors first in a series of larger randomly sized block rewrites as described above. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > > Second of all, the cleaning lady copy attack (described in section > > 10.3), where someone can regularly make bit-wise copies of the > > entire disk containing the encrypted image and determine the > > location of sensitive structures by means of differential analysis > > is not very practical. > > Actually, it's quite practical. It requires no hardware modification that > might be noticed, and it only requires intermittent access to the machine. > And as I said above, traffic analysis will yield considerable results toward > breaking the encryption. Do you keep *your* laptop next to you 24/7? Very > few people do. Some laptop manufacturers (e.g. Dell) even make it > particularly easy to remove the disk. Trying to prove your point by taking my statements out of context is not a very good way to argue a point. Let me reiterate: Second of all, the cleaning lady copy attack (described in section 10.3), where someone can regularly make bit-wise copies of the entire disk containing the encrypted image and determine the location of sensitive structures by means of differential analysis is not very practical. If someone has that kind of access to your computer then they are more likely to use a hardware keylogger and intercept the passphrase. I never implied this kind of attack would be impossible, it is in fact probable. What I did imply is that this kind of attack is less practical than simply using a keylogger to intercept the passphrase. If you assume that you are dealing with an attacker capable of differential analysis, you can also safely assume that such an attacker knows that employing a keylogger would be an easier way to achieve the same goal, therefore the attacker would be more likely to resort to using a keylogger than differential analysis. That is, if we also assume the attacker is sane and not a masochist. > While you might claim that the dedication to study the user's behavior and > mount such an attack is fanciful, I claim that it is not. Under observation, > GBDE's additional techniques do not stand up to the claim of being "spook > strength". I never made such a claim, you are missing the point. What I am saying is that as long as there are more practical ways of attacking GBDE in the particular scenario where an attacker has access to the cold disk in a way that enables that attacker to, among other possibilities, make bit-wise copies of the disk on a regular basis in order to perform differential analysis, such an attacker is more likely to resort to employing other easier methods first. You cannot use the argument of susceptibility to differential analysis against GBDE without using the same argument against CGD. In fact, CGD is even more susceptible to such analysis because eventhough it employs AES 256, it does nothing to obscure the location of sensitive sectors, while GBDE employs several mechanisms to achieve that goal and to also severely localize the extent and impact of a potential compromise resulting from differential analysis. Your point is therefore moot. I also believe that it would be beneficial to implement regular rewriting of randomly picked lock sector(s) at random times during a user specified interval (up to x rewrites within n seconds) in order to further obscure the write pattern and provide additional protection for lock sectors. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote:
> >For example, one can regularly scrub the unused areas around the
> >encrypted image (padding) with dd(1) using if=/dev/{u,}random and
> >similar. This can be fully automated with a cron job.
> >
> >One can also regularly scatter files with misleading names and
> > contents.
>
> etc. I think we need to be careful about phrases like "one can".
I was not assuming one would and I never implied that one should,
if you read my previous posts you probably noticed that all the
changes to GBDE I proposed were to be implemented in a way that
would let the user decide what they wanted. I was only stating
what could be done, in the end the user is the one who decides
what they want, but if they are aware of those threats they can
do a lot about them - if they choose to. One can also choose not
to use encryption at all.
> I decided to stop supposing and gather some real data, so I wrote some
> analysis tools to measure the entropy of disk drives. I need to
> rewrite some of my tools and do a lot more analysis, but I think the
> results thus far are quite interesting. See
> http://www.cs.columbia.edu/~smb/rawdisk-entropy.ps
That seems very interesting, I will take a look! :-) We both posted at
about the same time talking about data entropy. Well, given the topic
that could hardly be considered a coincidence. :-))
Could you make the tools you used publically available? I would very
much like to run that kind of analysis on my disks, especially now
that I'm planning the implementation of the GBDE changes I proposed.
It would also be interesting to see the statistics from others,
perhaps someone would be willing to put up some kind of web site
so people could submit their results into a database.
> Anyway -- the moral of the story is that you really need to analyze
> your environment and your threat model when designing crypto. The
> answer to SAN link eavesdropping might be IPsec or link encryptors; the
> answer to cleaning lady attacks might be cleared personnel, two party
> rules, or other non-crypto solutions. But don't assume, and don't say
> "one can" or "one should". (As a footnote, I realized that my own cgd
> "partition" (via vnd) was created from /dev/zero instead of /dev/urandom;
> the result is that the entropy of the file itself reveals almost
> exactly how much of the cgd partition is in use. I'll have to correct
> that)
I agree with you on the first part and about assuming, but I disagree
about the "one can" part. Saying that one can do something does not
imply that one should or that one would do that, it only implies that
an option exists. So you falsely assumed that I assumed when I was in
fact only addressing the other poster's false assumption that users
would do nothing. :-> They might do nothing, but they can do a lot
if they choose to.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
Someone from the NetBSD community who wishes to remain unnamed sent
me the following email, so I thought I would comment on it here because
there seem to be many others who are confused about the same issue.
> My thinking is that for each of 2^30 sectors, you're looking for
> one of 2^128 keys. So for sector 0, 2^128 keys. For sector 1,
> 2^128 keys. For sector 2, 2^128 keys. That 3 sectors and 3 * 2^128
> keys. 2^30 sectors: 2^30 * 2^128 keys, 2^(30+128) = 2^158.
That assumption is wrong, sectors are not completely independent data,
they are connected in such a way that if you want the entire disk, you
want the right variation of all the keys for all of the sectors on that
disk.
In a 128 bit key, each bit can be either 0 or 1. How many key variations
exist? The number of possible values a bit can have to the power of the
number of bits in the key (key length in bits), which is:
2^128
Now, on a disk consisting of 2^30 sectors, each sector can be encrypted
with one of 2^128 possible keys. How many disk variations exist? The
number of possible keys for a single sector to the power of the number
of sectors in a disk (disk size in sectors), which is:
(2^128)^(2^30) = 2^(128*2^30) = 2^(2^37) = 2^137438953472
Let me give you an example. Let's say you are looking for an English
3 letter word. The English alphabet has 26 letters, so if you were to
try to guess that word by brute forcing it, how many attempts would it
take to try all the variations?
The following perl script will answer that question by enumerating and
listing all the variations.
#!/usr/bin/perl
foreach $x (A..Z) {
foreach $y (A..Z) {
foreach $z (A..Z) {
$i++;
print "$i $x$y$z\n";
}
}
}
As you can see there are 17576 (26^3) and not 78 (3*26) variations,
as some falsely believe. The same can be applied to sectors. You could
argue that once you assume you have the right letter you might be able
to guess another letter because the number of valid three letters
words is a known subset of all the variations and because you know
that the entropy of the English language is low (around 2.1 bits/letter),
but even when you take those facts and apply them to sectors you will
see that it would take much more than 2^158 steps to brute force GBDE
because although the sectors are structured and you could guess a lot,
the data entropy is not zero.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote:
> There are at least two ways to determine this information fairly easily:
As easily as one can get accepted into the crypto community? :->
> 1) If you're doing analysis of a cold disk, it is ~trivial to tell
> the difference between a sector that has been written only once and
> a sector that has been rewritten.
This is hardly trivial, you are basing your statement on the false
assumption that one cannot or will not do anything to protect the
encrypted image after the initialization. One can do a lot.
For example, one can regularly scrub the unused areas around the
encrypted image (padding) with dd(1) using if=/dev/{u,}random and
similar. This can be fully automated with a cron job.
One can also regularly scatter files with misleading names and
contents. These files would be of various sizes, some would be
filled with random garbage and others would be specially
constructed as to cause a false negative upon possible decryption
by brute force or other means. This is easy to implement and
very effective, for example, you can use this approach to encrypt
a file full of random garbage with the same algorithm as the
underlying mechanism (AES 128 in this case). You could also
construct a file containing fake metadata and fragments (even from
other filesystems like EXT2 etc.), which would send an attacker on
a wild goose chase if they were to somehow manage to decrypt part
of the contents of such a file. Such a fake metadata file would
have to be padded to the appropriate length with other valid-looking
data in such a way that it would be contained entirely in a single
zone, otherwise it would expose the remaining sectors is the zone.
Perhaps GBDE could be extended to make such a thwarting subterfuging
mechanism possible through means of a utility which would guarantee
the exclusive placement of a file in a separate zone (or zones if it
were bigger than a single zone, of course). It could be called gezcp
or something like that. Poul-Henning, what do you think of this
feature? :-)
One could then have a cron job periodically (say, every 5 minutes)
launch a script which would scatter the misleading files in specified
locations, always making sure not to use more than the specified
amount of disk space. These files would be recycled, of course, with
older ones being randomly replaced by new ones. This would be fully
automated and would introduce a good level of dispersion of misleading
contents and regular data written to the disk by the user(s). It would
also obscure access and write patterns to the point of making this
attack vector very unattractive.
> 2) When used in a SAN environment, or an environment where
> multiple accesses to the drive can be done over time, it is
> possible to determine this fairly quickly using traffic analysis.
> The GBDE paper even touches on this in section 10.3. Have you
> read it?
First of all, protection against traffic analysis on a SAN is in
the territory of hot disk protection and GBDE, as you must have
surely read, is designed for cold disk protection. SANs are by
definition high availability environments and as such have high
volume traffic, so if you have someone who has access to be able
to monitor that traffic and can also analyze such high volumes
of traffic and can also clone your entire SAN storage devices
unnoticed without causing a service disruption then you have
much bigger problems, so worrying about GBDE should be the
least of your concerns. :-)
Second of all, the cleaning lady copy attack (described in section
10.3), where someone can regularly make bit-wise copies of the
entire disk containing the encrypted image and determine the
location of sensitive structures by means of differential analysis
is not very practical. If someone has that kind of access to your
computer then they are more likely to use a hardware keylogger and
intercept the passphrase. You can get such keyloggers for less
than $100, take a look at Key Katcher, for example:
http://www.thinkgeek.com/gadgets/electronic/5a05/an
Also, the journaling mechanism I mentioned in my previous posts
combined with the thwarting and subterfuging approaches I described
above would make any kind of differential analysis very difficult
and no longer practical.
Who is clutching at straws now? :->
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > The principle of bivalence merely states that every proposition > is either true or false. "Tertium non datur" is the law of the > excluded middle, which is not the same. > Furthermore, neither one says anything about half > the population falling on one side or the other; you're either making > that up or confusing it with something else. > > I refer you to: > > http://en.wikipedia.org/wiki/Bivalent > http://en.wikipedia.org/wiki/Law_of_excluded_middle You are wrong, tertium non datur is the law of the exclusion of the THIRD possibility (it stems from Latin and means "the third is not given"), meaning that any statement can only be either true or false. Some of us have learned mathematics at school, you should try that too, eventhough Wikipedia can be informative, I'm sure. :-> > > You really don't know what you're talking about, do you? > > Hey, you're the one who argued that it's 2^384 to break. Even > PHK's own paper on GBDE puts the effort to break it at 2^129. > Who is it that hasn't read the paper? Roland argued against 2^384, I argued against Roland's underestimate of 2^158, not for 2^384 specifically. Please learn to pay attention. > > You're right, IIRC PKZIP v1.10 had DES encryption back in 1990, > > someone should have told PHK! :-P Please, get a clue, read PHK's > > papers. > > And yet more nonsense. PKZIP isn't even a disk encryption > system. And you know very well that CGD and Loop-AES both predate > GBDE. Claiming that there is "nothing like it" is objectively false. > > Now, if you'd care to stop making ad hominem attacks, perhaps > there can be some useful discussion. Perfer et obdura, dolor hic tibi proderit olim. :-)) Go check if that is in Wikipedia. :-)) You can email me for the translation if you cannot find it online. :-> ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > Your disk has 2^128 sectors? Where can I buy one of those? In the same movie I referenced in the post you took that from. :-> Either there or in the dream I referenced a bit later. :-> ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote:
> It is a serial attack that is:
>
> for (i=0; i < n; i++) {
> crack the i'th key--key block;
> }
>
> So it is actually where $n$ is the number of key--key sectors:
[ ASCII art removed and sent to the museum of modern arts :-> ]
>
> So, for a disk with 2^30 key--key sectors it would be
>
> 2^30 * 2^128 = 2^158
>
> I realise that PHK has been claiming that you might get false
> positives, and that you somehow have to maintain a matrix of past
> this and that. It is a lot simpler than this really.
Your assumption is wrong. First of all, the first sector of the
encrypted image does not necessarily start at the beginning of
the disk, nor does the last sector have to be the last sector
of the disk. At initialization first_sector, last_sector and
total_sectors can be set so that the encrypted image is placed
at an offset from both sides of the disk. If you also use
random_flush that free space (padding) is filled with random
garbage automatically, so one cannot detect where the encrypted
image actually begins or ends.
I would like to see some statistics regarding the distribution
of superblock, inode and directory structures, but I believe
the attack you are describing cannot be automated to the point
of being practical.
You also completely ignored the fact that the smallest logical data
sector size is 512 bytes, but that it can also be set to any
reasonable 2^n size (as PHK already pointed out, 2kb is the
recommended size on FFS). You can only guess as to the size
of the logical sector.
You also have to take into acount the fact that there are at
least 4 512 byte lock sectors (regardless of the size of the
logical sector) which will thwart your automated brute forcing
attempt further. Lock sectors can be anywhere, their location is
picked randomly at initialization and everything else has to map
around them, so you cannot assume anything about their location
or know that you stumbled upon them.
If you take into account that you cannot be sure that you got a
complete zone or that you are indeed looking at a single logical
data sector things become complicated quickly, so your estimate
is way too optimistic.
BTW, since you claim to have studied the papers, you may want to
start using the correct terminology, there is no such thing as a
key-key sector, there are only key sectors, data sectors, lock
sectors, the master key, generated key-keys and sector keys.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
;t use a key for too much data, > and we have some ways these days of calculating how much data "too > much" is. Do you understand how that calculation is performed? Are you sure it would be OK for me to answer that question? After all, I'm not a member of the crypto community and I might insult some member of the crypto community by answering. Oh, well, I'll just have to risk it. AES 256 CBC mode collision after: key size * 2^(cipher block size / 2) = 16 * 2^(128/2) = 2^68 bytes > > You have to trust Roland to integrate the well known and > > understood algorithms in a correct way, trusting the algorithms > > alone is not enough. > > His code did indeed have some bugs to begin with. It was reviewed > and they were fixed. For now. At least the most obvious ones - or should I say the least obvious ones? > > I am not designing cryptographic algorithms, what PHK did with > > GBDE cannot be compared to inventing MD5, snap out of it, you > > are starting to sound like a broken record. > > But the problem is that he crossed a line, so it *can* be > compared to things like inventing MD5. He isn't merely using existing > algorithms in well known ways. He is, in fact, using algorithms in modes > that they having been used in before and making very very specific > claims of work factors to break these new modes. Oh my GOD, he crossed the line, how dare he! There are probably angry cryptographers picketing in front of his house now. Luckily it's quite cold this time of year in Denmark as well, so they should not be there long. > > I assure you PHK knows very well what he is doing > > I've read his paper. I must respectfully disagree. I must respectfully disagree with you, then. > > and I think you should not mention his name in the same breath > > along with the names of the designers of WEP. > > The comparison seems to be perfectly apt -- people competent in > one field assuming that another very complicated field is trivial, > and extending their work into that other field, in which they are no > longer competent. Again you've proven that you do not even read what people here have written, even if they replied to you directly. I believe PHK has great respect for the cryptographers and the profession as such and that he in no way finds it to be trivial, quite the opposite. But you seem to enjoy writing more than reading and you probably talk a lot because you enjoy hearing the sound of your own voice. Maybe a radio show would be something for you to consider? :-> > It does mean that if I invented a new mode for using a set of > ciphers, I would first send them to a bunch of crypto geeks to vet, > then I would write a detailed paper, and after a couple of years I > might consider actually using it in the real world. If you ever invent anything usable in a production environment let me know. Also let me know when your radio show will be on and on what frequency so I know when to tune out. :-> ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > I'm not going to defend what Thor said, nor do I even think it's > worth discussing as it largely amounts to an "appeal to privileged > knowledge." > However, this is some extremely sloppy thinking in your writing. You do not understand what was said. > To wit: > > On Thursday 03 March 2005 02:43, ALeine wrote: > > At any time half of all the people are wrong about something, > > it's only a matter of time when your time will come to be in the > > wrong half or rather the right half to be wrong. > > That's a false dichotomy. There are many subjects on which the > vast majority of people agree (such, as, I'll wager, the roundness > of the Earth). Have you ever heard of statistical probability distribution and the logical principle of bivalence (tertium non datur)? If at any time there are x people then exists (vertically mirrored E) such a proposition P that for at least x/2 of the people the proposition R "x is wrong about P" holds true. The people who are wrong and the proposition(s) are dynamic and change with time but that property remains true at all times in a system with sufficient propositions and a large enough number of people. Q.E.D. > It is being given a chance. "Giving it a chance" does not mean > "stepping back and ignoring it until someone publishes an exploit." Giving it a chance does not mean spreading FUD about it and shouting around "It's new, it must be bad! I have not even read the papers or looked at the code myself, but I will criticize it because I like NetBSD better!" If you want to really be constructive do something that is constructive, analyze GBDE, write a paper, improve the code. You're just adding noise to the discussion, you may have as well commented on my punctuation marks. > At least one weakness has been identified -- namely, using a weaker > encryption mode for the key-key blocks can reduce the strength of > the entire system. Or to put it metaphorically, "an algorithm is only > as strong as its weakest link." You really don't know what you're talking about, do you? > > GBDE is not replacing anything because there was nothing like > > it to replace in the first place. > > That's purely false. There are several other disk encryption > systems around. You're right, IIRC PKZIP v1.10 had DES encryption back in 1990, someone should have told PHK! :-P Please, get a clue, read PHK's papers. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > Unfortunately, all these well-intentioned and very intelligent > people were wrong. The novel cryptographic modes they designed > to always be harder to break were in fact sometimes -- in fact, > in the case of PCBC, pretty much always -- easier to break than > the boring, ordinary, pedestrian constructions they were meant > to replace. > > And after all those well meaning and clever people got burned > over the years, the consensus of the community of experts (as > I percieve it, anyway) gradually became that novel cryptographic > constructions should not be used in implementations until they > had been extensively studied over a period of many years by > experts. At any time half of all the people are wrong about something, it's only a matter of time when your time will come to be in the wrong half or rather the right half to be wrong. That stops neither half from going forward and doing what they feel is right. Just because there is a tendency for new cryptographic systems to be broken does not mean this applies to GBDE, otherwise anything new would be considered wrong and we might as well stop even trying to innovate. Give GBDE a chance. GBDE is not replacing anything because there was nothing like it to replace in the first place. Also, there is a catch 22 situation with studying things without using them. The longer you study something without using it the less likely it is to make it into production, the world is not waiting for anyone. GBDE is here, you can analyze the design and the code, when you do a formal analysis let us know, shouting "It's new, it must be bad!" is not an argument. > Those who do not know the mistakes of the past are doomed to > repeat them. Those who are afraid of making mistakes are sentenced to regretting that mistake and living in the past. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > On Wed, Mar 02, 2005 at 04:33:16PM -0800, ALeine wrote: > > [EMAIL PROTECTED] wrote: > > > It is _plainly_obvious_ that if you encrypt 2^30 sectors each > > > with a different 128 bit key then there are at most 2^158 > > > different > > > ways to decrypt the entire disk. Period. > > > > out which of the 2^128^(2^30) sector variations is the right > one? > > Which, I think, is 2^(128 + 30) == 2^158, which is what Roland > said. No, you are wrong. 2^128*2^30 = 2^158 We are actually dealing with: (2^128)^(2^30) = 2^(128*2^30) = 2^(2^37) = 2^137438953472 ^--- notice the minor difference ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > > You are mistaking people who design cryptographic algorithms > > and those who design cryptographic systems which integrate those > > algorithms into functional systems. > > No, I am not. PHK invented new cryptographic modes for his work. > The fact that he does not understand this is part of the problem. He designed GBDE to always be harder than and never easier to break than the cryptographic algorithms it relies on. Not only that, but it does not rely exclusively on any single cryptographic algorithm and it does not reuse keys, both of which CGD is guilty of. > > Would you care to explain what qualifies Roland as a more > > competent cyrptographic system designer than PHK? > > Roland didn't try to do anything that wasn't already heavily > understood in the literature. He invented no cryptographic modes. > He used only algorithms that have been pre-vetted. He also asked a > bunch of people who know better than he does to check his work. > > Thus, you don't have to trust Roland at all. He didn't invent any > new way of using any of the algorithms. You have to trust only the > designers of the block cipher you choose to use (I'd suggest AES) > and the password algorithm you choose to use (though the PKCS stuff > is very good already). In order to permit even greater defense > against key cracking, he put in a very standard and straightforward > mechanism to permit N factor authentication. MD5 was believed to be heavily understood in literature. It was well established. Look at what happened to it. The fact that Roland did not invent any new ways of using algorithms does not mean that CGD is more secure. In fact, IMHO it is less secure because it uses the same key for the entire disk and because it reuses the same key for IV generation and encryption. You have to trust Roland to integrate the well known and understood algorithms in a correct way, trusting the algorithms alone is not enough. In that regard, I would rather trust PHK's proven and very well established track record as a programmer than Roland's. To be honest, the first time I heard of Roland was when I found out about CGD, I have not seen his name mentioned in any other reference before. On the other hand, I have known about PHK being an excellent programmer for at least a decade now. > > There is a reason everything happens so slowly in the academic > > circles. Everyone is trying to cover their asses and trying so > > hard not to be wrong that they analyze everything ad nauseum. > > No. You Do Not Understand. I am speaking from personal experience and I know very well what the academic circles are like, at least in Europe. > Are you as good a cryptographer as Ron Rivest? I certainly am > not. Somehow, however, MD5 has been crushed anyway. This is not > unusual. Cryptographic algorithms are not like sorting algorithms > or graph traversal algorithms. When you're doing 3DES, it is not > obvious that doing the CBC on the outside instead of between the > rounds is critical to good security -- indeed it wasn't obvious > even to trained cryptographers. I am not designing cryptographic algorithms, what PHK did with GBDE cannot be compared to inventing MD5, snap out of it, you are starting to sound like a broken record. > If you aren't as good as Ron Rivest, then why are you expecting > to design a new cryptographic mode on your first try without any > issues arising? It is your unfounded assumption that one has to get it perfectly right in the first try, not mine or PHK's, AFAIK. Again, we are not discussing the invention of the successor to SHA. > WEP is even weaker than its design. That is because its designers > did not know what they were doing. I assure you PHK knows very well what he is doing and I think you should not mention his name in the same breath along with the names of the designers of WEP. > Inventing new cryptographic modes is dangerous. Living is dangerous, today you are here, tomorrow you might get hit by a bus. But that does not mean you will stay inside your house where you are safe (at least from buses) forever, does it? > Anyone can get a paper published at Crypto or Eurocrypt. You need > no PhD or other credentials. All you have to do is have something > interesting to say. People who are "outsiders" get stuff > published. Your claim is baseless. Getting a paper published does not mean much. Do you know how many papers get published at various conferences in Europe and nobody ever even reads them, let alone implements any of the ideas in a production environment? > In general, geeks are meritocratic. Crypto people are not unlike > other geeks. If you find that crypto people laugh at you, it is > probably not because you don't know the right
Re: FUD about CGD and GBDE
I must have missed this one before. [EMAIL PROTECTED] wrote: > Most of this started when I disputed some of the wild claims that > PHK has made about the security of GBDE. You have not disputed them, you have only confirmed the strengths of GBDE and exposed the issue of atomic writes. > Let me restate: > > In: > > http://www.bsdcan.org/2004/papers/gbde.pdf > > The claim is made that there is at least O(2^256) work to crack a > disk and O(2^384) to crack the disk if the lock sectors are > destroyed. Have you read PHK's paper located at: http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf > I do not believe that I need any credibility whatsoever to call > shenanigans on these outrageous claims. > > It is _plainly_obvious_ that if you encrypt 2^30 sectors each > with a different 128 bit key then there are at most 2^158 different > ways to decrypt the entire disk. Period. You need 2^128 steps to break the encryption of a single sector. But you have no idea which of the 2^128 sectors is the right one, so you store all of the 2^128 * 512 = 2^137 bytes. Right, which movie is this from? Imagine that you could do the same with the next sector... And you do this for 2^30 sectors and then figure out which of the 2^128^(2^30) sector variations is the right one? This is the worst case scenario for an attacker and it obviously is beyond anyone's dreams. You have to resort to attacking GBDE using knowledge about how it does encryption if you want to have any kind of realistic chance of breaking it. In the paper I mentioned PHK analyzed the attack vectors and what kind of threat each one of them represents. You act as if you could just brute force GBDE automatically. It cannot happen. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: > > We need more ideas and more people trying out ideas. > > There is a profession called "cryptographer" out there. They are > the folks who try out these new ideas, and they fill lots of > conference proceedings with their new ideas, including things like crypto > modes designed specifically for disk encryption. You are mistaking people who design cryptographic algorithms and those who design cryptographic systems which integrate those algorithms into functional systems. PHK does not need to invent the replacement for SHA in order to be a competent and well respected cryptographic system designer. Besides, there are too many well respected academics who do nothing but attend conferences, PHK has actually implemented something that works and that has so far been publically recognized as solid by two very well respected cryptographers. > People who are members of this profession spend many years > learning what is and is not likely to work when it comes to various > cryptographic schemes, and they often learn the hard way that > most new ideas in cryptography fail under scrutiny. Even the best of them > are very leery of recommending the use of their own new schemes in > the real world before they have been heavily reviewed. Even if you > are Ron Rivest or Don Coppersmith, you make mistakes, and sometimes bad > ones. Would you care to explain what qualifies Roland as a more competent cyrptographic system designer than PHK? > Were you a cryptographer, and were you proposing, in a > theoretical way, a new cryptographic mode for doing disk encryption, > and were you presenting it in a paper at Crypto or some such, well, > that would be perfectly fine. People could then review it, tear it > apart (or fail to) etc, and no one would be harmed. The papers are there, the code is there, review it, analyze it, talk about it on TV. Just because it was not done in the way academics like to do it does not mean it has any less merit. Heck, I would love to see Erez Zadok's NCryptFS, but the academic process seems to be so slow that we'll be lucky to see anything before 2006. If PHK took that road we'd be looking forward to GBDE in FreeBSD 7. > Instead, however, what is happening is that you are implementing > your ideas, which do not appear to be very well founded in the > experience the crypto community has gained at great price, and > they're being tested first on actual users before any peer review > of your design. There is a reason everything happens so slowly in the academic circles. Everyone is trying to cover their asses and trying so hard not to be wrong that they analyze everything ad nauseum. The bolder approach PHK took is well thought-out and some compromises were made with full awareness of the consequences because GBDE is designed to be usable and improved, it's not a final solution. Using it will expose any weaknesses it might have and if/when they are discovered you can be sure they will be fixed. Along with the analyses done on it, it's the best way to make sure you have something usable and cryptographically solid both today and in the future. > WEP was a particularly amusing case, because, like you, its > designers thought that it was safe to use an existing encryption > algorithm in ways that they never even realized were new and potentially > damaging. They didn't understand what they were doing, and so the > results were very bad. WEP relies on RC4 and has a 24-bit IV which means the key stream will definitely get reused after 5 hours of heavy traffic. You are not only comparing apples and oranges, but apples and straw now. Read PHK's papers on GBDE - all of them. You are clutching at straws. > Let me also mention that everyone who does crypto work hears, at > intervals, what horrid insular people cryptographers are and how > little respect they have for "outsiders". Actually, nothing could > be further from the truth. The crypto community is very open -- but > it is a meritocracy, and merit is not demonstrated by throwing lots > of stuff to the wall and seeing what sticks. Everyone who has the proper education from one of the elite universities, knows the right people, has not dared publish anything seriously relevant to outdo their mentor before he retires and everyone who dismisses everyone else who does not have the same pedigree of a proper cryptographer is welcome to join the crypto community, of course. IMHO, the academic community looks at the IT industry with scorn when someone dares insult them with a solution that might prove to be better than something they have been working on with an entire team of international academics for years. ALeine __
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > I can not encourage you enough to try it. > > Don't let peole like Thor scare you away, progress happens when > people try to follow their ideas, even if told that they are fools by > people who (think they) know better. Thor? Who is Thor? :-> Seriously, this discussion is only making me more eager to implement my ideas, I know exactly what I want to implement, it just might take me more time than you seasoned kernel programmers who live the code. :-) ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
Again I was left out of the loop by a certain someone who is not subscribed to [EMAIL PROTECTED], so I apologize for replying indirectly. [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, > "Steven M. Bellovin" writes: > > >I don't claim that there's a flaw. I do assert that that I > >haven't seen a threat model that would justify extra complexity. What about the threat model I described in my reply to you: http://docs.FreeBSD.org/cgi/mid.cgi?200503010320.j213KI8U047666 Do not let the 666 at the end scare you. :-) > It is all sounds and true advice about simplicity, but only if we > don't simplify so much that people do not trust the result. > > As Einstein said: "As simple as possible, but no simpler". Exactly, and people should stop trying to apply Occam's razor (the principle of parsimony) in an attempt to justify the simpler approach when the basic premise for it does not even exist. Occam's razor favours the simpler of the numerous explanations/solutions for an observed phenomenon. Here you have two distinct mechanisms that are not the same phenomenon, eventhough data is being encrypted in both cases. Here's an analogy: GBDE is like a jacket with many pockets both on the inside and the outside, with some secret pockets with keys for other locked pockets within pockets. If someone steals you jacket they might be able to pick some pockets, but picking one pocket will not give you the contents of all the other pockets, nor will it give you their location. CGD, on the other hand, is like a large bag, if you manage to get hold of it and open it (the same assumption as in being able to look inside a regular jacket pocket), everything inside it is yours. I prefer jackets, they also keep you warm. Besides, wearing a bag would be silly, but some people might decide it's their style. :-> ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Thor Lancelot Simon > writes: > > Where I come from "home-grown" is not derogative. All > cryptosystems are by necessity home-grown for somebody somewhere. I second that, standards do not come into existence out of thin air and we might get to see the day when GBDE becomes a standard. Now I'm waiting for someone to say that's only how we Europeans think eventhough we have no common identity as Europeans. > >Generally, complexity is not considered a desirable property in > >cryptosystems. GBDE violates this rule in spades. There are > >_reasons_ why complexity is not good: to begin with, a very complex > >cryptographic construct will require detailed analysis (which it > >does not appear GBDE has had by anyone but its author until Roland > >started looking at it) in order that we may know that it is even as > >secure as the underlying algorithmic building blocks it uses. > > Both Lucky Green and David Wagner has nodded vertical on GBDE. I trust the professional opinions of both Lucky Green and David Wagner at least an order of magnitute more than that of Roland Dowdeswell, especially after this discussion. Just what exactly is it about GBDE that is complex? You could explain the concepts behind GBDE to a 12 year old and they would understand them. The complexity lies not in analyzing GBDE but in breaking it. You can analyze it to see how you could break it, but breaking it is something that goes way beyond brute forcing individual sectors. CGD, on the other hand, is the perfect victim for such brute forcing. > I can not convince myself that encrypting a 40 GB disk sector by > sector using the same key, even if it is 256 bits, is a safe > design. Neither can I, which is why I will base my work on GBDE. ALeine P.S.: All you people cross-posting out there please cross-post properly (CC me). :-> ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > I gave up on journalling myself because IMO it complicates > things a lot and the problem it solves is very very small. If only hardware manufacturers were to equip hard drives with a mechanism to ensure atomic writes. A capacitor large enough to hold enough energy to flush the cache upon detecting the power supply was cut would be sufficient. They could even use a battery the status of which could be monitored via S.M.A.R.T., I don't see how implementing something like that could possibly make the cost noticably higher. Recent IBM Thinkpad and Apple PowerBook G4 laptops have sudden motion sensors which park the disk heads when a sudden motion is detected in order to prevent damage from a fall and similar, so this atomic write guarantee mechanism should be trivial for them to implement and it would save us a lot of work. > The impact in disk seeks is non-trivial to predict, but it is > very hard to argue that it will not lead to an increase in > disk seeks. (This is really a variant of the age old argument > between jounaling filesystems and "traditional" filesystems) > > I can only recommend that you try :-) Journaling would definitely cause more seeks, but the question is how well that can be compensated for by the reduction of writes gained from using the other speedup mechanisms I proposed. I might try implementing this in GBDE first to see what the benchmarks say. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Bernd > Walter writes: > > >And how would you know that a restore from backup is required > >for a damaged file? > > 100% true. > > The trouble is that it would cost a lot in performance and a > doubling in metadata to protect yourself against this. Not necessarily, if one were to implement the ideas I proposed I believe the performance could be kept at the same level as now. To summarize my ideas: 1. Introduction of journaling I described this idea in detail here: http://docs.FreeBSD.org/cgi/mid.cgi?200502282202.j1SM21qs042751 The user would decide how many key sectors would be using a single key shadow sector, for example, 1 key shadow sector for every 8 key sectors. That would add only 1/8th (12.5%) in metadata size and 1/264th (0.38%) overall. On a 400 Gb disk this would be 1.5 Gb. 264 = 8 * (32 data sectors + 1 key sector) Then a kernel sysctl variable would control whether journaling is enabled or not (kern.geom.bde.atomic_writes_enabled). Now there are two possibilities: either make journaling a volume initialization option: if you specify it the key shadow sectors are allocated, otherwise not (kern.geom.bde.atomic_writes_enabled is ignored, which might make someone falsely believe that they have journaling on a volume that was not initialized for it) or make it possible to turn journaling on later by allocating key shadow sectors by default (so they are used according to kern.geom.bde.atomic_writes_enabled). One could even implement a totally automatic fsck(8) recovery of incomplete writes by storing the HMAC of the last written data sector inside the shadow key sector, there is plenty of room for it there. This way one would get data integrity and automatically recoverable volumes without having to store the HMAC for every data sector, in the example I stated above there would be one HMAC (shadow key sector) place holder protecting 256 data sectors. 2. Introduction of per-key sector grouping This would be set at volume initialization, the user would set the number of sectors that are to be encrypted with the same key. Based on this one could also increase the key size as long as all the keys for a zone fit inside one sector (for example, by having two sectors encrypted with the same key one could already use AES256). 3. Introduction of control over key regeneration cycle There would be a sysctl variable to control after how many writes the key is regenerated (kern.geom.bde.key_regeneration_on_write_cycle). This would speed things up quite a bit and users would be allowed to decide what is more important to them in terms of speed and assumed security. If all this were implemented I believe the performance on volumes initialized to take advantage of the possible speedups would not be worse than with the current implementation of GBDE. Comments? ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: > The fact that the CGD author(s) engage in this FUD spreading in > random mailing lists rather than contact me directly speaks > speaks for itself, but here are my replies to some of the points raised: Obviously this is a part of some aggressive NetBSD advocacy campaign that was started just recently, I find it hard to believe that someone just happened to find my original RFC on backporting GEOM to 4.x from like a month ago and then decided to revive the thread. Someone was looking for something recent about GBDE they could claw into. Anyone who has read recent posts by Chritos Zoulas can see the pattern, this seems to be an organized effort not so much pro NetBSD but anti other BSDs. There is really no need for that kind of campaigning, it gives a bad name to all BSDs. All software has some merit, just state the facts and let the users decide what they want. I agree with you on almost all the other points you addressed (journaling being an exception - I would make it optional, not mandatory) as I have stated pretty much the same things myself in my previous posts, so I will not further comment on that, but I would like to ask your opinion on the matters I raised about introducing the following changes to GBDE: 1. Introducing a sysctl variable to control how often (after how many writes) the random key is regenerated: kern.geom.bde.random_key_regeneration_cycle The way it works now would correspond to the value being 1 with regeneration happening on every write. Setting this higher would improve the performance and people could decide for themselves what value fits their needs. 2. Backporting to 4.x - this has more or less come to the point that I would rather write the whole thing from scratch, similar to vncrypt (ports/security/vncrypt), only implementing the main principles found in GBDE. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
27;t help; > you still need to read, decrypt, re-encrypt, and rewrite each block, > since any likely compromise scenario would involve compromise of the > key block as well. Agreed, the user-specified key would be used to encrypt keys for data encryption, so only those keys would have to be rekeyed, the data itself would remain unchanged. This would be done in a way which would not make it possible for someone to reconstruct the master key or decrypt any other keys, so any compromise would be very localized. The user-specified key would naturally have to be changed regularly because it is the weakest link in that chain. > There's a school of cryptographic design that tosses in > mechanisms on the vague hunch that there's threat out there. Unless you > understand the threats and the tradeoffs, though, you're likely to make > matters worse, not better. Often, there is no perfect solution, but if > you don't understand the *real* threats you'll make the wrong tradeoffs. > > It's worth noting that there is a very real threat not addressed > here: detecting unauthorized changes to an encrypted disk. For a very > elegant solution, see > http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf Thank you, I will definitely take a closer look, perhaps that approach might also be used to provide faster guaranteed atomic writes in a multistep scenario such as the one I described. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
ent in GBDE and eventhough not that many reputable cryptographers have reviewed GBDE so far, those who have are very well respected, like Lucky Green, for example. I hope you will find the time to write an analysis of the weaknesses you found, I would be very interested in seeing if they would apply to what I have in mind. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: > This does not work. The problem is that in GBDE for sector n > which is written, there are two operations: > > 1. change the key by which sector n is encrypted, and > 2. write sector n ecnrypted with the new key. > > If one of these fails, how could the write be ignored? If one of > the two completes but not both, then one is left in the situation > of either: > > 1. trying to decrypt the old sector with the new > encryption key, or No. > 2. trying to decrypt the new sector with the old > encryption key. Yes, the data sector is written first and then the key sector. Since, as you pointed out, GBDE is more susceptible to dictionary attacks than CGD one can then use this advantage (it's a feature, not a design flaw!) to recover the lost key so no data is lost. :-> Seriously, how can one make writing atomic without breaking compatibility with existing GBDE volumes? Which approach does CGD use to solve the problem of atomic writing? How about changing GBDE in a backwards-incompatible way by adding one key shadow sector for every n key sectors (n would be chosen at volume initialization)? The key shadow sector would hold the xor of the last encrypted key in the zone to be replaced and its replacement key, a 32 byte status chunk to indicate the status of the operation: all zeros (0x0) would indicate the new key has not been written to the key sector yet (but it is present in xor-ed form in the key shadow sector), all ones (0xFF) would indicate the new encrypted data sector has been written successfully and random garbage would indicate that both the new key and the encrypted data have been successfully written to disk. Then the relative offset of the key sector from the key shadow sector would follow and then the offset of the key within the key sector. The rest of the sector would also be padded with random garbage which would be regenerated every x writes (this value could be tunable via sysctl, kern.geom.bde.garbage_recycle_freq). The whole write procedure would look something like this: 1. read old key from key sector 2. xor-ed key = new key ^ old key 3. pad xor-ed key with: - status chunk: 32 0x0 characters - relative offset of key sector from key shadow sector (chosen at volume initialization, 8 bytes by default) - relative offset of key within key sector (8 bytes by default) 4. write padded xored key to key shadow sector 5. encrypt data with new key 6. write encrypted data to disk 7. set status chunk in key shadow sector to 0xFF 8. write new key to key sector 9. if (number of key writes % kern.geom.bde.garbage_recycle_freq == 0) then overwrite control chunk in key shadow sector and the rest of sector with random garbage else overwrite only control chunk in key shadow sector with random garbage (not to waste entropy) endif > Either way, the sector has been lost. Neither the original > contents of the sector nor the new contents can be recovered without > breaking AES-128. Fsck(8) does not contain this functionality (and it > would be rather impressive if it did.) The solution I proposed always provides consistent atomic writes. If only the encrypted data sector gets written and the key does not get written to the key sector, you can recover the new key by xor-ing the xor-ed key from the key shadow sector with the old key. That way fsck(8) would only need to walk through all the key shadow sectors and check for 0xFF status chunks and recover new keys automatically. Zero control chunks would have to be handled by the user since fsck(8) would have no way of telling whether a zero chunk means the newly encrypted data got written to disk (and the plug was pulled just before the control chunk was to be set to 0xFF) or not (the new key just got written to disk in xor-ed form, but the existing key and data are unchanged). The simplest way would be to let fsck(8) report and record all zero chunks in the form which could be fed to a utility which would set the key directly. The input (output generated by fsck(8)) for such a utility would consist of the device name, relative offset and the key. Both options would always be listed and then the user could try all the alternatives and see which key is the right one. There would be a performance hit, but I would like to see this implemented to see just how big the difference would be. What do you guys think of this solution? ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: > [ cc'ing [EMAIL PROTECTED], because there has been talk > of GBDE there in the past.] > > Well, I thought that since I saw this: > > ALeine wrote a while ago: > >[EMAIL PROTECTED] wrote: > >> > >> Wouldn't be easier porting cgd* from NetBSD ? > >> > >> * http://www.netbsd.org/guide/en/chap-cgd.html > > > >Perhaps, but I believe GBDE to be superior to CGD for a number > >of reasons, one of the most important being that with GBDE you > >can change the passphrase without re-encrypting the entire disk, > >which is not the case with CGD, AFAIK. From Poul-Henning Kamp's > >paper on GBDE: > > That, as the author of CGD, I should respond to some common > misconceptions about my work which seem to be percolating around. > > First, on the capability front, you can: > > 1. change the passphrase on a disk without re-encrypting it, > 2. have as many passphrases as you would like to configure, > 3. use n-factor authentication with arbitrary large n. > > Also, GBDE has a number of serious drawbacks. All of which would > be show-stoppers if I were considering using it for serious security > work, or even use in a production environment. > > There is no protection _at_all_ against dictionary attacks. Where > CGD uses PKCS#5 in a completely standard way to frustrate dictionary > attacks, GBDE does exactly nothing. In fact, worse than nothing. > It is possible to conduct half of the dictionary attack offline, > so the actual online portion of the attack is something that my > laptop could make about 2^30 guesses in a couple of hours. So, it > is insecure from the start. > > GBDE has no facility for using different encryption algorithms than > the rather... interesting one that it comes with. There is no > way to trade speed and security for different use cases, and the > only algorithm that it comes with is very slow. Less than half > the performance of CGD's most secure algorithm (AES256). > > So, now that we've touched on the security problems... Let's think > about using GBDE in production. Please reference > > http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf > > And read Section 7.5, and refer to figure 2. > > Each disk write involves two writes to the disk. Where is the > journal? I do not see any talk about a journal in the paper, or > the GBDE source code. Hence, if the OS crashes or if a removable > disk is removed at the wrong time, etc. etc. it is possible that > only one of those writes would succeed. I think that we can all > see where this is going. > > -- > Roland Dowdeswell http://www.Imrryr.ORG/~elric/ Thank you for taking the time to write that very informative post. I was not fully aware of all the issues you raised here, I'll look into them. In the meantime maybe someone more familiar with GBDE than myself could share their comments. I am CC:-ing this to freebsd-hackers@freebsd.org as well since I originally posted there as well. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sandisk cruzer mini quirks [failure] on RELENG_4
[EMAIL PROTECTED] wrote: > I did this as the first hack. It made the problem worse. I'll try > patching both umass.c and scsi_da.c maybe they will have some sort of > synergistic effect. You said the problem occurs only when you copy files to the device using cp(1) and not dd(1). The main difference between how cp(1) and dd(1) copy files (other than cp(1) mmap(2)-ing files which are <= 8 Mb in size) is that cp(1) copies files in 64kb (MAXBSIZE) chunks while dd(1) copies files in 512 byte chunks by default. They both use read(2) and write(2), so I would suggest using dd with bs=64k and then applying the bisection method to find the largest transfer block size for writing the device can handle. Does this problem occur with cpdup (ports/sysutils/cpdup) as well? It currently copies files in 32kb chunks, which could easily be changed since the transfer block size is set in a single place. You may want to patch cpdup to use the maximum transfer block size the device can handle as a temporary workaround and then use cpdup for copying files to the device. > maybe i should just bite the bullet and upgrade the box to 5.3. Let's hope you won't have to. :-) Can you verify that this problem does not occur on 5.x without upgrading (by using a FreeSBIE LiveCD)? ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sandisk cruzer mini quirks [failure] on RELENG_4
[EMAIL PROTECTED] wrote:
> I have a 512mb version of the SanDisk Cruzer Mini keychain drive.
> ProductId = 0x5150 (VendorID=0x0781). I am unable to correctly
> get it to stop crashing the system when using cp(1) to copy large
> files to it.
> I patched /usr/src/sys/dev/usb/umass.c as:
>
> if (UGETW(dd->idVendor) == USB_VENDOR_SANDISK &&
> (UGETW(dd->idProduct) == 0x5150) {
> sc->proto = UMASS_PROTO_SCSI | UMASS_PROTO_BBB;
> sc->quirks |= IGNORE_RESIDUE;
> }
Try extending da_quirk_table in sys/cam/scsi/scsi_da.c with an
entry like this:
{
/*
* SanDisk Cruzer Mini 512MB
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, "SanDisk" , "Cruzer Mini", "*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE
}
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sharing data between user space and kernel
[EMAIL PROTECTED] wrote: > Could you please point me to the place where "GEOM > gstat" is implemented ? I don't seem to find it :-( You can find gstat in src/usr.sbin/gstat if you have the source tree on your disk or online at: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/gstat/ ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error in my C programming
[EMAIL PROTECTED] wrote: > If anyone can recomend online resources for Makefiles I would > apreciate it :) How about a source which is already on your disk? :-) zcat /usr/share/doc/psd/12.make/paper.ascii.gz | less You may also want to study the first chapter of the FreeBSD System Programming book at: http://www.khmere.com/freebsd_book/html/ch01.html Reading about the alternatives might be a good idea as well: http://developers.slashdot.org/article.pl?sid=05/01/29/2033230 ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: remote connection to mysql
[EMAIL PROTECTED] wrote:
> use DBI;
>
> my $dbh = DBI->connect(
> 'dbi:mysql:[EMAIL PROTECTED]:3306',
>'user', 'passwd', {
>RaiseError => 1, AutoCommit => 1
>}
> );
>
> Yet I continue to receive connection errors. Can't connect to
> the MySQL server on 3306 (10061). I'v verified that the server is
> listening on the port. I also found some info on google about
> Perl DBD::mysql problems. I tried resetting the user's password
> with the OLD_PASSWORD option. Nothing works. Can anyone help???
Error code 10061 = connection refused. Are you sure there is no firewall
in place blocking access to port 3306? Can you telnet to host.org 3306?
If so, you might want to try changing your script like this:
use DBI;
my $dbh = DBI->connect(
'dbi:mysql:database=;host=;port=3306',
'user', 'passwd', { RaiseError => 1, AutoCommit => 1 }
);
Otherwise if you are running 4.10 you might want to use sysctl to set
net.inet.ip.portrange.randomized to 0.
Use may also want to use sockstat to make sure your script is actually
trying to connect to the right IP.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: occasional ECONNREFUSED when connect()ing.
> After further investigation and digging, I uncovered the true cause of > the error: connect() returning ECONNREFUSED. You are probably exhausting the queue of pending connections, you may want to read man 2 listen and use sysctl to set kern.ipc.somaxconn accordingly. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ln question
[EMAIL PROTECTED] wrote: > I have one strange thing about 'ln' command. > my box is 5.2R. This is not strange, it works exactly as expected, but you do not seem to understand how ln works. Read on for the explanation... > I built some directory on $HOME , such as $HOME/a/b > I want to create a symbolic link for 'b' under top directory , > $HOME. > > so , I typed some command as > > $ mkdir $HOME/a > $ mkdir $HOME/a/b > > $ cd $HOME/a > $ ln -s b ../ > $ cd $HOME/b > cd: can't cd to /home/matrix/b > $ file $HOME/b > b: broken symbolic link to b You created a symbolic link $HOME/b which is pointing to b. Since it is not pointing to an absolute path ($HOME/b -> /home/you/a/b), but rather a relative one ($HOME/b -> b), the full path is obtained by using the directory which contains the symbolic link as the base directory, meaning your symbolic link is pointing to itself. If you used a shell like tcsh you would see something like this when trying to cd due to the recursion caused by the self reference: b: Too many levels of symbolic links. > but when I also created another symbolic link as following again > , it is > ok. why is it broken symbolic link?! > $ rm $HOME/b > $ rmdir $HOME/a/b > $ rmdir $HOME/a > > $ mkdir $HOME/a > $ mkdir $HOME/a/b > $ cd $HOME > $ ln -s a/b . > $ cd $HOME/b You created a symbolic link $HOME/b which points to a/b. Because it is pointing to a relative path, again the directory containing the symbolic link is used as the base directory, meaning your symbolic link is pointing to $HOME/a/b, which is what you want. Reading man 1 ln and using ls -al to check where your symbolic links are pointing would have made that clear. You may want to post such questions to freebsd-questions@freebsd.org in the future. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: > What about porting NetBSD's cgd(4) [1] driver ? It *might* be > easier to port since it does not require GEOM. Thanks for the suggestion, but IMHO GBDE is superior to CGD, as I have already explained in detail a couple of weeks ago: http://leaf.dragonflybsd.org/mailarchive/kernel/2005-02/msg00037.html ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode - HELP!
[EMAIL PROTECTED] wrote: > We have two NFS file servers running FreeBSD 5.2.1-RELEASE-p9 on > Dell Poweredge 1750's that crash randomly. They each have about 1.3TB > of disk. They are used to server email and web content to several > WEB/EMAIL servers. Followin is the console log messages and the kernel boot > messages. Any ideas as to what the problem may be? Try turning TCP SACK off by putting net.inet.tcp.sack.enable=0 in sysctl.conf. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for comments: CoxR, a CVS/mail-lists/BTS
[EMAIL PROTECTED] wrote: > If I were to reply in kind to your message, it would be something > like: > > Listen you worthless hunk of flesh. I'm not trying to insult > you, since I have the utmost respect for the miserable life > you no doubt must lead. Nothing could be farther from the > intentions I had when I set out ot write this, but you clearly > could use a personality transplant. > > The secret to effective communication is making sure that you > communicate the message that you intend to communicate. By > saying in one paragraph that you have the utmost respect for people > (and by the way misunderstanding how the core team works and its > relationship to the project, but I digress), and then insulting > them in the next paragraph, you're clearly showing your contempt > or disrespect. > > Please, learn some manners. The secret to effective communication is making sure you first understand what was said before speaking up. If you were to reply in that manner I would have to conclude either that you grossly misunderstood what I had said and that you were overreacting in an insulting and patronizing manner unbecoming of a Core team member or that someone else was posting as you. If I were then to reply in kind it would be something like: Dear Mr. Losh, a village idiot seems to be posting as you and lashing out against me. I am not impressed, but you may not find the impact of such posts important enough to prevent the imposter from impersonating you further with impunity. Someone more impartial might impart the same advice, but it is up to you to decide how impeccable or impaired you want your reputation to be. If you care to reread my previous post you might notice that in the first paragraph I was referring to the post I posted before my previous post. I also said I had a lot of respect for the (current) Core team members and that I have utmost respect for Mr. Watson (my utmost respect does not extend to the entire team, you misunderstood that as well), who is unlike certain former Security Officers. Why you are lashing out against me and jumping to conclusions is not clear, but I suspect that it must fall under the "If the shoe fits" category with you being both a former Security Officer and a current Core team member. There are no contradictions in what I said. I have a lot of respect for most of the current Core team members (sadly, that status changed slightly after your post) and Mr. Watson still has my utmost respect. I never intended to insult Mr. Watson in any way, I was making a point about the complexity of the system going too far. Complexity of the system was the issue, but nobody even mentioned that in their replies, yet all those who replied got very defensive and offensive and started going on about disrespect in an attempt to turn this into a personal issue. But I digress, you see what you want to see. I will attribute your incorrect conclusion that I am misunderstanding the role of the Core team to the same misunderstanding and flawed reasoning that led you to the conclusion that I was being disrespectful to the current Core team members. I was not, my comment in the previous post was directed at Kris Kennaway, your successor in the role of Security Officer. One who advises others to learn some manners should at least try to show one has at least some manners oneself. Using words like worthless, miserable and personality transplant while directly addressing someone you claim should learn some manners is not the best way to show manners, at least not in Austria. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS
[EMAIL PROTECTED] wrote: > Consider not insulting the intelligence of the FreeBSD developers > if you want them to ever help you again with your kernel newbie > questions. That kind of trash-talking may be cool in other > projects, but around here it's not going to win you friends. Consider not mischaracterizing, belittling and alienating people for voicing their opinions. I had no intention of insulting anyone, my point was exactly the opposite of what you seem to believe - I claim that if such seasoned, highly intelligent and skilled developers do not feel comfortable making changes to certain subsystems then that is an indication that the complexity has gone too far. Let me reiterate, I believe the Core team members to be highly intelligent, skilled and friendly people and I have a lot of respect for them and their work. I have utmost respect for Mr. Watson because I believe he better than anyone else embodies the spirit of the Project, he is always very informative, thorough, helpful, friendly, polite, willing to share his vast knowledge and experience and offer his insight, unlike certain former Security Officers. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS
[EMAIL PROTECTED] wrote: > I appreciate that not everyone is a fan of mutex synchronization, > but "mutex hell" is a bit of an odd description: most bugs I see > getting reported (and fixed) aren't even locking-related. They're > generally a property of lack of testing exposure for more obscure > features or edge cases that are hard to test for without a wide > testing base, such as edge-case hardware, bugs associated with > longer run times, or a recently introduced feature, etc. Well, mutex hell is more of a humorous description, but unfortunately it is not too far from what is becoming a reality. I believe that the path the FreeBSD Project has taken with the 5.x branch (not only in regard to mutex locking but in general) has made things far too complex in ways that make even seasoned hardcore developers such as yourself unwilling to touch certain subsystems because only one or two people really understand that system well enough to introduce only a few (instead of a few dozen) critical bugs when changing that subsystem. Or do you want to tell me that you could go right in and get the critical section related stuff sorted out on your own without John Baldwin and Stephan Uphoff in order to get to merge your UMA related changes? :-) I've been examining kernel sources in greater detail these past few days and from what I've seen so far I believe certain subsystems should just be rewritten from scratch in order to simplify things in terms of solving MP problems and UP performance (burning a lot of unnecessary cycles on every mutex release and the like is just not acceptable, IMHO). Rewritting the IPI code and the scheduler should be a good start, but I doubt anyone from the Core team would even consider that because you've all invested so much into what is in place now. As you keep working on the same things you've been working on for years things get more and more complex and you become more and more resistant to change, while potential developers become more and more discouraged and in the end things might get very stale with only a handful overworked developers who won't be able to see the forest for the trees. I do not mean to start a flame war or anything, this is just my opinion, I do have a lot of respect for all of you guys working hard on the 5.x and the 6.x branches, I just politely disagree with the direction in which the project is heading. :-) ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS
[EMAIL PROTECTED] wrote: > Thanks for the many feedbacks about CoxR. > We modified the CoxR based on feedback. > And so, please try CoxR function once more. > I would like to have your impressions on the above mentioned information > system as an open source expert > Any feedback including the answer of questions above, comments, suggestions, > etc are always welcome, I took a quick look, but the page does not even display properly due to bad HTML. I suggest you run a HTML validator on the page and clean up the HTML code first: http://validator.w3.org/check?uri=http%3A%2F%2Fscorpion.ics.es.osaka-u.ac.jp%2Fcgi-bin%2FCodeSearch%2Fcoxr.html > Bug Trucking System Oh come, FreeBSD 5.x does have a mutex hell going on, but to say it has so many bugs as to require a truck is absurd. :-> A smaller lorry perhaps, but a truck - definitely not. :-) It might also be a good idea to use an automated spell-check on your pages, I've noticed a number of typos such as "divelopers" and similar. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: > The subject of doxygen has come up a few times, and people haven't been > too keen on it: > > http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00197.html > http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00199.html > > I'm assuming you'd have to have the extra data from doxygen to generate > those graphs, as I've not done that process, myself. Basically, doxygen generates graph file language (dot) files, which are then fed to graphviz to generate the graphs. An important thing to note is that the HTML generated by doxygen uses map area tags, which means that graph nodes are clickable, so you can browse code graphically and very quickly familiarize yourself with all the dependencies and intricate details. Here is another demonstrative example: http://manson.vistech.net/~manager/vfs__syscalls_8c_a44_cgraph.png If you install doxygen from the FreeBSD ports (devel/doxygen) it will automatically install graphviz (graphics/graphviz) and then you can just launch doxywizard and create a doxyfile within 3 minutes even if you've never set eyes on doxygen before. Once you are happy with the results all you need is a cron job to run doxygen using your doxywizard generated doxyfile. There is no maintenance overhead, so I do not see a reason why this should not be implemented. Also, the generated documentation can reside where ever you want it to be, so the source tree can remain intact. This sort of documentation should be seen as supplementary and not as a replacement for the handbook documentation or anything else. It's also not meant to be implemented in a way that would interfere with the established source coding and documenting practices. The few developers who "live the code" could totally ignore the doxygen generated documentation, but the rest of us would find it a great help to have this kind of resource. I also think that even those hardcore developers could use this kind of documentation for quickly looking up all the functions that call a certain function and to save time when explaining the details to other developers. Why spend 5 minutes describing something you can explain by having someone take a look at a graph? Maybe most developers think that etags and cscope are all they need, but to me personally the reference graphs alone are reason enough to use doxygen. As you probably know Robert Watson runs a nice FreeBSD Cross-reference site (fxr.watson.org), but I believe doxygen to be superior to the LXR/FXR engine, so perhaps it would be a good idea to replace LXR/FXR with doxygen. Any opinions on that? The bottom line is, doxygen takes 10 minutes to set up and other than a fair amount of CPU time and a few GB of disk space for the generated documentation it requires nothing special. :-) It will not interfere with anyone's work, but it will make the development process easier and more accessible to a number of potential developers. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: > What you may want to do is create a character device driver that > resembles the md(4)/vn(4) mechanism: it consumes another file or > device, forwards I/O from its own device node to the underlying > device after performing the transformation. If possible, you'd > want to attempt to provide a small and approximate subset of the > GEOM API to GBDE so that you could leave GBDE as intact as possible. I have been examining the GEOM code and at this point it seems that creating a subset of the GEOM API in order to leave GBDE intact would take more effort than ripping the cryptographic mechanism out of GBDE and integrating it into vn(4). Speaking of examining code, do you guys use data flow diagrams and other visual representation systems so you can work more quickly and effectively on such a huge and complex code base? I'm using doxygen and graphviz and I have to say they're really great, as can be seen from the following g_bde_work struct example: http://manson.vistech.net/~manager/gbde/structg__bde__work.html The rest can be found at: http://manson.vistech.net/~manager/gbde/ This sort of detailed visual documentation would allow faster development while also making it easier for new developers to join the project. What do you guys think about having such documentation for the entire source tree available on the web? Having the docs regenerated automatically once a day would probably be sufficient to be useful. > Regarding getting this into 4.x: I suspect the biggest concern > would be forward compatibility issues. It would be substantially > counter-productive to merge a feature back with a different > interface/compatibility, as it would make forward upgrades > harder. That is another reason why I think I should isolate the whole thing by creating a cryptographic character device driver (cvn(4)). It would also make it easier to port to DragonFly BSD. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: > This may not be exactly what you are looking for, but I think it > may be important to look at it at least : > > http://www.filesystems.org/ > > The project is named FiST and it uses stackable layers so you > can, for example, encrypt file content. Thanks, I'm actually familiar with the inner workings of Erez Zadok's (FiST based) CryptFS, it's been running on my test system for about 2 years now. The problem with CryptFS is that it's not of production quality, it's more of a proof-of-concept academic type of implementation. Back in 2003 I tracked down a serious (kernel-panic-causing) off-by-one bug in the FreeBSD 4 and 5 vnode fistgen templates for which I also submitted a patch. Erez said he would see to it that the patch got committed, but I just checked and I see that that bug is still present in the latest version (0.0.7). Oh well, if you want to use CryptFS on your FreeBSD 4.x and 5.x systems without kernel panics feel free to contact me for the patch. Maybe someone would be willing to put the patch somewhere on freebsd.org so that new CryptFS users can easily find it? Anyway, Erez has also been working on NCryptFS, which seems quite promising: http://filesystems.org/docs/ncryptfs/ncryptfs.html The problem with NCryptFS is that so far no code has been released and since it looks like it might get released a day after Duke Nuke 'em Forever I thought I would see what I can do about backporting GDBE to the 4.x branch. :-/ ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: > I guess the interesting question is why to do this? Thank you for your very thorough and insightful reply. :-) I've already discussed my reasons in detail with Matt Dillon, you can read our exchange at: http://leaf.dragonflybsd.org/mailarchive/kernel/2005-02/index.html Basically, it seems like I should save myself a lot of trouble and just deGEOMify GBDE so it can be integrated into FreeBSD 4.x and DragonFly BSD. I can live without GEOM GATE, but GBDE (or dGDE as it will probably be called once I'm done botching it :->) is something I really really need in 4.x. Would this be something the Core members would like to see committed to RELENG_4? I would also appreciate it very much if you could give me some pointers on deGEOMifying GBDE. Thank you, ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RFC: backporting GEOM to the 4.x branch
I would hereby like to politely request your comments on backporting GEOM to the 4.x branch. I personally would like to see GEOM backported to the 4.x branch and I would appreciate it if all the developers (especially Mr. Poul-Henning Kamp) who are familiar with the inner workings of GEOM could comment on that idea, especially in terms of giving me a rough overview of what would need to be done and pointing me in the right direction so I could get started with backporting GEOM myself. I should mention that I am an experienced programmer, but my kernel programming experience is limited, I've only done some minor work on a couple of kernel modules. I do understand that this would be quite an undertaking, so I would also like to hear from others who would be willing to work on backporting GEOM to the 4.x branch and having the port integrated into DragonFly BSD. Thank you, ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sigmatel USB IrDA dongle
Hi, I'd like to use the SigmaTel USB IrDA dongle to connect my computer (FreeBSD 4.10-STABLE) and my mobile phone (Samsung X600). According to my log, the dongle is recognized: /kernel: ugen0: Sigmatel Inc IrDA/USB Bridge, rev 1.10/0.08, addr 2 So what do I do now? I've searched everywhere and there seems to be no software I can use with the dongle (birda, lirc, gnokii all support only serial IrDA dongles at best). Is anyone working on something to make use of USB IrDA dongles on FreeBSD? If not, does anyone have some sort of alternative solution? Some Linux mini distribution with irda-tools running inside bochs or VMware? I installed VMware 3.2 from the ports because it is supposed to now support mapping of USB devices, but since it is a native Linux application it would need a true, mapped usbdevfs under /compat/linux/proc/bus/usb to actually work. Is anyone working on this? I know that almost exactly two years ago Bruce M Simpson posted on freebsd-hackers about this issue, but I have no info on what has been done. Any info will be greatly appreciated, I'm interested in making this work even if I have to spend a few months coding everything myself. Thanks & best regards, ALeine ___ WebMail FREE http://mail.austrosearch.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
