linux-kernel - Re: [PATCH] Intel Management Engine Interface

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]

Message-ID: <ea8d860a0808121224y63bd4178xe0c74d5fb3e34180@mail.gmail.com>
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/