Linux 2.6.25.10
Greg KH
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.
I'll also be replying to this message with a copy of the patch between
2.6.25.9 and 2.6.25.10
The updated 2.6.25.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=summary
thanks,
greg k-h
-------------
Makefile | 2
arch/x86/kernel/i387.c | 4 -
arch/x86/kernel/ptrace.c | 45 +++++++------
arch/x86/kernel/smpboot_64.c | 1
drivers/char/drm/i915_drv.c | 1
drivers/infiniband/hw/mthca/mthca_memfree.c | 6 +
drivers/net/hamradio/6pack.c | 2
drivers/net/hamradio/mkiss.c | 8 +-
drivers/net/irda/irtty-sir.c | 4 -
drivers/net/ppp_async.c | 3
drivers/net/ppp_synctty.c | 3
drivers/net/slip.c | 14 +++-
drivers/net/wan/x25_asy.c | 10 ++-
drivers/net/wireless/strip.c | 3
include/asm-x86/msr.h | 2
kernel/futex.c | 93 +++++++++++++++++++++-------
kernel/sched.c | 1
17 files changed, 147 insertions(+), 55 deletions(-)
Alan Cox (1):
TTY: fix for tty operations bugs
Dmitry Adamushko (1):
sched: fix cpu hotplug
Eli Cohen (1):
IB/mthca: Clear ICM pages before handing to FW
Greg Kroah-Hartman (1):
Linux 2.6.25.10
Jie Luo (1):
DRM: enable bus mastering on i915 at resume time
Max Asbock (1):
x86: shift bits the right way in native_read_tscp
Roland McGrath (1):
x86_64 ptrace: fix sys32_ptrace task_struct leak
TAKADA Yoshihito (1):
ptrace GET/SET FPXREGS broken
Thomas Gleixner (1):
futexes: fix fault handling in futex_lock_pi
Yanmin Zhang (1):
x86: fix cpu hotplug crash
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
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);
Bart Van Assche
> 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.
Greg KH
> On Thu, Jul 3, 2008 at 5:58 AM, Greg KH <gre...@suse.de> 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
Greg KH
> 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 <gre...@suse.de> 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.
Chris Rankin
> 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
Greg KH
> > 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
Nix
> 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.
Stefan Roas
> > 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
Bart Van Assche
> 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.
page...@freemail.hu
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?
Greg KH
> On Thu, Jul 3, 2008 at 7:29 PM, Greg KH <gre...@suse.de> 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
Greg KH
On Thu, Jul 03, 2008 at 09:31:45PM +0200, page...@freemail.hu 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 secu...@kernel.org
are handled, which is totally different from -stable releases, right?
thanks,
greg k-h
page...@freemail.hu
> 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 secu...@kernel.org
> 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
Linus Torvalds
On Tue, 15 Jul 2008, page...@freemail.hu 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
page...@freemail.hu
> 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.
Linus Torvalds
On Tue, 15 Jul 2008, page...@freemail.hu 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
Linus Torvalds
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!
Theodore Tso
> 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
vendo...@lst.de mailing list, or the secu...@kernel.org list
mentioned in Documentation/SecurityBugs.
Both vendor-sec and secu...@kernel.org 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
page...@freemail.hu
> On Tue, 15 Jul 2008, page...@freemail.hu 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
Linus Torvalds
On Tue, 15 Jul 2008, page...@freemail.hu 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
Linus Torvalds
On Tue, 15 Jul 2008, page...@freemail.hu wrote:
>
> in any case, i don't see why you can't put keywords into the commit
> that say the bug being fixed is 'security related' or 'potentially
> exploitable', etc. people can then decide how to prioritize them.
Because I see no point. Quite often, we don't even realize some random bug
could have been a security issue.
It's not worth my energy, in other words.
page...@freemail.hu
>
>
> On Tue, 15 Jul 2008, page...@freemail.hu wrote:
> >
> > in any case, i don't see why you can't put keywords into the commit
> > that say the bug being fixed is 'security related' or 'potentially
> > exploitable', etc. people can then decide how to prioritize them.
>
> Because I see no point. Quite often, we don't even realize some random bug
> could have been a security issue.
>
> It's not worth my energy, in other words.
i understand and i think noone expects that. in fact, i know how much
expertise and time it takes to determine that. but what happens when
you do figure out the security relevance of a bug during bug submission
(say, it goes directly to secu...@kernel.org with a PoC to trigger it)
or while working out the fix or you see that it falls into an well-known
exploitable bug class? you have the information yet you still make no
mention of it. *that* at least can be fixed, if you chose so.
cheers,
PaX Team
page...@freemail.hu
On 15 Jul 2008 at 14:33, Theodore Tso wrote:
> On Tue, Jul 15, 2008 at 05:31:09PM +0200, page...@freemail.hu 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
> vendo...@lst.de mailing list, or the secu...@kernel.org list
> mentioned in Documentation/SecurityBugs.
he's on secu...@kernel.org i think.
> Both vendor-sec and secu...@kernel.org 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
Linus Torvalds
On Tue, 15 Jul 2008, page...@freemail.hu wrote:
>
> i understand and i think noone expects that. in fact, i know how much
> expertise and time it takes to determine that. but what happens when
> you do figure out the security relevance of a bug during bug submission
The issue is that I think it's then _misleading_ to mark that kind of
commit specially, when I actually believe that it's in the minority.
If people think that they are safer for only applying (or upgrading to)
certain patches that are marked as being security-specific, they are
missing all the ones that weren't marked as such. Making them even
_believe_ that the magic security marking is meaningful is simply a lie.
It's not going to be.
So why would I add some marking that I most emphatically do not believe in
myself, and think is just mostly security theater?
I generally do not remove peoples changelog entries, although I _will_
do even that if I think it's just too much of an actual exploit
description (of course - the patch itself can make the exploit fairly
clear). So you'll find CVE entries etc in the logs if you look.
But I do hope that anybody who looks for them is _aware_ that it's just a
small minority of possible problems.
Don't get me wrong - I'm not saying that security bugs are _common_, but
especially some local DoS thing for a specific driver or filesystem or
whatever can be a big security problem for _somebody_.
Linus
Linus Torvalds
On Tue, 15 Jul 2008, page...@freemail.hu wrote:
>
> and how is that different from today's situation where they aren't told
> at all?
Umm. They are. They are told to upgrade to the stable kernel, which
should have everything we know about.
I'm just saying that why mark things, when the marking have no meaning?
People who believe in them are just _wrong_.
page...@freemail.hu
> On Tue, 15 Jul 2008, page...@freemail.hu wrote:
> >
> > i understand and i think noone expects that. in fact, i know how much
> > expertise and time it takes to determine that. but what happens when
> > you do figure out the security relevance of a bug during bug submission
>
> The issue is that I think it's then _misleading_ to mark that kind of
> commit specially, when I actually believe that it's in the minority.
>
> If people think that they are safer for only applying (or upgrading to)
> certain patches that are marked as being security-specific, they are
> missing all the ones that weren't marked as such.
and how is that different from today's situation where they aren't told
at all? in other words, they already learned to live with that risk. if
you tell them about a security bug, they will build that knowledge into
their risk assessment process (which is what security is all about in
the end). anything you omit will skew their decision making process (in
particular, expose them to exploits if they fail to apply a fix because
they make a bad judgement call).
in other words, you should not be worrying about people not learning about
all security fixes, they already know it's not possible to provide such
information. however sharing your knowledge that you do have will *help*
them because 1. they can know for sure it's something important to apply
(no need to use their limited human resources to make that judgement),
2. they can spend more of their resources on analyzing the *other* unmarked
fixes. overall this can only improve everyone's security.
what you're afraid of is that people will take your 'we mark security
fixes we learn about' as 'we mark ALL security fixes that are such'. well,
make that very clear in a public document (Documentation/SecurityBugs is
a good place) and that's it, people will know you're doing a best effort
disclosure and not more.
cheers,
PaX Team
page...@freemail.hu
>
>
> On Tue, 15 Jul 2008, page...@freemail.hu wrote:
> >
> > and how is that different from today's situation where they aren't told
> > at all?
>
> Umm. They are. They are told to upgrade to the stable kernel, which
> should have everything we know about.
you should check out the last few -stable releases then and see how
the announcement doesn't ever mention the word 'security' while fixing
security bugs (see my analysis at http://lwn.net/Articles/288473/).
unless one digs into the actual commits and determines what's going on,
it's easy to make a bad judgement call even for -stable. you know, there
are places that can't just reboot into a new kernel every week for no
reason (Microsoft has patch Tuesday once a month only).
also what about people running older kernels, outside of -stable focus?
do you determine how far back a fix should be applied? i don't think so,
but people maintaining older series will do that, provided they get a hint.
in other words, it's all the more reason to have the commit say it's
fixing a security issue.
> I'm just saying that why mark things, when the marking have no meaning?
> People who believe in them are just _wrong_.
what is wrong in particular? when you know that you're about to commit a
patch that fixes a security bug, why is it wrong to say so in the commit?
in what way will people reading that commit be misled? they will see it's
fixing a security bug and they can prioritize it for whatever processes they
have for backports, analysis, etc. if they don't see such marks, they will
have to do a whole lot more work (effectively duplicating your own and even
each other's efforts) to figure out the same. why not save them time and
tell them directly what you already know?
cheers,
PaX Team
David Miller
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 :-)
Greg KH
> 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
Tiago Assumpcao
>
> 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
page...@freemail.hu
> On Tue, Jul 15, 2008 at 10:28:44PM +0200, page...@freemail.hu 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
page...@freemail.hu
> From: Greg KH <gr...@kroah.com>
> 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
Linus Torvalds
On Wed, 16 Jul 2008, page...@freemail.hu wrote:
>
> you should check out the last few -stable releases then and see how
> the announcement doesn't ever mention the word 'security' while fixing
> security bugs
Umm. What part of "they are just normal bugs" did you have issues with?
I expressly told you that security bugs should not be marked as such,
because bugs are bugs.
> in other words, it's all the more reason to have the commit say it's
> fixing a security issue.
No.
> > I'm just saying that why mark things, when the marking have no meaning?
> > People who believe in them are just _wrong_.
>
> what is wrong in particular?
You have two cases:
- people think the marking is somehow trustworthy.
People are WRONG, and are misled by the partial markings, thinking that
unmarked bugfixes are "less important". They aren't.
- People don't think it matters
People are right, and the marking is pointless.
In either case it's just stupid to mark them. I don't want to do it,
because I don't want to perpetuate the myth of "security fixes" as a
separate thing from "plain regular bug fixes".
They're all fixes. They're all important. As are new features, for that
matter.
> when you know that you're about to commit a patch that fixes a security
> bug, why is it wrong to say so in the commit?
It's pointless and wrong because it makes people think that other bugs
aren't potential security fixes.
What was unclear about that?
Linus
page...@freemail.hu
> From: Tiago Assumpcao <ti...@assumpcao.org>
> 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.
David Miller
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.
David Miller
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.
Tiago Assumpcao
>
> 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
Tiago Assumpcao
>
> 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
Tiago Assumpcao
For all the above: no. And this is the point of divergence.
For you, as a person who "writes software", every bug is equivalent. You
need to resolve problems, not classify them.
However, as I previously explained [http://lkml.org/lkml/2008/7/15/654],
security issues are identified and communicated through what can be a
long and complicated (due to DNAs, etc.) process. If it culminates at
implementation, without proper information forwarding from the
development team, it will never reach the "upper layers" -- vendors,
distributors, end users, et al.
Therefore, yes, it is of major importance that you people, too, buy the
problem and support the process as a whole. Otherwise... well,
otherwise, we're back to where we started, 20 years ago. Good luck Linux
users.
--t
page...@freemail.hu
> On Wed, 16 Jul 2008, page...@freemail.hu wrote:
> >
> > you should check out the last few -stable releases then and see how
> > the announcement doesn't ever mention the word 'security' while fixing
> > security bugs
>
> Umm. What part of "they are just normal bugs" did you have issues with?
oh, we're back to that. i told you that already, here it is again (just
quoting myself back):
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.
we went through this and you yourself said that security bugs are *not*
treated as normal bugs because you do omit relevant information from such
commits whereas you do *not* omit relevant information from normal commits.
for security bugs the fact that they fix a security issue is relevant
information.
> I expressly told you that security bugs should not be marked as such,
> because bugs are bugs.
repeating the same thing doesn't make the self-contradiction above go
away. bugs are properly described in the commits, security bugs aren't
(you said so yourself), therefore they can't be of the same category.
what you're still trying to justify is why you are covering up security
bugs, plain and simple.
> > > I'm just saying that why mark things, when the marking have no meaning?
> > > People who believe in them are just _wrong_.
> >
> > what is wrong in particular?
>
> You have two cases:
>
> - people think the marking is somehow trustworthy.
>
> People are WRONG, and are misled by the partial markings, thinking that
> unmarked bugfixes are "less important". They aren't.
why would people think that unmarked bugfixes are less important? who are
you to make that judgement for them anyway? the importance of bugs is
*orthogonal* to their classification (security, etc). it's up to the people
and their decision making processes to deal with that. all you should do
is help them by not withholding relevant information. in case it wasn't
clear, i'm not talking about just about any person like my grandma, but
people whose work involves following kernel development, who can use all
the extra information to make judgement calls about what to prioritize.
they're certainly not dumb and would not think that only commits marked
as such are security related.
> - People don't think it matters
>
> People are right, and the marking is pointless.
you have yet to prove why it's pointless. the above attempt failed to do so.
> In either case it's just stupid to mark them. I don't want to do it,
> because I don't want to perpetuate the myth of "security fixes" as a
> separate thing from "plain regular bug fixes".
it's not a myth, it's called reality. a bugfix that gets my pc speaker beep
again is very different from a fix that stops the tcp/ip stack sending out
random kernel memory to the net (just made them up, before anyone starts
looking). you're desperately trying to ignore the importance of security
bugs but you're failing. the world has decided that security bugs *are*
important and deserve special attention. and it's not as if you had to do
any extra work, you already have the information, you should just not
*withhold* it.
> They're all fixes. They're all important. As are new features, for that
> matter.
'importance' is not a big grey goo that applies equally to all fixes. you
want to make it appear so, but that doesn't make it so.
> > when you know that you're about to commit a patch that fixes a security
> > bug, why is it wrong to say so in the commit?
>
> It's pointless and wrong because it makes people think that other bugs
> aren't potential security fixes.
why does it make people think that? did you ask them? what if you told them
as i suggested (and you conveniently skipped) what to expect? do you think
people dealing with kernel maintenance at companies, distros, etc are that
dumb?
cheers,
PaX Team
Linus Torvalds
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> However, as I previously explained [http://lkml.org/lkml/2008/7/15/654],
> security issues are identified and communicated through what can be a long and
> complicated (due to DNAs, etc.) process. If it culminates at implementation,
> without proper information forwarding from the development team, it will never
> reach the "upper layers" -- vendors, distributors, end users, et al.
Umm. That shouldn't be our worry. If others had a long and involved (and
broken) process, they should be the ones that track the fixes too. We
weren't involved, we didn't see that, we simply _cannot_ care.
> Therefore, yes, it is of major importance that you people, too, buy the
> problem and support the process as a whole. Otherwise... well, otherwise,
> we're back to where we started, 20 years ago. Good luck Linux users.
Umm. What was wrong with 20 years ago exactly?
Are you talking about all the wonderful work that the DNS people did for
that new bug, and how they are heroes for synchronizing a fix and keeping
it all under wraps?
And isn't that the same bug that djb talked about and fixed in djbdns from
the start? Which he did about ten YEARS ago?
Excuse me for not exactly being a huge fan of "security lists" and best
practices. They seem to be _entirely_ be based on PR and how much you can
talk up a specific bug. No thank you,
Linus
Linus Torvalds
On Wed, 16 Jul 2008, page...@freemail.hu wrote:
>
> we went through this and you yourself said that security bugs are *not*
> treated as normal bugs because you do omit relevant information from such
> commits
Actually, we disagree on one fundamental thing. We disagree on
that single word: "relevant".
I do not think it's helpful _or_ relevant to explicitly point out how to
tigger a bug. It's very helpful and relevant when we're trying to chase
the bug down, but once it is fixed, it becomes irrelevant.
You think that explicitly pointing something out as a security issue is
really important, so you think it's always "relevant". And I take mostly
the opposite view. I think pointing it out is actually likely to be
counter-productive.
For example, the way I prefer to work is to have people send me and the
kernel list a patch for a fix, and then in the very next email send (in
private) an example exploit of the problem to the security mailing list
(and that one goes to the private security list just because we don't want
all the people at universities rushing in to test it). THAT is how things
should work.
Should I document the exploit in the commit message? Hell no. It's
private for a reason, even if it's real information. It was real
information for the developers to explain why a patch is needed, but once
explained, it shouldn't be spread around unnecessarily.
Linus
Tiago Assumpcao
>
> On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>> However, as I previously explained [http://lkml.org/lkml/2008/7/15/654],
>> security issues are identified and communicated through what can be a long and
>> complicated (due to DNAs, etc.) process. If it culminates at implementation,
>> without proper information forwarding from the development team, it will never
>> reach the "upper layers" -- vendors, distributors, end users, et al.
>
> Umm. That shouldn't be our worry.
Yeah, at this point, it is clear to the world. No needs for repeated
wording ;)
> If others had a long and involved (and broken) process, they should be the ones that track the fixes too. We
> weren't involved, we didn't see that, we simply _cannot_ care.
You weren't involved? Hold on, aren't you the developers, thence, those
who commit mistakes, a.k.a the bug inducing point?
>
>> Therefore, yes, it is of major importance that you people, too, buy the
>> problem and support the process as a whole. Otherwise... well, otherwise,
>> we're back to where we started, 20 years ago. Good luck Linux users.
>
> Umm. What was wrong with 20 years ago exactly?
What was wrong for the computer theoretic people about 100 years ago?
Lack of development? Not sure. Perhaps the same that existed for
information security 20 years ago. Just perhaps.
I apologize for assuming you hold such information, anyway.
>
> Are you talking about all the wonderful work that the DNS people did for
> that new bug, and how they are heroes for synchronizing a fix and keeping
> it all under wraps?
>
> And isn't that the same bug that djb talked about and fixed in djbdns from
> the start? Which he did about ten YEARS ago?
Are you trying to justify your irresponsibly indulgent act towards the
operating system that my mother is likely to use with one alone
exception? Because it rains umbrellas are a waste of time?
>
> Excuse me for not exactly being a huge fan of "security lists" and best
> practices. They seem to be _entirely_ be based on PR and how much you can
> talk up a specific bug. No thank you,
>
> Linus
Personally, I, too, have a major disgust for most crap seen in the so
called info-sec world. I hand you my agreement on this one.
Except, it changes in nothing your responsibilities.
Take good care,
--t
page...@freemail.hu
> On Wed, 16 Jul 2008, page...@freemail.hu wrote:
> >
> > we went through this and you yourself said that security bugs are *not*
> > treated as normal bugs because you do omit relevant information from such
> > commits
>
> Actually, we disagree on one fundamental thing. We disagree on
> that single word: "relevant".
we'll see :)
> I do not think it's helpful _or_ relevant to explicitly point out how to
> tigger a bug.
nor did i say that (actually, what i said is that it didn't belong into
the commit message, see below for more).
> It's very helpful and relevant when we're trying to chase
> the bug down, but once it is fixed, it becomes irrelevant.
you're wrong on that however. it is important for many people to able
to perform the same verification that you do. just imagine the backports
to versions that you don't do yourselves. but organizing the dissemination
of such code is not what i've been talking about all this time.
> You think that explicitly pointing something out as a security issue is
> really important, so you think it's always "relevant".
don't mistake my presence in this thread as me, an invidual arguing for his
own benefit. i already know when you fix security bugs, even when you don't
sometimes. so when i say something is relevant, it's not merely my opinion,
it's what most people dealing with security issues (both inside and outside
the linux universe) think. with that said, let's move on:
> And I take mostly the opposite view. I think pointing it out is
> actually likely to be counter-productive.
you keep saying that, but you don't explain *why*.
> For example, the way I prefer to work is to have people send me and the
> kernel list a patch for a fix, and then in the very next email send (in
> private) an example exploit of the problem to the security mailing list
> (and that one goes to the private security list just because we don't want
> all the people at universities rushing in to test it). THAT is how things
> should work.
fine with me, i wasn't talking about that at all though ;).
> Should I document the exploit in the commit message? Hell no.
fully understood and agreed. never even asked for that.
> It's private for a reason, even if it's real information. It was real
> information for the developers to explain why a patch is needed, but
> once explained, it shouldn't be spread around unnecessarily.
agreed (with the same additonal thoughts as above on the trigger code).
ok, so let's make it simpler for everyone to understand what is at issue
here. it seems that we agree that there're several levels of information
that exist when it comes to security bugs and we don't understand each
other as to what should go into a commit and what should stay out. let
me propose a categorization and you tell me what you think you would be
willing to put into a commit (feel free to break them up further if that's
what it takes).
1. simple words/phrases that one can grep for (mentally or automated)
examples: 'security', 'exploitable', 'DoS', 'buffer overflow', etc
2. simple sentence describing roughly what kind of security bug it is
example: fix exploitable null function pointer dereference in foo.
3. sample code able to trigger the bug and cause an oops/crash but not
privilege elevation, no effort made to be 'weapons grade' (does not
support several archs, kernel versions, etc)
4. proof-of-concept exploit that triggers the bug, and demonstrates its
effect (say privilege elevation) with manual tweaking (say, you look
up an address in System.map and the like, but nothing automated)
5. full blown weaponized exploit
i believe 3-5 are definitely not commit message material. 1 or 2 are.
5 should never be published or disseminated, 3 and 4 may be distributed
to interested parties.
cheers,
PaX Team
Linus Torvalds
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> You weren't involved? Hold on, aren't you the developers, thence, those who
> commit mistakes, a.k.a the bug inducing point?
Umm. And if the whole discussion it was hidden from us on some private
vendor list, why should we then help track their hidden state?
That's what you claimed we should do, wasn't it?
> Personally, I, too, have a major disgust for most crap seen in the so called
> info-sec world. I hand you my agreement on this one.
> Except, it changes in nothing your responsibilities.
My responsibility is to do a good job. And not pander to the people who
want to turn security into a media circus.
Which is exactly what I'm doing. No media circus.
Linus
Theodore Tso
> For all the above: no. And this is the point of divergence.
> For you, as a person who "writes software", every bug is equivalent. You
> need to resolve problems, not classify them.
>
> However, as I previously explained [http://lkml.org/lkml/2008/7/15/654],
> security issues are identified and communicated through what can be a
> long and complicated (due to DNAs, etc.) process. If it culminates at
> implementation, without proper information forwarding from the
> development team, it will never reach the "upper layers" -- vendors,
> distributors, end users, et al.
Look if you want this, pay $$$ to a distribution and get their
supported distribution. It costs time and effort to classify bugs as
security related (or not), and the people who care about this the most
also want to freeze a kernel version to simplify their application
testing, *but* get new drivers and bus support code back-ported so
they can use the latest hardware (while still keeping their
applications and 3rd party proprietary kernel modules from Nvidia and
Vertias stable and working) *and* they want the latest security fixes
(and only security fixes, since other fixes might destablize their
application). People who want this can get it, today. Just pick up
the phone and give a call to your favoriate enterprise Linux
distribution. It will cost you money, but hey, the people who want
this sort of thing typically are willing to pay for the service.
I'll note that trying to classify bugs as being "security-related" at
the kernel.org level often doesn't help the distro's, since many of
these bugs won't even apply to whatever version of the kernel the
distro's snapshotted 9-18 months ago. So if the distro snapshotted
2.6.18 in Fall 2006, and their next snapshot will be sometime two
years later in the fall of this year, they will have no use for some
potential local denial of service attack that was introduced by
accident in 2.6.24-rc3, and fixed in 2.6.25-rc1. It just doesn't
matter to them.
So basically, if there are enough kernel.org users who care, they can
pay someone to classify and issue CVE numbers for each and every
potential "security bug" that might appear and then disappear. Or
they can volunteer and do it themselves. Of course, this will provide
aid and comfort to Microsoft-shills masquerading as analysts who
misuse CVE numbers to generate reports "proving" that Microsoft is
more secure (because they don't do their development in the open, so
issues that appear and disappear in development snapshots don't get
CVE numbers assigned), but hopefully most users are sophsitcated
enough not to get taken in by that kind of bogus study. :-)
The one thing which is really pointless to do is to ask kernel
developers to do all of this classification work to get CVE numbers,
etc., for free. In free software, people do what they (or their
company) deem to be valuable for them. Flaming and complaining that
the kernel git logs aren't providing free marketing for PaX/grsecurity
isn't going to do much good.
- Ted
Linus Torvalds
On Wed, 16 Jul 2008, page...@freemail.hu wrote:
>
> > And I take mostly the opposite view. I think pointing it out is
> > actually likely to be counter-productive.
>
> you keep saying that, but you don't explain *why*.
>
> > For example, the way I prefer to work is to have people send me and the
> > kernel list a patch for a fix, and then in the very next email send (in
> > private) an example exploit of the problem to the security mailing list
> > (and that one goes to the private security list just because we don't want
> > all the people at universities rushing in to test it). THAT is how things
> > should work.
>
> fine with me, i wasn't talking about that at all though ;).
Oh, so now you're suddenly fine with not doing "full disclosure"?
Just a few emails ago you berated me for not doing full disclosure, but
now you're saying it is fine?
Can you now admit that it's a gray line, and that we just have very
different opinions of where the line is drawn?
> 1. simple words/phrases that one can grep for (mentally or automated)
> examples: 'security', 'exploitable', 'DoS', 'buffer overflow', etc
I literally draw the line at anything that is simply greppable for. If
it's not a very public security issue already, I don't want a simple "git
log + grep" to help find it.
That said, I don't _plan_ messages or obfuscate them, so "overflow" might
well be part of the message just because it simply describes the fix. So
I'm not claiming that the messages can never help somebody pinpoint
interesting commits to look at, I'm just also not at all interested in
doing so reliably.
> i believe 3-5 are definitely not commit message material. 1 or 2 are.
> 5 should never be published or disseminated, 3 and 4 may be distributed
> to interested parties.
And I believe you now at least understand the difference. I draw the line
between 0 and 1, where 0 is "explain the fix" - which is something that
any - and every - commit message should do.
Linus
Tiago Assumpcao
>
> Umm. And if the whole discussion it was hidden from us on some private
> vendor list, why should we then help track their hidden state?
>
> That's what you claimed we should do, wasn't it?
How can I expect one to treat the unknown? If you are not aware of it,
you do nothing. Whenever a software organization is informed of a
problem in some product of their responsibility, they act upon it. On
the contrary, no, I don't expect any magic from you. Thanks for
bothering, though.
>
>> Personally, I, too, have a major disgust for most crap seen in the so called
>> info-sec world. I hand you my agreement on this one.
>> Except, it changes in nothing your responsibilities.
>
> My responsibility is to do a good job. And not pander to the people who
> want to turn security into a media circus.
And I thank you for that. No to the "security media circus".
>
> Which is exactly what I'm doing. No media circus.
>
> Linus
>
Wrong. This is not "media circus".
Whoever reads this thread with the basic understanding of software
development procedures, the reality of information security and with
legit judgment will clearly understand what you are doing and what
"pageexec" and I claim for. Further, I claim for decency from your part.
All I ask for is to receive the "There are updates available." message
as soon as one security problem is reported, understood and treated by
your development part. And that is, the sooner possible, if you please.
Plus, if one bothers, to be able to know the exact location of this bug
and its characteristics.
However, for these to happen, we need your collaboration. Or, with two
words, your responsibility.
Thanks,
--t
page...@freemail.hu
> On Wed, 16 Jul 2008, page...@freemail.hu wrote:
> >
> > > And I take mostly the opposite view. I think pointing it out is
> > > actually likely to be counter-productive.
> >
> > you keep saying that, but you don't explain *why*.
> >
> > > For example, the way I prefer to work is to have people send me and the
> > > kernel list a patch for a fix, and then in the very next email send (in
> > > private) an example exploit of the problem to the security mailing list
> > > (and that one goes to the private security list just because we don't want
> > > all the people at universities rushing in to test it). THAT is how things
> > > should work.
> >
> > fine with me, i wasn't talking about that at all though ;).
>
> Oh, so now you're suddenly fine with not doing "full disclosure"?
>
> Just a few emails ago you berated me for not doing full disclosure, but
> now you're saying it is fine?
>
> Can you now admit that it's a gray line, and that we just have very
> different opinions of where the line is drawn?
you didn't pay attention to me very well. i said a few times in this
thread already that i did *not* care what disclosure policy you choose
for the kernel security bugs, that's none of my business. what i (and
many others) do care about is that you follow through that choice.
as it is, you supposedly practice full disclosure, whether you know what
that term means or not, it does mean something very specific for people
with a security background and you most certainly do *not* practice it.
*that* is what i was complaining about - inconsistency between your words
and actions. i even told you that you can solve it two ways: change one
or the other. that is, you can begin to practice full disclosure (or as
we figured it out slowly, some form of disclosure at least as what you
turned out to be doing can best be described as no disclosure or less
affectionately, coverup), *or* you can declare (=let the world know) that
you do *not* practice any disclosure, certainly not full disclosure at
least.
> > 1. simple words/phrases that one can grep for (mentally or automated)
> > examples: 'security', 'exploitable', 'DoS', 'buffer overflow', etc
>
> I literally draw the line at anything that is simply greppable for. If
> it's not a very public security issue already, I don't want a simple "git
> log + grep" to help find it.
fair enough, that's another way to say 'i cover them up'. at least we got
that out in the clear, thank you. you would have saved a lot of time if you
had declared this somewhere in the kernel docs. it's still not too late and
would be the prudent thing to do, there're *many* people living under the
assumption that you don't actually do this.
> That said, I don't _plan_ messages or obfuscate them, so "overflow" might
> well be part of the message just because it simply describes the fix. So
> I'm not claiming that the messages can never help somebody pinpoint
> interesting commits to look at, I'm just also not at all interested in
> doing so reliably.
>
> > i believe 3-5 are definitely not commit message material. 1 or 2 are.
> > 5 should never be published or disseminated, 3 and 4 may be distributed
> > to interested parties.
>
> And I believe you now at least understand the difference. I draw the line
> between 0 and 1, where 0 is "explain the fix" - which is something that
> any - and every - commit message should do.
yes, perfectly clear. as i said, the disclosure policy (whether you call it
that or not) is your choice. please make it public somewhere.
cheers and good night,
PaX Team
Linus Torvalds
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> How can I expect one to treat the unknown? If you are not aware of it, you do
> nothing.
Well, some people keep it secret and track it on vendor-sec or similar,
hidden from us.
But then when they are ready to announce it, they want our help to glorify
their corrupt process when they finally deign to let us know. And that
really irritates me.
> All I ask for is to receive the "There are updates available." message as soon
> as one security problem is reported, understood and treated by your
> development part. And that is, the sooner possible, if you please.
Umm. You're talking to _entirely_ the wrong person.
The people who want to track security issues don't run my development
kernels. They usually don't even run the _stable_ kernels. They tend to
run the kernels from some commercial distribution, and usually one that is
more than six months old as far as I - and other kernel developers - are
concerned.
IOW, when we fix security issues, it's simply not even appropriate or
relevant to you. More importantly, when we fix them, your vendor probably
won't have the fix for at least another week or two in most cases anyway.
So ask yourself - what would happen if I actually made a big deal out of
every bug we find that could possibly be a security issue. HONESTLY now!
We'd basically be announcing a bug that (a) may not be relevant to you,
but (b) _if_ it is relevant to you, you almost certainly won't actually
have fixed packages until a week or two later available to you!
Do you see?
I would not actually be helping you. I'd be helping the people you want to
protect against!
Linus
page...@freemail.hu
> Flaming and complaining that the kernel git logs aren't providing free
> marketing for PaX/grsecurity isn't going to do much good.
what free marketing are you talking about?
Tiago Assumpcao
> Look if you want this, pay $$$ to a distribution and get their
> supported distribution. It costs time and effort to classify bugs as
That's fallacious. Assuming that you have good programmers, and you do,
it's of very low cost the act of identifying what *is likely to be* a
security bug. In most cases, they are easy to spot. And, hey, we are not
asking for an absurd amount of care. You must not pay $200 /hour for
someone to review your software. All I, personally, ask for is that the
basic attention is given. With this simple act, I'm sure you would cover
the majority of the bugs.
> It will cost you money, but hey, the people who want
> this sort of thing typically are willing to pay for the service.
>
So, only those willing to pay have the right of respect? Because, you
see, this is rather a matter of respect with those who choose to use
your solution. And, no, the "free will" argument does not qualify
herein. My mother is not aware of your absurd acts.
> I'll note that trying to classify bugs as being "security-related" at
> the kernel.org level often doesn't help the distro's, since many of
> these bugs won't even apply to whatever version of the kernel the
> distro's snapshotted 9-18 months ago. So if the distro snapshotted
> 2.6.18 in Fall 2006, and their next snapshot will be sometime two
> years later in the fall of this year, they will have no use for some
> potential local denial of service attack that was introduced by
> accident in 2.6.24-rc3, and fixed in 2.6.25-rc1. It just doesn't
> matter to them.
I don't follow what you have just said. What is the problem with
"versioning" and the strictness of its relation to bugs, security or not?
>
> So basically, if there are enough kernel.org users who care, they can
> pay someone to classify and issue CVE numbers for each and every
> potential "security bug" that might appear and then disappear.
I think, CVE registration or the alike would be too much for what I call
"act of decency". A single parenthesis note on the bug itself would be
of great help and of small effort.
--t
Linus Torvalds
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> So, only those willing to pay have the right of respect?
You keep using that word. I do not think it means what you think it means.
How about respecting my opinion instead?
But no, you claim I must respect you, because you have some other notion
of what should be done, even though I've explained why I don't agree.
It cuts both ways.
Linus
Tiago Assumpcao
>
> Well, some people keep it secret and track it on vendor-sec or similar,
> hidden from us.
>
> But then when they are ready to announce it, they want our help to glorify
> their corrupt process when they finally deign to let us know. And that
> really irritates me.
>
Again, not asking for what you can not provide. You must, however, do
your part.
> The people who want to track security issues don't run my development
> kernels. They usually don't even run the _stable_ kernels. They tend to
> run the kernels from some commercial distribution, and usually one that is
> more than six months old as far as I - and other kernel developers - are
> concerned.
Right *there* is where it is born! Right at your development kernels. It
may or may not survive up to the big market. However, being at the
source level, it is your duty to a) resolve the source-level issues; b)
put affordable efforts in order to prevent one known issue to arrive at
the end point.
>
> IOW, when we fix security issues, it's simply not even appropriate or
> relevant to you. More importantly, when we fix them, your vendor probably
> won't have the fix for at least another week or two in most cases anyway.
>
There is obviously room for suffering from this delay. It's really
small, however, if you understand that this is not enough time for
widely spread exploits to be in the hands of every corner kid. Not.
Thus, consider the following: how many computers are likely to suffer
from one bug that has been advised (marked as "security related" in your
bugzilla), and, one week later, fixed? Now, how many computers are
likely to suffer from one bug that has been advised and fixed 8 weeks
later? A lot more, I presume.
Ok. Now, imagine this scenario: one bug that has never been identified
as "security relevant" is assigned and/or fixed by your people.
Remember, your list is open to public. Do you have a clue of how many
individuals keep watching every bug/fix, with a "security antenna"
turned on, expecting for the right bug to show up and... not receive the
attention it needs so they can do whatever they want, for the amount of
time they please? Several.
Now, tell me, how many computers are likely to suffer from the last
scenario; the one that you cultivate?
> So ask yourself - what would happen if I actually made a big deal out of
> every bug we find that could possibly be a security issue. HONESTLY now!
>
Just mark it. No big deal.
>
> I would not actually be helping you. I'd be helping the people you want to
> protect against!
>
> Linus
>
Those who can see, and quickly exploit it, do not need your mark. They
will figure it out right after it was assigned and an exploit will exist
in the wild not after you fix the bug. So, let's work for the smallest
pain. Right?
--t
Tiago Assumpcao
>
> How about respecting my opinion instead?
>
> But no, you claim I must respect you, because you have some other notion
> of what should be done, even though I've explained why I don't agree.
>
This is not a question of ideology or taste. It is a practical matter
that is supported by what has been, far from just "pure reasoning",
argued. Sad that you can't, for whatever reason, see it and I will not
push you any further.
Have a good night.
--t
Theodore Tso
>> The people who want to track security issues don't run my development
>> kernels. They usually don't even run the _stable_ kernels. They tend to
>> run the kernels from some commercial distribution, and usually one that
>> is more than six months old as far as I - and other kernel developers -
>> are concerned.
>
> Right *there* is where it is born! Right at your development kernels. It
> may or may not survive up to the big market. However, being at the
> source level, it is your duty to a) resolve the source-level issues; b)
> put affordable efforts in order to prevent one known issue to arrive at
> the end point.
I don't think we've ever heard any of the distro kernel engineers
complain that there is a problem with how commits are documented in
the upstream source. Keep in mind, the distro kernels are usually at
least 6-9, to sometimes 18-24 months old. So many of the security
bugs that show up in the developement kernels simply don't *apply* to
the distro kernels; they security bugs simply aren't present in those
older kernels.
Of course, sometimes there are long-standing bugs. But I don't think
the distro engineers have been complaining that they aren't finding
out about them because they aren't marked <<------ SECURITY BUG HERE
in big bold letters.
And again, talking about something as if it were their ***duty*** is
not a good way to pursuade people to do things in the open source
world. The only guaranteed way to get something done in the open
source is to help pay for it, or do it yourself. Sometimes you can
convince others to do your work for you, but usually that requires
some reciprocity in the long run.
Regards,
- Ted
Greg KH
>
> All I ask for is to receive the "There are updates available." message as
> soon as one security problem is reported, understood and treated by your
> development part. And that is, the sooner possible, if you please.
Do we not already do this today? I know I do this as soon as possible
for any reported problem for the -stable tree, as soon as the fix is in
Linus's tree.
See the 2.6.25.11 release for an example of this.
> Plus, if one bothers, to be able to know the exact location of this bug and
> its characteristics.
That's the extra work that you are saying we also need to do. Linus and
others have already detailed why we don't do that.
thanks,
greg k-h
Casey Schaufler
> Theodore Tso wrote:
>> Look if you want this, pay $$$ to a distribution and get their
>> supported distribution. It costs time and effort to classify bugs as
>> security related (or not), (...)
>
> That's fallacious. Assuming that you have good programmers, and you
> do, it's of very low cost the act of identifying what *is likely to
> be* a security bug.
That is based on lots and lots of assumptions that are just not true.
Ted Tso, Stephen Smalley and I are all recognized as security experts
and we can't even agree on whether sockets are objects or not, much
less what constitutes a security bug and even less what is likely to
be a security bug. Goodness, there are some of us who would argue
that since DNS is itself a security bug it is just not possible for
DNS to have a security bug, as an example.
> In most cases, they are easy to spot.
Err, no, in the kernel environment a real security flaw is likely to
be pretty subtle.
Linus Torvalds
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> This is not a question of ideology or taste.
Oh, so only your opinion matters? And only _your_ "practical matters" is
what people should care about?
Yes, master.
Linus
Tiago Assumpcao
> Ted Tso, Stephen Smalley and I are all recognized as security experts
> and we can't even agree on whether sockets are objects or not, much
> less what constitutes a security bug and even less what is likely to
> be a security bug. Goodness, there are some of us who would argue
> that since DNS is itself a security bug it is just not possible for
> DNS to have a security bug, as an example.
>
>> In most cases, they are easy to spot.
>
> Err, no, in the kernel environment a real security flaw is likely to
> be pretty subtle.
You do not hesitate in categorizing yourself as something as obscure
as... what's that term again? "Expert". But then you fail on basic
pragmatism when attempting to define what, nearly always, is a true or
false question?
Jeez ;)
Tiago Assumpcao
> Oh, so only your opinion matters? And only _your_ "practical matters" is
> what people should care about?
>
claims for security measures.
Enough said. It's your project. Do with it whatever you find the better.
Best wishes,
--t
Linus Torvalds
On Wed, 16 Jul 2008, Tiago Assumpcao wrote:
>
> You do not hesitate in categorizing yourself as something as obscure as...
> what's that term again? "Expert". But then you fail on basic pragmatism when
> attempting to define what, nearly always, is a true or false question?
I would suggest you maintain your own kernel version, since you're so
obviously more competent at it than we are.
Then, when you inevitably show your superiority, people will start using
your version of the kernel. That's the point of open source, after all. It
keeps us all honest - at any point, we can be overtaken by somebody
better.
I've actually been waiting for this moment for over fifteen years now:
finding that person who can take over so that I don't have to bother any
more. I'll continue to do my own maintenance in parallel while you get up
to speed, but I expect that everybody will have dropped my feeble efforts
soon enough, so you can probably just ignore that.
Thanks,
Linus
Tiago Assumpcao
> I would suggest you maintain your own kernel version, since you're so
> obviously more competent at it than we are.
Raising an honest question and following with one, not less sincere,
debate makes me all that competent? I don't understand.
> I've actually been waiting for this moment for over fifteen years now:
> finding that person who can take over so that I don't have to bother any
> more. I'll continue to do my own maintenance in parallel while you get up
> to speed, but I expect that everybody will have dropped my feeble efforts
> soon enough, so you can probably just ignore that.
>
> Thanks,
>
> Linus
>
No, thank you. I'll stick up with poetry.
--t
Linus Torvalds
On Wed, 16 Jul 2008, Tiago Assumpcao wrote:
>
> Raising an honest question and following with one, not less sincere, debate
> makes me all that competent? I don't understand.
No, you must be more competent that everybody you talk to, since you seem
to always know the answers and can dismiss their concerns. That's all I
tried to say,
Linus
Casey Schaufler
> Casey Schaufler wrote:
>> Ted Tso, Stephen Smalley and I are all recognized as security experts
>> and we can't even agree on whether sockets are objects or not, much
>> less what constitutes a security bug and even less what is likely to
>> be a security bug. Goodness, there are some of us who would argue
>> that since DNS is itself a security bug it is just not possible for
>> DNS to have a security bug, as an example.
>>
>>> In most cases, they are easy to spot.
>>
>> Err, no, in the kernel environment a real security flaw is likely to
>> be pretty subtle.
>
> You do not hesitate in categorizing yourself as something as obscure
> as... what's that term again? "Expert".
Actually, I always hesitate before calling myself an expert,
in spite of the credentials I have to back the title. Too
many people seem to think that if you disagree with their
point of view you can't know what you're talking about.
> But then you fail on basic pragmatism when attempting to define what,
> nearly always, is a true or false question?
HeeHeeHee. Security questions are almost never true or false,
black or white, on or off. SPAM is *the* major computer security
issue and it has nothing at all to do with computers or security.
Is a use of strcpy() a security vulnerability? Sure it can be,
but in reality it almost never is, but the hysteria associated
with buffer overruns gave it a bad oder.
> Jeez ;)
It's not so bad. We'll be OK. Really.
page...@freemail.hu
> On Tue, Jul 15, 2008 at 10:10:19PM -0300, Tiago Assumpcao wrote:
> >
> > All I ask for is to receive the "There are updates available." message as
> > soon as one security problem is reported, understood and treated by your
> > development part. And that is, the sooner possible, if you please.
>
> Do we not already do this today? I know I do this as soon as possible
> for any reported problem for the -stable tree, as soon as the fix is in
> Linus's tree.
>
> See the 2.6.25.11 release for an example of this.
very good example of how you actually do *not* do what you claim. find me
the word 'security' in your announcement. it's not there. amazing, isn't it.
despite what your fellow -stable maintainer claimed *he* would at least do
(and regularly tries to do so in fact). despite what you yourself did on
other occasions (remember 2.6.23.8?). what's wrong with you Greg? have you
not been told and proven to cover up security bugs enough times already?
cheers,
PaX Team
Gabor Gombas
> very good example of how you actually do *not* do what you claim. find me
> the word 'security' in your announcement. it's not there. amazing, isn't it.
> despite what your fellow -stable maintainer claimed *he* would at least do
> (and regularly tries to do so in fact). despite what you yourself did on
> other occasions (remember 2.6.23.8?). what's wrong with you Greg? have you
> not been told and proven to cover up security bugs enough times already?
Huh? Have you read the announcement? If one do not understand from the
wording that this _is_ a security fix then he/she is stupid beyond hope.
And I see that the biggest difference between you and the kernel
developers: the kernel developers want you to _think_ whether that
particular patch is important for you or not. You on the other hand want
to be able to mindlessly apply patches marked as "security fix" without
any consideration about how all the other unfixed bugs can bite you.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
page...@freemail.hu
> Tiago Assumpcao wrote:
> > Theodore Tso wrote:
> >> Look if you want this, pay $$$ to a distribution and get their
> >> supported distribution. It costs time and effort to classify bugs as
> >> security related (or not), (...)
> >
> > That's fallacious. Assuming that you have good programmers, and you
> > do, it's of very low cost the act of identifying what *is likely to
> > be* a security bug.
>
> That is based on lots and lots of assumptions that are just not true.
> Ted Tso, Stephen Smalley and I are all recognized as security experts
not so quick. security is a big field, noone really can claim to be
a general expert. Ted knows kerberos but he would be unable to exploit
the task refcount leak bug fixed in 2.6.25.10. Stephen and you know
MAC systems inside out but you too would be unable to exploit that bug.
different domains, different expertise, despite all being 'security'.
with that foreword:
> and we can't even agree on whether sockets are objects or not,
and it's utterly irrelevant to the next hacker that will own your precious
MAC by exploiting a kernel bug that you 'experts' didn't deem important
enough to tell the world about. do you understand that we've been talking
about *kernel* bugs here? do you understand what privilege elevation is?
you surely do since you work with MAC systems all the time whose purpose
is, well, access control.
> much less what constitutes a security bug and even less what is likely to
> be a security bug.
privilege elevation bugs are security bugs, no ifs and buts. whether a given
bug can be exploited at that level is a different question, and if you can't
make that judgement you're welcome to err on the side of safety (i.e., have
people upgrade/backport rather than be possibly exposed) or bring in help
(if Microsoft can pay people to do that, so can commercial Linux companies).
> Goodness, there are some of us who would argue
> that since DNS is itself a security bug it is just not possible for
> DNS to have a security bug, as an example.
it's all very much irrelevant to local kernel security that we're talking
about.
> > In most cases, they are easy to spot.
>
> Err, no, in the kernel environment a real security flaw is likely to
> be pretty subtle.
i don't have stats about 'most' vs 'likely', but yes, they can indeed
be subtle, that's why you should not be overly optimistic and dismiss
potentially exploitable bugs as not relevant and cover them up.
cheers,
PaX Team
page...@freemail.hu
> On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
> > All I ask for is to receive the "There are updates available." message as soon
> > as one security problem is reported, understood and treated by your
> > development part. And that is, the sooner possible, if you please.
>
> Umm. You're talking to _entirely_ the wrong person.
>
> The people who want to track security issues don't run my development
> kernels. They usually don't even run the _stable_ kernels.
how do you *know*?
> They tend to
> run the kernels from some commercial distribution, and usually one that is
> more than six months old as far as I - and other kernel developers - are
> concerned.
>
> IOW, when we fix security issues, it's simply not even appropriate or
> relevant to you.
why? what makes you think that a bug fixed in 2.6.26 is not relevant to
2.6.20? do you or anyone else personally verify that? color me impressed
if you do that on every single fix you commit.
> More importantly, when we fix them, your vendor probably
> won't have the fix for at least another week or two in most cases anyway.
correct, but also irrelevant, see below.
> So ask yourself - what would happen if I actually made a big deal out of
> every bug we find that could possibly be a security issue. HONESTLY now!
why do you and others keep exaggerating of what is (well, was) expected from
you? what's with this 'big deal' business? can't you image a middle ground
where you simply just state what you know? say, my category 1-2 i talked
about before.
> We'd basically be announcing a bug that (a) may not be relevant to you,
> but (b) _if_ it is relevant to you, you almost certainly won't actually
> have fixed packages until a week or two later available to you!
>
> Do you see?
>
> I would not actually be helping you. I'd be helping the people you want to
> protect against!
your argument rests on a fallacy that we discussed already but you keep
coming back with it. what makes you think that people exploiting kernel
bugs *rely* on your marking security bugs as such? they do *not*. they
are smarter (read: domain experts) than you or anyone else on lkml. they
will most likely spot the security issue when you *introduce* it, not
when you *fix* it. in other words, you are only helping the attackers by
withholding security information, not your users.
cheers,
PaX Team
David Miller
Date: Wed, 16 Jul 2008 11:49:45 +0200
> why? what makes you think that a bug fixed in 2.6.26 is not relevant to
> 2.6.20? do you or anyone else personally verify that? color me impressed
> if you do that on every single fix you commit.
Many people who do kernel development do exactly this for the vendor
they work for.
The SCTP socket option overflow fix got into various dist releases not
by chance and not because of some utterly pointless "security" tag in
the commit message.
page...@freemail.hu
> On Wed, Jul 16, 2008 at 11:01:51AM +0200, page...@freemail.hu wrote:
>
> > very good example of how you actually do *not* do what you claim. find me
> > the word 'security' in your announcement. it's not there. amazing, isn't it.
> > despite what your fellow -stable maintainer claimed *he* would at least do
> > (and regularly tries to do so in fact). despite what you yourself did on
> > other occasions (remember 2.6.23.8?). what's wrong with you Greg? have you
> > not been told and proven to cover up security bugs enough times already?
>
> Huh? Have you read the announcement? If one do not understand from the
> wording that this _is_ a security fix then he/she is stupid beyond hope.
i understand what it is, i would understand it even if it said even
less.
what does this have to do with carefully avoiding the word 'security'
on one hand and disclosing it on another? do you understand the word
'consistency' or are you 'stupid beyond hope'?
> And I see that the biggest difference between you and the kernel
> developers:
no you don't see it. you haven't even read or understood all the
discussion else you would not be making stupid claims as below:
> the kernel developers want you to _think_ whether that
> particular patch is important for you or not.
are you out of your mind? since when it is the job of users (meaning,
users of commit logs) to reverse engineer what the heck the given
commit was supposed to actually fix? do you think they don't have
better use of their time? if there is a purpose of a commit message
then it's that of informing the reader, not confusing or misleading
him.
> You on the other hand want
> to be able to mindlessly apply patches marked as "security fix"
what is mindless about applying a security fix?
> without
> any consideration about how all the other unfixed bugs can bite you.
where did i say that people should apply security fixes without
considering other, unmarked fixes? i said the exact opposite which
you would know if you had actually cared to read the thread in its
entirety.
udv,
PaX Team
page...@freemail.hu
> From: page...@freemail.hu
> Date: Wed, 16 Jul 2008 11:49:45 +0200
>
> > why? what makes you think that a bug fixed in 2.6.26 is not relevant to
> > 2.6.20? do you or anyone else personally verify that? color me impressed
> > if you do that on every single fix you commit.
>
> Many people who do kernel development do exactly this for the vendor
> they work for.
i know that. but you conveniently skipped what i was replying to, here
it is for proper context:
> IOW, when we fix security issues, it's simply not even appropriate or
> relevant to you.
i'll ask again: why aren't security fixes that you fix relevant to users
of older kernels (as that's what the topic was)? in other words, Linus was
trying to justify with one more silly reason why security fixe aren't marked
as such. the above basically said 'because they are not relevant to you'
and i asked him why it is so. you're welcome to explain it as well. and no,
vendors having people go through every single commit doesn't answer why you
couldn't make *their* life easier as well by not withholding information.
and not to mentiond a whole world of interested users beyond the commercial
companies that can afford this kind of cost.
> The SCTP socket option overflow fix got into various dist releases not
> by chance and not because of some utterly pointless "security" tag in
> the commit message.
why do you call a security tag 'utterly pointless'? i've heard Linus's
opinion and deconstructed every single one of his 'justifications' so far.
what's yours gonna be?
cheers,
PaX Team
David Miller
Date: Wed, 16 Jul 2008 12:23:50 +0200
> On 16 Jul 2008 at 3:08, David Miller wrote:
>
> > IOW, when we fix security issues, it's simply not even appropriate or
> > relevant to you.
>
> i'll ask again: why aren't security fixes that you fix relevant to users
> of older kernels (as that's what the topic was)?
Backporting any fix to older kernels is a chore, the further back you
go, the harder and less fun it is.
The tipping point is really quick to where someone hacking the kernel
for fun simply isn't going to do it, nor should they be expected to.
That's why people who want a stable supported kernel with fixes
constantly backported have grown accustomed to paying for that service.
And to me that is entirely reasonable.
page...@freemail.hu
> From: page...@freemail.hu
> Date: Wed, 16 Jul 2008 12:23:50 +0200
>
> > On 16 Jul 2008 at 3:08, David Miller wrote:
> >
> > > IOW, when we fix security issues, it's simply not even appropriate or
> > > relevant to you.
> >
> > i'll ask again: why aren't security fixes that you fix relevant to users
> > of older kernels (as that's what the topic was)?
>
> Backporting any fix to older kernels is a chore, the further back you
> go, the harder and less fun it is.
it depends on the fix and the context of the code it touches. a one
liner in 2.6.26 may not necessarily have to become a 100 line, multi-file
fix in 2.6.16. look at 28d838cc4dfea980cb6eda0a7409cbf91889ca74 for an
example, that was trivial to backport to many kernel versions before.
also, if you can find a commercial distro whose kernel predates even
yours (i.e., yours is between mainline and a well maintained commercial
one) then you may not actually have such a big problem with backports
even for more complex fixes as you can peek at what the commercial guys
are doing.
in any case, you're answering a different question or i'm failing to see
the logical connection between 'irrelevant' and 'laborious'. basically you
said now that you don't provide security info because it's labourious to
backport fixes, or something like that. i'm afraid there's no such logical
connection. you also didn't answer the question about why you should not
make the life of people doing the actual backports (paid for, commercial,
whatever the trigger word for you is) easier.
> The tipping point is really quick to where someone hacking the kernel
> for fun simply isn't going to do it, nor should they be expected to.
>
> That's why people who want a stable supported kernel with fixes
> constantly backported have grown accustomed to paying for that service.
and how does that imply that you should not mark security fixes as such?
remember, we're not discussing how backports are done in the world, but
why you're helping them by withholding security information. because if
you admit that you're not, then that's one less reason to withhold this
info.
cheers,
PaX Team
David Miller
Date: Wed, 16 Jul 2008 12:51:31 +0200
> On 16 Jul 2008 at 3:31, David Miller wrote:
>
> > From: page...@freemail.hu
> > Date: Wed, 16 Jul 2008 12:23:50 +0200
> >
> > > On 16 Jul 2008 at 3:08, David Miller wrote:
> > >
> > > > IOW, when we fix security issues, it's simply not even appropriate or
> > > > relevant to you.
> > >
> > > i'll ask again: why aren't security fixes that you fix relevant to users
> > > of older kernels (as that's what the topic was)?
> >
> > Backporting any fix to older kernels is a chore, the further back you
> > go, the harder and less fun it is.
...
> > The tipping point is really quick to where someone hacking the kernel
> > for fun simply isn't going to do it, nor should they be expected to.
> >
> > That's why people who want a stable supported kernel with fixes
> > constantly backported have grown accustomed to paying for that service.
>
> and how does that imply that you should not mark security fixes as such?
You asked me why fixes are not relevant to users of older upstream
non-dist kernels. And I answered that question.
page...@freemail.hu
> From: page...@freemail.hu
> Date: Wed, 16 Jul 2008 12:51:31 +0200
>
> > On 16 Jul 2008 at 3:31, David Miller wrote:
> >
> > > From: page...@freemail.hu
> > > Date: Wed, 16 Jul 2008 12:23:50 +0200
> > >
> > > > On 16 Jul 2008 at 3:08, David Miller wrote:
> > > >
> > > > > IOW, when we fix security issues, it's simply not even appropriate or
> > > > > relevant to you.
> > > >
> > > > i'll ask again: why aren't security fixes that you fix relevant to users
> > > > of older kernels (as that's what the topic was)?
> > >
> > > Backporting any fix to older kernels is a chore, the further back you
> > > go, the harder and less fun it is.
> ...
> > > The tipping point is really quick to where someone hacking the kernel
> > > for fun simply isn't going to do it, nor should they be expected to.
> > >
> > > That's why people who want a stable supported kernel with fixes
> > > constantly backported have grown accustomed to paying for that service.
> >
> > and how does that imply that you should not mark security fixes as such?
>
> You asked me why fixes are not relevant to users of older upstream
> non-dist kernels. And I answered that question.
no you did not because that was not my question actually. i wasn't
asking about 'older upstream non-dist kernels' but 'older kernels',
regardless of their being of vanilla or distro or whatever variety.
here it is again (you even quoted it above btw):
"why aren't security fixes that you fix relevant to users of older kernels"
it doesn't say 'distro'. in fact, i chose my words carefully as there
seems to be a tendency among you guys where you simply ignore or don't
care about the interests of several user groups. there's a whole world
beyond Red Hat and Novell, and some of those people are very well
capable of backporting fixes, so your 'it is too labourious to backport
therefore we don't mark security fixes' argument is simply wrong (an in
all honesty, it's not up to you guys to decide what people are capable or
willing to backport, your responsibility should be to help them, no make
decisions for them). if you want an inside voice, go ask the 2.4 maintainer.
i quoted him already here already in fact:
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)
so what's the next 'justification' for covering up security bugs?
cheers,
PaX Team
Theodore Tso
> > > That's fallacious. Assuming that you have good programmers, and you
> > > do, it's of very low cost the act of identifying what *is likely to
> > > be* a security bug.
> >
> > That is based on lots and lots of assumptions that are just not true.
> > Ted Tso, Stephen Smalley and I are all recognized as security experts
>
> not so quick. security is a big field, noone really can claim to be
> a general expert. Ted knows kerberos but he would be unable to exploit
> the task refcount leak bug fixed in 2.6.25.10. Stephen and you know
> MAC systems inside out but you too would be unable to exploit that bug.
> different domains, different expertise, despite all being 'security'.
As far as I am concerned, knowing how to exploit a task refcount leak
bug is a technician's job. Sure, I can write code that given an
intercepted or stolen Kerberos srvtab/ketab file, how to forge
Kerberos tickets. But at the end of the day, that's perhaps the least
important part of what a "Security Expert" has to do. Bruce Schneier
has written about this extensively.
The important thing to recognize about security is that it is all
about tradeoffs. How do you protect the System (which may consist of
one computers or multiple computers) given a particular threat
environment, given adversaries with different levels of capability,
given the consequences of a security breach, and how do you do it
within a given parameters of cost and usability?
What a security expert might do is laugh at someone who is spending
all of their time and energy worrying about local escalation attacks,
when they discover that all of the network exchanges are unprotected
and on an insecure network. Or, they might point out that you are
spending 10 times as much money and effort on securing a system as the
cost of a security breach, and that might not make sense either.
This is why there are so many arguments over security. There are
disagreements over what deserves more focus and attention, and what is
and isn't worthwhile trading off against other things. For example,
last I looked, PaX significantly reduces the chance of buffer overrun
attacks, but at the cost of cutting your address space in half and
forcing you to use a custom-built kernels since modules are not
supported either (which means no tools like Systemtap, as well). For
some people, particularly on 32-bit systems, this is unacceptable.
But some people might consider that a valid tradeoff.
As another example, take for example some bug that might be able to
cause a local privilege escalation. If the machine running that
particular kernel is part of a computing cluster which is totally
disconnected from the Internet, that bug is from a security point of
view totally irrelevant.
So to do a true security analysis about the seriousness of a bug
*always* requires some amount of context about what the capabilities
that the adversary might have (or might have acquired). Given that
most systems these days are single user systems, a local privilege
escalation attack may not be as big a of deal in this day and age.
Many people draw their trust boundary around the entire computer.
At the end of the day, it is an engineering discipline, and it is all
about tradeoffs. So while it is useful to have people who focus on
the security of a single box against adversaries who have local shell
access, it is very easy to lose perspective of the greater security
picture. And someone like Linus who is worried about the overall
system, it's even easier to lose perspective. Consider that there was
only one computer system that to my knowledge, ever managed to get
evaluated as passing the Orange Book A1 security requirements; and
that system was a commercial failure. It took too long to bring to
market, it was too slow, and was too expensive. It would be like
people assuming that you could always build a tank by putting more
armor on it, and that there is no such thing as "too much armor".
Same principle.
I have a theory which is that people who are focused on local system
security to the exclusion of all else have a high risk of becoming
unbalanced; they end up like Theo de Rant, frustrated because people
aren't paying attention to them, and that others aren't worried about
the same problems that they think are important. But, the good news
of open source is that if you *do* care about local system security to
the exclusion of all else, including high SMP scalability, and wide
hardware support, etc., you can go use OpenBSD! They may be much more
your type of people. Or, you can pay for support for an enterprise
Linux distribution, where they do have people who will help you out
for it. Hopefully their idea of security and priorities matches up
with your own, although I will note that some of the companies that
have focused exclusively on security to the exclusion of all else
(e.g. Trustix AS, Immunix) haven't necessarily done very well
commercially.
Regards,
- Ted
Greg KH
>
> > On Tue, Jul 15, 2008 at 10:10:19PM -0300, Tiago Assumpcao wrote:
> > >
> > > All I ask for is to receive the "There are updates available." message as
> > > soon as one security problem is reported, understood and treated by your
> > > development part. And that is, the sooner possible, if you please.
> >
> > Do we not already do this today? I know I do this as soon as possible
> > for any reported problem for the -stable tree, as soon as the fix is in
> > Linus's tree.
> >
> > See the 2.6.25.11 release for an example of this.
>
> very good example of how you actually do *not* do what you claim. find me
> the word 'security' in your announcement. it's not there. amazing, isn't it.
No, it was a consious decision to do just to piss you off, glad to see
it worked :)
Come on, give me a break, Tiago asked that we do releases as soon as we
know about a security problem. 2.6.25.11 was released because of this,
and all users were told to upgrade. Is the fact that I add the magic
word "security" in a sentance in the email some specific requirement
that will make you happy?
Take a look at the words I used, if someone can't determine if they
should upgrade or not based on that, then they need to rely on a company
to provide updates for them, and not be running their own kernels
because they really have no clue about system management.
Bah, what a joke.
greg k-h
page...@freemail.hu
> On Wed, Jul 16, 2008 at 11:01:51AM +0200, page...@freemail.hu wrote:
> > On 15 Jul 2008 at 20:13, Greg KH wrote:
> >
> > very good example of how you actually do *not* do what you claim. find me
> > the word 'security' in your announcement. it's not there. amazing, isn't it.
>
> No, it was a consious decision to do just to piss you off, glad to see
> it worked :)
>
> Come on, give me a break, Tiago asked that we do releases as soon as we
> know about a security problem. 2.6.25.11 was released because of this,
> and all users were told to upgrade. Is the fact that I add the magic
> word "security" in a sentance in the email some specific requirement
> that will make you happy?
it's not about making me happy Greg. i can figure these things out for
myself, i do *not* need your help in that. there're many users however
who rely on your providing accurate information. announcing a security
fix as such is the proper thing to do, i can't imagine how you guys can
dance around that simple fact for so long. just look at what your own
employer does with security bugs, if they see it fit to mark them as
such, how can you possibly argue that you're somehow acting in good
faith when you cover them up? will you next tell your corporate bosses
that they're bloody idiots that can't tell a bug from a bug and should
just omit the word 'security' altogether from future announcements? i
didn't think so either.
> Take a look at the words I used, if someone can't determine if they
> should upgrade or not based on that,
your carefully chosen words are *wrong* in fact. exploiting local bugs
has nothing to do with having untrusted users in the age of client side
exploits. due to your completely mischaracterized description, individual
home users may very well feel that they do not need to upgrade, to the
delight of the next malware owning their browser. you can congratulate
yourself Greg, you successfully misled a whole class of users.
> then they need to rely on a company
> to provide updates for them, and not be running their own kernels
> because they really have no clue about system management.
you conveniently failed to respond to the rest of my mail where i showed
that Chris Wright, heck, even yourself did announce security fixes as such
in the past. how do you explain that?
> Bah, what a joke.
and i thought i was the one getting pissed ;).
cheer up,
PaX Team
page...@freemail.hu
> On Wed, Jul 16, 2008 at 11:33:12AM +0200, page...@freemail.hu wrote:
> > not so quick. security is a big field, noone really can claim to be
> > a general expert. Ted knows kerberos but he would be unable to exploit
> > the task refcount leak bug fixed in 2.6.25.10. Stephen and you know
> > MAC systems inside out but you too would be unable to exploit that bug.
> > different domains, different expertise, despite all being 'security'.
>
> As far as I am concerned, knowing how to exploit a task refcount leak
> bug is a technician's job.
you can try to downplay it like that, but it doesn't make it a simple
technician's job (go tell that to the NSA's red team members ;). exploit
development is an art, it's an expertise that you can't acquire in formal
education for example. that holds for many other aspects of computer
security in fact, that's why it's not an engineering discipline in any
sense that civil or mechanical engineering is. let's wait a few more
decades or centuries, and it will probably become one, but not today.
the reason i mentioned exploit development is actually that if you are
not aware of how you can exploit a bug, you're likely to make a bad
judgement call when you have to decide a bug's exploitability. *that*
will have bad effects on everyone else depending on your judgement.
> Sure, I can write code that given an
> intercepted or stolen Kerberos srvtab/ketab file, how to forge
> Kerberos tickets. But at the end of the day, that's perhaps the least
> important part of what a "Security Expert" has to do. Bruce Schneier
> has written about this extensively.
what is important depends on the situation. for a pentester it's quite
important to be able to write exploits for example.
> The important thing to recognize about security is that it is all
> about tradeoffs. How do you protect the System (which may consist of
> one computers or multiple computers) given a particular threat
> environment, given adversaries with different levels of capability,
> given the consequences of a security breach, and how do you do it
> within a given parameters of cost and usability?
we have a simpler description for the purpose of security: it's all
about risk management. risk management is indeed about making decisions
that often involve tradeoffs. the responsibility of kernel developers
is, or should be, if it isn't, to help such decisions by not covering
up security fixes.
> This is why there are so many arguments over security. There are
> disagreements over what deserves more focus and attention, and what is
> and isn't worthwhile trading off against other things. For example,
> last I looked, PaX significantly reduces the chance of buffer overrun
> attacks, but at the cost of cutting your address space in half and
> forcing you to use a custom-built kernels since modules are not
> supported either (which means no tools like Systemtap, as well). For
> some people, particularly on 32-bit systems, this is unacceptable.
> But some people might consider that a valid tradeoff.
actually, if we're talking 2.6, that's not true anymore, PaX will use
the hw NX bit if present, else it will fall back to the segmentation
based method. also, there's been module support for years now, in fact
it's better than that of vanilla in that i added proper separation of
rx/rw mappings for modules.
> As another example, take for example some bug that might be able to
> cause a local privilege escalation. If the machine running that
> particular kernel is part of a computing cluster which is totally
> disconnected from the Internet, that bug is from a security point of
> view totally irrelevant.
not necessarily, it depends on who has local access to that cluster
and whether they separate privileges or not. say, if the admin/user
roles are separate, then it's very much relevant there as well. sure,
the threat model is different, but it doesn't mean it's non-existent.
> So to do a true security analysis about the seriousness of a bug
> *always* requires some amount of context about what the capabilities
> that the adversary might have (or might have acquired). Given that
> most systems these days are single user systems, a local privilege
> escalation attack may not be as big a of deal in this day and age.
> Many people draw their trust boundary around the entire computer.
in fact, in this day and age of client side bugs (think browsers, media
players, etc), it is even more relevant. not because as if acquiring
normal user privileges didn't already break the given user's security,
but because by elevating to root, an attacker reduces his risk of being
discovered, not to mention gaining access to both the wife's and the
husband's emails at once. FWIW, i'm told that there's windows malware
that uses 0-day for both browser exploitation and local privilege
escalation, there's no reason to believe that the same cannot occur
on linux or elsewhere.
> At the end of the day, it is an engineering discipline, and it is all
> about tradeoffs. So while it is useful to have people who focus on
> the security of a single box against adversaries who have local shell
> access, it is very easy to lose perspective of the greater security
> picture.
i'm not sure if you're thinking of me as who's losing focus, but let
me tell you why you can't just so easily separate local from remote
bugs. in this age of networks, we do not simply have computer networks,
we also have trust networks. if you have a shell account at mit.edu,
then someone elevating to root there will be able to trigger a client
side ssh bug on your personal box (just an example, don't go looking
for one). in other words, locally exploitable bugs != single box
security.
> I have a theory which is that people who are focused on local system
> security to the exclusion of all else have a high risk of becoming
> unbalanced;
why does asking kernel developers to describe security fixes as such
risk becoming unbalanced?
cheers,
PaX Team
Greg KH
> > Take a look at the words I used, if someone can't determine if they
> > should upgrade or not based on that,
>
> your carefully chosen words are *wrong* in fact.
I do not think so, but you are free to disagree.
> exploiting local bugs has nothing to do with having untrusted users in
> the age of client side exploits. due to your completely
> mischaracterized description, individual home users may very well feel
> that they do not need to upgrade, to the delight of the next malware
> owning their browser. you can congratulate yourself Greg, you
> successfully misled a whole class of users.
No, I do not believe this is true, for this bug, sorry. If you
disagree, please feel free to post such an exploit. Such a problem
would be a browser issue, and totally out of scope for a kernel issue.
> > then they need to rely on a company
> > to provide updates for them, and not be running their own kernels
> > because they really have no clue about system management.
>
> you conveniently failed to respond to the rest of my mail where i showed
> that Chris Wright, heck, even yourself did announce security fixes as such
> in the past. how do you explain that?
I am human and as such, word things differently at times. Based on crap
like this thread, and from discussions with Linus and others, trying to
classify such things as "security fixes" all the time isn't useful or
helpful.
Again, I still feel my original wording was sufficent. If you disagree,
feel free to start releasing your own kernels with whatever wording you
like. If people find them useful, perhaps they will use them instead of
the ones I do at times.
good luck,
greg k-h
page...@freemail.hu
> On Wed, Jul 16, 2008 at 05:43:15PM +0200, page...@freemail.hu wrote:
> > exploiting local bugs has nothing to do with having untrusted users in
> > the age of client side exploits. due to your completely
> > mischaracterized description, individual home users may very well feel
> > that they do not need to upgrade, to the delight of the next malware
> > owning their browser. you can congratulate yourself Greg, you
> > successfully misled a whole class of users.
>
> No, I do not believe this is true, for this bug, sorry.
what do you not believe in? that a task refcount leak can be exploited
for privilege elevation?
> If you disagree, please feel free to post such an exploit.
i never post exploits. however spender did write at least a proof-of-concept
that triggers it and proves that it's potentially exploitable. writing a
weaponized version takes a whole lot more effort than it's worth for us
(though i bet others have been working on it ever since if they didn't
already write one when the bug got introduced).
> Such a problem
> would be a browser issue, and totally out of scope for a kernel issue.
what i said was *not* specific to this bug at all, any local privilege
elevation bug can be used to, well, elevate privileges, regardless of
how one gets into a box. the browser example was just that, to highlight
that even single home user systems may very well be affected. sure, the
browser bug is not your problem, but the local privilege elevation due
to kernel bugs *is*. your wording was wrong, untrusted users are only
*one* potential kind of threat therefore if only such systems update,
many others will remain vulnerable.
> > > then they need to rely on a company
> > > to provide updates for them, and not be running their own kernels
> > > because they really have no clue about system management.
> >
> > you conveniently failed to respond to the rest of my mail where i showed
> > that Chris Wright, heck, even yourself did announce security fixes as such
> > in the past. how do you explain that?
>
> I am human and as such, word things differently at times. Based on crap
> like this thread, and from discussions with Linus and others, trying to
> classify such things as "security fixes" all the time isn't useful or
> helpful.
why isn't it useful? i've been asking every one of you who said so and
have yet to receive a reasonable justification. remember, your own
employers do it 'all the time', it must be useful to someone.
and what's with this 'all the time'? if you guys fix security bugs all
the time, then yes, you are expected to announce them all the time. if
you think that reflects badly on the quality of the kernel code, then
maybe you should think over your development process that results in
security fixes 'all the time'.
> Again, I still feel my original wording was sufficent. If you disagree,
> feel free to start releasing your own kernels with whatever wording you
> like. If people find them useful, perhaps they will use them instead of
> the ones I do at times.
if you are not qualified to do this job then don't do it. noone forced
you to accept this task. look at Chris Wright, he has no problems with
disclosing the security issues and he actually publicly pledged to do
his best to do so (and i hope he won't revert his position now).
cheers,
PaX Team
Theodore Tso
> if you are not qualified to do this job then don't do it. noone forced
> you to accept this task. look at Chris Wright, he has no problems with
> disclosing the security issues and he actually publicly pledged to do
> his best to do so (and i hope he won't revert his position now).
News flash: You have no right to tell someone what to do --- or not to
do.
All you can get to make decisions on is what you choose to do
yourself. If you want to compete with the very good job that Greg KH
is doing, please feel free to do so. Otherwise, please go away and
perhaps take some classes or do some meditating on how to work with
other people in a more constructive fashion.
- Ted
page...@freemail.hu
> On Wed, Jul 16, 2008 at 07:25:17PM +0200, page...@freemail.hu wrote:
> > if you are not qualified to do this job then don't do it. noone forced
> > you to accept this task. look at Chris Wright, he has no problems with
> > disclosing the security issues and he actually publicly pledged to do
> > his best to do so (and i hope he won't revert his position now).
>
> News flash: You have no right to tell someone what to do --- or not to
> do.
but you have the right to tell me what rights i have. very smart ;)
newsflash: try to parse the 'if... then' structure as not command
but conditional.
> All you can get to make decisions on is what you choose to do
> yourself. If you want to compete with the very good job that Greg KH
> is doing, please feel free to do so.
in a sense, i've been doing that for many years now, years before
-stable or even 2.6 was born. the result is in PaX, and unfortunately,
it's become quite a sizable chunk of it, fixing various problems in
linux.
> Otherwise, please go away and perhaps take some classes or do some
> meditating on how to work with other people in a more constructive
> fashion.
yes, learning manners on this list is really the best advice you can
give me. you mean, like this: http://lkml.org/lkml/2008/6/17/244 ?
Mike Galbraith
> > Again, I still feel my original wording was sufficent. If you disagree,
> > feel free to start releasing your own kernels with whatever wording you
> > like. If people find them useful, perhaps they will use them instead of
> > the ones I do at times.
>
> if you are not qualified to do this job then don't do it. noone forced
> you to accept this task. look at Chris Wright, he has no problems with
> disclosing the security issues and he actually publicly pledged to do
> his best to do so (and i hope he won't revert his position now).
That world is not going to comply with your every whim should be
perfectly clear by now. Please go spam some other list.
P.S. You have a shift key.
Phil Pell
cause my critical systems to crash = worse. Bugs that allow the Croatian mafia
to get credit cards in the names of 300,000 of my customers = catastrophic and
incredibly costly.
Anyone remember Maslow's hierarchy of human needs? It's kind of like that.
Let's fix all the bugs we can and give kudos to the people who do. Let's just
try to fix the worst ones first if at all possible.
Linus, I have nothing but the greatest respect for what you started and the
community caused to flourish. Yes, the security guys deserve kudos for fixing
the kinds of bugs the Microsoft hides. The folks that fix the bugs that cause
random, frustrating crashes deserve kudos too but in the long run they're never
going to be on CNN. If we wanted to be famous we'd date Britney Spears.
Warmest regards,
Phil Pell, PMP, CISSP, EIEIO
Chief Information Security Officer
Butler College
Rafael C. de Almeida
> On 15 Jul 2008 at 13:42, Linus Torvalds wrote:
>
>> On Tue, 15 Jul 2008, page...@freemail.hu wrote:
>>> i understand and i think noone expects that. in fact, i know how much
>>> expertise and time it takes to determine that. but what happens when
>>> you do figure out the security relevance of a bug during bug submission
>> The issue is that I think it's then _misleading_ to mark that kind of
>> commit specially, when I actually believe that it's in the minority.
>>
>> If people think that they are safer for only applying (or upgrading to)
>> certain patches that are marked as being security-specific, they are
>> missing all the ones that weren't marked as such.
>
> and how is that different from today's situation where they aren't told
> at all? in other words, they already learned to live with that risk. if
> you tell them about a security bug, they will build that knowledge into
> their risk assessment process (which is what security is all about in
> the end). anything you omit will skew their decision making process (in
> particular, expose them to exploits if they fail to apply a fix because
> they make a bad judgement call).
>
> in other words, you should not be worrying about people not learning about
> all security fixes, they already know it's not possible to provide such
> information. however sharing your knowledge that you do have will *help*
> them because 1. they can know for sure it's something important to apply
> (no need to use their limited human resources to make that judgement),
> 2. they can spend more of their resources on analyzing the *other* unmarked
> fixes. overall this can only improve everyone's security.
Hey, I have a crazy idea! What if they just mark all the bugs as a
security bug (after all they all kinda are for some definition of
security anyway)? That way people just apply all the patches and do not
have to analyze anything, therefore not wasting their limited human
resources at all!
Linus' point is exactly that they shouldn't be treated differently, so
you shouldn't allocate human resources to other bugs and just apply the
security ones. If you want to convince someone you must tell us *why*
those so-called security bugs are more important. Also, you need to tell
us what you consider to be a security bug. That's not clear to me at least.
> what you're afraid of is that people will take your 'we mark security
> fixes we learn about' as 'we mark ALL security fixes that are such'. well,
> make that very clear in a public document (Documentation/SecurityBugs is
> a good place) and that's it, people will know you're doing a best effort
> disclosure and not more.
>
> cheers,
> PaX Team
page...@freemail.hu
> page...@freemail.hu wrote:
> > in other words, you should not be worrying about people not learning about
> > all security fixes, they already know it's not possible to provide such
> > information. however sharing your knowledge that you do have will *help*
> > them because 1. they can know for sure it's something important to apply
> > (no need to use their limited human resources to make that judgement),
> > 2. they can spend more of their resources on analyzing the *other* unmarked
> > fixes. overall this can only improve everyone's security.
>
> Hey, I have a crazy idea! What if they just mark all the bugs as a
> security bug (after all they all kinda are for some definition of
> security anyway)? That way people just apply all the patches and do not
> have to analyze anything, therefore not wasting their limited human
> resources at all!
>
> Linus' point is exactly that they shouldn't be treated differently,
yet they already are, see below.
> so you shouldn't allocate human resources to other bugs and just apply the
> security ones. If you want to convince someone you must tell us *why*
> those so-called security bugs are more important.
look at what went into 2.6.25.11 for example. it's a security fix. you do
treat them differently: you include them in -stable to the exclusion of
many other 'less important' fixes. read Documentation/stable_kernel_rules.txt
for how you not treat all fixes as equal (it's not only security ones that
are special cased).
> Also, you need to tell
> us what you consider to be a security bug. That's not clear to me at least.
anything that breaks the kernel's security model. privilege elevation
always does.
Aidan Thornton
>
>
> 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
David Schwartz
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
da...@lang.hm
> 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
David Schwartz
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
Willy Tarreau
> 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
Tiago Assumpcao
>
> 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
Bernd Eckenfels
> 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.
The Security Comunity as a whole (especially the commercial service offices
who gat paied to make up new security leaks) is very good in finding,
tracking and classifying bugs. This together with the distributors works
very well for Linux users. What are you missing?
> 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.
Well, since most often the developers rely on the same source to be notified
about it, its not really a problem.
Gruss
Bernd