losetup problems during encryption!!!

raklo · 01-28-2007, 10:53 PM

the pipeline thing also doesnt work,in short

#losetup -e aes-128 -p 5 /dev/loop2 /dev/hdc2 5</root/passwd-file

the above command doesnt work in nash, and i wanna make it work.
this command does work in ash,but if i replace nash with ash in the initrd image,my system hangs

wot else can i try????

Nick_Battle · 01-29-2007, 07:10 AM

It's a bit of work, but you could write a small program (in C) to open your file, dup the file descriptor into (say) fd0, then exec "losetup -p0...". That's then independent of nash...

#include <unistd.h>
#include <fcntl.h>

int main(int argc, char *argv[])
{
int fd = open(argv[1], O_RDONLY);
close(0);
dup(fd);
execvp(argv[2], argv+2);
}

Usage is fd0 <file for -p0> <cmd> [<args>...]
eg:

$ fd0 fd0.c wc -l
11
$

Which counts the number of lines in its own source :-)

In your case, fd0 passwd losetup -e aes-128 -p0 /dev/loop2 /dev/hdc2

HTH

raklo · 01-31-2007, 02:28 AM

hey thanx nick,ur solution seems to be working,
i wrote a small c code,which executes the losetup command without redirection and the code works perfectly on my harddisk,and does the intended work.

but when i execute it thru the initrd,into the board with compact flash it shows me

Code:

bio too big device loop2 (2 > 0)

wot can b wrong??

Nick_Battle · 01-31-2007, 02:58 AM

> wot can b wrong??

Not sure, can you email me the code (you can mail me through my LQ account here). You're saying my fd0 redirection works, but you've also tried to do this a different way and that is giving the error?

Incidentally, my code was as small as I could make it, but it doesn't check for any errors. You might want to consider checking the return values of the syscalls it makes and exiting appropriately!

raklo · 01-31-2007, 03:44 AM

this is the code.
i tried this code on hard disk,and it works fine and losetup does wot it is suposed to do,but the exact thing doesnt work when i do this with a compact flash.

Code:

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>

#define PATH "/sbin:/bin"
char *env[]={ 
	"PATH="  PATH,
	NULL
	    };	
char* itoa(int val, int base)
{
	static char buf[32] = {0};
	int i = 30;
	for(; val && i ; --i, val /= base)
		buf[i] = "0123456789abcdef"[val % base];
	return &buf[i+1];	
}
int main(void)
{
	int fd,fd1,pid,i;
	char *filedes;
	filedes=malloc(sizeof(char *));
	fd=open("/etc/a",O_RDONLY);
	if(fd<0)
	{
		printf("Error opening the file \n");
		exit(0);
	}
	fd1=dup(fd);
	if(fd1<0)
	{
		printf("Error duplicating the file descriptor\n");
		exit(0);
	}
	filedes=itoa(fd1,10);
	char *args[]={ "/bin/losetup",
			"-e",
			"aes-128",
			"-p",
//			filedes,
			"4",
			"/dev/loop2",
			"/dev/hdc2",
			NULL };	
	printf("Descriptor : %s\n",filedes);
	printf("%s %s %s %s %s %s %s\n",args[0],args[1],args[2],args[3],args[4],args[5],args[6]);
//	if((pid=fork())==0)
	pid=fork();
	if(pid<0)
	{
		printf("process not forked\n");
		exit(0);
	}
	else
	if(pid==0)
	{
		execve(args[0],args,env);
		printf("Executed...\n");
		exit(0);
	}
        free(filedes);//this line has been added now
	close(fd1);
	close(fd);
	return 0;
}

if u need any more data,revert back,
my yahoo id is rakesh_nair123@yahoo.co.in
i can b online anytime.
thanx

raklo · 01-31-2007, 07:53 AM

hey i gt the source of problem,
actually in the above code,the execve is not getting executed,nd thatis why it shows all kinds of error messages.
the rest of code is gd and it works fine,if i execute this code on a working system,i.e
#gcc losetup.c(losetup.c is the name of program)
#./a.out
its working fine,but when im using it in the init script of initrd.img execve doesnt work.
so u need to tell me how to get execve do its work.

Nick_Battle · 01-31-2007, 08:24 AM

Hmmm. execve (rather than execvp) needs to be passed the fully qualified pathname of the binary, rather than depending on the $PATH environment. You're passing /bin/losetup, so (depending on the errno set by execve) I'd guess that it can't find that binary. That probably means that pathnames of the binaries that are visible in the ramdisk state are not what you would normally expect...

Check the errno after exeve fails. You'll probably get ENOENT (see errno.h), but there might be another error that gives a clue.

Try using execvp, and just passing "losetup". Did you mean that my small program (which uses execvp) works?

I think the "bio too big device" is just a consequence of the device not being looped successfully.

Nick_Battle · 01-31-2007, 08:26 AM

BTW, your "printf("Executed...\n");" line should never be reached, unless the exec fails. You can replace this with "printf("errno=%d\n", errno);"

raklo · 02-01-2007, 02:50 AM

as seen in the source,there is a malloc() in the code but no free(), and i suppose that was creting the problem,when i free()d the pointer,the system
started booting,but now there is a problem.
once every 2-3 boots thereis a kernel panic,and every time during boot time
i see the following message

Code:

*** glibc detected *** free(): invalid pointer: 0x080a5d7e ***
ERROR: /bin/a.out exited abnormally! (pid 1003)

even if the kernel boots properly,i get this message, n i think that the kernel panics one in a while just bcoz of this.

syntactically my code is rite,(i've edited the code that i had previously sent u,just take a look above to find free() line)then why is it that im getting invalid pointer error??//

as for this

Quote:

BTW, your "printf("Executed...\n");" line should never be reached, unless the exec fails. You can replace this with "printf("errno=%d\n", errno);"

i tried it,bt the printf doesnt get executed in any of the cases,
this is the loop that ive used

Code:

  if((execv(args[0],args))!=0)
         {
                printf(" error......%d\n",errno);
                else
                printf("Error: %d\n",errno);
                exit(0);
        }

Nick_Battle · 02-01-2007, 03:46 AM

It's difficult to debug this remotely!

I didn't notice the missing free() call in your original code, but the process would just terminate anyway. Your call to free is freeing the value that you overwrote with itoa(), so it isn't a valid pointer.

Why are you forking the process and execing in the child? You don't need the parent to do anything, so you can just exec losetup as soon as you've sorted out the file descriptor.

You didn't answer my earlier question: does my code work? Being simpler, it might be easier to debug even if it doesn't. Your code is rather "over-complicated". :-)

raklo · 02-01-2007, 04:23 AM

as my inputs were constant, i decided not to use command line args.
I just took idea from ur code,i DIDNT try ur code out.
i initially wrote the code without forking,but that didnt work (dont know the reason)so i had to fork the process and let it do the work.

as far as free() is concerned,do u mean to say i need not call free() function???
even if the pointer has been overwritten,i can still free it,can't i????

anyways i'll try it again without forking n let u know ASAP,lemme se if it works
thanx again,but do reply about my pointer overwriting query.

raklo · 02-01-2007, 04:39 AM

hey i tried the code without forking a process,but it isnt working.
n if i dont use free() in my code,the system never boots,so i have to use it .
so how can i free the allocated memory???

Nick_Battle · 02-01-2007, 06:50 AM

Malloc and free allocate and release dynamic storage, but when a process ends all its storage is deallocated anyway. It's good practice to free anything you malloc, but in this application it's not really necessary to malloc anything as you're sure of the sizes of things - just using a char array on the stack would do. You may find sprintf useful instead of itoa as well. But if you close/dup file descriptor zero, you could dispense with a lot of this detail anyway.

I understand your point about knowing your losetup arguments, and so building it into the code. But can you please *try* my code, then if it works we can slowly evolve it into something like yours - or if it doesn't, we have a much simpler program to debug.

You would invoke it (if it's called fd0 ad the password is in /etc/a) as:

fd0 /etc/a losetup -e aes-128 -p0 /dev/loop2 /dev/hdc2

raklo · 02-01-2007, 11:57 PM

here there r 2 cases
1) either the memory to the pointer is free()d by itself n so when i m calling free() it leads to an invalied pointer error,or
2) when free() is called the pointer is still in use by execve() as the execution is parallel(for execve),nd so free is not successfull

now when i comment free() out of the code,the system never boots(which means that pointer isnot free()d by itself),so i deduce that 1st case may not be true and 2nd case can b possible.

Now,can u tell me ny method by which i can stop this parallelism,i.e free is called only after execve() completes its execution.

is using semaphore possible in user space???
can i use atomic operations in user space???

i'm seriously VERY VERY SORRY, as i havent still tried out ur code, as i dont wanna mve the focus from this code.kindly pardon my disobedience.

Also,as u said i used a char filedes, instead of char *filedes, though the code works fine on console,it goes to panic(everytime) when i use it in initrd.

waiting

Nick_Battle · 02-02-2007, 03:33 AM

Quote:

1) either the memory to the pointer is free()d by itself n so when i m calling free() it leads to an invalied pointer error,or
2) when free() is called the pointer is still in use by execve() as the execution is parallel(for execve),nd so free is not successfull

Or 3), when you do "filedes=itoa(fd1,10)" the filedes malloc pointer is replaced with a pointer into the static array in the itoa function. Therefore it is no longer pointing to something that can be free()d, and so free(filedes) gives an error.

It's just a coding error. There's nothing complicated going on.

Quote:

i'm seriously VERY VERY SORRY, as i havent still tried out ur code, as i dont wanna mve the focus from this code.kindly pardon my disobedience.

I can see it's frustrating :-)

Quote:

Also,as u said i used a char filedes, instead of char *filedes, though the code works fine on console,it goes to panic(everytime) when i use it in initrd.

This tells us something about the real problem, (assuming the new code is OK).

It's looking like there's something about the environment in your ramdisk that isn't right. Did you copy all the shared libraries that might be needed by the shell and losetup into the ramdisk's /lib? It might be that the exec is starting the losetup process correctly, but that the dynamic linker can't find a shared library that it needs. I'm not sure what effect that would have.

If this is true, then my program won't work either! Worth a try though, eh?

On the other hand, if you can interactively call losetup in the ramdisk init script and provide the password at the console (ie. remove the -p argument), then the library environment must be complete. Does this work?