[SOLVED] Is there a /dev/one (like /dev/zero)?

JZL240I-U · 02-08-2008, 10:13 AM

With /dev/zero one can fill memory of any kind with all bits set to zero (0x00).

How can set everything to binary 1 (0xFF), or rather, is there a device to do that?

pixellany · 02-08-2008, 11:07 AM

Quote:

Originally Posted by JZL240I-U

With /dev/zero one can fill memory of any kind with all bits set to zero (0x00).

How can set everything to binary 1 (0xFF), or rather, is there a device to do that?

I don't think so.....If the keepers of the tablets provided this, then people would ask for /dev/two, and /dev/three.....There would be no end...

You can write to the raw device in various ways, including:
echo stuff > dev/sda11
or
echo stuff | dd of=/dev/sda11

(The latter allows you to include the "seek" option to tell it WHERE on sda11)

I haven't found how to write the actual binary patterns--I'm sure there's a way.......

Matir · 02-08-2008, 11:36 AM

FYI, binary one is 0x01, unless you mean every bit binary one, which would be 0xFF/binary 11111111/decimal 255/octal 377.

And no, no such virtual device exists.

You could do something like:

Code:

tr '\000' '\377' < /dev/zero

JZL240I-U · 02-11-2008, 12:51 AM

Quote:

Originally Posted by Matir

FYI, binary one is 0x01, unless you mean every bit binary one, which would be 0xFF/binary 11111111/decimal 255/octal 377.

Yes, that's what I meant and why I wrote "0xFF".

Quote:

Originally Posted by Matir

And no, no such virtual device exists.

A pity. So what do those programs do which flip bits on your hard disk several times to get their "0xFF" (e.g. for secure erasure)?

Quote:

Originally Posted by Matir

You could do something like:

Code:

tr '\000' '\377' < /dev/zero

Is this the best (no criticism intended)? It looks a little heavy on the CPU side, so to say...

@ pixellany

Quote:

Originally Posted by pixellany

...I don't think so.....If the keepers of the tablets provided this, then people would ask for /dev/two, and /dev/three.....There would be no end...

Not really. All zeros or all ones are end members the others just patterns in between. You need the end members e.g. for secure erasure of disks. Of course there are workarounds but /dev/one would be a clean solution

.

Matir · 02-11-2008, 07:14 AM

I don't think using 'tr' is particularly heavy. Programs that flip bits probably use something like:

Code:

int ones=0xFFFFFFFF;

I imagine very few PROGRAMS use /dev/zero: it's more likely used by shell scripts and the like.

JZL240I-U · 02-11-2008, 08:13 AM

Quote:

Originally Posted by Matir

I don't think using 'tr' is particularly heavy. Programs that flip bits probably use something like:

Code:

int ones=0xFFFFFFFF;

Weeell ... but still, every byte / int / long has to be (loaded, flipped and) written back, no bs=4M ...

.

Quote:

Originally Posted by Matir

I imagine very few PROGRAMS use /dev/zero: it's more likely used by shell scripts and the like.

Sure. Or programs would rather use calloc(). I meant it for use with "dd".

Matir · 02-11-2008, 09:09 AM

You could write a program that uses memset to set all the values to ones. What are you trying to achieve, anyway?

JZL240I-U · 02-11-2008, 09:57 AM

Well, I was thinking along the lines of secure erasure of hard disks. I read that one had to change the values of the bits five to seven times to make it forensically impossible to reconstruct the contents of the disk.

To make sure that every bit on a hd is flipped, it is not enough to use /dev/urandom which might or might not flip a particular bit, being random as it is

. You can insure that only by a "hard wired" flipping of all bits to 1-0-1-0-1-0...

Since there is /dev/zero I was interested whether there is a comparable handy tool like a /dev/one, but alas ...

.

Matir · 02-11-2008, 10:16 AM

There's a program called "wipe" designed to do just that. Or you can use a bootable disk like "Dan's Boot and Nuke", designed explicitly for wiping data.

JZL240I-U · 02-12-2008, 01:36 AM

Thanks for "wipe", dban I knew. I guess I'll have to read their readmes, perhaps they describe their technique(s) and how they get their 0xFFs. Anyhow, it was worth a question to LQ, thanks for your sustained input and help.

JZL240I-U · 02-12-2008, 05:17 AM

Quote:

Originally Posted by JZL240I-U

...read their readmes...

Done.

Anybody reading this thread please go to sourceforge and read the documentation for dban and wipe (and links therein! Or dig for literature by P. Gutmann). Zeros and ones are not a good idea at all for "cleaning" hard disks...

Matir · 02-12-2008, 07:16 AM

Zeros and ones are all we have!

(At the bit level)

But you're right -- repeated passes of random data work much better.

FreeBSoD · 03-03-2008, 07:07 AM

If you're still interested, I wrote a kernel patch for /dev/one support. Apply to drivers/char/mem.c.

Code:

--- mem.c.orig	2008-02-13 21:01:54.000000000 +0100
+++ mem.c	2008-02-14 00:11:53.000000000 +0100
@@ -8,6 +8,11 @@
  *  Shared /dev/zero mmaping support, Feb 2000, Kanoj Sarcar <kanoj@sgi.com>
  */
 
+/*   
+ *  Added support for the /dev/one device. Intended for poly-p-ux.
+ *    Feb-09-2008, Marcin Koziuk <marcin.koziuk@planet.nl>
+ */
+
 #include <linux/mm.h>
 #include <linux/miscdevice.h>
 #include <linux/slab.h>
@@ -654,6 +659,23 @@
 	return written ? written : -EFAULT;
 }
 
+static ssize_t read_one(struct file * file, char __user * buf, 
+			 size_t count, loff_t *ppos)
+{
+	size_t written;
+	unsigned long unwritten;
+	static int one = ~0;
+
+	for (written = 0; written < count; written++) {
+		unwritten = copy_to_user(&buf[written], &one, 1);
+		if (unwritten)
+			break;
+		cond_resched();
+	}
+		
+	return written ? written : -EFAULT;
+}
+
 static int mmap_zero(struct file * file, struct vm_area_struct * vma)
 {
 #ifndef CONFIG_MMU
@@ -724,6 +746,9 @@
 #define open_mem	open_port
 #define open_kmem	open_mem
 #define open_oldmem	open_mem
+#define one_lseek	null_lseek
+#define write_one	write_null
+#define mmap_one	mmap_zero
 
 static const struct file_operations mem_fops = {
 	.llseek		= memory_lseek,
@@ -766,6 +791,12 @@
 	.mmap		= mmap_zero,
 };
 
+static const struct file_operations one_fops = {
+	.llseek		= one_lseek,
+	.read		= read_one,
+	.write		= write_one,
+	.mmap		= mmap_one,
+};
 /*
  * capabilities for /dev/zero
  * - permits private mappings, "copies" are taken of the source of zeros
@@ -854,6 +885,10 @@
 			filp->f_op = &oldmem_fops;
 			break;
 #endif
+		case 13:
+			filp->f_mapping->backing_dev_info = &zero_bdi;
+			filp->f_op = &one_fops;
+			break;
 		default:
 			return -ENXIO;
 	}
@@ -886,6 +921,7 @@
 #ifdef CONFIG_CRASH_DUMP
 	{12,"oldmem",    S_IRUSR | S_IWUSR | S_IRGRP, &oldmem_fops},
 #endif
+	{13,"one",     S_IRUGO | S_IWUGO,           &one_fops},
 };
 
 static struct class *mem_class;

JZL240I-U · 03-04-2008, 01:31 AM

Now this is interesting, thanks a load FreeBSoD. I didn't do a kernel compile yet (I have only a 56k modem access to the net), but I will bookmark this and when I am big

or rather my modem grows to reasonable speeds I'll come back here and try it.

jschiwal · 03-04-2008, 02:02 AM

Why not wipe the drive with the urandom device a few times and then zero's. Actually, if you are going encrypt your partitions, you want to start with the partition filled with psuedo-random junk, rather than all zero's or all ones. If on the other hand you are going to reuse the drive for a fresh install and want to create an image backup, having zeroed out free space will allow the image to compress nicely.