On Tue, Dec 05, 2017 at 09:25:07AM +, Ard Biesheuvel wrote:
> On 5 December 2017 at 08:52, Greg Kroah-Hartman
> wrote:
> > On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote:
> >> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> >> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Yo
On Tue, Dec 05, 2017 at 05:24:10PM +0800, Dave Young wrote:
> On 12/05/17 at 04:45pm, Dave Young wrote:
> > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > > On Mon,
On 12/05/17 at 09:52am, Greg Kroah-Hartman wrote:
> On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote:
> > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > >
On 5 December 2017 at 08:52, Greg Kroah-Hartman
wrote:
> On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote:
>> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
>> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
>> > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
>> > >
On 12/05/17 at 04:45pm, Dave Young wrote:
> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > > From:
On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote:
> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrot
On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > From: Ard Biesheuvel
> > > > > Sent: 04 December 2017 10:
On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > From: Ard Biesheuvel
> > > > Sent: 04 December 2017 10:03
> > > ...
> > > > and uses __ATTR_RO() to emit initialize
On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > From: Ard Biesheuvel
> > > Sent: 04 December 2017 10:03
> > ...
> > > and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes
> > > the .store member as well, which d
On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> From: Ard Biesheuvel
> > Sent: 04 December 2017 10:03
> ...
> > and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes
> > the .store member as well, which does not exists, and so it cannot be
> > used directly.
> >
>
From: Ard Biesheuvel
> Sent: 04 December 2017 10:03
...
> and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes
> the .store member as well, which does not exists, and so it cannot be
> used directly.
>
> So we should either add a .store member that is always NULL, or we
> should
On Mon, Dec 04, 2017 at 10:03:19AM +, Ard Biesheuvel wrote:
> On 4 December 2017 at 09:59, Greg Kroah-Hartman
> wrote:
> > On Mon, Dec 04, 2017 at 09:48:37AM +, Ard Biesheuvel wrote:
> >> On 4 December 2017 at 09:34, Greg Kroah-Hartman
> >> wrote:
> >> > On Mon, Dec 04, 2017 at 05:29:28PM
On 4 December 2017 at 09:59, Greg Kroah-Hartman
wrote:
> On Mon, Dec 04, 2017 at 09:48:37AM +, Ard Biesheuvel wrote:
>> On 4 December 2017 at 09:34, Greg Kroah-Hartman
>> wrote:
>> > On Mon, Dec 04, 2017 at 05:29:28PM +0800, Dave Young wrote:
>> >> On 12/04/17 at 08:36am, Greg Kroah-Hartman w
On Mon, Dec 04, 2017 at 09:48:37AM +, Ard Biesheuvel wrote:
> On 4 December 2017 at 09:34, Greg Kroah-Hartman
> wrote:
> > On Mon, Dec 04, 2017 at 05:29:28PM +0800, Dave Young wrote:
> >> On 12/04/17 at 08:36am, Greg Kroah-Hartman wrote:
> >> > On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Yo
On 4 December 2017 at 09:34, Greg Kroah-Hartman
wrote:
> On Mon, Dec 04, 2017 at 05:29:28PM +0800, Dave Young wrote:
>> On 12/04/17 at 08:36am, Greg Kroah-Hartman wrote:
>> > On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote:
>> > > +#define __ATTR_IRUSR(_name) {
On Mon, Dec 04, 2017 at 05:29:28PM +0800, Dave Young wrote:
> On 12/04/17 at 08:36am, Greg Kroah-Hartman wrote:
> > On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote:
> > > +#define __ATTR_IRUSR(_name) {
> > > \
> > > + .attr = { .name = __stri
On 12/04/17 at 08:36am, Greg Kroah-Hartman wrote:
> On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote:
> > +#define __ATTR_IRUSR(_name) {
> > \
> > + .attr = { .name = __stringify(_name), .mode = S_IRUSR }, \
> > + .show = _name##_
On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote:
> +#define __ATTR_IRUSR(_name) {
> \
> + .attr = { .name = __stringify(_name), .mode = S_IRUSR }, \
> + .show = _name##_show, \
> +}
On 12/03/17 at 06:33pm, Joe Perches wrote:
> On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote:
> > I think 0400 is good enough for this issue.
> >
> > Greg, would you like to agree add an extra macro like below?
> []
> > -static struct map_attribute map_type_attr = __ATTR_RO(type);
> > -static
On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote:
> I think 0400 is good enough for this issue.
>
> Greg, would you like to agree add an extra macro like below?
[]
> -static struct map_attribute map_type_attr = __ATTR_RO(type);
> -static struct map_attribute map_phys_addr_attr = __ATTR_RO(phy
On 12/02/17 at 10:22pm, Matt Fleming wrote:
> (Cc'ing Dave since this is used for kexec on EFI)
>
> On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote:
> > On 1 December 2017 at 09:48, Greg Kroah-Hartman
> > wrote:
> > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote:
> > >> On 3
On 12/02/17 at 10:22pm, Matt Fleming wrote:
> (Cc'ing Dave since this is used for kexec on EFI)
>
> On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote:
> > On 1 December 2017 at 09:48, Greg Kroah-Hartman
> > wrote:
> > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote:
> > >> On 3
(Cc'ing Dave since this is used for kexec on EFI)
On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote:
> On 1 December 2017 at 09:48, Greg Kroah-Hartman
> wrote:
> > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote:
> >> On 30 November 2017 at 17:10, Greg Kroah-Hartman
> >> wrote:
On 1 December 2017 at 16:33, Kees Cook wrote:
> On Fri, Dec 1, 2017 at 7:34 AM, Greg Kroah-Hartman
> wrote:
>
>> And isn't there a specific %p modifier you should use for a kernel
>> pointer. I've lost the thread here for what should, or should not, be
>> done for kernel pointers these days base
On Fri, Dec 1, 2017 at 7:34 AM, Greg Kroah-Hartman
wrote:
> And isn't there a specific %p modifier you should use for a kernel
> pointer. I've lost the thread here for what should, or should not, be
> done for kernel pointers these days based on the long email discussion.
Current implementation
On Fri, Dec 01, 2017 at 09:54:43AM +, Ard Biesheuvel wrote:
> On 1 December 2017 at 09:48, Greg Kroah-Hartman
> wrote:
> > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote:
> >> On 30 November 2017 at 17:10, Greg Kroah-Hartman
> >> wrote:
> >> > On Thu, Nov 30, 2017 at 04:32:35P
On 1 December 2017 at 09:48, Greg Kroah-Hartman
wrote:
> On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote:
>> On 30 November 2017 at 17:10, Greg Kroah-Hartman
>> wrote:
>> > On Thu, Nov 30, 2017 at 04:32:35PM +, Greg Kroah-Hartman wrote:
>> >> On Wed, Nov 29, 2017 at 01:36:25PM
On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote:
> On 30 November 2017 at 17:10, Greg Kroah-Hartman
> wrote:
> > On Thu, Nov 30, 2017 at 04:32:35PM +, Greg Kroah-Hartman wrote:
> >> On Wed, Nov 29, 2017 at 01:36:25PM -0800, Linus Torvalds wrote:
> >> > On Wed, Nov 29, 2017 at 1:
On Thu, Nov 30, 2017 at 06:17:47PM -0500, Linus Torvalds wrote:
> On Thu, Nov 30, 2017 at 12:10 PM, Greg Kroah-Hartman
> wrote:
> >
> > So changing it to use __ATTR() should fix this remaning leakage up.
> > That is if we even really need to export these values at all. What does
> > userspace do
On Thu, Nov 30, 2017 at 12:10 PM, Greg Kroah-Hartman
wrote:
>
> So changing it to use __ATTR() should fix this remaning leakage up.
> That is if we even really need to export these values at all. What does
> userspace do with them? Shouldn't they just be in debugfs instead?
So what I find dista
On 30 November 2017 at 17:10, Greg Kroah-Hartman
wrote:
> On Thu, Nov 30, 2017 at 04:32:35PM +, Greg Kroah-Hartman wrote:
>> On Wed, Nov 29, 2017 at 01:36:25PM -0800, Linus Torvalds wrote:
>> > On Wed, Nov 29, 2017 at 1:14 PM, Linus Torvalds
>> > wrote:
>> > >
>> > > Not because %pK itself ch
On Thu, Nov 30, 2017 at 04:32:35PM +, Greg Kroah-Hartman wrote:
> On Wed, Nov 29, 2017 at 01:36:25PM -0800, Linus Torvalds wrote:
> > On Wed, Nov 29, 2017 at 1:14 PM, Linus Torvalds
> > wrote:
> > >
> > > Not because %pK itself changed, but because the semantics of %p did.
> > > The baseline m
On Wed, Nov 29, 2017 at 01:36:25PM -0800, Linus Torvalds wrote:
> On Wed, Nov 29, 2017 at 1:14 PM, Linus Torvalds
> wrote:
> >
> > Not because %pK itself changed, but because the semantics of %p did.
> > The baseline moved, and the "safe" version did not.
>
> Btw, that baseline for me is now that
On Wed, Nov 29, 2017 at 1:14 PM, Linus Torvalds
wrote:
>
> Not because %pK itself changed, but because the semantics of %p did.
> The baseline moved, and the "safe" version did not.
Btw, that baseline for me is now that I can do
./scripts/leaking_addresses.pl | wc -l
18
and of those 18 hits
On Wed, Nov 29, 2017 at 11:39 AM, Linus Torvalds
wrote:
> On Wed, Nov 29, 2017 at 11:22 AM, Linus Torvalds
> wrote:
>>
>> What I didn't realize until after pulling this and testing, is that it
>> completely breaks '%pK'.
>>
>> We've marked various sensitive pointers with %pK, but that is now
>> _
On Wed, Nov 29, 2017 at 01:14:38PM -0800, Linus Torvalds wrote:
> On Wed, Nov 29, 2017 at 1:08 PM, Tobin C. Harding wrote:
> >
> > If you haven't wasted enough time on this can you tell me what you mean
> > by 'completely breaks %pK'?
>
> The whole point of %pK is that it's a "safer" %p that does
On Wed, Nov 29, 2017 at 1:08 PM, Tobin C. Harding wrote:
>
> If you haven't wasted enough time on this can you tell me what you mean
> by 'completely breaks %pK'?
The whole point of %pK is that it's a "safer" %p that doesn't leak
information if you set kptr_restrict.
With that patch-set, it now
On Wed, Nov 29, 2017 at 11:22:29AM -0800, Linus Torvalds wrote:
> On Tue, Nov 28, 2017 at 8:59 PM, Tobin C. Harding wrote:
> >
> > git://github.com/tcharding/linux.git tags/printk-hash-pointer-4.15-rc2
>
> Bah.
Sorry for creating extra work for you.
> What I didn't realize until after pulling
On Wed, Nov 29, 2017 at 12:54 PM, Joe Perches wrote:
>
> I'd prefer a global sed of '%pK' to '%pxK' and remove '%pK' altogether
No, we really don't want %pK to become %pxK.
Most of the %pK users absolutely do not want the real hex address.
They are things like the socket pointers in /proc etc. T
On Wed, 2017-11-29 at 11:39 -0800, Linus Torvalds wrote:
> On Wed, Nov 29, 2017 at 11:22 AM, Linus Torvalds
> wrote:
> >
> > What I didn't realize until after pulling this and testing, is that it
> > completely breaks '%pK'.
> >
> > We've marked various sensitive pointers with %pK, but that is n
On Wed, Nov 29, 2017 at 11:22 AM, Linus Torvalds
wrote:
>
> What I didn't realize until after pulling this and testing, is that it
> completely breaks '%pK'.
>
> We've marked various sensitive pointers with %pK, but that is now
> _less_ secure than %p is, since it doesn't do the hashing because of
On Tue, Nov 28, 2017 at 8:59 PM, Tobin C. Harding wrote:
>
> git://github.com/tcharding/linux.git tags/printk-hash-pointer-4.15-rc2
Bah.
What I didn't realize until after pulling this and testing, is that it
completely breaks '%pK'.
We've marked various sensitive pointers with %pK, but that i
42 matches
Mail list logo