On Monday 2008-12-01 23:02, John Haxby wrote:
>>>+ sg_init_table(sg, 2);
>>>+ sg_set_buf(&sg[0], data, n);
>>>+ strcpy(digest_password, sysrq_password);
>>>+ i = strlen(digest_password);
>>>+ sg_set_buf(&sg[1], digest_password, i);
>>
>> Could we directly use sysrq_password instead of copying it to
>> digest_password first?
>
> No :-) Eventually I discovered the reason my code wasn't working
> boils down to the definition of sg_set_buf:
>
> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf))
>
> which doesn't work for sysrq_password. I don't know why I'll
> double check.
Well, sysrq_password is in the .bss section, where as digest_password
is on the heap due to being kmalloc'ed. Maybe that makes a difference?
Someone more versed with the virtual memory layer might know.
>+static char sysrq_password[64];
>[...]
>+ digest_password = kmalloc(sizeof(sysrq_password), GFP_KERNEL);
From: Jan Engelhardt <[email protected]>
Date: Mon, 1 Dec 2008 23:40:18 +0100 (CET)
>
> On Monday 2008-12-01 23:02, John Haxby wrote:
> >>>+ sg_init_table(sg, 2);
> >>>+ sg_set_buf(&sg[0], data, n);
> >>>+ strcpy(digest_password, sysrq_password);
> >>>+ i = strlen(digest_password);
> >>>+ sg_set_buf(&sg[1], digest_password, i);
> >>
> >> Could we directly use sysrq_password instead of copying it to
> >> digest_password first?
> >
> > No :-) Eventually I discovered the reason my code wasn't working
> > boils down to the definition of sg_set_buf:
> >
> > sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf))
> >
> > which doesn't work for sysrq_password. I don't know why I'll
> > double check.
>
> Well, sysrq_password is in the .bss section, where as digest_password
> is on the heap due to being kmalloc'ed. Maybe that makes a difference?
> Someone more versed with the virtual memory layer might know.
You can't use these interfaces on kernel image addresses.
On Tuesday 2008-12-02 01:10, David Miller wrote:
>> On Monday 2008-12-01 23:02, John Haxby wrote:
>> >>>+ sg_init_table(sg, 2);
>> >>>+ sg_set_buf(&sg[0], data, n);
>> >>>+ strcpy(digest_password, sysrq_password);
>> >>>+ i = strlen(digest_password);
>> >>>+ sg_set_buf(&sg[1], digest_password, i);
>> >>
>> >> Could we directly use sysrq_password instead of copying it to
>> >> digest_password first?
>> >
>> > No :-) Eventually I discovered the reason my code wasn't working
>> > boils down to the definition of sg_set_buf:
>> >
>> > sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf))
>> >
>> > which doesn't work for sysrq_password. I don't know why I'll
>> > double check.
>>
>> Well, sysrq_password is in the .bss section, where as digest_password
>> is on the heap due to being kmalloc'ed. Maybe that makes a difference?
>> Someone more versed with the virtual memory layer might know.
>
>You can't use these interfaces on kernel image addresses.
>
Great :-) So what is the best way to use the SHA1 crypto algo
with in-kernel addresses?
Jan
From: Jan Engelhardt <[email protected]>
Date: Tue, 2 Dec 2008 01:13:34 +0100 (CET)
>
> On Tuesday 2008-12-02 01:10, David Miller wrote:
> >> On Monday 2008-12-01 23:02, John Haxby wrote:
> >> >>>+ sg_init_table(sg, 2);
> >> >>>+ sg_set_buf(&sg[0], data, n);
> >> >>>+ strcpy(digest_password, sysrq_password);
> >> >>>+ i = strlen(digest_password);
> >> >>>+ sg_set_buf(&sg[1], digest_password, i);
> >> >>
> >> >> Could we directly use sysrq_password instead of copying it to
> >> >> digest_password first?
> >> >
> >> > No :-) Eventually I discovered the reason my code wasn't working
> >> > boils down to the definition of sg_set_buf:
> >> >
> >> > sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf))
> >> >
> >> > which doesn't work for sysrq_password. I don't know why I'll
> >> > double check.
> >>
> >> Well, sysrq_password is in the .bss section, where as digest_password
> >> is on the heap due to being kmalloc'ed. Maybe that makes a difference?
> >> Someone more versed with the virtual memory layer might know.
> >
> >You can't use these interfaces on kernel image addresses.
> >
> Great :-) So what is the best way to use the SHA1 crypto algo
> with in-kernel addresses?
kmalloc and copy it there, or something like that, you just
can't use in-kernel addresses, ever.
On Tuesday 2008-12-02 01:14, David Miller wrote:
>> >>
>> >> Well, sysrq_password is in the .bss section, where as digest_password
>> >> is on the heap due to being kmalloc'ed. Maybe that makes a difference?
>> >> Someone more versed with the virtual memory layer might know.
>> >
>> >You can't use these interfaces on kernel image addresses.
>> >
>> Great :-) So what is the best way to use the SHA1 crypto algo
>> with in-kernel addresses?
>
>kmalloc and copy it there, or something like that, you just
>can't use in-kernel addresses, ever.
>
Yes, kmalloc is already used. But then, what sort of address
does kmalloc return, if not an address within kernelspace?
(usually >=0xc0000000 on standard i386)
From: Jan Engelhardt <[email protected]>
Date: Tue, 2 Dec 2008 02:41:02 +0100 (CET)
>
> On Tuesday 2008-12-02 01:14, David Miller wrote:
> >> >>
> >> >> Well, sysrq_password is in the .bss section, where as digest_password
> >> >> is on the heap due to being kmalloc'ed. Maybe that makes a difference?
> >> >> Someone more versed with the virtual memory layer might know.
> >> >
> >> >You can't use these interfaces on kernel image addresses.
> >> >
> >> Great :-) So what is the best way to use the SHA1 crypto algo
> >> with in-kernel addresses?
> >
> >kmalloc and copy it there, or something like that, you just
> >can't use in-kernel addresses, ever.
> >
> Yes, kmalloc is already used. But then, what sort of address
> does kmalloc return, if not an address within kernelspace?
> (usually >=0xc0000000 on standard i386)
I said "kernel image" addresses are a problem, not "kernel space."
And by "kernel image" I mean addresses within the confines defined
by the sections of the vmlinux binary.