twitter: linux.kernel - 25 new messages in 18 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

==============================================================================
TOPIC: atarilance: timeout ignored in lance_open()
http://groups.google.com/group/linux.kernel/t/29320d9575029de5?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:10 am
From: Roel Kluin

Op 27-12-09 14:28, Roel Kluin schreef:
> With `while (--limit > 0)' i reaches 0 after the loop, so upon timeout the
> error was not returned.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> diff --git a/drivers/net/niu.c b/drivers/net/niu.c

Oops, forgot to update the subject, please ignore, I'll send another.

Roel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: lvds downclocking breaks on G45/thinkpad T500
http://groups.google.com/group/linux.kernel/t/08f948a2aa45284c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:20 am
From: Andres Freund

On Sunday 27 December 2009 14:10:55 ykzhao wrote:
> On Sun, 2009-12-27 at 01:41 +0800, Andres Freund wrote:
> > On Saturday 26 December 2009 17:49:29 Andres Freund wrote:
> > > On 2.6.33-rc1 I noticed that the display of my T500 with a G45 reacts
> > > very slowly (you can see the text appearing) and colors take a time to
> > > "solidify". I.e. making a white terminal black takes some seconds. ...
> > > Anything I can do to help analyzing the issue?
> >
> > Thats with recent git checkouts of xorg btw, if thats relevant (which I
> > doubt a bit).
> >
> > The missing config is attached now as well.
>
> It will be great if you can open a new bug on
> bugs.freedesktop.org(Product=xorg, component = driver/intel) and attach
> the following info:
> 1. add the boot option of "drm.debug=0x06" and attach the output of
> dmesg.
> 2. attach the output of "xrandr -q --verbose"
> 3. attach the vbios.dump, which can be obtained by using the
> following command:
> echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
> cat /sys/devices/pci0000:00/0000:00:02.0/rom
> 4. attach the output of Xorg.0.log
Is it relevant whether I boot a kernel with the patch really enabled?

Andres
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [RFC] Asynchronous suspend/resume - test results
http://groups.google.com/group/linux.kernel/t/837a4c71102b1527?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:20 am
From: "Rafael J. Wysocki"

On Saturday 26 December 2009, Nigel Cunningham wrote:
> Hi.
>
> Rafael J. Wysocki wrote:
> > Yes, it did. Please compare these lines:
> >
> > (from the "sync" dmesg):
> > [ 31.640676] PM: freeze of devices complete after 709.277 msecs
> > [ 37.087548] PM: restore of devices complete after 4973.508 msecs
> >
> > (from the "async" dmesg):
> > [ 25.600067] PM: freeze of devices complete after 620.429 msecs
> > [ 29.195366] PM: restore of devices complete after 3057.982 msecs
> >
> > So clearly, there's a difference. :-)
>
> Oh okay.
>
> It still feels like a long time. How do I find out which device took the
> longest? It looks to me like the patch is only recording when things
> start their restore, not when they finish.

First, you need to boot with initcall_debug in the kernel command line.

Then, after a hibernate-resume cycle do something like this:

$ dmesg | grep "call .* returned " | awk '{print $8 "\t" $4;}' | sort -nr

That will give you both the suspend and resume times for all devices,
sorted in the decreasing order.

If you want to separate suspend times from resume times, you generally need
to save the dmesg output and cut everything except for the interesting part
(eg. device suspend) from it. Then you'll get the times by running the above
command.

> > Of course, in terms of total hibernate/restore time this is only a little
> > improvement, but if that was suspend to RAM and resume, the reduction of
> > the device resume time by almost 2 s would be a big deal.
> >
> >> I'll see if I can find the time to do the other computers, then.
> >
> > I'd appreciate that very much.
>
> I'm not sure I'll find the time now - it's Sunday morning here and we
> still have packing and so on to do after I take this morning's service.
>
> Sorry!

No problem at all. :-)

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: pointless assignments
http://groups.google.com/group/linux.kernel/t/cc261b82999b3c76?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:20 am
From: Boaz Harrosh

On 12/27/2009 03:41 PM, Dan Carpenter wrote:
> drivers/scsi/osd/osd_initiator.c +1435 osd_finalize_request warning: assignment to 'ret' was never used

Thanks, very good catch. Humans 0 Robots 1 ;-)

I'll queue the below patch for next Kernel. (Such an unused code path no need
rocking the bote)

Boaz
---
From: Boaz Harrosh <bharrosh@panasas.com>
Date: Sun, 27 Dec 2009 16:06:47 +0200
Subject: [PATCH] libosd: Fix unchecked err return found by smatch

Doing CHECK="smatch --two-passes gives:
drivers/scsi/osd/osd_initiator.c +1435 osd_finalize_request warning: assignment to 'ret' was never used

Which is an unchecked possible allocation failure, Fixed.

Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
drivers/scsi/osd/osd_initiator.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index 2422347..9334431 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -1433,6 +1433,10 @@ int osd_finalize_request(struct osd_request *or,
cdbh->command_specific_options |= or->attributes_mode;
if (or->attributes_mode == OSD_CDB_GET_ATTR_PAGE_SET_ONE) {
ret = _osd_req_finalize_attr_page(or);
+ if (ret) {
+ OSD_DEBUG("_osd_req_finalize_set_attr_list failed\n");
+ return ret;
+ }
} else {
/* TODO: I think that for the GET_ATTR command these 2 should
* be reversed to keep them in execution order (for embeded
--
1.6.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Input: speed up suspend/shutdown for PS/2 mice and keyboards
http://groups.google.com/group/linux.kernel/t/4e2c28cab24ef192?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:30 am
From: Andreas Mohr

Hi,

On an ATI SB600 (RS690), no problems either on mouse/kbd after a S2R cycle,
on current git with this patch applied (verified).
And this with a rather problematic "new-fangled, designer (tm)"
Logitech Wireless Keyboard M/N Y-RR54 , P/N 867512-0102 (plus mouse!),
plugged into PS/2 connectors!

Thanks for your work!

Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: AlacrityVM guest drivers for 2.6.33
http://groups.google.com/group/linux.kernel/t/265f7bf4a9a1d92d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:40 am
From: Gregory Haskins

On 12/27/09 8:49 AM, Avi Kivity wrote:
> On 12/27/2009 03:34 PM, Gregory Haskins wrote:
>> On 12/27/09 4:33 AM, Avi Kivity wrote:
>>
>>> On 12/24/2009 11:36 AM, Gregory Haskins wrote:
>>>
>>>>> As a twist on this, the VMware paravirt driver interface is so
>>>>> hardware-like that they're getting hardware vendors to supply cards
>>>>> that
>>>>> implement it. Try that with a pure software approach.
>>>>>
>>>>>
>>>> Any hardware engineer (myself included) will tell you that, generally
>>>> speaking, what you can do in hardware you can do in software (think of
>>>> what QEMU does today, for instance). It's purely a cost/performance
>>>> tradeoff.
>>>>
>>>> I can at least tell you that is true of vbus. Anything on the vbus
>>>> side
>>>> would be equally eligible for a hardware implementation, though
>>>> there is
>>>> not reason to do this today since we have equivalent functionality in
>>>> baremetal already.
>>>>
>>> There's a huge difference in the probability of vmware getting cards to
>>> their spec, or x86 vendors improving interrupt delivery to guests,
>>> compared to vbus being implemented in hardware.
>>>
>> Thats not relevant, however. I said in the original quote that you
>> snipped that I made it a software design on purpose, and you tried to
>> somehow paint that as a negative because vmware made theirs
>> "hardware-like" and you implied it could not be done with my approach
>> with the statement "try that with a pure software approach". And the
>> bottom line is that the statement is incorrect and/or misleading.
>>
>
> It's not incorrect.

At the very best it's misleading.

> VMware stuck to the pci specs and as a result they
> can have hardware implement their virtual NIC protocol. For vbus this
> is much harder

Not really.

> to do since you need a side-channel between different
> cards to coordinate interrupt delivery. In theory you can do eveything
> if you don't consider practicalities.

pci based designs, such as vmware and virtio-pci arent free of this
notion either. They simply rely on APIC emulation for the irq-chip, and
it just so happens that vbus implements a different irq-chip (more
specifically, the connector that we employ between the guest and vbus
does). On one hand, you have the advantage of the guest already
supporting the irq-chip ABI, and on other other, you have an optimized
(e.g. shared memory based inject/ack) and feature enhanced ABI
(interrupt priority, no IDT constraints, etc). The are pros and cons to
either direction, but the vbus project charter is to go for maximum
performance and features, so that is acceptable to us.

>
> That's a digression, though, I'm not suggesting we'll see virtio
> hardware or that this is a virtio/pci advantage vs. vbus. It's an
> anecdote showing that sticking with specs has its advantages.

It also has distinct disadvantages. For instance, the PCI spec is
gigantic, yet almost none of it is needed to do the job here. When you
are talking full-virt, you are left with no choice. With para-virt, you
do have a choice, and the vbus-connector for AlacrityVM capitalizes on this.

As an example, think about all the work that went into emulating the PCI
chipset, the APIC chipset, MSI-X support, irq-routing, etc, when all you
needed was a simple event-queue to indicate that an event (e.g. an
"interrupt") occurred.

This is an example connector in vbus:

http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=kernel/vbus/connectors/null.c;h=b6d16cb68b7e49e07528278bc9f5b73e1dac0c2f;hb=HEAD

It encapsulates all of hotplug, signal (interrupt) routing, and memory
routing for both sides of the "link" in 584 lines of code. And that
also implicitly brings in device discovery and configuration since that
is covered by the vbus framework. Try doing that with PCI, especially
when you are not already under the qemu umbrella, and the "standards
based" approach suddenly doesn't look very attractive.

>
> wrt pci vs vbus, the difference is in the ability to use improvements in
> interrupt delivery accelerations in virt hardware.

Most of which will also apply to the current vbus design as well since
at some point I have to have an underlying IDT mechanism too, btw.

> If this happens,
> virtio/pci can immediately take advantage of it, while vbus has to stick
> with software delivery for backward compatibility, and all that code
> becomes a useless support burden.
>

The shared-memory path will always be the fastest anyway, so I am not
too worried about it. But vbus supports feature negotiation, so we can
always phase that out if need be, same as anything else.

> As an example of what hardware can do when it really sets its mind to
> it, s390 can IPI from vcpu to vcpu without exiting to the host.

Great! I am just not in the practice of waiting for hardware to cover
sloppy software. There is a ton of impracticality in doing so, such as
the fact that the hardware, even once available, will not be ubiquitous
instantly.

>
>>>> The only motiviation is if you wanted to preserve
>>>> ABI etc, which is what vmware is presumably after. However, I am not
>>>> advocating this as necessary at this juncture.
>>>>
>>>>
>>> Maybe AlacrityVM users don't care about compatibility, but my users do.
>>>
>> Again, not relevant to this thread. Making your interface
>> "hardware-like" buys you nothing in the end, as you ultimately need to
>> load drivers in the guest either way, and any major OS lets you extend
>> both devices and buses with relative ease. The only counter example
>> would be if you truly were "hardware-exactly" like e1000 emulation, but
>> we already know that this means it is hardware centric and not
>> "exit-rate aware" and would perform poorly. Otherwise "compatible" is
>> purely a point on the time line (for instance, the moment virtio-pci ABI
>> shipped), not an architectural description such as "hardware-like".
>>
>
> True, not related to the thread. But it is a problem.

Agreed. It is a distinct disadvantage to switching. Note that I am not
advocating that we need to switch. virtio-pci can coexist peacefully
from my perspective, and AlacrityVM does exactly this.

-Greg

==============================================================================
TOPIC: paride: test off by one
http://groups.google.com/group/linux.kernel/t/625de40aaaf20f80?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:50 am
From: Roel Kluin

With `while (j++ < PX_SPIN)' j reaches PX_SPIN + 1 after the loop. This is
probably unlikely to produce a problem.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
drivers/block/paride/pcd.c | 2 +-
drivers/block/paride/pf.c | 2 +-
drivers/block/paride/pt.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/paride/pcd.c b/drivers/block/paride/pcd.c
index 8866ca3..5b9b40b 100644
--- a/drivers/block/paride/pcd.c
+++ b/drivers/block/paride/pcd.c
@@ -341,7 +341,7 @@ static int pcd_wait(struct pcd_unit *cd, int go, int stop, char *fun, char *msg)
&& (j++ < PCD_SPIN))
udelay(PCD_DELAY);

- if ((r & (IDE_ERR & stop)) || (j >= PCD_SPIN)) {
+ if ((r & (IDE_ERR & stop)) || (j > PCD_SPIN)) {
s = read_reg(cd, 7);
e = read_reg(cd, 1);
p = read_reg(cd, 2);
diff --git a/drivers/block/paride/pf.c b/drivers/block/paride/pf.c
index ea54ea3..8418a36 100644
--- a/drivers/block/paride/pf.c
+++ b/drivers/block/paride/pf.c
@@ -391,7 +391,7 @@ static int pf_wait(struct pf_unit *pf, int go, int stop, char *fun, char *msg)
&& (j++ < PF_SPIN))
udelay(PF_SPIN_DEL);

- if ((r & (STAT_ERR & stop)) || (j >= PF_SPIN)) {
+ if ((r & (STAT_ERR & stop)) || (j > PF_SPIN)) {
s = read_reg(pf, 7);
e = read_reg(pf, 1);
p = read_reg(pf, 2);
diff --git a/drivers/block/paride/pt.c b/drivers/block/paride/pt.c
index 1e4006e..4fd99d9 100644
--- a/drivers/block/paride/pt.c
+++ b/drivers/block/paride/pt.c
@@ -274,7 +274,7 @@ static int pt_wait(struct pt_unit *tape, int go, int stop, char *fun, char *msg)
&& (j++ < PT_SPIN))
udelay(PT_SPIN_DEL);

- if ((r & (STAT_ERR & stop)) || (j >= PT_SPIN)) {
+ if ((r & (STAT_ERR & stop)) || (j > PT_SPIN)) {
s = read_reg(pi, 7);
e = read_reg(pi, 1);
p = read_reg(pi, 2);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: i2c: test off by one in {piix4,vt596}_transaction()
http://groups.google.com/group/linux.kernel/t/f48e3cfb2f21b1fb?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:50 am
From: Roel Kluin

With `while (timeout++ < MAX_TIMEOUT)' timeout reaches MAX_TIMEOUT + 1 after the loop
This is probably unlikely to produce a problem.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
drivers/i2c/busses/i2c-piix4.c | 2 +-
drivers/i2c/busses/i2c-viapro.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 1e245e9..d8e0df0 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -329,7 +329,7 @@ static int piix4_transaction(void)
msleep(1);

/* If the SMBus is still busy, we give up */
- if (timeout >= MAX_TIMEOUT) {
+ if (timeout > MAX_TIMEOUT) {
dev_err(&piix4_adapter.dev, "SMBus Timeout!\n");
result = -ETIMEDOUT;
}
diff --git a/drivers/i2c/busses/i2c-viapro.c b/drivers/i2c/busses/i2c-viapro.c
index e4b1543..8a2e0d5 100644
--- a/drivers/i2c/busses/i2c-viapro.c
+++ b/drivers/i2c/busses/i2c-viapro.c
@@ -168,7 +168,7 @@ static int vt596_transaction(u8 size)
} while ((temp & 0x01) && (timeout++ < MAX_TIMEOUT));

/* If the SMBus is still busy, we give up */
- if (timeout >= MAX_TIMEOUT) {
+ if (timeout > MAX_TIMEOUT) {
result = -ETIMEDOUT;
dev_err(&vt596_adapter.dev, "SMBus timeout!\n");
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: A basic question about the security_* hooks
http://groups.google.com/group/linux.kernel/t/860e4528087880f6?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 6:50 am
From: "Serge E. Hallyn"

Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
> On Sun, 27 Dec 2009 13:02:54 +0900, Tetsuo Handa said:
> > I believe TOMOYO can safely coexist with other security modules.
> > Why TOMOYO must not be used with SELinux or Smack or AppArmor?
> > What interference are you worrying when enabling TOMOYO with SELinux or Smack
> > or AppArmor?

...

> First, it's possible to totally screw up your box - consider 2 defective
> policies where each prevents a reload of the other's policy. Now note that it
> doesn't even need to be the *policy* - if the Tomoyo policy files get
> mislabeled with the wrong SELinux context, then an SELinux component will
> probably prevent access to the policy and thus prevent the load. Your system
> is now *at best* running SELinux-only (and now vulnerable to to any attacks you
> were depending on Tomoyo to stop). At worst, the wrecked Tomoyo policy will
> mean that Tomoyo will then reject the SELinux 'restorecon' command to correct
> the labels, leaving you in a situation where you can't recover your box.
>
> Second, it's unclear what a combo of two different MAC systems would *mean*,
> and whether it creates corner cases that can be exploited - the "two systems
> block each other's reloads" mentioned above is but one example. If a system that
> depends on inode labeling is active at the same time as a path-based system,
> what happens if you manage to do an 'mv' command that changes the security
> context in the path-based system while leaving the inode label the same, or
> relabel an inode without rename it to match? The file has just experienced
> a security transition for one system, but not the other. Are there any
> files and transitions where the mismatch matters?
>
> If the two systems load policies with the same semantics, why are you
> bothering? And if they load different semantics, can the difference be
> leveraged by an attacker?

Agree with everything Valdis said (including after this part, which I cut).

Why do you compose the two? I assume you went to the trouble because
you have a specific use case, a definite advantage?

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: RFC: disablenetwork facility. (v4)
http://groups.google.com/group/linux.kernel/t/b10d3d92ccc2351e?hl=en
==============================================================================

== 1 of 7 ==
Date: Sun, Dec 27 2009 7:00 am
From: "Serge E. Hallyn"

Quoting Tetsuo Handa (penguin-kernel@I-love.SAKURA.ne.jp):
> Pavel Machek wrote:
> > Syscalls are very wrong granularity for security system. But easy to
> > implement, see seccomp.
>
> Quoting from http://en.wikipedia.org/wiki/Seccomp
> > It allows a process to make a one-way transition into a "secure" state where
> > it cannot make any system calls except exit(), read() and write() to
> > already-open file descriptors.
>
> I think seccomp() is too much restricted to apply for general applications.
> Most applications will need some other syscalls in addition to exit(), read()
> and write(). Most applications cannot use seccomp().
>
> What I want to do is similar to seccomp(), but allows userland process to
> forbid some syscalls like execve(), mount(), chroot(), link(), unlink(),
> socket(), bind(), listen() etc. selectively.

The nice thing about the disablenetwork module is that (AFAICS so far)
it actually is safe for an unprivileged user to do. I can't think of
any setuid-root software which, if started with restricted-network by
an unprivileged user, would become unsafe rather than simply failing (*1).

Adding syscalls becomes much scarier.

-serge

*1 - Michael Stone, without looking back over the patches, do you also
restrict opening netlink sockets? Should we worry about preventing
an error message from being sent to the audit daemon?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 7 ==
Date: Sun, Dec 27 2009 7:50 am
From: Michael Stone

Serge Hallyn writes:

> Michael Stone, without looking back over the patches, do you also
> restrict opening netlink sockets?

The current version of the patch restricts netlink sockets which were not bound
to an address before calling disablenetwork(). It does so primarily on the
grounds of "fail safe", due to the following sorts of discussions and
observations:

http://kerneltrap.org/mailarchive/linux-kernel/2007/12/7/493793/thread
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5461
http://marc.info/?l=linux-kernel&m=125448727130301&w=2

I would be willing to entertain an argument that some kind of exemption for
AF_NETLINK ought to be introduced but I'd need to hear some more details before
I could implement it and before I could satisfy myself that the result was
sound.

> Should we worry about preventing an error message from being sent to the
> audit daemon?

I've considered the matter and I don't see much to worry about at this time.

The first reason why I'm not too worried is that anyone in a position to use
disablenetwork for nefarious purposes is also probably able to use ptrace(),
kill(), and/or LD_PRELOAD to similar ends.

The second reason why I'm not too worried is that I believe it to be
straightforward to use the pre-existing MAC frameworks to prevent individually
important processes from dropping networking privileges.

Do you have a specific concern in mind not addressed by either of these
observations?

Regards,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 7 ==
Date: Sun, Dec 27 2009 8:00 am
From: "Serge E. Hallyn"

Quoting Michael Stone (michael@laptop.org):
> Serge Hallyn writes:
>
>> Michael Stone, without looking back over the patches, do you also
>> restrict opening netlink sockets?
>
> The current version of the patch restricts netlink sockets which were not bound
> to an address before calling disablenetwork(). It does so primarily on the
> grounds of "fail safe", due to the following sorts of discussions and
> observations:
>
> http://kerneltrap.org/mailarchive/linux-kernel/2007/12/7/493793/thread
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5461
> http://marc.info/?l=linux-kernel&m=125448727130301&w=2
>
> I would be willing to entertain an argument that some kind of exemption for
> AF_NETLINK ought to be introduced but I'd need to hear some more details before
> I could implement it and before I could satisfy myself that the result was
> sound.
>
>> Should we worry about preventing an error message from being sent to the
>> audit daemon?
>
> I've considered the matter and I don't see much to worry about at this
> time.

I don't either, because I don't know of userspace programs other than
/bin/login (and I'm guessing at that) using netlink to send audit messages,
but I could be wrong, and there could be "important software" out there
that does so.

> The first reason why I'm not too worried is that anyone in a position to use
> disablenetwork for nefarious purposes is also probably able to use ptrace(),
> kill(), and/or LD_PRELOAD to similar ends.

How do you mean? I thought that disabling network was a completely
unprivileged operation? And subsequently executing a setuid-root
application won't reset the flag.

> The second reason why I'm not too worried is that I believe it to be
> straightforward to use the pre-existing MAC frameworks to prevent individually
> important processes from dropping networking privileges.
>
> Do you have a specific concern in mind not addressed by either of these
> observations?

Near as I can tell the worst one could do would be to prevent remote
admins from getting useful audit messages, which could give you unlimited
time to keep re-trying the server, on your quest to a brute-force attack
of some sort, i.e. restarting the server with random passwords, and now
no audit msg about the wrong password gets generated, so you're free to
exhaust the space of valid passwords.

Not saying I'm all that worried about it - just something that came to
mind.

== 4 of 7 ==
Date: Sun, Dec 27 2009 8:00 am
From: Michael Stone

Tetsuo Handa wrote:

> I expect that the future figure of this "disablenetwork" functionality
> becomes "disablesyscall" functionality.

Thanks for the suggestion, but I'm not interested in pursuing a generic
disablesyscall facility at this time.

== 5 of 7 ==
Date: Sun, Dec 27 2009 8:30 am
From: Michael Stone

Tetsuo Handa wrote:
> Michael Stone wrote:
>> +Exceptions are made for
>> + * processes calling sendmsg() on a previously connected socket
>> + (i.e. one with msg.msg_name == NULL && msg.msg_namelen == 0) or
>
> What should we do for non connection oriented protocols (e.g. UDP)
> but destination is already configured by previous connect() request?
>
> struct sockaddr_in addr = { ... };
> int fd2 = socket(PF_INET, SOCK_DGRAM, 0);
> connect(fd2, (struct sockadr *) &addr, sizeof(addr));
> prctl( ... );
> sendto(fd2, buffer, len, 0, NULL, 0); /* Should we allow this? */

This call should be allowed. man 2 send states that this call is equivalent to

send(fd2, buffer, len, 0)

and, since the flags field is 0, to

write(fd2, buffer, len)

which are both clearly permitted.

> sendto(fd2, buffer, len, 0, (struct sockadr *) &addr, sizeof(addr)); /* Should we reject this? */

It is reasonable to reject this call because it is not required to be
equivalent to a send() or write() call.

(In fact, the current UDP implementation unconditionally uses the addr argument
passed to sendmsg in favor of the socket addr whenever it exists.)

However, it might also be reasonable to permit the send when the call would be
equivalent to a permitted send() or write() call: for example, when the socket
destination address exists and matches the message destination address.

Unfortunately, I don't think that we have an appropriate generic address
comparison function for deciding this equivalence. Am I mistaken?

Regards, and thanks for your questions,

Michael

P.S. - I would be happy to include a brief explanatory comment in the code
defining this test since this is by far the most complex test in the patch. Any
suggestions on what it might say?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 6 of 7 ==
Date: Sun, Dec 27 2009 8:40 am
From: Michael Stone

Serge Hallyn writes:
> Michael Stone writes:
>> The first reason why I'm not too worried is that anyone in a position to use
>> disablenetwork for nefarious purposes is also probably able to use ptrace(),
>> kill(), and/or LD_PRELOAD to similar ends.
>
> How do you mean?

I meant that, with the current interface, to set disablenetwork for pid P, you
have either be pid P or to have been one of P's ancestors. In either case, you
have lots of opportunity to mess with P's environment.

> I thought that disabling network was a completely
> unprivileged operation? And subsequently executing a setuid-root
> application won't reset the flag.

Correct and correct for the current patches.

>> The second reason why I'm not too worried is that I believe it to be
>> straightforward to use the pre-existing MAC frameworks to prevent individually
>> important processes from dropping networking privileges.
>>
>> Do you have a specific concern in mind not addressed by either of these
>> observations?
>
> Near as I can tell the worst one could do would be to prevent remote
> admins from getting useful audit messages, which could give you unlimited
> time to keep re-trying the server, on your quest to a brute-force attack
> of some sort, i.e. restarting the server with random passwords, and now
> no audit msg about the wrong password gets generated, so you're free to
> exhaust the space of valid passwords.
>
> Not saying I'm all that worried about it - just something that came to
> mind.

I'll think about it further. Fortunately, there's no need to be hasty. :)

== 7 of 7 ==
Date: Sun, Dec 27 2009 10:10 am
From: Pavel Machek

> >I thought that disabling network was a completely
> >unprivileged operation? And subsequently executing a setuid-root
> >application won't reset the flag.
>
> Correct and correct for the current patches.

Then you are introducing a security problem. User can now mess with
setuid0 binary.

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Improve usability in case of init binary failure
http://groups.google.com/group/linux.kernel/t/c157159028a93457?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 7:10 am
From: Andreas Mohr

On Tue, Nov 17, 2009 at 09:40:16PM +0100, Andreas Mohr wrote:
> I'll submit a new version of this patch very soon.

Well, took quite a while longer, partly due to broken Broadcom USB host
(OpenWrt fix to be submitted) and non-working USB-audio on nicer platforms.

Took most of the comments into account (thanks!), improved some wording.

Patch against current git, compile- and runtime-tested,
checkpatch.pl'd (with a single nice hierarchy warning resulting from mixing
git diff output and manual /dev/null diffing).

Thanks!

Signed-off-by: Andreas Mohr <andi@lisas.de>

diff --git a/init/main.c b/init/main.c
index dac44a9..33748c6 100644
--- a/init/main.c
+++ b/init/main.c
@@ -836,7 +836,8 @@ static noinline int init_post(void)
run_init_process("/bin/init");
run_init_process("/bin/sh");

- panic("No init found. Try passing init= option to kernel.");
+ panic("No init found. Try passing init= option to kernel. "
+ "See Linux Documentation/init.txt for guidance.");
}

static int __init kernel_init(void * unused)
--- /dev/null 2009-12-27 16:25:29.521258205 +0100
+++ Documentation/init.txt 2009-12-27 15:47:46.000000000 +0100
@@ -0,0 +1,49 @@
+Explaining the dreaded "No init found." boot hang message
+=========================================================
+
+OK, so you've got this pretty unintuitive message (currently located
+in init/main.c) and are wondering what the H*** went wrong.
+Some high-level reasons for failure (listed roughly in order of execution)
+to load the init binary are:
+A) Unable to mount root FS
+B) init binary doesn't exist on rootfs
+C) broken console device
+D) binary exists but dependencies not available
+E) binary cannot be loaded
+
+Detailed explanations:
+0) Set "debug" kernel parameter (in bootloader config file or CONFIG_CMDLINE)
+ to get more detailed kernel messages.
+A) make sure you have the correct root FS type
+ (and root= kernel parameter points to the correct partition),
+ required drivers such as storage hardware (such as SCSI or USB!)
+ and filesystem (ext3, jffs2 etc.) are builtin (alternatively as modules,
+ to be pre-loaded by an initrd)
+C) Possibly a conflict in console= setup --> initial console unavailable.
+ E.g. some serial consoles are unreliable due to serial IRQ issues (e.g.
+ missing interrupt-based configuration).
+ Try using a different console= device or e.g. netconsole= .
+D) e.g. required library dependencies of the init binary such as
+ /lib/ld-linux.so.2 missing or broken. Use readelf -d <INIT>|grep NEEDED
+ to find out which libraries are required.
+E) make sure the binary's architecture matches your hardware.
+ E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM hardware.
+ In case you tried loading a non-binary file here (shell script?),
+ you should make sure that the script specifies an interpreter in its shebang
+ header line (#!/...) that is fully working (including its library
+ dependencies). And before tackling scripts, better first test a simple
+ non-script binary such as /bin/sh and confirm its successful execution.
+ To find out more, add code to init/main.c to display kernel_execve()s
+ return values.
+
+Please extend this explanation whenever you find new failure causes
+(after all loading the init binary is a CRITICAL and hard transition step
+which needs to be made as painless as possible), then submit patch to LKML.
+Further TODOs:
+- Implement the various run_init_process() invocations via a struct array
+ which can then store the kernel_execve() result value and on failure
+ log it all by iterating over _all_ results (very important usability fix).
+- try to make the implementation itself more helpful in general,
+ e.g. by providing additional error messages at affected places.
+
+Andreas Mohr <andi at lisas period de>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: parisc: test off by one in sgl_frem() and dbl_frem()
http://groups.google.com/group/linux.kernel/t/4eb7af21fb92c035?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Dec 27 2009 7:20 am
From: "John David Anglin"

> With `while (stepcount-- > 0)' stepcount reaches -1 after the loop.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> arch/parisc/math-emu/dfrem.c | 2 +-
> arch/parisc/math-emu/sfrem.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Unless I am missing something?

Are you sure the correct fix isn't to move the decrement of stepcount
into the loop?

Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Dec 27 2009 7:40 am
From: James Bottomley

On Sun, 2009-12-27 at 14:21 +0100, Roel Kluin wrote:
> With `while (stepcount-- > 0)' stepcount reaches -1 after the loop.

This is true, but seems to be by design

> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> arch/parisc/math-emu/dfrem.c | 2 +-
> arch/parisc/math-emu/sfrem.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Unless I am missing something?
>
> diff --git a/arch/parisc/math-emu/dfrem.c b/arch/parisc/math-emu/dfrem.c
> index b983785..3283445 100644
> --- a/arch/parisc/math-emu/dfrem.c
> +++ b/arch/parisc/math-emu/dfrem.c
> @@ -234,7 +234,7 @@ dbl_frem (dbl_floating_point * srcptr1, dbl_floating_point * srcptr2,
> Dbl_subtract(opnd1p1,opnd1p2,opnd2p1,opnd2p2,opnd1p1,opnd1p2);
> roundup = TRUE;
> }
> - if (stepcount > 0 || Dbl_iszero(opnd1p1,opnd1p2)) {
> + if (stepcount >= 0 || Dbl_iszero(opnd1p1,opnd1p2)) {
> /* division is exact, remainder is zero */
> Dbl_setzero_exponentmantissa(resultp1,resultp2);
> Dbl_copytoptr(resultp1,resultp2,dstptr);
> diff --git a/arch/parisc/math-emu/sfrem.c b/arch/parisc/math-emu/sfrem.c
> index 3a1b7a3..ad87832 100644
> --- a/arch/parisc/math-emu/sfrem.c
> +++ b/arch/parisc/math-emu/sfrem.c
> @@ -229,7 +229,7 @@ sgl_frem (sgl_floating_point * srcptr1, sgl_floating_point * srcptr2,
> Sgl_subtract(opnd1,opnd2,opnd1);
> roundup = TRUE;
> }
> - if (stepcount > 0 || Sgl_iszero(opnd1)) {
> + if (stepcount >= 0 || Sgl_iszero(opnd1)) {
> /* division is exact, remainder is zero */
> Sgl_setzero_exponentmantissa(result);
> *dstptr = result;

Your patch does nothing to the actual execution flow (Sgl_iszero is true
if stepcount == 0) ... what's the point of applying it?

James

==============================================================================
TOPIC: you have won 801,613.00 euro..
http://groups.google.com/group/linux.kernel/t/38c6d3821b89a839?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 7:20 am
From: "IL"

Hello,
you have won 801,613.00 euro from the Irish Christmas lottery. Call Monte
Fred now on phone: +447031953564 and send your
name,address,age,occupation,nationality,phone number etc to
fredmonte505@gmail.com so that he can help you make to arrangement
transfer your 801,613.00 euro to your bank account in your country.

Deniss Powell
P.R.O.
Irish Lottry

==============================================================================
TOPIC: agpgart-amd64 not initialized in 2.6.33-rc2
http://groups.google.com/group/linux.kernel/t/5587b32bf06d09f6?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 7:30 am
From: Marin Mitov

Hi all,

Recently (2.6.33-rc2 kernel, x86_64, 4GB RAM) I found (in dmesg):

[drm:mga_do_agp_dma_bootstrap] *ERROR* Unable to acquire AGP: -19

and there is no /dev/agpgart device on the machine while all is OK
if booting 2.6.32.2.

In both kernels I have:

CONFIG_AGP=y
CONFIG_AGP_AMD64=y

CONFIG_GART_IOMMU=y

but nevertheless dmesg shows:

PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

due to quirks in via K8T800Pro host bridge.

Looking for the reason I found that agp_amd64_init() appears in:

#ifndef CONFIG_GART_IOMMU
module_init(agp_amd64_init);
module_exit(agp_amd64_cleanup);

twitter

Sunday, December 27, 2009

linux.kernel - 25 new messages in 18 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts