Naive Questsions about 3rd Party Kernel Module

Naive Questsions about 3rd Party Kernel Module

[Ronald Oakes]

I have some, I presume naive, questions about some messages I'm
getting as a result of running (or attempting to run) my
vendor-provided kernel module under qemu.  (I've not tried on the real
hardware yet, I'd like it at least to boot somewhat cleaner on the
emulator before I commit to burning a CD to attempt real hardware even
if at this point that is just the same PC I'm developing on).

1: Upon each boot - or more correctly when I attempt to load my module
as part of an init.d script - I get a couple of messages from my
driver:
  "altadriver: module license 'Proprietary' taints kernel."
followed by:
  "Disabling lock debugging due to kernel taint"

Is there any way to prevent the prosperity license from tainting the
kernel?  As the kernel module is indeed under a proprietary license
(which isn't a problem - my product has a single customer so licensing
is not an issue), I don't want to override the license, but I don't
want it to impact kernel debugging should other issues develop.

2: I'm also getting a number of Unknown symbol messages such as:
  "altadriver: Unknown symbol ___stack_chk_fail  (err 0)"

Am I correct that these indicate that I'm missing a runtime library
dependency?  If so, any suggestions on how to locate what library has
the missing functions?  I do have these modules working on the native
system, so I know that I have the native versions of these libraries
and just need to identify and add them to my target system.

3: Related to the previous question, how important is the name of the
library in /usr/lib at the time that the module (or any other program)
starts?

On the native installer, one of the precompiled libraries gets
installed as symbolic link called /usr/lib/<filename>.so pointing to
where the file is unpacked.  I was unable to successfully get a
symbolic link of this name created on my target yesterday (even though
the same recipe created two other symbolic links in /usr/lib of the
same format), leaving only the actual file (named
/usr/lib/<filename>.so.<version>).  So, I modified my init.d script to
create the symbolic link before calling the program that, I believe,
installs the module (the program is a vendor supplied pre-compiled
binary that is used to create the device for the vendor hardware).
However, if the module is installed before that it is possible that
the symbolic link doesn’t exist but the library file is in /usr/lib
under a different but related name.

Thank You
  Ron Oakes

Re: Naive Questsions about 3rd Party Kernel Module

[Ronald Oakes]

Following up as I've done more investigation and debugging this afternoon:

I've been able to resolve my problem with the missing symbolic link to
<filename>.so by explicitly including a runtime dependency
(RDEPENDS_${PN}) to the -dev module, so my link is now present on the
filesystem image at boot.  I've also found reasonably strong evidence
that that library contains the function __stack_chk_fail; but the
evidence could equally indicate that that library calls it as I found
the string using the strings function.

Either way, it looks like I have a critical kernel module, and a less
critical kernel module, that are relying on a shared library that
either are missing on my image or are not available properly in kernel
space.  Any suggestions on how I can resolve this would be greatly
appreciated.

Thank You
  Ron Oakes


On Fri, Sep 9, 2016 at 10:01 AM, Ronald Oakes <ronaldo@brc2.com> wrote:
> I have some, I presume naive, questions about some messages I'm
> getting as a result of running (or attempting to run) my
> vendor-provided kernel module under qemu.  (I've not tried on the real
> hardware yet, I'd like it at least to boot somewhat cleaner on the
> emulator before I commit to burning a CD to attempt real hardware even
> if at this point that is just the same PC I'm developing on).
>
> 1: Upon each boot - or more correctly when I attempt to load my module
> as part of an init.d script - I get a couple of messages from my
> driver:
>   "altadriver: module license 'Proprietary' taints kernel."
> followed by:
>   "Disabling lock debugging due to kernel taint"
>
> Is there any way to prevent the prosperity license from tainting the
> kernel?  As the kernel module is indeed under a proprietary license
> (which isn't a problem - my product has a single customer so licensing
> is not an issue), I don't want to override the license, but I don't
> want it to impact kernel debugging should other issues develop.
>
> 2: I'm also getting a number of Unknown symbol messages such as:
>   "altadriver: Unknown symbol ___stack_chk_fail  (err 0)"
>
> Am I correct that these indicate that I'm missing a runtime library
> dependency?  If so, any suggestions on how to locate what library has
> the missing functions?  I do have these modules working on the native
> system, so I know that I have the native versions of these libraries
> and just need to identify and add them to my target system.
>
> 3: Related to the previous question, how important is the name of the
> library in /usr/lib at the time that the module (or any other program)
> starts?
>
> On the native installer, one of the precompiled libraries gets
> installed as symbolic link called /usr/lib/<filename>.so pointing to
> where the file is unpacked.  I was unable to successfully get a
> symbolic link of this name created on my target yesterday (even though
> the same recipe created two other symbolic links in /usr/lib of the
> same format), leaving only the actual file (named
> /usr/lib/<filename>.so.<version>).  So, I modified my init.d script to
> create the symbolic link before calling the program that, I believe,
> installs the module (the program is a vendor supplied pre-compiled
> binary that is used to create the device for the vendor hardware).
> However, if the module is installed before that it is possible that
> the symbolic link doesn’t exist but the library file is in /usr/lib
> under a different but related name.
>
> Thank You
>   Ron Oakes

Re: Naive Questsions about 3rd Party Kernel Module

[Lennart Sorensen]

On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
> Following up as I've done more investigation and debugging this afternoon:
> 
> I've been able to resolve my problem with the missing symbolic link to
> <filename>.so by explicitly including a runtime dependency
> (RDEPENDS_${PN}) to the -dev module, so my link is now present on the
> filesystem image at boot.  I've also found reasonably strong evidence
> that that library contains the function __stack_chk_fail; but the
> evidence could equally indicate that that library calls it as I found
> the string using the strings function.
> 
> Either way, it looks like I have a critical kernel module, and a less
> critical kernel module, that are relying on a shared library that
> either are missing on my image or are not available properly in kernel
> space.  Any suggestions on how I can resolve this would be greatly
> appreciated.

Kernel modules only use kernel code.  They never use user space libraries.
It simply doesn't work that way.

-- 
Len Sorensen

Re: Naive Questsions about 3rd Party Kernel Module

[Daniel.]

Ronald,

If you don't make your driver GPL you can't access GPL symbols. This
*may* be the reason behind the "Unknown symbols"
Regards,

2016-09-12 13:02 GMT-03:00 Lennart Sorensen <lsorense@csclub.uwaterloo.ca>:
> On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
>> Following up as I've done more investigation and debugging this afternoon:
>>
>> I've been able to resolve my problem with the missing symbolic link to
>> <filename>.so by explicitly including a runtime dependency
>> (RDEPENDS_${PN}) to the -dev module, so my link is now present on the
>> filesystem image at boot.  I've also found reasonably strong evidence
>> that that library contains the function __stack_chk_fail; but the
>> evidence could equally indicate that that library calls it as I found
>> the string using the strings function.
>>
>> Either way, it looks like I have a critical kernel module, and a less
>> critical kernel module, that are relying on a shared library that
>> either are missing on my image or are not available properly in kernel
>> space.  Any suggestions on how I can resolve this would be greatly
>> appreciated.
>
> Kernel modules only use kernel code.  They never use user space libraries.
> It simply doesn't work that way.
>
> --
> Len Sorensen
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Do or do not. There is no try"
  Yoda Master

Re: Naive Questsions about 3rd Party Kernel Module

[Lennart Sorensen]

On Mon, Sep 12, 2016 at 01:41:24PM -0300, Daniel. wrote:
> If you don't make your driver GPL you can't access GPL symbols. This
> *may* be the reason behind the "Unknown symbols"
> Regards,

Well at least for __stack_chk_fail the kernel has:

#ifdef CONFIG_CC_STACKPROTECTOR

/*
 * Called when gcc's -fstack-protector feature is used, and
 * gcc detects corruption of the on-stack canary value
 */
__visible void __stack_chk_fail(void)
{
        panic("stack-protector: Kernel stack is corrupted in: %p\n",
                __builtin_return_address(0));
}
EXPORT_SYMBOL(__stack_chk_fail);

#endif

So as long as the kernel is configured with CC_STACKPROTECTOR, it should
exist, and it is not GPL only.

So at least as long as the kernel module is built by the same kernel
build files as the kernel was with the same config and the same compiler,
it should work.  If someone tries to manually build the kernel module
instead of using the kernel build scripts to do it, then they are asking
for trouble.

-- 
Len Sorensen

Re: Naive Questsions about 3rd Party Kernel Module

[Ronald Oakes]

I was able to resovle my problem (with a bit of help from Google and
Stack Overflow) by including a stub version of __stack_check_fail() in
my recepie.

It appears that the shared object libarary was not needed after all,
and was just a red herring in my invesgagation.

Thank you for your assistance.

Ron Oakes

On Mon, Sep 12, 2016 at 10:02 AM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
>> Following up as I've done more investigation and debugging this afternoon:
>>
>> I've been able to resolve my problem with the missing symbolic link to
>> <filename>.so by explicitly including a runtime dependency
>> (RDEPENDS_${PN}) to the -dev module, so my link is now present on the
>> filesystem image at boot.  I've also found reasonably strong evidence
>> that that library contains the function __stack_chk_fail; but the
>> evidence could equally indicate that that library calls it as I found
>> the string using the strings function.
>>
>> Either way, it looks like I have a critical kernel module, and a less
>> critical kernel module, that are relying on a shared library that
>> either are missing on my image or are not available properly in kernel
>> space.  Any suggestions on how I can resolve this would be greatly
>> appreciated.
>
> Kernel modules only use kernel code.  They never use user space libraries.
> It simply doesn't work that way.
>
> --
> Len Sorensen