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
| ||
|
Date: Tue, 12 Aug 2008 20:24:51 +0100 From: "Marcin Obara" <marcin_obara@...rs.sourceforge.net> To: "Jiri Slaby" <jirislaby@...il.com> Cc: "Andrew Morton" <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Intel Management Engine Interface 2008/8/12 Jiri Slaby <jirislaby@...il.com>: > On 08/12/2008 06:53 AM, Andrew Morton wrote: >> >> On Mon, 11 Aug 2008 21:23:01 +0200 (CEST) >> Marcin Obara <marcin_obara@...rs.sourceforge.net> wrote: >>> +#define ECORRUPTED_MESSAGE_HEADER 1000 >>> +#define ECOMPLETE_MESSAGE 1001 >> >> What's this? The driver defines its onw errno numbers? >> >> Are these ever returned to userspace? >> >> This is risky/confusing/misleading, isn't it? > > Yes and already pointed out. This leaks to userspace and it's wrong. Please > go and read my comments to version #1 once again and if you don't understand > anything, please drop a message, but do not silently ignore others' > comments. Sorry. I will try to explain. This source code was designed few years ago and there is already written userspace software. Removal of driver internal error codes may affect software. I think it is more risky than keeping these own errno numbers. > > E.g. unlocked_ioctl switch hasn't been done plus other things mentioned > below too (not all of them) > unlocked_ioctl would require to add lock as big kernel lock replacement. It is risky in such complex code, especially if speed increase is not expected. >>> + spin_lock_bh(&dev->device_lock); >>> + dev->wd_timer.function = &heci_wd_timer; >>> + dev->wd_timer.data = (unsigned long) dev; >>> + spin_unlock_bh(&dev->device_lock); >> >> Use setup_timer(). >> >> Note that setup_timer() does init_timer(), but we already have an >> init_timer(dev->wd_timer) elsewhere. Please sort that out. > > Already commented, left unchanged and without an explanation. Sorry. Explanation: We don't want to init_timer() here. It is done later, to avoid race condition. We only configure timer, but we are not ready to start it. > >>> +/* IOCTL commands */ >>> +#define IOCTL_HECI_GET_VERSION \ >>> + _IOWR('H' , 0x0, struct heci_message_data) > ... and conflicts with hid as I commented before. Sorry for missing explanations. This conflict can't be avoided, because there is already written software that depends on these ioctl definitions. -- Regards Marcin -- 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/
Powered by blists - more mailing lists