* [kernel-hardening] hardening mmc driver
@ 2017-08-18 5:57 Ran Shalit
2017-08-18 20:44 ` Kees Cook
0 siblings, 1 reply; 5+ messages in thread
From: Ran Shalit @ 2017-08-18 5:57 UTC (permalink / raw)
To: kernel-hardening
Hello,
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 ?
Thank you,
Ran
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] hardening mmc driver
2017-08-18 5:57 [kernel-hardening] hardening mmc driver Ran Shalit
@ 2017-08-18 20:44 ` Kees Cook
2017-08-20 6:53 ` Ran Shalit
0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2017-08-18 20:44 UTC (permalink / raw)
To: Ran Shalit; +Cc: kernel-hardening@lists.openwall.com
On Thu, Aug 17, 2017 at 10:57 PM, Ran Shalit <ranshalit@gmail.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?
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] hardening mmc driver
2017-08-18 20:44 ` Kees Cook
@ 2017-08-20 6:53 ` Ran Shalit
2017-08-20 7:04 ` Ran Shalit
2017-08-20 16:59 ` Greg KH
0 siblings, 2 replies; 5+ messages in thread
From: Ran Shalit @ 2017-08-20 6:53 UTC (permalink / raw)
To: Kees Cook; +Cc: kernel-hardening@lists.openwall.com
On Fri, Aug 18, 2017 at 11:44 PM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Aug 17, 2017 at 10:57 PM, Ran Shalit <ranshalit@gmail.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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] hardening mmc driver
2017-08-20 6:53 ` Ran Shalit
@ 2017-08-20 7:04 ` Ran Shalit
2017-08-20 16:59 ` Greg KH
1 sibling, 0 replies; 5+ messages in thread
From: Ran Shalit @ 2017-08-20 7:04 UTC (permalink / raw)
To: Kees Cook; +Cc: kernel-hardening@lists.openwall.com
On Sun, Aug 20, 2017 at 9:53 AM, Ran Shalit <ranshalit@gmail.com> wrote:
> On Fri, Aug 18, 2017 at 11:44 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, Aug 17, 2017 at 10:57 PM, Ran Shalit <ranshalit@gmail.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
Does this article seems as a good starting point as guidelines for
hardening device driver ?
Thanks,
Ran
>>
>> --
>> Kees Cook
>> Pixel Security
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] hardening mmc driver
2017-08-20 6:53 ` Ran Shalit
2017-08-20 7:04 ` Ran Shalit
@ 2017-08-20 16:59 ` Greg KH
1 sibling, 0 replies; 5+ messages in thread
From: Greg KH @ 2017-08-20 16:59 UTC (permalink / raw)
To: Ran Shalit; +Cc: Kees Cook, kernel-hardening@lists.openwall.com
On Sun, Aug 20, 2017 at 09:53:00AM +0300, Ran Shalit wrote:
> On Fri, Aug 18, 2017 at 11:44 PM, Kees Cook <keescook@chromium.org> wrote:
> > On Thu, Aug 17, 2017 at 10:57 PM, Ran Shalit <ranshalit@gmail.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.
Please note the date of that article, 2002, so some things in there
might not be valid anymore, and some are flat out wrong (hint, never use
'volatile' in the kernel, or anywhere really...). But overall, it's a
good place to start.
good luck!
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-08-20 16:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-18 5:57 [kernel-hardening] hardening mmc driver Ran Shalit
2017-08-18 20:44 ` Kees Cook
2017-08-20 6:53 ` Ran Shalit
2017-08-20 7:04 ` Ran Shalit
2017-08-20 16:59 ` Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.