Re: secure file flag?
On 2003-11-23 17:31 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: What I'm suggesting is to have the obliteration implemented as an add on to the dirty buffer flush, with the difference that the buffer contents is prepared for the next step of the erasure process, written out, and then not declared free but again prepared for the next overwrite pass. This next pass won't be until thirty seconds later, so it'll take about half an hour to completely obliterate a file. Furthermore, These 30 seconds are not a universal constant and ISTR. I had in mind, that one obliteration pass is performed. After each pass, a cache flush has to be performed, and the next pass is performed immediately or only after a brief delay. I see, that this may cause too many CPU cycles spent traversing the buffer cache. unmounting a file system less than half an hour after a file is deleted or truncated will fail, and shutting down will most likely leave the file system unclean due to repeated failures to flush the dirty buffer list. Yes, that's why I meant that fsck might be used to trigger the restart of an erasure process that was not completed due to shutdown or a crash. This does obviously no good in case that somebody else got hold of your disk, menawhile, but it covers cases that are not dealt with by a user-land utility (which would just be stopped halfway through when the system goes down). Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-23 18:04 +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: 1. Look for BIO_DELETE in the kernel. Seems that BIO_DELETE isn't really supported anymore (according to a comment in your GEOM sources ;-) AFAICT, BIO_DELETE can't easily be made a long running operation (taking tens of revolutions of a disk media) without really hurting performance because of assumptions that it will take about the same time as BIO_WRITE ... 2. Use GBDE or other encryption. Yes, probably. But encryption is only as good as key management and secure storage (and deletion) of keys. How do you implement unattended reboot, if you consider unauthorized (physical) access to your system as one of the attack scenarios to protect against ? (Not meaning, that secure erase would really solve that problem ...) Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
In message [EMAIL PROTECTED], Stefan =?iso-8859-1 ?Q?E=DFer?= writes: Yes, probably. But encryption is only as good as key management and secure storage (and deletion) of keys. How do you implement unattended reboot, if you consider unauthorized (physical) access to your system as one of the attack scenarios to protect against ? (Not meaning, that secure erase would really solve that problem ...) See my paper for a suggestion about using weak-link/strong-link methods for that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
can't fsck_ext2fs on a non sliced disk on 5.1
I got this message : # fsck_ext2fs -d /dev/ad3 ** /dev/ad3 BAD SUPER BLOCK: MAGIC NUMBER WRONG ioctl (GCINFO): Inappropriate ioctl for device /dev/ad3: can't read disk label is this due to geom or to FreeBSD 5.1? It worked on a 4.6.2. Though /dev/ad3 could be mounted when it was clean. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Size-independent byte order swapping functions.
Hello hackers...
Macros in attached patch are designed for doing life a little easier.
If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc.
those macros are helpful IMHO, because futher value size changes does not
affects code for byte order managing. This also does not hit perfromance,
because this should be resolved at compile-time.
I'm not sure if dedicated epanic() is the best way to implement out-of-range
errors prevention - the more handy solution should cause compile error.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
--- endian.h.orig Sat Nov 22 13:15:40 2003
+++ endian.hMon Nov 24 10:57:02 2003
@@ -49,6 +49,46 @@
#endif
/*
+ * Size-independent byte order swapping functions.
+ */
+#ifdef _KERNEL
+#defineepanic(msg) _epanic(msg, __FILE__, __LINE__)
+/* New function, because panic(9) type is void and this is not enough. */
+static __inline int
+_epanic(const char *msg, const char *file, unsigned line)
+{
+
+ panic(%s:%u: %s, file, line, msg);
+ /* NOTREACHED */
+}
+#definebswap(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? bswap16(x) : \
+ (sizeof(x) == 4 ? bswap32(x) : \
+ (sizeof(x) == 8 ? bswap64(x) : \
+ epanic(out of range in bswap())
+#definehtobe(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? htobe16(x) : \
+ (sizeof(x) == 4 ? htobe32(x) : \
+ (sizeof(x) == 8 ? htobe64(x) : \
+ epanic(out of range in htobe())
+#definehtole(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? htole16(x) : \
+ (sizeof(x) == 4 ? htole32(x) : \
+ (sizeof(x) == 8 ? htole64(x) : \
+ epanic(out of range in htole())
+#definebetoh(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? betoh16(x) : \
+ (sizeof(x) == 4 ? betoh32(x) : \
+ (sizeof(x) == 8 ? betoh64(x) : \
+ epanic(out of range in betoh())
+#defineletoh(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? letoh16(x) : \
+ (sizeof(x) == 4 ? letoh32(x) : \
+ (sizeof(x) == 8 ? letoh64(x) : \
+ epanic(out of range in letoh())
+#endif
+
+/*
* General byte order swapping functions.
*/
#definebswap16(x) __bswap16(x)
pgp0.pgp
Description: PGP signature
Re: secure file flag?
On 2003-11-23 10:11 -0800, Wes Peters [EMAIL PROTECTED] wrote: Encrypting data and secure removal of data are orthogonal and in case you need one, the other propbably won't be a good choice. Both are completely adequate to protect the data on the disk from disclosure. Yes, if effective. Encryption protects as long as the keys are unknown to the attacker, secure removal protects as long as the data is overwritten before the attacker tries to get access. I'm sure you know that ... fsck could identify incompletely erased (in the sense of multipass overwrite with specific patterns) blocks, if that state was marked in the inode. But if someone is attempting to recover your deleted data, they're not going to run tools that would potentially eliminate that data from the disk. I'm designing to the idea of a disk that has been physically taken to a data recovery lab, because the intermediate steps don't interest me. But you see that: Thanks! I'm getting more convinced that there might a chance to communicate, now ;-) This is not meant as protection in case power is removed and the disk is analyzed off-line since most probably no fsck will ever be run over the filesystem again. The data needs to be overwritten in a timely manner as well. Leaving the disk in a partly erased state is the same as leaving it unerased. If you don't want the processing delay needed to do the full erasure you obviously don't really need full erasure. Yes. That's why encryption can be required. It protects data from the instant the clear-text has vanished (from RAM or some media). Secure deletion can't provide that! But there may still be situations, where you want to securely erase data from a medium. Either because that medium contained sensitive plain text or because it contained key data, for example (which is just another kind of sensitive plain text, in a way ;-) In that case, a small window of wulnerability may be tolerable (at least in a commercial environment). Encryption promises to keep existing data secret, and that promise may be broken. But in case you still need that data, you don't have much choice. Deleting it will not be an option. Secure erase gets rid of that data, and you don't have to worry that anybody may get hold of some kind of access key, once it's gone (which may take some time and effort to achieve, and that's what started this thread). Again: Nothing new to you ... It is meant to protect against a power failure (or reboot) with data not being erased according to the specification, which might survive for a long time after next start (not by an attacker but in normal service). This is extra paranoia (compare to a crash while obliterate is overwriting blocks, which will not be restarted after a crash ...) It seems that you are opposed to having secure erase support in the kernel, and in fact, I'm not sure it is that useful, myself. No, at one time I had it on my todo list, but came to a more full understanding of the expense and abadoned it for that reason. I may someday do it in the simplest form just to prove it workable to myself, but I doubt that is a solution of general interest to FreeBSD. Ok. I've also thought some about this, and I think that different media might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. Flash media). High density disks (ATA more than SCSI, actually) seem to make it much harder to recover remains of overwritten data, and it may in fact be acceptable to perform just a few passes with random data (as suggested by Peter Gutmann, 7 years ago, when areal densities were one to two orders of magnitude lower than today ...) But in case it is considered useful and implemented (I'd try it myself, if I was interested in using this feature), then we should discuss the techical (and security) aspects of several designs and that's what I'm trying to do. There is some merit in providing a mechanism that is 90% as secure at 10% the computational cost. I basic infrastructure that provides a secure removal flag at the file and/or filesystem layer and a choice of patterns would be a nice solution. Those who just want to make sure the contents of an email aren't inadvertantly disclosed to another user could specify a simple pattern like overwrite with zeros once, those who want to keep the FBI at bay could use the whole 37 passes and spend days deleting files. Maybe I'll look into this again after all. The former variant seems like it might even be useful for a mail server or similar application. The ability to specify different patterns seems useful. I'd consider a window of vulnerability of 10 seconds to one minute acceptable, and I guess this should be possible to acchive, even for nontrivial amounts of data that are to be deleted (40 passes at 1MB/s effective (including seeks) would impose a limit of 25KB/s per disk, while 8 passes at 4MB/s effective would
Re: secure file flag?
Stefan Eßer [EMAIL PROTECTED] writes: Ok. I've also thought some about this, and I think that different media might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. Flash media). PRML is not an encoding scheme like MFM or RLL, it is an algorithm for recovering a bitstream from a weak analog signal. Modern disks mostly use RLL encoding. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
4GB memory issues in current
Hi, i have stability problems with a xeon dual (same problems with UP kernel) and 4 GB of memory. After about 1 day, one apache does not deliver content and no logins are performed (console, ssh, ftp, ...) anymore. Console shows only motd message and nothing more. I have tried to set the following at loader.conf, but uptime inceases only to 4 days: kern.maxusers=512 kern.vm.kmem.size=45000 kern.maxvnodes=20 There was a posting about 4GB (fixed?) issues: Von:Paul Saab ([EMAIL PROTECTED]) -- snip -- Betrifft:Re: High mem (4GB) support on FreeBSD 4.8 Newsgroups:mailing.freebsd.hackers Datum:2003-10-19 13:42:00 PST -- snip -- Could someone tell me more about this issue? bye, Andy -- Andy Hilker -- mailto:[EMAIL PROTECTED] http://www.cryptobank.de -- PGP Key: https://ca.crypta.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Question: unable to open /dev/ugen0 more than once
On Sun, Nov 23, 2003 at 08:50:45PM -0500, Michael E. Mercer wrote: Hello peoples, I posted this to questions with no reply, I was hoping someone here may be able to give some insight. Question: Should I be able to open /dev/ugen0 more than once? I am using FreeBSD 4.9-Stable, libusb-0.1.7. From reading the libusb docs, you must open the device for each interface you want to acquire. However, once it is opened once, it can't be opened again. Furthermore, calls to usb_find_devices() shows that /dev/ugen0 has disappeared. Investigation on how they(libusb) finds devices, shows they are trying to open the device read only... this is where it tries to open it the second time. This second try fails and therefore libusb thinks the device was removed. Question: Is this the correct behavior? Yes - this is correct. A client using ugen on a multiple interface only need to open /dev/ugen? for probing only - the work should be done using the interface specific endpoints /dev/ugen?.? Opening /dev/ugen? read-only makes no sense, because there is no read only access possible - /dev/ugen? is for the control endpoint which always means sending commands to the device. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
using devel/libusb to access USB
Travis Campbell and I are looking at apcupsd to get it working with the APC RS/XS series of USB capable UPSs. We're concentrating on 4.x. Some work has been done in this area by Riccardo Torrini. See http://docs.freebsd.org/cgi/getmsg.cgi?fetch=57225+0+archive/2003/free bsd-hardware/20030608.freebsd-hardware We have been looking at the devel/libusb port and experimenting with testlibusb which is a part of that port. We have noticed that usb_find_devices() does not find any devices. Looking at the usb.c code within libusb, we found that usb_os_find_devices() does not return any devices, and therefore the while loop is never entered. We tracked the problem down to usb_os_find_devices() (within bsd.c) and found that various things were preventing the list from being created. We're wondering if anyone has had success with devel/libusb for similar things. -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a FreeBSD DVD
In a message written on Mon, Nov 24, 2003 at 03:00:12PM +1030, Daniel O'Connor wrote: make release will make an directory suitable to put on a CD or DVD. It's just that if you use a DVD you can fit a lot more packages/distfiles on the disk (which make release doesn't do for you anyway). Well, what I'm really interested in is the install + live file system on a single DVD, which is how the DVD's at FreeBSD mall are advertised (I've never bought one, myself). So, I can build an install CD, I (think I) can build a live file system CD. How do you get them both on a DVD, and give the user a boot choice? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Going realmode in kernel drivers?
i386/FreeBSD-4.x/lkm.
How does one get into 'realmode' inside a kernel driver?
The reason for the need is a tight timeing loop that measures the lenght of
pulses. And disableing interrupts is just not enough.
Target cpu's are AMD K5 + AMD XP.
Asfair when reading cycles per opcode. The number of cycles required increase
about three times when useing protected mode or similar.
Code excerpt:
u_int32_t register cnt1;
u_int32_t register cnt_max=0xFF;
u_int32_t register *store_ptr;
u_int32_t register *store_end;
u_int8_t register last_val=0;
store_ptr = ..;
store_end = ..+ SIZ;
disable_intr();
for(;;)
{
for(cnt1=0; cnt1cnt_max ((inb(0x379)0x20) != last_val); cnt1++)
;
*(store_ptr++) = cnt1;
if( store_ptr=store_end )
break;
last_val ^= 0x20;
}
enable_intr();
(Will start on a new count every signal flank).
/P
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: TWE driver IOCTL's]
Tried this on current, but no responses...maybe some one here has some ideas? Hello, I looking to extend the smartmontools support (/usr/ports/sysutils/smartmontools) to include support for drives behind a TWE device. I looked at the source for the TWE driver, and it seems to support what I neednot sure yet, as the linux version use the ATA Passthru IOCTL. At any rate, there does not appear to be any twe.h include files installed into /usr/include anywhere for my program to be able to pick the correct definitions. Is this just an oversight? Or did I miss something? Thanks, Ed -- Eduard Martinescu [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-24 12:20 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: Ok. I've also thought some about this, and I think that different media might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. Flash media). PRML is not an encoding scheme like MFM or RLL, it is an algorithm for recovering a bitstream from a weak analog signal. Modern disks mostly use RLL encoding. So what? PRML is not complementary to RLL. RLL is typically used to mean 1,7 RLL offering a 2/3 coding, while PRML starts at 8/9 and current devices use up to 24/25 (i.e. 24 bits in 25 channel bits). MFM can be considered a special case of RLL encoding, too, BTW ... But it's utterly irrelevant, that PRML data is written to disk as an RLL encoded data stream. What matters is what can be read back from the disk media (and PRML is about reading, not writing ;-) You probably don't want to claim that 1,7 RLL and a modern PRML encoding can be decoded with similar effort ... And that is what this thread is about: Secure removal of data from storage media. There definitely is a difference between RLL (as in 1,7i RLL) and modern PRML drives under this aspect. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote: I am wondering if it is useful to have a secure file flag?? The secure file flag will be set for files that contain sensitive data. Then the OS will take special care when operating on those secure files. e.g. when deleting a secure file, the OS will overwrite the file with random data. It would also be useful to have a noexport flag, which would have the NFS code refuse to send it over the network. I could personally use this for setting on my PGP and SSH keys, while exporting the rest of /home. I did look at implementing this, but couldn't find the correct place to do the check for the flag. Any pointers for a kernel newbie? Ceri -- pgp0.pgp Description: PGP signature
Re: Making a FreeBSD DVD
On Tuesday 25 November 2003 01:36, Leo Bicknell wrote: In a message written on Mon, Nov 24, 2003 at 03:00:12PM +1030, Daniel O'Connor wrote: make release will make an directory suitable to put on a CD or DVD. It's just that if you use a DVD you can fit a lot more packages/distfiles on the disk (which make release doesn't do for you anyway). Well, what I'm really interested in is the install + live file system on a single DVD, which is how the DVD's at FreeBSD mall are advertised (I've never bought one, myself). So, I can build an install CD, I (think I) can build a live file system CD. How do you get them both on a DVD, and give the user a boot choice? Good question.. I suggest you buy one from FreeBSDMall and look at how they do it :) (Although be careful not to violate their copyright) Maybe even ask them how they did it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Size-independent byte order swapping functions.
On Mon, Nov 24, 2003, Pawel Jakub Dawidek wrote: If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc. those macros are helpful IMHO, because futher value size changes does not affects code for byte order managing. This also does not hit perfromance, because this should be resolved at compile-time. Cool, looks useful. I'm not sure if dedicated epanic() is the best way to implement out-of-range errors prevention - the more handy solution should cause compile error. See CTASSERT. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
In message [EMAIL PROTECTED], Stefan =?iso-8859-1 And that is what this thread is about: Secure removal of data from storage media. There definitely is a difference between RLL (as in 1,7i RLL) and modern PRML drives under this aspect. No there isn't. It's been proven again and again that you cannot reliably overwrite data on a magnetic media. In particular the difference in read/write geometry and lack of fine control over head placement makes this impossible. The only reliable way to loose data is to encrypt them and throw the key away. Live with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
