linux-kernel - Re: [PATCH 7/11] 2.6.18-mm3 pktcdvd: make procfs interface optional

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 09 Oct 2006 12:05:11 +0200
From:	"Thomas Maier" <balagi@...tmail.de>
To:	"Peter Osterlund" <petero2@...ia.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/11] 2.6.18-mm3 pktcdvd: make procfs interface optional

Hello,

Am 05.10.2006, 21:59 Uhr, schrieb Peter Osterlund <petero2@...ia.com>:

> Given the fact that Linus doesn't allow breaking user space tools
> unless absolutely necessary, I don't think it makes sense to be able
> to disable the character device control code.

Hmm, since it will be optional to leave the procfs interface in the
kernel, it is on the admin / distribution builder to decide this.
I know only one tool that uses this interface (pktsetup), maybe there
are others, but if the sysfs interface will be available in future (?),
there is another (simple) option to control the driver, using simple
shell commands e.g.
And i read anywhere, that procfs should only contain process information
in a far away (?) future ;)

> Therefore a patch that unconditionally moves
> /proc/driver/pktcdvd/pktcdvd? to debugfs would make a lot of sense.

Then move it to debugfs and drop it from procfs.

> Also, the current change has another problem:
>
> static int pkt_seq_show(struct seq_file *m, void *p)
> +{
> +       struct pktcdvd_device *pd = m->private;
> +       char buf[1024];
> +
> +       pkt_print_info(pd, buf, sizeof(buf));
> +       seq_printf(m, "%s", buf);
> +       return 0;
> +}
>
> This wastes 1K stack space, and it can corrupt the stack if the
> pkt_print_info() function wants to write more than 1K data.

Ok, 1k is a little bit high, since only about 300 chars are written
into the buffer currently.
But also, pkt_print_info() would only write sizeof(buf) chars into
the buffer.

-Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/