* [kernel-hardening] %pK continuation
@ 2017-02-10 19:02 Roberts, William C
2017-02-10 19:52 ` Greg KH
2017-02-10 23:41 ` [kernel-hardening] " Kees Cook
0 siblings, 2 replies; 6+ messages in thread
From: Roberts, William C @ 2017-02-10 19:02 UTC (permalink / raw)
To: kernel-hardening; +Cc: Kees Cook
I haven't had time to really work on the continuation of:
http://www.openwall.com/lists/kernel-hardening/2016/10/07/1
I think the simple approach of killing %p based on kptr_restrict remains the simplest, IMHO best way to achieve a better level of
preventing leaks of kernel addresses. In example of %pK going wrong can be found here:
https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-bypassing-samsungs.html.
Granted, the exploit author would have found another way to defeat KASL, I'd like to force their hand.
In a nut shell, the driver use %pk instead of %pK (capitalization of K matters). This would actually be a
good checkpatch.pl check. I grep'd the kernel for %pk (lower case k) and found no usages!
Just passing along some thoughts,
Bill
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening] %pK continuation
2017-02-10 19:02 [kernel-hardening] %pK continuation Roberts, William C
@ 2017-02-10 19:52 ` Greg KH
2017-02-10 21:53 ` Nicolas Iooss
2017-02-10 23:41 ` [kernel-hardening] " Kees Cook
1 sibling, 1 reply; 6+ messages in thread
From: Greg KH @ 2017-02-10 19:52 UTC (permalink / raw)
To: Roberts, William C; +Cc: kernel-hardening, Kees Cook
On Fri, Feb 10, 2017 at 07:02:42PM +0000, Roberts, William C wrote:
> I haven't had time to really work on the continuation of:
> http://www.openwall.com/lists/kernel-hardening/2016/10/07/1
>
> I think the simple approach of killing %p based on kptr_restrict remains the simplest, IMHO best way to achieve a better level of
> preventing leaks of kernel addresses. In example of %pK going wrong can be found here:
> https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-bypassing-samsungs.html.
>
> Granted, the exploit author would have found another way to defeat KASL, I'd like to force their hand.
>
> In a nut shell, the driver use %pk instead of %pK (capitalization of K matters). This would actually be a
> good checkpatch.pl check. I grep'd the kernel for %pk (lower case k) and found no usages!
%pk is not a valid kernel printk() modifier at all, so I sure hope you
%would not find any usages :)
Documentation/printk-formats.txt is a good thing to check.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening] %pK continuation
2017-02-10 19:52 ` Greg KH
@ 2017-02-10 21:53 ` Nicolas Iooss
0 siblings, 0 replies; 6+ messages in thread
From: Nicolas Iooss @ 2017-02-10 21:53 UTC (permalink / raw)
To: Greg KH, Roberts, William C, kernel-hardening; +Cc: Kees Cook
On 10/02/17 20:52, Greg KH wrote:
> On Fri, Feb 10, 2017 at 07:02:42PM +0000, Roberts, William C wrote:
>> I haven't had time to really work on the continuation of:
>> http://www.openwall.com/lists/kernel-hardening/2016/10/07/1
>>
>> I think the simple approach of killing %p based on kptr_restrict remains the simplest, IMHO best way to achieve a better level of
>> preventing leaks of kernel addresses. In example of %pK going wrong can be found here:
>> https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-bypassing-samsungs.html.
>>
>> Granted, the exploit author would have found another way to defeat KASL, I'd like to force their hand.
>>
>> In a nut shell, the driver use %pk instead of %pK (capitalization of K matters). This would actually be a
>> good checkpatch.pl check. I grep'd the kernel for %pk (lower case k) and found no usages!
>
> %pk is not a valid kernel printk() modifier at all, so I sure hope you
> %would not find any usages :)
Actually such a format string was present in the kernel until commit
901d805c33fc ("UBSAN: fix typo in format string") (merged in 4.8). I
found it using a gcc plugin and I guess other people are performing
static analysis on the kernel code and report the bug they find. This
would better explain why it is quite difficult to find inconsistent
format strings today.
And this just reminded me that I sent some patches back in October to
fix some issues in drivers/isdn/hardware/eicon/ (e.g.
https://lkml.org/lkml/2016/10/29/140), and these patches have not been
applied because they needed more work. As my own free time to work on
the kernel is quite scarse, someone else on kernel-hardening@ might be
willing to take over these patches...
Regards,
Nicolas
^ permalink raw reply [flat|nested] 6+ messages in thread
* [kernel-hardening] Re: %pK continuation
2017-02-10 19:02 [kernel-hardening] %pK continuation Roberts, William C
2017-02-10 19:52 ` Greg KH
@ 2017-02-10 23:41 ` Kees Cook
2017-02-13 19:50 ` [kernel-hardening] " Roberts, William C
1 sibling, 1 reply; 6+ messages in thread
From: Kees Cook @ 2017-02-10 23:41 UTC (permalink / raw)
To: Roberts, William C; +Cc: kernel-hardening
On Fri, Feb 10, 2017 at 11:02 AM, Roberts, William C
<william.c.roberts@intel.com> wrote:
> I haven't had time to really work on the continuation of:
> http://www.openwall.com/lists/kernel-hardening/2016/10/07/1
>
> I think the simple approach of killing %p based on kptr_restrict remains the simplest, IMHO best way to achieve a better level of
> preventing leaks of kernel addresses. In example of %pK going wrong can be found here:
> https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-bypassing-samsungs.html.
There's been some experimentation in Android kernels recently based on
your original version, though it's not quite ready for prime-time. I'm
hoping to see it posted to this list soon...
> Granted, the exploit author would have found another way to defeat KASL, I'd like to force their hand.
Always true, but better to keep raising the bar, I think. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 6+ messages in thread
* [kernel-hardening] RE: %pK continuation
2017-02-10 23:41 ` [kernel-hardening] " Kees Cook
@ 2017-02-13 19:50 ` Roberts, William C
2017-02-13 20:06 ` [kernel-hardening] " Kees Cook
0 siblings, 1 reply; 6+ messages in thread
From: Roberts, William C @ 2017-02-13 19:50 UTC (permalink / raw)
To: Kees Cook; +Cc: kernel-hardening
> -----Original Message-----
> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, February 10, 2017 3:42 PM
> To: Roberts, William C <william.c.roberts@intel.com>
> Cc: kernel-hardening@lists.openwall.com
> Subject: Re: %pK continuation
>
> On Fri, Feb 10, 2017 at 11:02 AM, Roberts, William C
> <william.c.roberts@intel.com> wrote:
> > I haven't had time to really work on the continuation of:
> > http://www.openwall.com/lists/kernel-hardening/2016/10/07/1
> >
> > I think the simple approach of killing %p based on kptr_restrict
> > remains the simplest, IMHO best way to achieve a better level of preventing
> leaks of kernel addresses. In example of %pK going wrong can be found here:
> > https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-
> bypassing-samsungs.html.
>
> There's been some experimentation in Android kernels recently based on your
> original version, though it's not quite ready for prime-time. I'm hoping to see it
> posted to this list soon...
Oh really, do you have any links to those patches?
>
> > Granted, the exploit author would have found another way to defeat KASL, I'd
> like to force their hand.
>
> Always true, but better to keep raising the bar, I think. :)
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
^ permalink raw reply [flat|nested] 6+ messages in thread
* [kernel-hardening] Re: %pK continuation
2017-02-13 19:50 ` [kernel-hardening] " Roberts, William C
@ 2017-02-13 20:06 ` Kees Cook
0 siblings, 0 replies; 6+ messages in thread
From: Kees Cook @ 2017-02-13 20:06 UTC (permalink / raw)
To: Roberts, William C; +Cc: kernel-hardening
On Mon, Feb 13, 2017 at 11:50 AM, Roberts, William C
<william.c.roberts@intel.com> wrote:
>> -----Original Message-----
>> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees
>> Cook
>> Sent: Friday, February 10, 2017 3:42 PM
>> To: Roberts, William C <william.c.roberts@intel.com>
>> Cc: kernel-hardening@lists.openwall.com
>> Subject: Re: %pK continuation
>>
>> On Fri, Feb 10, 2017 at 11:02 AM, Roberts, William C
>> <william.c.roberts@intel.com> wrote:
>> > I haven't had time to really work on the continuation of:
>> > http://www.openwall.com/lists/kernel-hardening/2016/10/07/1
>> >
>> > I think the simple approach of killing %p based on kptr_restrict
>> > remains the simplest, IMHO best way to achieve a better level of preventing
>> leaks of kernel addresses. In example of %pK going wrong can be found here:
>> > https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-
>> bypassing-samsungs.html.
>>
>> There's been some experimentation in Android kernels recently based on your
>> original version, though it's not quite ready for prime-time. I'm hoping to see it
>> posted to this list soon...
>
> Oh really, do you have any links to those patches?
Not yet, but hopefully soon. I'll get them posted as soon as I have them.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-13 20:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-10 19:02 [kernel-hardening] %pK continuation Roberts, William C
2017-02-10 19:52 ` Greg KH
2017-02-10 21:53 ` Nicolas Iooss
2017-02-10 23:41 ` [kernel-hardening] " Kees Cook
2017-02-13 19:50 ` [kernel-hardening] " Roberts, William C
2017-02-13 20:06 ` [kernel-hardening] " Kees Cook
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.