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
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
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
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
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 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,
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:
> > > > >
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:
> > > > >
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
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
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
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
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
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
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
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
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.
> >
>
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
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
> >>
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
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
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
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
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
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
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 =
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 =
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 =
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 =
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 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 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 =
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 =
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
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
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
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
(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,
(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
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
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
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
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
> >>
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
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
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 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
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.
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
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
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
>> >
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
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
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
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,
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
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 |
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://github.com/tcharding/linux.git tags/printk-hash-pointer-4.15-rc2
for you to fetch changes up to
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://github.com/tcharding/linux.git tags/printk-hash-pointer-4.15-rc2
for you to fetch changes up to
86 matches
Mail list logo