Re: Where to find the information how to write a state of the art USB driver?
On Thu, Jan 13, 2022 at 04:33:50PM +0100, Greg KH wrote: > On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote: > > On 1/12/22 10:54 AM, Greg KH wrote: > > > That driver tried to be an example for an unknown device, doing multiple > > > different things that no single driver/device would probably ever need. > > > Also it can almost always just be replaced with a simple userspace > > > program using libusb, as I bet your driver could be replaced with as > > > well, right? > > Yes it can be replaced by a userspace program but even this is not required. > > It is an issue if you are trying to write a new driver. We do not take > new drivers into the kernel tree if they can be in the kernel instead. That should be: if they can be written in userspace instead. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Where to find the information how to write a state of the art USB driver?
On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote: > On 1/12/22 10:54 AM, Greg KH wrote: > > That driver tried to be an example for an unknown device, doing multiple > > different things that no single driver/device would probably ever need. > > Also it can almost always just be replaced with a simple userspace > > program using libusb, as I bet your driver could be replaced with as > > well, right? > Yes it can be replaced by a userspace program but even this is not required. It is an issue if you are trying to write a new driver. We do not take new drivers into the kernel tree if they can be in the kernel instead. > For the USB LCD a userspace program is available from vendor. Great! > For the USB to serial Adapter the driver exists in the kernel ch341.c. > It appears as a ttyUSB0 device. For devices that need to show up to userspace as a common device type (like a serial port), we need to have a kernel driver, so this is to be expected. > I think what happens to very custom drivers that could be userspace programs > can be seen in the file /drivers/usb/misc/usblcd.c > - It is written in 2005 and is only supporting one device from one vendor. > - I cannot find/buy a suitable device. > - I have tried two times to contact the author of the driver but: > The response from the remote server was: > 550 5.1.1 : Recipient address rejected: User unknown > - The idVendor = 0x10D2 does also not help because RayComposer - R. Adams > does not response and does not seam to offer such products. What is the problem with this driver? If it is not hurting anyone, and still builds, it's not causing any problems. > To me it is unused code but how to verify? When it is unused what does the > kernel do with it? Putting it to the staging area? Why do you want to delete it? We can remove old drivers that no one uses, we do that all the time. But usually that is because the maintance burden on them get too high and we determine that no one actually uses the thing. This driver doesn't seem to be causing any problems that I can see, so why delete it? That being said, if you do think it should be removed, great, let's do so and if someone later shows up that uses it, we can trivially add it back. Just submit a patch to do so. But this doesn't have much to do with your original question, so I'm confused as to what usblcd.c has to do with writing a new USB driver? thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to disable address randomization ?
On Thu, Jan 13, 2022 at 4:04 PM admin LI wrote:
>
> I'm developing a kernel module for an ARM machine, while debugging I found
> addresses
> printed are all randomized and useless for debugging.
>
> To prove I was not crazy I wrote this small program:
>
> -
> #include
> #include
> #include
> #include
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Somebody");
> MODULE_DESCRIPTION("A simple example Linux module.");
> MODULE_VERSION("0.01");
>
> static int __init example_init(void) {
> uint32_t a;
> uint32_t b;
> uint32_t c;
> uint8_t d[10];
> uint8_t *e;
>
> printk(KERN_INFO "Hello, World!\n");
> printk(KERN_INFO " %p\n",);
> printk(KERN_INFO " %p\n",);
> printk(KERN_INFO " %p\n",);
> printk(KERN_INFO " %p\n",d);
> printk(KERN_INFO "[0] %p\n",[0]);
> printk(KERN_INFO "[1] %p\n",[1]);
>
> e = kmalloc(10, GFP_KERNEL);
> printk(KERN_INFO "[0] %p\n",[0]);
> printk(KERN_INFO "[1] %p\n",[1]);
>
> kfree(e);
>
> return 0;
> }
>
> static void __exit example_exit(void) {
> printk(KERN_INFO "Goodbye, World!\n");
> }
>
> module_init(example_init);
> module_exit(example_exit);
> -
> And it gave me this output:
>
> Hello, World!
> b3f9fa31
> 27e1c68a
> da50d287
> 9f9aec2b
> [0] 9f9aec2b
> [1] cc627580
> [0] 98b8c9eb
> [1] 45f248f8
>
> Then I tested on my debian host machine which gave me the same kind of
> randomized addresses.
>
> When I search randomization the only thing I found is KASLR which I don't
> think is the same thing.
I think something else may be going on, but I'll toss this out there
in case it helps.
In the past randomization was disabled by writing 0 to
/proc/sys/kernel/randomize_va_space. Something like:
sysctl -w kernel.randomize_va_space=0
To make it permanent, change it in /etc/sysctl.conf.
Jeff
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to disable address randomization ?
> > When I search randomization the only thing I found is KASLR which I > don't think is the same thing. > Think about this carefully. When you insmod that kernel module which address space is it using ? Kernel or Userspace ? :-) This will help: https://askubuntu.com/questions/318315/how-can-i-temporarily-disable-aslr-address-space-layout-randomization Good luck -Aruna ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to disable address randomization ?
Hi,
I'm developing a kernel module for an ARM machine, while debugging I found
addresses
printed are all randomized and useless for debugging.
To prove I was not crazy I wrote this small program:
-
#include
#include
#include
#include
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Somebody");
MODULE_DESCRIPTION("A simple example Linux module.");
MODULE_VERSION("0.01");
static int __init example_init(void) {
uint32_t a;
uint32_t b;
uint32_t c;
uint8_t d[10];
uint8_t *e;
printk(KERN_INFO "Hello, World!\n");
printk(KERN_INFO " %p\n",);
printk(KERN_INFO " %p\n",);
printk(KERN_INFO " %p\n",);
printk(KERN_INFO " %p\n",d);
printk(KERN_INFO "[0] %p\n",[0]);
printk(KERN_INFO "[1] %p\n",[1]);
e = kmalloc(10, GFP_KERNEL);
printk(KERN_INFO "[0] %p\n",[0]);
printk(KERN_INFO "[1] %p\n",[1]);
kfree(e);
return 0;
}
static void __exit example_exit(void) {
printk(KERN_INFO "Goodbye, World!\n");
}
module_init(example_init);
module_exit(example_exit);
-
And it gave me this output:
Hello, World!
b3f9fa31
27e1c68a
da50d287
9f9aec2b
[0] 9f9aec2b
[1] cc627580
[0] 98b8c9eb
[1] 45f248f8
Then I tested on my debian host machine which gave me the same kind of
randomized addresses.
When I search randomization the only thing I found is KASLR which I don't
think is the same thing.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Where to find the information how to write a state of the art USB driver?
On Thu, Jan 13, 2022 at 08:01:04PM +0100, Greg KH wrote: > On Thu, Jan 13, 2022 at 07:54:19PM +0100, Philipp Hortmann wrote: > > On 1/13/22 4:33 PM, Greg KH wrote: > > > On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote: > > > > On 1/12/22 10:54 AM, Greg KH wrote: > > > > > That driver tried to be an example for an unknown device, doing > > > > > multiple > > > > > different things that no single driver/device would probably ever > > > > > need. > > > > > Also it can almost always just be replaced with a simple userspace > > > > > program using libusb, as I bet your driver could be replaced with as > > > > > well, right? > > > > Yes it can be replaced by a userspace program but even this is not > > > > required. > > > It is an issue if you are trying to write a new driver. We do not take > > > new drivers into the kernel tree if they can be in the kernel instead. > > > > > > > Sorry I did not clearly express what I plan to do. I plan to do maintenance > > and bug fixes on the kernel. > > That's wonderful, try starting out in drivers/staging/*/TODO for lots of > things that need work. And, there are USB drivers in there as well, if that is what you are interested in working on. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Where to find the information how to write a state of the art USB driver?
On Thu, Jan 13, 2022 at 07:54:19PM +0100, Philipp Hortmann wrote: > On 1/13/22 4:33 PM, Greg KH wrote: > > On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote: > > > On 1/12/22 10:54 AM, Greg KH wrote: > > > > That driver tried to be an example for an unknown device, doing multiple > > > > different things that no single driver/device would probably ever need. > > > > Also it can almost always just be replaced with a simple userspace > > > > program using libusb, as I bet your driver could be replaced with as > > > > well, right? > > > Yes it can be replaced by a userspace program but even this is not > > > required. > > It is an issue if you are trying to write a new driver. We do not take > > new drivers into the kernel tree if they can be in the kernel instead. > > > > Sorry I did not clearly express what I plan to do. I plan to do maintenance > and bug fixes on the kernel. That's wonderful, try starting out in drivers/staging/*/TODO for lots of things that need work. Messing around with old USB drivers that "just work" and you don't have the hardware for, might be a tough thing to work on as a beginning task. No need to touch things that no one is complaining about if you can help it :) thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Where to find the information how to write a state of the art USB driver?
On 1/13/22 4:33 PM, Greg KH wrote: On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote: On 1/12/22 10:54 AM, Greg KH wrote: That driver tried to be an example for an unknown device, doing multiple different things that no single driver/device would probably ever need. Also it can almost always just be replaced with a simple userspace program using libusb, as I bet your driver could be replaced with as well, right? Yes it can be replaced by a userspace program but even this is not required. It is an issue if you are trying to write a new driver. We do not take new drivers into the kernel tree if they can be in the kernel instead. Sorry I did not clearly express what I plan to do. I plan to do maintenance and bug fixes on the kernel. I am writing on drivers only for my personal education. No new drivers for the kernel. Thanks for your quick and long replies. Bye Philipp ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: How to disable address randomization ?
Hi,
To print kernel virtual address, you should use %px instead of %p in the printk.
Probably that’s why you couldn’t see the pointer values correctly.
Chan
From: admin LI
Sent: Friday, January 14, 2022 6:02 AM
To: kernelnewbies@kernelnewbies.org
Subject: How to disable address randomization ?
Hi,
I'm developing a kernel module for an ARM machine, while debugging I found
addresses
printed are all randomized and useless for debugging.
To prove I was not crazy I wrote this small program:
-
#include
#include
#include
#include
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Somebody");
MODULE_DESCRIPTION("A simple example Linux module.");
MODULE_VERSION("0.01");
static int __init example_init(void) {
uint32_t a;
uint32_t b;
uint32_t c;
uint8_t d[10];
uint8_t *e;
printk(KERN_INFO "Hello, World!\n");
printk(KERN_INFO " %p\n",);
printk(KERN_INFO " %p\n",);
printk(KERN_INFO " %p\n",);
printk(KERN_INFO " %p\n",d);
printk(KERN_INFO "[0] %p\n",[0]);
printk(KERN_INFO "[1] %p\n",[1]);
e = kmalloc(10, GFP_KERNEL);
printk(KERN_INFO "[0] %p\n",[0]);
printk(KERN_INFO "[1] %p\n",[1]);
kfree(e);
return 0;
}
static void __exit example_exit(void) {
printk(KERN_INFO "Goodbye, World!\n");
}
module_init(example_init);
module_exit(example_exit);
-
And it gave me this output:
Hello, World!
b3f9fa31
27e1c68a
da50d287
9f9aec2b
[0] 9f9aec2b
[1] cc627580
[0] 98b8c9eb
[1] 45f248f8
Then I tested on my debian host machine which gave me the same kind of
randomized addresses.
When I search randomization the only thing I found is KASLR which I don't think
is the same thing.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: How to disable address randomization ?
Hi Chan,
Thank you for pointing me to the right direction.
Pointer Types
=
Pointers printed without a specifier extension (i.e unadorned %p) are hashed to
give a unique identifier without leaking kernel addresses to user space. On 64
bit machines the first 32 bits are zeroed. If you _really_ want the address see
%px below.
Get BlueMail for Android
On Jan 14, 2022, 01:36, at 01:36, Chan Kim wrote:
>Hi,
>
>To print kernel virtual address, you should use %px instead of %p in
>the printk.
>
>Probably that’s why you couldn’t see the pointer values correctly.
>
>Chan
>
>
>
>From: admin LI
>Sent: Friday, January 14, 2022 6:02 AM
>To: kernelnewbies@kernelnewbies.org
>Subject: How to disable address randomization ?
>
>
>
>Hi,
>
>I'm developing a kernel module for an ARM machine, while debugging I
>found addresses
>printed are all randomized and useless for debugging.
>
>To prove I was not crazy I wrote this small program:
>
>-
>#include
>#include
>#include
>#include
>
>MODULE_LICENSE("GPL");
>MODULE_AUTHOR("Somebody");
>MODULE_DESCRIPTION("A simple example Linux module.");
>MODULE_VERSION("0.01");
>
>static int __init example_init(void) {
>uint32_t a;
>uint32_t b;
>uint32_t c;
>uint8_t d[10];
>uint8_t *e;
>
>printk(KERN_INFO "Hello, World!\n");
>printk(KERN_INFO " %p\n",);
>printk(KERN_INFO " %p\n",);
>printk(KERN_INFO " %p\n",);
>printk(KERN_INFO " %p\n",d);
>printk(KERN_INFO "[0] %p\n",[0]);
>printk(KERN_INFO "[1] %p\n",[1]);
>
>e = kmalloc(10, GFP_KERNEL);
>printk(KERN_INFO "[0] %p\n",[0]);
>printk(KERN_INFO "[1] %p\n",[1]);
>
>kfree(e);
>
> return 0;
>}
>
>static void __exit example_exit(void) {
> printk(KERN_INFO "Goodbye, World!\n");
>}
>
>module_init(example_init);
>module_exit(example_exit);
>-
>And it gave me this output:
>
>Hello, World!
> b3f9fa31
> 27e1c68a
> da50d287
> 9f9aec2b
>[0] 9f9aec2b
>[1] cc627580
>[0] 98b8c9eb
>[1] 45f248f8
>
>Then I tested on my debian host machine which gave me the same kind of
>randomized addresses.
>
>When I search randomization the only thing I found is KASLR which I
>don't think is the same thing.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to disable address randomization ?
Hi Jeff,
Thanks for your help, finally I found this in kernel document.
Pointer Types
=
Pointers printed without a specifier extension (i.e unadorned %p) are hashed to
give a unique identifier without leaking kernel addresses to user space. On 64
bit machines the first 32 bits are zeroed. If you _really_ want the address see
%px below.
Get BlueMail for Android
On Jan 13, 2022, 23:44, at 23:44, Jeffrey Walton wrote:
>On Thu, Jan 13, 2022 at 4:04 PM admin LI wrote:
>>
>> I'm developing a kernel module for an ARM machine, while debugging I
>found addresses
>> printed are all randomized and useless for debugging.
>>
>> To prove I was not crazy I wrote this small program:
>>
>> -
>> #include
>> #include
>> #include
>> #include
>>
>> MODULE_LICENSE("GPL");
>> MODULE_AUTHOR("Somebody");
>> MODULE_DESCRIPTION("A simple example Linux module.");
>> MODULE_VERSION("0.01");
>>
>> static int __init example_init(void) {
>> uint32_t a;
>> uint32_t b;
>> uint32_t c;
>> uint8_t d[10];
>> uint8_t *e;
>>
>> printk(KERN_INFO "Hello, World!\n");
>> printk(KERN_INFO " %p\n",);
>> printk(KERN_INFO " %p\n",);
>> printk(KERN_INFO " %p\n",);
>> printk(KERN_INFO " %p\n",d);
>> printk(KERN_INFO "[0] %p\n",[0]);
>> printk(KERN_INFO "[1] %p\n",[1]);
>>
>> e = kmalloc(10, GFP_KERNEL);
>> printk(KERN_INFO "[0] %p\n",[0]);
>> printk(KERN_INFO "[1] %p\n",[1]);
>>
>> kfree(e);
>>
>> return 0;
>> }
>>
>> static void __exit example_exit(void) {
>> printk(KERN_INFO "Goodbye, World!\n");
>> }
>>
>> module_init(example_init);
>> module_exit(example_exit);
>> -
>> And it gave me this output:
>>
>> Hello, World!
>> b3f9fa31
>> 27e1c68a
>> da50d287
>> 9f9aec2b
>> [0] 9f9aec2b
>> [1] cc627580
>> [0] 98b8c9eb
>> [1] 45f248f8
>>
>> Then I tested on my debian host machine which gave me the same kind
>of randomized addresses.
>>
>> When I search randomization the only thing I found is KASLR which I
>don't think is the same thing.
>
>I think something else may be going on, but I'll toss this out there
>in case it helps.
>
>In the past randomization was disabled by writing 0 to
>/proc/sys/kernel/randomize_va_space. Something like:
>
>sysctl -w kernel.randomize_va_space=0
>
>To make it permanent, change it in /etc/sysctl.conf.
>
>Jeff
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
