linux-kernel - Re: [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP events

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, 8 Apr 2019 17:41:15 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     gwendal@...omium.org, bleung@...omium.org,
        linux-kernel@...r.kernel.org, groeck@...omium.org,
        kernel@...labora.com, dtor@...omium.org,
        Vincent Palatin <vpalatin@...omium.org>
Subject: Re: [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP
 events

Hi Lee,

On 2/4/19 6:06, Lee Jones wrote:
> On Fri, 08 Mar 2019, Enric Balletbo i Serra wrote:
> 
>> From: Vincent Palatin <vpalatin@...omium.org>
>>
>> Allow to poll on the cros_ec device to receive the MKBP events.
>>
>> The /dev/cros_[ec|fp|..] file operations now implements the poll
>> operation. The userspace can now receive specific MKBP events by doing the
>> following:
>> - Open the /dev/cros_XX file.
>> - Call the CROS_EC_DEV_IOCEVENTMASK ioctl with the bitmap of the MKBP
>>   events it wishes to receive as argument.
>> - Poll on the file descriptor.
>> - When it gets POLLIN, do a read on the file descriptor, the first
>>   queued event will be returned (using the struct
>>   ec_response_get_next_event format: one byte of event type, then
>>   the payload).
>>
>> The read() operation returns at most one event even if there are several
>> queued, and it might be truncated if the buffer is smaller than the
>> event (but the caller should know the maximum size of the events it is
>> reading).
>>
>> read() used to return the EC version string, it still does it when no
>> event mask or an empty event is set for backward compatibility (despite
>> nobody really using this feature).
>>
>> This will be used, for example, by the userspace daemon to receive and
>> treat the EC_MKBP_EVENT_FINGERPRINT sent by the FP MCU.
> 
> MFD does not seem like the correct place for this.  Maybe this is a
> good candidate for drivers/platform/chrome/* where the rest of your
> platform empire now resides.
> 

The patch itself can't be moved without moving other parts, this would imply
move all the file_operations and the chardev, those already resides in MFD, and
some event handling. Is this what you're suggesting?

If that's the case I need to look in more detail.

Thanks,
 Enric


>> Signed-off-by: Vincent Palatin <vpalatin@...omium.org>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
>> ---
>>
>>  drivers/mfd/cros_ec_dev.c | 163 +++++++++++++++++++++++++++++++++++++-
>>  drivers/mfd/cros_ec_dev.h |   1 +
>>  2 files changed, 160 insertions(+), 4 deletions(-)
>