LinuxLists.cc - Linux 2.6.25.10

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

diff --git a/Makefile b/Makefile
index 3eb71f8..e26eb7d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 25
-EXTRAVERSION = .9
+EXTRAVERSION = .10
NAME = Funky Weasel is Jiggy wit it

# *DOCUMENTATION*
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index d2e39e6..5f04579 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -130,7 +130,7 @@ int xfpregs_get(struct task_struct *target, const struct user_regset *regset,
void *kbuf, void __user *ubuf)
{
if (!cpu_has_fxsr)
- return -ENODEV;
+ return -EIO;

init_fpu(target);

@@ -145,7 +145,7 @@ int xfpregs_set(struct task_struct *target, const struct user_regset *regset,
int ret;

if (!cpu_has_fxsr)
- return -ENODEV;
+ return -EIO;

init_fpu(target);
set_stopped_child_used_math(target);
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 9003e0b..a10ba65 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1309,42 +1309,49 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
break;

case PTRACE_GETREGS: /* Get all gp regs from the child. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_GENERAL,
- 0, sizeof(struct user_regs_struct32),
- datap);
+ ret = copy_regset_to_user(child, &user_x86_32_view,
+ REGSET_GENERAL,
+ 0, sizeof(struct user_regs_struct32),
+ datap);
+ break;

case PTRACE_SETREGS: /* Set all gp regs in the child. */
- return copy_regset_from_user(child, &user_x86_32_view,
- REGSET_GENERAL, 0,
- sizeof(struct user_regs_struct32),
- datap);
+ ret = copy_regset_from_user(child, &user_x86_32_view,
+ REGSET_GENERAL, 0,
+ sizeof(struct user_regs_struct32),
+ datap);
+ break;

case PTRACE_GETFPREGS: /* Get the child FPU state. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_FP, 0,
- sizeof(struct user_i387_ia32_struct),
- datap);
+ ret = copy_regset_to_user(child, &user_x86_32_view,
+ REGSET_FP, 0,
+ sizeof(struct user_i387_ia32_struct),
+ datap);
+ break;

case PTRACE_SETFPREGS: /* Set the child FPU state. */
- return copy_regset_from_user(
+ ret = copy_regset_from_user(
child, &user_x86_32_view, REGSET_FP,
0, sizeof(struct user_i387_ia32_struct), datap);
+ break;

case PTRACE_GETFPXREGS: /* Get the child extended FPU state. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_XFP, 0,
- sizeof(struct user32_fxsr_struct),
- datap);
+ ret = copy_regset_to_user(child, &user_x86_32_view,
+ REGSET_XFP, 0,
+ sizeof(struct user32_fxsr_struct),
+ datap);
+ break;

case PTRACE_SETFPXREGS: /* Set the child extended FPU state. */
- return copy_regset_from_user(child, &user_x86_32_view,
+ ret = copy_regset_from_user(child, &user_x86_32_view,
REGSET_XFP, 0,
sizeof(struct user32_fxsr_struct),
datap);
+ break;

default:
- return compat_ptrace_request(child, request, addr, data);
+ ret = compat_ptrace_request(child, request, addr, data);
+ break;
}

out:
diff --git a/arch/x86/kernel/smpboot_64.c b/arch/x86/kernel/smpboot_64.c
index 0880f2c..7b768e3 100644
--- a/arch/x86/kernel/smpboot_64.c
+++ b/arch/x86/kernel/smpboot_64.c
@@ -704,7 +704,6 @@ do_rest:
clear_bit(cpu, (unsigned long *)&cpu_initialized); /* was set by cpu_init() */
clear_node_cpumask(cpu); /* was set by numa_add_cpu */
cpu_clear(cpu, cpu_present_map);
- cpu_clear(cpu, cpu_possible_map);
per_cpu(x86_cpu_to_apicid, cpu) = BAD_APICID;
return -EIO;
}
diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index b2b451d..becab51 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -385,6 +385,7 @@ static int i915_resume(struct drm_device *dev)
pci_restore_state(dev->pdev);
if (pci_enable_device(dev->pdev))
return -1;
+ pci_set_master(dev->pdev);

pci_write_config_byte(dev->pdev, LBB, dev_priv->saveLBB);

diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c b/drivers/infiniband/hw/mthca/mthca_memfree.c
index 252db08..0b92d3e 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -109,7 +109,11 @@ static int mthca_alloc_icm_pages(struct scatterlist *mem, int order, gfp_t gfp_m
{
struct page *page;

- page = alloc_pages(gfp_mask, order);
+ /*
+ * Use __GFP_ZERO because buggy firmware assumes ICM pages are
+ * cleared, and subtle failures are seen if they aren't.
+ */
+ page = alloc_pages(gfp_mask | __GFP_ZERO, order);
if (!page)
return -ENOMEM;

diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 0a9b751..756e1bb 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -601,6 +601,8 @@ static int sixpack_open(struct tty_struct *tty)

if (!capable(CAP_NET_ADMIN))
return -EPERM;
+ if (!tty->driver->write)
+ return -EOPNOTSUPP;

dev = alloc_netdev(sizeof(struct sixpack), "sp%d", sp_setup);
if (!dev) {
diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c
index 30c9b3b..f650da3 100644
--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c
@@ -529,6 +529,7 @@ static void ax_encaps(struct net_device *dev, unsigned char *icp, int len)
static int ax_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct mkiss *ax = netdev_priv(dev);
+ int cib = 0;

if (!netif_running(dev)) {
printk(KERN_ERR "mkiss: %s: xmit call when iface is down\n", dev->name);
@@ -544,10 +545,11 @@ static int ax_xmit(struct sk_buff *skb, struct net_device *dev)
/* 20 sec timeout not reached */
return 1;
}
+ if (ax->tty->driver->chars_in_buffer)
+ cib = ax->tty->driver->chars_in_buffer(ax->tty);

printk(KERN_ERR "mkiss: %s: transmit timed out, %s?\n", dev->name,
- (ax->tty->driver->chars_in_buffer(ax->tty) || ax->xleft) ?
- "bad line quality" : "driver error");
+ cib || ax->xleft ? "bad line quality" : "driver error");

ax->xleft = 0;
clear_bit(TTY_DO_WRITE_WAKEUP, &ax->tty->flags);
@@ -736,6 +738,8 @@ static int mkiss_open(struct tty_struct *tty)

if (!capable(CAP_NET_ADMIN))
return -EPERM;
+ if (!tty->driver->write)
+ return -EOPNOTSUPP;

dev = alloc_netdev(sizeof(struct mkiss), "ax%d", ax_setup);
if (!dev) {
diff --git a/drivers/net/irda/irtty-sir.c b/drivers/net/irda/irtty-sir.c
index fc753d7..df755f5 100644
--- a/drivers/net/irda/irtty-sir.c
+++ b/drivers/net/irda/irtty-sir.c
@@ -64,7 +64,9 @@ static int irtty_chars_in_buffer(struct sir_dev *dev)
IRDA_ASSERT(priv != NULL, return -1;);
IRDA_ASSERT(priv->magic == IRTTY_MAGIC, return -1;);

- return priv->tty->driver->chars_in_buffer(priv->tty);
+ if (priv->tty->driver->chars_in_buffer)
+ return priv->tty->driver->chars_in_buffer(priv->tty);
+ return 0;
}

/* Wait (sleep) until underlaying hardware finished transmission
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index f023d5b..098bf44 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -158,6 +158,9 @@ ppp_asynctty_open(struct tty_struct *tty)
struct asyncppp *ap;
int err;

+ if (!tty->driver->write)
+ return -EOPNOTSUPP;
+
err = -ENOMEM;
ap = kzalloc(sizeof(*ap), GFP_KERNEL);
if (!ap)
diff --git a/drivers/net/ppp_synctty.c b/drivers/net/ppp_synctty.c
index 0d80fa5..7372938 100644
--- a/drivers/net/ppp_synctty.c
+++ b/drivers/net/ppp_synctty.c
@@ -207,6 +207,9 @@ ppp_sync_open(struct tty_struct *tty)
struct syncppp *ap;
int err;

+ if (!tty->driver->write)
+ return -EOPNOTSUPP;
+
ap = kzalloc(sizeof(*ap), GFP_KERNEL);
err = -ENOMEM;
if (!ap)
diff --git a/drivers/net/slip.c b/drivers/net/slip.c
index 5a55ede..9d138bf 100644
--- a/drivers/net/slip.c
+++ b/drivers/net/slip.c
@@ -460,10 +460,14 @@ static void sl_tx_timeout(struct net_device *dev)
/* 20 sec timeout not reached */
goto out;
}
- printk(KERN_WARNING "%s: transmit timed out, %s?\n",
- dev->name,
- (sl->tty->driver->chars_in_buffer(sl->tty) || sl->xleft) ?
- "bad line quality" : "driver error");
+ {
+ int cib = 0;
+ if (sl->tty->driver->chars_in_buffer)
+ cib = sl->tty->driver->chars_in_buffer(sl->tty);
+ printk(KERN_WARNING "%s: transmit timed out, %s?\n",
+ dev->name, (cib || sl->xleft) ?
+ "bad line quality" : "driver error");
+ }
sl->xleft = 0;
sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP);
sl_unlock(sl);
@@ -829,6 +833,8 @@ static int slip_open(struct tty_struct *tty)

if (!capable(CAP_NET_ADMIN))
return -EPERM;
+ if (!tty->driver->write)
+ return -EOPNOTSUPP;

/* RTnetlink lock is misused here to serialize concurrent
opens of slip channels. There are better ways, but it is
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 0f8aca8..f5b9a71 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -283,6 +283,10 @@ static void x25_asy_write_wakeup(struct tty_struct *tty)
static void x25_asy_timeout(struct net_device *dev)
{
struct x25_asy *sl = (struct x25_asy*)(dev->priv);
+ int cib = 0;
+
+ if (sl->tty->driver->chars_in_buffer)
+ cib = sl->tty->driver->chars_in_buffer(sl->tty);

spin_lock(&sl->lock);
if (netif_queue_stopped(dev)) {
@@ -290,8 +294,7 @@ static void x25_asy_timeout(struct net_device *dev)
* 14 Oct 1994 Dmitry Gorodchanin.
*/
printk(KERN_WARNING "%s: transmit timed out, %s?\n", dev->name,
- (sl->tty->driver->chars_in_buffer(sl->tty) || sl->xleft) ?
- "bad line quality" : "driver error");
+ (cib || sl->xleft) ? "bad line quality" : "driver error");
sl->xleft = 0;
sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP);
x25_asy_unlock(sl);
@@ -561,6 +564,9 @@ static int x25_asy_open_tty(struct tty_struct *tty)
return -EEXIST;
}

+ if (!tty->driver->write)
+ return -EOPNOTSUPP;
+
/* OK. Find a free X.25 channel to use. */
if ((sl = x25_asy_alloc()) == NULL) {
return -ENFILE;
diff --git a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c
index 88efe1b..5536a94 100644
--- a/drivers/net/wireless/strip.c
+++ b/drivers/net/wireless/strip.c
@@ -802,7 +802,8 @@ static void set_baud(struct tty_struct *tty, unsigned int baudcode)
struct ktermios old_termios = *(tty->termios);
tty->termios->c_cflag &= ~CBAUD; /* Clear the old baud setting */
tty->termios->c_cflag |= baudcode; /* Set the new baud setting */
- tty->driver->set_termios(tty, &old_termios);
+ if (tty->driver->set_termios)
+ tty->driver->set_termios(tty, &old_termios);
}

/*
diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
index 3ca29eb..84a15b6 100644
--- a/include/asm-x86/msr.h
+++ b/include/asm-x86/msr.h
@@ -18,7 +18,7 @@ static inline unsigned long long native_read_tscp(unsigned int *aux)
unsigned long low, high;
asm volatile (".byte 0x0f,0x01,0xf9"
: "=a" (low), "=d" (high), "=c" (*aux));
- return low | ((u64)high >> 32);
+ return low | ((u64)high << 32);
}

/*
diff --git a/kernel/futex.c b/kernel/futex.c
index e43945e..cc6fd0d 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1118,21 +1118,64 @@ static void unqueue_me_pi(struct futex_q *q)
* private futexes.
*/
static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
- struct task_struct *newowner)
+ struct task_struct *newowner,
+ struct rw_semaphore *fshared)
{
u32 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
struct futex_pi_state *pi_state = q->pi_state;
+ struct task_struct *oldowner = pi_state->owner;
u32 uval, curval, newval;
- int ret;
+ int ret, attempt = 0;

/* Owner died? */
+ if (!pi_state->owner)
+ newtid |= FUTEX_OWNER_DIED;
+
+ /*
+ * We are here either because we stole the rtmutex from the
+ * pending owner or we are the pending owner which failed to
+ * get the rtmutex. We have to replace the pending owner TID
+ * in the user space variable. This must be atomic as we have
+ * to preserve the owner died bit here.
+ *
+ * Note: We write the user space value _before_ changing the
+ * pi_state because we can fault here. Imagine swapped out
+ * pages or a fork, which was running right before we acquired
+ * mmap_sem, that marked all the anonymous memory readonly for
+ * cow.
+ *
+ * Modifying pi_state _before_ the user space value would
+ * leave the pi_state in an inconsistent state when we fault
+ * here, because we need to drop the hash bucket lock to
+ * handle the fault. This might be observed in the PID check
+ * in lookup_pi_state.
+ */
+retry:
+ if (get_futex_value_locked(&uval, uaddr))
+ goto handle_fault;
+
+ while (1) {
+ newval = (uval & FUTEX_OWNER_DIED) | newtid;
+
+ curval = cmpxchg_futex_value_locked(uaddr, uval, newval);
+
+ if (curval == -EFAULT)
+ goto handle_fault;
+ if (curval == uval)
+ break;
+ uval = curval;
+ }
+
+ /*
+ * We fixed up user space. Now we need to fix the pi_state
+ * itself.
+ */
if (pi_state->owner != NULL) {
spin_lock_irq(&pi_state->owner->pi_lock);
WARN_ON(list_empty(&pi_state->list));
list_del_init(&pi_state->list);
spin_unlock_irq(&pi_state->owner->pi_lock);
- } else
- newtid |= FUTEX_OWNER_DIED;
+ }

pi_state->owner = newowner;

@@ -1140,26 +1183,35 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
WARN_ON(!list_empty(&pi_state->list));
list_add(&pi_state->list, &newowner->pi_state_list);
spin_unlock_irq(&newowner->pi_lock);
+ return 0;

/*
- * We own it, so we have to replace the pending owner
- * TID. This must be atomic as we have preserve the
- * owner died bit here.
+ * To handle the page fault we need to drop the hash bucket
+ * lock here. That gives the other task (either the pending
+ * owner itself or the task which stole the rtmutex) the
+ * chance to try the fixup of the pi_state. So once we are
+ * back from handling the fault we need to check the pi_state
+ * after reacquiring the hash bucket lock and before trying to
+ * do another fixup. When the fixup has been done already we
+ * simply return.
*/
- ret = get_futex_value_locked(&uval, uaddr);
+handle_fault:
+ spin_unlock(q->lock_ptr);

- while (!ret) {
- newval = (uval & FUTEX_OWNER_DIED) | newtid;
+ ret = futex_handle_fault((unsigned long)uaddr, fshared, attempt++);

- curval = cmpxchg_futex_value_locked(uaddr, uval, newval);
+ spin_lock(q->lock_ptr);

- if (curval == -EFAULT)
- ret = -EFAULT;
- if (curval == uval)
- break;
- uval = curval;
- }
- return ret;
+ /*
+ * Check if someone else fixed it for us:
+ */
+ if (pi_state->owner != oldowner)
+ return 0;
+
+ if (ret)
+ return ret;
+
+ goto retry;
}

/*
@@ -1524,7 +1576,7 @@ static int futex_lock_pi(u32 __user *uaddr, struct rw_semaphore *fshared,
* that case:
*/
if (q.pi_state->owner != curr)
- ret = fixup_pi_state_owner(uaddr, &q, curr);
+ ret = fixup_pi_state_owner(uaddr, &q, curr, fshared);
} else {
/*
* Catch the rare case, where the lock was released
@@ -1556,7 +1608,8 @@ static int futex_lock_pi(u32 __user *uaddr, struct rw_semaphore *fshared,
int res;

owner = rt_mutex_owner(&q.pi_state->pi_mutex);
- res = fixup_pi_state_owner(uaddr, &q, owner);
+ res = fixup_pi_state_owner(uaddr, &q, owner,
+ fshared);

/* propagate -EFAULT, if the fixup failed */
if (res)
diff --git a/kernel/sched.c b/kernel/sched.c
index 1e4596c..c54077c 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5728,6 +5728,7 @@ static void migrate_dead_tasks(unsigned int dead_cpu)
next = pick_next_task(rq, rq->curr);
if (!next)
break;
+ next->sched_class->put_prev_task(rq, next);
migrate_dead(dead_cpu, next);

}

2008-07-03 17:08:58

by Bart Van Assche

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On Thu, Jul 3, 2008 at 5:58 AM, Greg KH <[email protected]> wrote:
> We (the -stable team) are announcing the release of the 2.6.25.10
> kernel.
>
> It contains a number of assorted bugfixes all over the tree. And once
> again, any users of the 2.6.25 kernel series are STRONGLY encouraged to
> upgrade to this release.

Hello Greg,

Thanks for all the work you and the stable team are doing on the
stable series. To me the above message is a little bit cryptic however
-- which bugs have been fixed, and what was their impact ? I know it
takes time to write down such information, sometimes called release
notes. But I think including this information with the announcements
of the stable releases would be a great service to the people reading
these announcements.

Bart.

2008-07-03 17:30:59

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On Thu, Jul 03, 2008 at 07:08:48PM +0200, Bart Van Assche wrote:
> On Thu, Jul 3, 2008 at 5:58 AM, Greg KH <[email protected]> wrote:
> > We (the -stable team) are announcing the release of the 2.6.25.10
> > kernel.
> >
> > It contains a number of assorted bugfixes all over the tree. And once
> > again, any users of the 2.6.25 kernel series are STRONGLY encouraged to
> > upgrade to this release.
>
> Hello Greg,
>
> Thanks for all the work you and the stable team are doing on the
> stable series. To me the above message is a little bit cryptic however
> -- which bugs have been fixed, and what was their impact ? I know it
> takes time to write down such information, sometimes called release
> notes. But I think including this information with the announcements
> of the stable releases would be a great service to the people reading
> these announcements.

The release notes are there in the shortlog in the email announcement
and full Changelog on the kernel.org site for exactly what specifically
was fixed:
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.10

If you have any specific questions about any of the individual changes,
please let us, and the developers who made those fixes know.

thanks,

greg k-h

2008-07-03 18:59:16

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On Thu, Jul 03, 2008 at 10:29:14AM -0700, Greg KH wrote:
> On Thu, Jul 03, 2008 at 07:08:48PM +0200, Bart Van Assche wrote:
> > On Thu, Jul 3, 2008 at 5:58 AM, Greg KH <[email protected]> wrote:
> > > We (the -stable team) are announcing the release of the 2.6.25.10
> > > kernel.
> > >
> > > It contains a number of assorted bugfixes all over the tree. And once
> > > again, any users of the 2.6.25 kernel series are STRONGLY encouraged to
> > > upgrade to this release.
> >
> > Hello Greg,
> >
> > Thanks for all the work you and the stable team are doing on the
> > stable series. To me the above message is a little bit cryptic however
> > -- which bugs have been fixed, and what was their impact ? I know it
> > takes time to write down such information, sometimes called release
> > notes. But I think including this information with the announcements
> > of the stable releases would be a great service to the people reading
> > these announcements.
>
> The release notes are there in the shortlog in the email announcement
> and full Changelog on the kernel.org site for exactly what specifically
> was fixed:
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.10
>
> If you have any specific questions about any of the individual changes,
> please let us, and the developers who made those fixes know.

Adding 2 more addresses to this thread, as they were said to have
questions about this kernel release.

Again, if the above information is somehow insufficient as to what
exactly is fixed in the -stable releases, and anyone has questions about
how these release announcements are created, please let me know.

thanks,

greg k-h

2008-07-03 23:42:24

by Chris Rankin

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

> Again, if the above information is somehow insufficient as to what
> exactly is fixed in the -stable releases, and anyone has questions about
> how these release announcements are created, please let me know.

Well, for example:

I have only machines with 32 bit CPUS, none of them is hot-pluggable and none has an i915 graphics chip. All my local users are "trusted", nor am I running any multi-threaded Java applications on SMP systems. (I also have no idea what ICM pages are, but they sound jolly impressive!)

And what is "native_read_tscp" all about?

So why am I being "STRONGLY encouraged to upgrade to this release"? (Your emphasis.) Is it because otherwise you're going to sneak up and burn my house down?

Cheers,
Chris

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

2008-07-03 23:57:42

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On Thu, Jul 03, 2008 at 04:42:01PM -0700, Chris Rankin wrote:
> > Again, if the above information is somehow insufficient as to what
> > exactly is fixed in the -stable releases, and anyone has questions about
> > how these release announcements are created, please let me know.
>
> Well, for example:
>
> I have only machines with 32 bit CPUS, none of them is hot-pluggable

All cpus these days can be "virtually" hotplugged :)

> and none has an i915 graphics chip. All my local users are "trusted",
> nor am I running any multi-threaded Java applications on SMP systems.
> (I also have no idea what ICM pages are, but they sound jolly
> impressive!)
>
> And what is "native_read_tscp" all about?

Ask the developer who did that.

> So why am I being "STRONGLY encouraged to upgrade to this release"?
> (Your emphasis.) Is it because otherwise you're going to sneak up and
> burn my house down?

Fixing an ABI breakage that you could hit might be a good thing for you
to have, as well as the other general fixes.

If you can read the changelog and see that you feel you can skip this
release, fine. Otherwise, please upgrade.

thanks,

greg k-h

2008-07-04 17:32:41

by Nix

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On 4 Jul 2008, Chris Rankin stated:
> I have only machines with 32 bit CPUS, none of them is hot-pluggable
> and none has an i915 graphics chip. All my local users are "trusted",
> nor am I running any multi-threaded Java applications on SMP
> systems. (I also have no idea what ICM pages are, but they sound jolly
> impressive!)

A good clue here is to look at the subdirectories that were touched.
The ICM stuff says in the commit log

IB/mthca: Clear ICM pages before handing to FW

and touches only files under drivers/infiniband/hw/mthca.

So if you don't use the InfiniBand driver, you're almost certainly safe
(and from what I understand of InfiniBand, if you're not running a huge
corporate SAN or something you're highly unlikely to be using it).

> And what is "native_read_tscp" all about?

>From the name I would have assumed something about networking with some
strangely-named protocol, but from the file being touched,
include/asm-x86/msr.h, it's something to do with x86 model-specific
registers. One function in that header calls it: `rdtscp()'. A grep -R
for `rdtscp' under arch/x86 indicates that there is a word in
/proc/cpuinfo devoted to indicating whether your CPU has this
feature. If it doesn't, the bug doesn't affect you.

>From the other hit, rdtscp()'s one call site, it seems to be some way to
get the current CPU fast on SMP x86-64 boxes. So perhaps you should
upgrade if you have one of those.

Generally a bit of grepping and matching on pathnames like this is
enough to comprehensively rule most changes in or out as things that
affect you, and of course if there are changes to mm code or something
like that it's generally a good idea to upgrade anyway, because you
can't very well avoid using said code.

> (Your emphasis.) Is it because otherwise you're going to sneak up and
> burn my house down?

Greg would never do a thing like that without forewarning.

2008-07-04 22:47:13

by Stefan Roas

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On Thu Jul 03, 2008 at 16:42:01, Chris Rankin wrote:
> > Again, if the above information is somehow insufficient as to what
> > exactly is fixed in the -stable releases, and anyone has questions about
> > how these release announcements are created, please let me know.
>
> Well, for example:
>
> I have only machines with 32 bit CPUS, none of them is hot-pluggable and none has an i915 graphics chip. All my local users are "trusted", nor am I running any multi-threaded Java applications on SMP systems. (I also have no idea what ICM pages are, but they sound jolly impressive!)
>
> And what is "native_read_tscp" all about?

To some degree I can understand that you are not sure of whether you are
affected or not. On the other hand you should probably be, when running
your own kernels on a productive system. After all there seems to be a
general agreement that distribution vendors take care of the stabilization
and bug fixing of their particular kernels. As far as I am
concerned, I'm grateful that there are these stable releases at all and I very
much consider it additional work for everyone in the release team. To that
end it should be your task to check whether the update affects you or not.

After all the releases are publicly announced on probably the busiest
mailing list on earth. That offers anyone the chance to add additional
information to the releases (there has been a discussion recently about
security implications that weren't mentioned in the announcement. Just
replying to the announcement will add the needed information, and as the
discussion showed, people actually do add information).

To sum all the above up: IMHO the announcements are great, the work of the
stable team is great and I wouldn't really want to push more work on the
people that voluntarily spend their time on this branch by explaining every
detail of every patch.

Just my 2 cents.

Best regards,
Stefan

2008-07-05 07:54:34

by Bart Van Assche

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On Thu, Jul 3, 2008 at 7:29 PM, Greg KH <[email protected]> wrote:
> The release notes are there in the shortlog in the email announcement
> and full Changelog on the kernel.org site for exactly what specifically
> was fixed:
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.10
>
> If you have any specific questions about any of the individual changes,
> please let us, and the developers who made those fixes know.

Sometimes I have to backport bugfixes to older kernels. In that case
it's important to know in which kernel version the bug was introduced.
This info is included for some of the bugfix patches in the changelog,
but not for all.

Bart.

2008-07-06 20:23:47

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

[spender's asked to be off the CC]

On 3 Jul 2008 at 11:57, Greg KH wrote:

> On Thu, Jul 03, 2008 at 10:29:14AM -0700, Greg KH wrote:
> Adding 2 more addresses to this thread, as they were said to have
> questions about this kernel release.

not only this one, but every commit for the past few years that fixed
bugs with security impact. for reference:

http://lwn.net/Articles/285438/
http://lwn.net/Articles/286263/
http://lwn.net/Articles/287339/
http://lwn.net/Articles/288473/

> Again, if the above information is somehow insufficient as to what
> exactly is fixed in the -stable releases, and anyone has questions about
> how these release announcements are created, please let me know.

what is the disclosure policy used for commits fixing bugs with security
impact (both vanilla and -stable, especially if there's a difference)?

what do you include/omit?

how does it relate to what is declared in Documentation/SecurityBugs?

2008-07-09 02:30:33

[permalink] [raw]

Subject: Re: Linux 2.6.25.10

On Sat, Jul 05, 2008 at 09:54:22AM +0200, Bart Van Assche wrote:
> On Thu, Jul 3, 2008 at 7:29 PM, Greg KH <[email protected]> wrote:
> > The release notes are there in the shortlog in the email announcement
> > and full Changelog on the kernel.org site for exactly what specifically
> > was fixed:
> > http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.10
> >
> > If you have any specific questions about any of the individual changes,
> > please let us, and the developers who made those fixes know.
>
> Sometimes I have to backport bugfixes to older kernels. In that case
> it's important to know in which kernel version the bug was introduced.
> This info is included for some of the bugfix patches in the changelog,
> but not for all.

That's because sometimes no one digs through the code to find this out.
I would recommend using 'git blame' to determine this if it is something
that you need to have.

But for the most part, -stable doesn't really care about older kernel
versions, we have to draw the line somewhere, sorry.

thanks,

greg k-h

2008-07-14 12:08:35

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

Sorry for the delay, was on vacation...

On Thu, Jul 03, 2008 at 09:31:45PM +0200, [email protected] wrote:
> [spender's asked to be off the CC]

Chicken :)

> On 3 Jul 2008 at 11:57, Greg KH wrote:
>
> > On Thu, Jul 03, 2008 at 10:29:14AM -0700, Greg KH wrote:
> > Adding 2 more addresses to this thread, as they were said to have
> > questions about this kernel release.
>
> not only this one, but every commit for the past few years that fixed
> bugs with security impact. for reference:
>
> http://lwn.net/Articles/285438/
> http://lwn.net/Articles/286263/
> http://lwn.net/Articles/287339/
> http://lwn.net/Articles/288473/

As I'm somewhere there is no web access, mind summarizing these if they
are relevant?

> > Again, if the above information is somehow insufficient as to what
> > exactly is fixed in the -stable releases, and anyone has questions about
> > how these release announcements are created, please let me know.
>
> what is the disclosure policy used for commits fixing bugs with security
> impact (both vanilla and -stable, especially if there's a difference)?

What is outlined in Documentation/SecurityBugs.

> what do you include/omit?

Personally, I omit posting full "and here is explicitly how to exploit
this problem" notices as that is foolish.

But also remember that -stable releases are just a compilation of
patches that developers have sent to the stable developers, we use the
original commit messages as published in the main kernel tree, except
where the patch differs, which is rare. So it's not like these releases
are any different than the main kernel releases on descriptions of
patches and issues surrounding them.

> how does it relate to what is declared in Documentation/SecurityBugs?

That deals with how security bugs that are sent to [email protected]
are handled, which is totally different from -stable releases, right?

thanks,

greg k-h

2008-07-15 02:15:56

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On 14 Jul 2008 at 5:04, Greg KH wrote:

> Sorry for the delay, was on vacation...

a collective one, i take it, as noone else bothered to respond either ;).

anyway, you must have been at an interesting place i suppose as you
even managed to slip a mail through a wormhole that somehow arrived
here on 8th ;).

> > On 3 Jul 2008 at 11:57, Greg KH wrote:
> >
> > > On Thu, Jul 03, 2008 at 10:29:14AM -0700, Greg KH wrote:
> > > Adding 2 more addresses to this thread, as they were said to have
> > > questions about this kernel release.
> >
> > not only this one, but every commit for the past few years that fixed
> > bugs with security impact. for reference:
> >
> > http://lwn.net/Articles/285438/
> > http://lwn.net/Articles/286263/
> > http://lwn.net/Articles/287339/
> > http://lwn.net/Articles/288473/
>
> As I'm somewhere there is no web access, mind summarizing these if they
> are relevant?

they're very relevant and rather long, you should take your time and read
them whenever you're back on the normal net. or you can do like RMS and
surf the web through email ;).

> > what is the disclosure policy used for commits fixing bugs with security
> > impact (both vanilla and -stable, especially if there's a difference)?
>
> What is outlined in Documentation/SecurityBugs.

so it's full disclosure for both vanilla and -stable, there's no difference?
just because at the end of your mail you say:

> > how does it relate to what is declared in Documentation/SecurityBugs?
>
> That deals with how security bugs that are sent to [email protected]
> are handled, which is totally different from -stable releases, right?

now are they totally different or not? ;)

in any case, you say the full disclosure policy applies. what does that mean
for you? does it mean omitting security impact information you know about
(not 'here is a working exploit' but 'this is a buffer overflow' or 'this
is an exploitable bug')? because such omissions have repeatedly occured for
the past many years (you'll find several examples pointed out at those LWN
URLs) and they're hard to reconcile with your declared disclosure policy.

> > what do you include/omit?
>
> Personally, I omit posting full "and here is explicitly how to exploit
> this problem" notices as that is foolish.

do you also omit any of the usual security related words, such as, say,
'buffer overflow', 'security' when describing a bug? say, look at today's
2.6.25.11 and its single fix that doesn't say anything about 'security',
heck, not even its announcement does. do you think it's what constitutes
full disclosure? ;)

> But also remember that -stable releases are just a compilation of
> patches that developers have sent to the stable developers, we use the
> original commit messages as published in the main kernel tree, except
> where the patch differs, which is rare.

you at least add CVE IDs on occasion, mainline commits are even worse in
that regard.

> So it's not like these releases are any different than the main kernel
> releases on descriptions of patches and issues surrounding them.

yes, the real and more important problem is with the mainline development
itself, you're mostly suffering collateral damage, so to speak. but since
you're also part of that development process, you can't hide behind that.

so guys (meaning not only Greg but Andrew, Linus, et al.), when will you
publicly explain why you're covering up security impact of bugs? and even
more importantly, when will you change your policy or bring your process
in line with what you declared?

cheers,
PaX Team

2008-07-15 02:28:17

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On Tue, 15 Jul 2008, [email protected] wrote:
>
> so guys (meaning not only Greg but Andrew, Linus, et al.), when will you
> publicly explain why you're covering up security impact of bugs? and even
> more importantly, when will you change your policy or bring your process
> in line with what you declared?

We went through this discussion a couple of weeks ago, and I had
absolutely zero interest in explaining it again.

I personally don't like embargoes. I don't think they work. That means
that I want to fix things asap. But that also means that there is never a
time when you can "let people know", except when it's not an issue any
more, at which point there is no _point_ in letting people know any more.

So I personally consider security bugs to be just "normal bugs". I don't
cover them up, but I also don't have any reason what-so-ever to think it's
a good idea to track them and announce them as something special.

So there is no "policy". Nor is it likely to change.

Linus

2008-07-15 15:52:23

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On 14 Jul 2008 at 19:27, Linus Torvalds wrote:

> We went through this discussion a couple of weeks ago, and I had
> absolutely zero interest in explaining it again.

sorry, i was unaware of that discussion. any quick URLs?

> I personally don't like embargoes. I don't think they work. That means
> that I want to fix things asap. But that also means that there is never a
> time when you can "let people know", except when it's not an issue any
> more, at which point there is no _point_ in letting people know any more.

i don't follow you here. you're making 4 statements essentially:

A. 'i want to fix bugs asap'
B. 'i can let people know only when it's not an issue any more'
C. 'there is no point in letting people know when it's not an issue any more'
D. A implies B and/or C

let's see them one by one.

A: fine and even commendable.

B: that's part of the disclosure policy, so be it, although it raises
the question of *when* a bug is no longer an issue. when the fix is
in your git tree? in all/some affected vendor trees? in all affected
linux trees in existence? or does it depend on when x % of the
affected machines is running it? what's your criterion?

C: do you realize what you just said? effectively, 'there's no point
in disclosure'. that's diametrically opposite to what you previously
argued for (rather vehemently, as vendor-sec readers surely remember).
to remind yourself of your own words:

http://lkml.org/lkml/2005/1/12/205
http://lkml.org/lkml/2005/1/12/363
http://lkml.org/lkml/2005/1/13/305

in any case, who decided this? you? did you ask anyone actually
affected (vendors, users, whatnot)? in case you missed about two
decades of security problems and their (mis)handling by proprietary
vendors, this was the *exact* reason why they got shamed repeatedly
in public (does bugtraq mean anything to you?) and why we have
public security mailing lists and a whole industry nowadays.

D: this one is a non-sequitur, the timeline (or even willingness) of
fixing bugs does not imply their disclosure policy. you can surely
fix a bug independently of telling about it. so the question stays:
why do you think not disclosing security impact info at all is good,
and is what users want?

> So I personally consider security bugs to be just "normal bugs".

security bugs aren't just 'normal bugs', the more serious of them
allow to completely break the security model of the kernel. the world
at large has long ago decided that such bugs *are* special and there's
an entire industry dedicated to finding/fixing/exploiting/etc them,
not to mention academic research of the same. you can't ignore reality
like that, i'm afraid.

> I don't cover them up,

by 'cover up' i meant that even when you know better, you quite
consciously do *not* report the security impact of said bugs - that's
the part called 'cover up' because it's about the opposite of full
disclosure that you also advocated in the past. now you made it clear
that you don't actually (want to) practice it (i'm not arguing with
that choice btw, just pointing out the inconsistency between your
declared words and actual actions).

> but I also don't have any reason what-so-ever to think it's
> a good idea to track them and announce them as something special.

see my comment about reality above. heck, even linux vendors do track
and announce them, it's part of the support they provide to paying
customers (and even non-paying users).

> So there is no "policy". Nor is it likely to change.

obviously there *is* a policy, it's just not what you guys declared
earlier in Documentation/SecurityBugs. would you care to update it
or, more properly, remove it altogether as it currently says:

Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
^^^^^^^^^^^^
disclosed as quickly as possible. Please report security bugs to the
^^^^^^^^^
Linux kernel security team.

and what you said above about disclosure and treatment of security bugs
is the opposite of it. there is no reason for the kernel security list
to exist, basically (you already have lkml and bugzilla to discuss bugs,
which, according to you, security bugs are as well, there's no need for
special treatment).

cheers,
PaX Team

PS: i do wonder however, how do you and others expect people to track the
quality of the development process if you apparently refuse to properly
account for security bugs? at this moment the Jeff Jones of the world are
smacking their head realizing the extent their statistics were flawed and
will no doubt have a field day with your statements.

2008-07-15 16:08:31

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On Tue, 15 Jul 2008, [email protected] wrote:
>
> by 'cover up' i meant that even when you know better, you quite
> consciously do *not* report the security impact of said bugs

Yes. Because the only place I consider appropriate is the kernel
changelogs, and since those get published with the sources, there is no
way I can convince myself that it's a good idea to say "Hey script
kiddies, try this" unless it's already very public indeed.

> see my comment about reality above. heck, even linux vendors do track
> and announce them, it's part of the support they provide to paying
> customers (and even non-paying users).

Umm. And they mostly do a crap job at it, only focusing on a small
percentage (the ones that were considered to be "big issues"), and because
they do the reporting they also feel they have to have embargoes in place.

That's why I don't do reporting - it almost inevitably leads to embargoes.

So as far as I'm concerned, "disclosing" is the fixing of the bug. It's
the "look at the source" approach.

Linus

2008-07-15 16:13:54

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On Tue, 15 Jul 2008, Linus Torvalds wrote:
>
> So as far as I'm concerned, "disclosing" is the fixing of the bug. It's
> the "look at the source" approach.

Btw, and you may not like this, since you are so focused on security, one
reason I refuse to bother with the whole security circus is that I think
it glorifies - and thus encourages - the wrong behavior.

It makes "heroes" out of security people, as if the people who don't just
fix normal bugs aren't as important.

In fact, all the boring normal bugs are _way_ more important, just because
there's a lot more of them. I don't think some spectacular security hole
should be glorified or cared about as being any more "special" than a
random spectacular crash due to bad locking.

Security people are often the black-and-white kind of people that I can't
stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

To me, security is important. But it's no less important than everything
*else* that is also important!

Linus

2008-07-15 18:34:29

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On Tue, Jul 15, 2008 at 05:31:09PM +0200, [email protected] wrote:
> obviously there *is* a policy, it's just not what you guys declared
> earlier in Documentation/SecurityBugs. would you care to update it
> or, more properly, remove it altogether as it currently says:

Hi, so I'm guessing you're new to the Linux kernel. What you are
missing is while *Linus* is unwilling to play the disclosure game,
there are kernel developers (many of whom work for distributions, and
who *do* want some extra time to prepare a package for release to
their customers) who do. So what Linus has expressed is his personal
opinion, and he is simply is not on any of the various mailing lists
that receive limited-disclosure information, such as the general
[email protected] mailing list, or the [email protected] list
mentioned in Documentation/SecurityBugs.

Both vendor-sec and [email protected] are not formal organizations,
so they can not sign NDAs, but they will honor non disclosure
requests, and the subscription list for both lists is carefully
controlled.

People like Linus who have a strong, principled stand for Full
Disclosure simply choose not to request to be placed on those mailing
lists. And if Linus finds out about a security bug, he will fix it
and check it into the public git repository right away. But he's very
honest in telling you that is what he will do --- so you can choose
whether or not to include him in any disclosures that you might choose
to make.

The arguments about whether or not Full Disclosure is a good idea or
not, and whether or not the "black hat" and "grey hat" and "white hat"
security research firms are unalloyed forces for good, or whether they
have downsides (and some might say very serious downsides) have been
arguments that I have personally witnessed for over two decades
(Speaking as someone who helped to dissect the Robert T. Morris
Internet Worm in 1988, led the Kerberos development team at MIT for
many years, and chaired the IP SEC Working Group for the IETF, I have
more than my fair share of experience). It is clear that we're not
going settle this debate now, and certainly not on the Linux Kernel
Mailing List.

Suffice it to say, though, that there are people whose views on these
matters span the entire gamut, and I know many reasonable people who
hold very different positions along the entire continuum --- and this
is true both in the Internet community at large, and in the Linux
Kernel development community specifically.

Best regards,

- Ted

2008-07-15 19:06:34

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On 15 Jul 2008 at 9:07, Linus Torvalds wrote:

> On Tue, 15 Jul 2008, [email protected] wrote:
> >
> > by 'cover up' i meant that even when you know better, you quite
> > consciously do *not* report the security impact of said bugs
>
> Yes. Because the only place I consider appropriate is the kernel
> changelogs, and since those get published with the sources, there is no
> way I can convince myself that it's a good idea to say "Hey script
> kiddies, try this" unless it's already very public indeed.

if you worry about script kiddies (btw, for someone not bothering with
the whole security circus you surely do use their terms as bogeymen
to rationalize your stand) triggering or even exploiting local kernel
bugs then you imply that they're already local users on that box and
that in turn means they have already been having fun all that time.
just remember how Andrew put it:

But there are so many ways to cripple a Linux box once you have
local access. (http://lkml.org/lkml/2005/1/12/379)

in other words, try a better argument, possibly without bogeymen.

next, what about, say, sysadmins , bigger and smaller distro maintainers,
etc trying to figure out whether they need to backport a given fix or
not? do you think you're helping them too?

on a sidenote, what do you know about script kiddies? how do you think
they operate? do you think they're watching a real-time rss from kernel.org
to catch the latest and greatest security fixes? do you think they can
write PoC or actual exploit code based on commits?

last but not least, if i submitted a security fix with the commit message
actually saying that it fixes a security problem, would you remove that
information before committing? based on the above that sounds as a 'yes',
but i'd like to have that explicitly on the record.

> > see my comment about reality above. heck, even linux vendors do track
> > and announce them, it's part of the support they provide to paying
> > customers (and even non-paying users).
>
> Umm. And they mostly do a crap job at it, only focusing on a small
> percentage (the ones that were considered to be "big issues"), and because
> they do the reporting they also feel they have to have embargoes in place.

people consider and backport patches that come to their attention,
which in turn happens by their scanning the changes, following various
threads of discussions (both public and private, depending on what they
have access to), etc. if you withhold security impact information then
you're skewing their 'big issue' detector as well, further reducing
*their* users' security.

> That's why I don't do reporting - it almost inevitably leads to embargoes.

i don't see you embargo normal bug fixes, why would you embargo security
bug fixes? they're just normal bugs, aren't they?

> So as far as I'm concerned, "disclosing" is the fixing of the bug. It's
> the "look at the source" approach.

when you fix a bug, the commit describes what it fixes without omitting
anything relevant. when you fix a security bug, its commit doesn't say
what it fixes (not even that it's a security fix, never mind actual
impact information), that is, you omit relevant information (based on
some ill-conceived argument that i deconstructed at the beginning). in
other words, you're *not* treating security bugs as normal bugs. for
all intents and purposes, you cover them up. i *wish* you did treat
them as normal bugs however.

cheers,
Pax Team

2008-07-15 19:16:39

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On Tue, 15 Jul 2008, [email protected] wrote:
>
> in other words, try a better argument, possibly without bogeymen.

You know what - when nobody does embargoes, I'll consider your argument to
have a point.

In the meantime, I'm not in the least interested in your idiotic
arguments. Especially as you can't even read what I wrote:

> i don't see you embargo normal bug fixes, why would you embargo security
> bug fixes? they're just normal bugs, aren't they?

Exactly. I don't embargo them. I refuse to have anything to even _do_ with
organizations like vendor-sec that I think is a corrupt cluster-fuck of
people who just want to cover their own ass.

They're just normal bugs.

But that also doesn't mean that I see any reason to make it obvious what
to do to trigger them, and cause problems at universities and such. So I
don't do "here's how to exploit it" commit logs, for example.

(If you haven't been at a univerisity, you don't know how many smart young
people want to "try it to see". And if you have been there, and don't
think it's a problem when they do and wouldn't be happier if they didn't,
you probably don't know what the word "empathy" means).

Linus

2008-07-15 20:31:19

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

Hello!

On 15 Jul 2008 at 14:33, Theodore Tso wrote:

> On Tue, Jul 15, 2008 at 05:31:09PM +0200, [email protected] wrote:
> > obviously there *is* a policy, it's just not what you guys declared
> > earlier in Documentation/SecurityBugs. would you care to update it
> > or, more properly, remove it altogether as it currently says:
>
> Hi, so I'm guessing you're new to the Linux kernel.

not that new, just not a subscriber, but i've been following it on and
off for many years now. just a few comments below:

> What you are
> missing is while *Linus* is unwilling to play the disclosure game,
> there are kernel developers (many of whom work for distributions, and
> who *do* want some extra time to prepare a package for release to
> their customers) who do. So what Linus has expressed is his personal
> opinion, and he is simply is not on any of the various mailing lists
> that receive limited-disclosure information, such as the general
> [email protected] mailing list, or the [email protected] list
> mentioned in Documentation/SecurityBugs.

he's on [email protected] i think.

> Both vendor-sec and [email protected] are not formal organizations,
> so they can not sign NDAs, but they will honor non disclosure
> requests, and the subscription list for both lists is carefully
> controlled.
>
> People like Linus who have a strong, principled stand for Full
> Disclosure simply choose not to request to be placed on those mailing
> lists.

Linus has just explained that he does *not* have any stand on full
disclosure in fact, he prefers no disclosure.

> And if Linus finds out about a security bug, he will fix it
> and check it into the public git repository right away.

yes, he does that. what he doesn't do is mention the fact that he's
just fixed a security bug.

> The arguments about whether or not Full Disclosure is a good idea or
> not, and whether or not the "black hat" and "grey hat" and "white hat"
> security research firms are unalloyed forces for good, or whether they
> have downsides (and some might say very serious downsides) have been
> arguments that I have personally witnessed for over two decades
> (Speaking as someone who helped to dissect the Robert T. Morris
> Internet Worm in 1988, led the Kerberos development team at MIT for
> many years, and chaired the IP SEC Working Group for the IETF, I have
> more than my fair share of experience). It is clear that we're not
> going settle this debate now, and certainly not on the Linux Kernel
> Mailing List.

Ted, the discussion is *not* about what the best disclosure policy
would be for the kernel. the problem i raised was that there's one
declared policy in Documentation/SecurityBugs (full disclosure) yet
actual actions are completely different and now Linus even admitted
it. the problem arising from such inconsistency is that people relying
on the declared disclosure policy will make bad decisions and potentially
endanger their users. there're two ways out of this sitution: either
follow full disclosure in practice or let the world at large know
that you (well, Linus) don't want to. in either case people will adjust
their security bug handling processes and everyone will be better off.

cheers,
PaX Team

2008-07-15 22:42:33

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On Tue, Jul 15, 2008 at 10:28:44PM +0200, [email protected] wrote:
> Ted, the discussion is *not* about what the best disclosure policy
> would be for the kernel. the problem i raised was that there's one
> declared policy in Documentation/SecurityBugs (full disclosure) yet
> actual actions are completely different and now Linus even admitted
> it.

Huh?

How does what is described there differ from what Linus said, or the
-stable team has been doing so far?

What specifically are you asking for that is different?

The -stable commits are exactly the same as they are in mainline
(Linus's tree). Are you upset by the fact that I am not saying, "Hey,
look, here's a bugfix that might be security related and here's how to
reproduce it!" in big flashing letters?

thanks,

greg k-h

2008-07-15 22:47:45

by David Miller

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

From: Greg KH <[email protected]>
Date: Tue, 15 Jul 2008 15:39:10 -0700

> The -stable commits are exactly the same as they are in mainline
> (Linus's tree). Are you upset by the fact that I am not saying, "Hey,
> look, here's a bugfix that might be security related and here's how to
> reproduce it!" in big flashing letters?

Don't sweat it Greg.

This complaint about "full disclosure" is coming from someone who isn't
even willing to communicate with the world using his real name.

The ultimate irony, in my book :-)

2008-07-15 23:10:57

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On 15 Jul 2008 at 15:39, Greg KH wrote:

> On Tue, Jul 15, 2008 at 10:28:44PM +0200, [email protected] wrote:
> > Ted, the discussion is *not* about what the best disclosure policy
> > would be for the kernel. the problem i raised was that there's one
> > declared policy in Documentation/SecurityBugs (full disclosure) yet
> > actual actions are completely different and now Linus even admitted
> > it.
>
> Huh?
>
> How does what is described there differ from what Linus said,

read his mails and my responses, it's all in there. basically, he said
so himself that he knowingly withholds information. no matter how you spin
that, that's not full disclosure. note that i'm not advocating for using
that disclosure policy for kernel bugs, it's what *you* guys chose and
i'm just asking why you're not practicing it. you're also free to change
to something else, just don't forget to tell the world about it.

> or the -stable team has been doing so far?
>
> What specifically are you asking for that is different?

that doc says full disclosure, it doesn't say 'but withholding this
or that'. if you don't know what 'full disclosure' means then you're
welcome to ask on proper security mailing lists such as bugtraq or
dailydave or, why not, the list named after this very policy.

> The -stable commits are exactly the same as they are in mainline
> (Linus's tree). Are you upset by the fact that I am not saying, "Hey,
> look, here's a bugfix that might be security related

yes, you should include that at least. i didn't say that btw, your fellow
-stable maintainer did:

Had I realized there was a security issue, I would highlight it in the
announce message. In fact, that's our standard procedure for -stable.
(http://lkml.org/lkml/2008/6/10/328)

the 2.4 maintainer agreed with him:

I don't like obfuscation at all WRT security issues, it does far more
harm than good because it reduces the probability to get them picked
and fixed by users, maintainers, distro packagers, etc...
(http://lkml.org/lkml/2008/6/10/452)

i think you're outgunned here Greg. and no, i'm not upset (after all, i'm
the one catching you cover up security bugs, right? you're not hurting me),
but more and more of your users are.

> and here's how to reproduce it!" in big flashing letters?

no, that doesn't really belong there but it's a nice addition for certain
people.

Greg, instead of pretending to be surprised and upset or whatever, go
read the whole thread first.

cheers,
PaX Team

2008-07-15 23:11:33

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

David Miller wrote:
>
> Don't sweat it Greg.
>
> This complaint about "full disclosure" is coming from someone who isn't
> even willing to communicate with the world using his real name.
>

Does a symbolic reference change the truth behind it? No, it doesn't.
Nor does "David Miller" change the utter idiocy of your commentary.

--t

2008-07-15 23:21:19

by David Miller

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

From: Tiago Assumpcao <[email protected]>
Date: Tue, 15 Jul 2008 20:08:50 -0300

> David Miller wrote:
> >
> > Don't sweat it Greg.
> >
> > This complaint about "full disclosure" is coming from someone who isn't
> > even willing to communicate with the world using his real name.
> >
>
> Does a symbolic reference change the truth behind it? No, it doesn't.

That's not the point.

The point is that he's a hypocrit because he's not willing to give the
world what he expects the world to give back to him.

That's, basically, unreasonable.

2008-07-15 23:24:36

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On 15 Jul 2008 at 15:47, David Miller wrote:

> From: Greg KH <[email protected]>
> Date: Tue, 15 Jul 2008 15:39:10 -0700
>
> > The -stable commits are exactly the same as they are in mainline
> > (Linus's tree). Are you upset by the fact that I am not saying, "Hey,
> > look, here's a bugfix that might be security related and here's how to
> > reproduce it!" in big flashing letters?
>
> Don't sweat it Greg.
>
> This complaint about "full disclosure" is coming from someone who isn't
> even willing to communicate with the world using his real name.

you too are welcome to read the thread. the issue is not full disclosure
per se, but your not practicing what you promised. that can be changed
either way. as for my real name, it's John Smith. will you take me now
seriously? i thought so.

> The ultimate irony, in my book :-)

your using of this anonymous person's code is probably an even bigger irony ;)

http://lkml.org/lkml/2004/7/1/30

2008-07-15 23:28:25

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On 15 Jul 2008 at 16:21, David Miller wrote:

> From: Tiago Assumpcao <[email protected]>
> Date: Tue, 15 Jul 2008 20:08:50 -0300
>
> > David Miller wrote:
> > >
> > > Don't sweat it Greg.
> > >
> > > This complaint about "full disclosure" is coming from someone who isn't
> > > even willing to communicate with the world using his real name.
> > >
> >
> > Does a symbolic reference change the truth behind it? No, it doesn't.
>
> That's not the point.
>
> The point is that he's a hypocrit because he's not willing to give the
> world what he expects the world to give back to him.

where did i expect the world to give out his/her/its real name? also, i'm
not talking in my own name really, i don't personally care whether you cheat
in your security bug statistics or not, i know better than that and so do
many people in the security industry and elsewhere. the actual damage is
done to innocent users who may not get timely fixes because you covered them
up despite having promised not to do so. any other discussion is irrelevant,
please take me off your replies if you can't help it.

> That's, basically, unreasonable.
>

2008-07-15 23:29:55

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

David Miller wrote:
>
> That's not the point.
>
> The point is that he's a hypocrit because he's not willing to give the
> world what he expects the world to give back to him.
>

The point that is not is that of his identity. Be it true or false the
inadequacy of his anonymity.

BTW, it seems like one previous e-mail regarding the relevant point of
the discussion has never arrived. I'll give it a try on resending.

--t

2008-07-15 23:35:26

by David Miller

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

From: [email protected]
Date: Wed, 16 Jul 2008 01:22:48 +0200

> On 15 Jul 2008 at 15:47, David Miller wrote:
>
> > The ultimate irony, in my book :-)
>
> your using of this anonymous person's code is probably an even bigger irony ;)
>
> http://lkml.org/lkml/2004/7/1/30

It's not about whether your code is correct or not, in that particular
case it was, and I therefore merged it.

And at the time, if you recall, I did give you a piece of my mind
about having to attribute your work using an email that didn't refer
to a real person's name.

2008-07-15 23:36:44

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

Linus Torvalds wrote:
>
> That means that I want to fix things asap. But that also means that there is never a
> time when you can "let people know", except when it's not an issue any
> more, at which point there is no _point_ in letting people know any more.
>

The only plausible solution people have found to this problem is
"letting the world know", so everyone involved in the different stages
of IT maintenance can do their part and properly spread the solution
throughout the assets.

Unless you have a better idea, the full-disclosure policy must remain or
we're going back into 1992AD -- except the threats are thereof 2008.

> So I personally consider security bugs to be just "normal bugs". I don't
> cover them up, but I also don't have any reason what-so-ever to think it's
> a good idea to track them and announce them as something special.
>
> So there is no "policy". Nor is it likely to change.
>
> Linus

Either someone classify and inform it as it is, a *security problem*, or
the issue is likely to pass unnoticed by the majority or to not receive
the necessary attention by the involved parts.

Right. You don't want your developers to be responsible for classifying
bugs towards security. Fine. Even though my intuition and personal
experience tell that the question must be approached by those deeply
involved in the development life-cycle, which, on their side, are
responsible for finding, classifying, advising and fixing the security
issues. This seems appropriate. Further, this appears to be what the big
software houses nowadays do: from early design and development stages,
have people to [security] review their applications before deployment,
up to giving high attention and adequate support to any reported
security problem, afterwards release. Maybe this is all silly and the
world is swimming in the wrong direction.

Opinions apart, what really matters: we have an ultimate declaration
about Linus' tree -- we may forget the pre-official (?) announcement
[Documentation/SecurityBugs] and know that someone else must,
eventually, classify and inform the world about security bugs existent
in their software.
From our consumer side, every time an issue of this nature is found,
let's pray for some intermediate, gray, angel to send us an "warning"
message.

Not more I can do but to make sure that all my peers are informed of
such a grave reality.

Sincerely,
Tiago

2008-07-17 21:08:57

by Aidan Thornton

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On 7/15/08, Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 15 Jul 2008, Linus Torvalds wrote:
>>
>> So as far as I'm concerned, "disclosing" is the fixing of the bug. It's
>> the "look at the source" approach.
>
> Btw, and you may not like this, since you are so focused on security, one
> reason I refuse to bother with the whole security circus is that I think
> it glorifies - and thus encourages - the wrong behavior.
>
> It makes "heroes" out of security people, as if the people who don't just
> fix normal bugs aren't as important.
>
> In fact, all the boring normal bugs are _way_ more important, just because
> there's a lot more of them. I don't think some spectacular security hole
> should be glorified or cared about as being any more "special" than a
> random spectacular crash due to bad locking.

I hate to state the obvious, but there's a reason security holes are treated differently - because they're *not* *obvious*. If a system is crashing spectacularly, generally someone notices and tries to fix it. On the other hand, security holes are usually invisible in normal operation until a hacker uses one to walk off with tens of thousands of people's credit card details. That's why there's so much effort put into tracking them.

> Security people are often the black-and-white kind of people that I can't
> stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in
> that they make such a big deal about concentrating on security to the
> point where they pretty much admit that nothing else matters to them.
>
> To me, security is important. But it's no less important than everything
> *else* that is also important!

True, there are other serious types of bugs (silent data corruption is one particularly nasty one). However, for *any* serious bug, it's important to be clear on what the likely impact is and what's affected. This goes particularly for the ones that might otherwise not be obvious to the person affected until it's too late, such as security and silent data corruption bugs, but really it applies to all serious bugs. I'm not convinced these descriptions are clear enough.

Aidan

2008-07-19 00:53:52

by David Schwartz

[permalink] [raw]

Subject: RE: [stable] Linux 2.6.25.10

Greg KH wrote:

> Personally, I omit posting full "and here is explicitly how to exploit
> this problem" notices as that is foolish.

That means only people with the time, energy, and expertise to create an
exploit will have an exploit. This includes probably 90% of the people who
would use the exploit maliciously and 100% of the people who pose a real
thread to the community. It does, however, ensure that the majority of
ordinary users won't be able to test their systems to see if they're
vulnerable or if the vulnerability is fixed. So at least it will have some
effect.

DS

2008-07-19 01:00:33

by David Lang

[permalink] [raw]

Subject: RE: [stable] Linux 2.6.25.10

On Fri, 18 Jul 2008, David Schwartz wrote:

> Greg KH wrote:
>
>> Personally, I omit posting full "and here is explicitly how to exploit
>> this problem" notices as that is foolish.
>
> That means only people with the time, energy, and expertise to create an
> exploit will have an exploit. This includes probably 90% of the people who
> would use the exploit maliciously

haven't you ever heard of script-kiddies? they are by far the majority of
attacks on systems but do not have the expertise to create exploits. it
takes someone else writing the exploit for them and packaging it to make
them a threat.

in the meantime there's a chance for the fix to get propogated out to a
released version and for people to upgrade their systems. providing
exploit code along with the bugfix means that the script kiddies have the
exploit immediatly, but the fix isn't in any released version (not even a
-rc or daily -git snapshot)

> and 100% of the people who pose a real
> thread to the community.

this depends on how you define threat.

> It does, however, ensure that the majority of
> ordinary users won't be able to test their systems to see if they're
> vulnerable or if the vulnerability is fixed. So at least it will have some
> effect.

how many people run exploits against their production systems to 'see if
they are fixed', very few, and those only on strict schedules with lots of
adnvance notice and other safeguards.

David Lang

2008-07-19 01:52:22

by David Schwartz

[permalink] [raw]

Subject: RE: [stable] Linux 2.6.25.10

David Lang wrote:

> > That means only people with the time, energy, and expertise to create an
> > exploit will have an exploit. This includes probably 90% of the
> > people who
> > would use the exploit maliciously

> haven't you ever heard of script-kiddies? they are by far the majority of
> attacks on systems but do not have the expertise to create exploits. it
> takes someone else writing the exploit for them and packaging it to make
> them a threat.

Nobody is saying you should package the exploit. If they need someone else
to package it, they'll still need that. So the question is not if this will
deter script kiddies but whether it will deter the people who package
exploits for them. And from experience, I can tell you that answer is no.
Manys attacks that were believed too difficult for the script kiddies to do
were packaged by people who had the expertise and then used by script
kiddies.

> in the meantime there's a chance for the fix to get propogated out to a
> released version and for people to upgrade their systems. providing
> exploit code along with the bugfix means that the script kiddies have the
> exploit immediatly, but the fix isn't in any released version (not even a
> -rc or daily -git snapshot)

The alternative is that the fix gets released but not implemented.

> > It does, however, ensure that the majority of
> > ordinary users won't be able to test their systems to see if they're
> > vulnerable or if the vulnerability is fixed. So at least it
> > will have some
> > effect.

> how many people run exploits against their production systems to 'see if
> they are fixed', very few, and those only on strict schedules
> with lots of
> adnvance notice and other safeguards.

I can tell you how many run exploits against their production systems when
they don't know the exploits exist -- zero. It takes, at a minimum, the
knowledge that an exploit is possible. In the cases being discussed, even
this was withheld.

Fixes will not be widely deployed on a timely basis unless, at an absolute
minimum, it is known that there is an exploitable bug that has been fixed.

DS

2008-07-19 05:41:21

by Willy Tarreau

[permalink] [raw]

Subject: Re: [stable] Linux 2.6.25.10

On Fri, Jul 18, 2008 at 06:51:42PM -0700, David Schwartz wrote:
> Nobody is saying you should package the exploit. If they need someone else
> to package it, they'll still need that. So the question is not if this will
> deter script kiddies but whether it will deter the people who package
> exploits for them.

Obvious exploits are generally written by random "joe hackers" to get a
name. However, most kernel exploits are really complex, and written by
the person who discover them because they're the only ones with enough
research on the problem to be able to do so (remember vmsplice ?).

> > how many people run exploits against their production systems to 'see if
> > they are fixed', very few, and those only on strict schedules
> > with lots of adnvance notice and other safeguards.
>
> I can tell you how many run exploits against their production systems when
> they don't know the exploits exist -- zero. It takes, at a minimum, the
> knowledge that an exploit is possible. In the cases being discussed, even
> this was withheld.

People generally don't run kernel exploits on their production systems,
simply because either the exploit works as expected and the system remains
safe, or it fails, and it generally means system crashes, freezes, or will
need a reboot very soon. The same is generally true for proof-of-concepts,
but those tend to touch less things and have less side effects in case of
failure.

> Fixes will not be widely deployed on a timely basis unless, at an absolute
> minimum, it is known that there is an exploitable bug that has been fixed.

To be clear, *I* am for telling people that they might be facing a problem
(and for not releasing exploits). This is probably because I work on
slow-moving code that people upgrade once a year or so. I know that when
you're wondering whether you'll upgrade your system after that long, you
need to what it will really fix, otherwise you don't upgrade it. That's
why I include indicators when I have them, whether they are about security,
or stability.

In fact, for people always running latest version and upgrading fast,
having all the details or not does not matter much. But as soon as the
code starts to stabilize, they don't upgrade that often, and they need
justifications for an upgrade. Right now, people running 2.6.25 would
have no reason not to upgrade, considering the variety of fixes each
version still carries. People running 2.4 or 2.6.16 *need* details.
And that's even more true for people maintaining their own kernels
or backporting fixes.

However, there is a point nobody has evocated here about backports.
For a long time I've been annoyed by not finding enough information
in some commit logs. But I finally figured that it was as simple as
asking privately either the reporter or the patch author to get that
sensible information sorted out. So the only remaining hard part of
the problem is to identify possible candidates in the huge patch flow
that 2.6 mainline it. That's true too for pure bugs, except that, as
some people have already indicated, they're often better documented.

Willy

2008-07-20 00:36:17