Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ2oMh+XPRDu_+VxZ1+thNnSpz9S1GXjNvng8+mWDH3GxZfu1Q@mail.gmail.com>
Date: Sun, 20 Aug 2017 09:53:00 +0300
From: Ran Shalit <ranshalit@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: hardening mmc driver

On Fri, Aug 18, 2017 at 11:44 PM, Kees Cook <keescook@...omium.org> wrote:
> On Thu, Aug 17, 2017 at 10:57 PM, Ran Shalit <ranshalit@...il.com> wrote:
>> Hello,
>
> Hi!
>
>> What action should be taken to make mmc driver secured ?
>>
>> If there any wiki or document, which can help to understand better
>> when a driver (like mmc)  is considered secured ?
>
> I don't have any specific pointers at the moment, but I think the main
> focus for drivers (or really any software) is being extremely careful
> with data processing and the validation of command arguments. Never
> assume the commands you're getting will follow an expected protocol:
> pretend the device at the other end of the bus (or the bus itself!) is
> trying to attack the driver. Same for any commands coming from
> userspace.
>
> Are there particular things you're concerned about for MMC security?
>

Hello Kees,

Thank you very much for your feedback.
I've found an interesing article by Intel, which tried to define and
strandarize hardening of device driver.
https://software.intel.com/sites/default/files/m/d/4/1/d/8/matassa.pdf
I have no special concern now for the driver, except trying to grasp
better how to make a driver "secured".
I will follow the article guidelines and your comment at the moment.

Best Regards,
Ran




> -Kees
>
> --
> Kees Cook
> Pixel Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.