Hello,
the patch below implements a new option -o for vbladed, denoting the
number of sectors that should be skipped at the beginning of the
exported file. Default is 0 (no offset, export from beginning, current
behaviour).
Rationale:
If the exported files are actually raw block devices on the target,
something that might happen when using logical volumes for exports,
several tools running on the target that assume block devices are
for exclusive local access only might create confusion or even
havoc. Most prominently:
* os-prober of grub (might be disabled, though)
Might mount any block device found that contain a file system.
* (Linux) logical volume management
Will report any physical volume if the export is used as such.
* (Linux) blkid
Reports any block device (minor impact, mostly information leakage)
The overall problem is applications are not aware some block devices
might be used from a remote client while there's no locking and that
might be hard to implement
Solutions tried but not considered helpful:
* Filter out exported block devices
Problems: The tools need the ability to filter; new tools might come
into existance, requiring new action. Filter languages might be hard
to use (Linux LVM is quite a nightmare here).
* Optionally open block devices with O_EXCL
Had no effect. Still exposes block devices where no vbladed is running
yet.
So the goal was to hide the actual content from these tools. One
approach was to obscure the data using XOR, however it seemed easier
to sacrifice one or more sectors (8 recommended for 4k sector hard
drives) for a simple workaround.
This is based on vblade-20, tests on Debian Linux included a simple
write of each sector with a unique ID and later re-read in order to
detect any re-ordering bugs, however everything worked as expected.
Christoph
--- a/aoe.c
+++ b/aoe.c
@@ -464,9 +464,10 @@ main(int argc, char **argv)
int ch, omode = 0, readonly = 0;
bufcnt = Bufcount;
+ offset = 0;
setbuf(stdin, NULL);
progname = *argv;
- while ((ch = getopt(argc, argv, "b:dsrm:")) != -1) {
+ while ((ch = getopt(argc, argv, "b:dsrm:o:")) != -1) {
switch (ch) {
case 'b':
bufcnt = atoi(optarg);
@@ -485,6 +486,9 @@ main(int argc, char **argv)
case 'm':
setmask(optarg);
break;
+ case 'o':
+ offset = atoi(optarg);
+ break;
case '?':
default:
usage();
@@ -505,6 +509,11 @@ main(int argc, char **argv)
setserial(argv[3], shelf, slot);
size = getsize(bfd);
size /= 512;
+ if (size < offset) {
+ fprintf(stderr, "Offset %u too big - remaining size is negative!\n", offset);
+ exit(1);
+ }
+ size -= offset;
ifname = argv[2];
sfd = dial(ifname, bufcnt);
getea(sfd, ifname, mac);
diff --git a/ata.c b/ata.c
index 4854f34..7c53b46 100644
--- a/ata.c
+++ b/ata.c
@@ -155,12 +155,12 @@ atacmd(Ataregs *p, uchar *dp, int ndp, int payload) // do the ata cmd
return 0;
}
if (p->cmd == 0x20 || p->cmd == 0x24)
- n = getsec(bfd, dp, lba, p->sectors);
+ n = getsec(bfd, dp, lba+offset, p->sectors);
else {
// packet should be big enough to contain the data
if (payload < 512 * p->sectors)
return -1;
- n = putsec(bfd, dp, lba, p->sectors);
+ n = putsec(bfd, dp, lba+offset, p->sectors);
}
n /= 512;
if (n != p->sectors) {
diff --git a/dat.h b/dat.h
index 064ab1e..f3a93d8 100644
--- a/dat.h
+++ b/dat.h
@@ -169,6 +169,7 @@ uchar mac[6];
int bfd; // block file descriptor
int sfd; // socket file descriptor
vlong size; // size of vblade
+unsigned offset;
char *progname;
char serial[Nserial+1];
diff --git a/vblade.8 b/vblade.8
index 2cd2b2c..3d8ff13 100644
--- a/vblade.8
+++ b/vblade.8
@@ -55,6 +55,10 @@ The -r flag restricts the export of the device to be read-only.
The -m flag takes an argument, a comma separated list of MAC addresses
permitted access to the vblade. A MAC address can be specified in upper
or lower case, with or without colons.
+.TP
+\fB-o\fP
+The -o flag takes an argument, the number of sectors that should be
+skipped at the beginning of filename.
.SH EXAMPLE
In this example, the root user on a host named
.I nai
Attachment:
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce
_______________________________________________ Aoetools-discuss mailing list Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
