Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Aug 2017 10:04:35 +0300
From: Ran Shalit <>
To: Kees Cook <>
Cc: "" <>
Subject: Re: hardening mmc driver

On Sun, Aug 20, 2017 at 9:53 AM, Ran Shalit <> wrote:
> On Fri, Aug 18, 2017 at 11:44 PM, Kees Cook <> wrote:
>> On Thu, Aug 17, 2017 at 10:57 PM, Ran Shalit <> 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.
> 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

Does this article seems as a good starting point as guidelines for
hardening device driver ?


>> --
>> 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.