headers
Alan Cox | 1 May 2007 01:04
Picon

Re: old buffer overflow in moxa driver

>   I noticed that the moxa input checking security bug described by
> CVE-2005-0504 appears to remain unfixed upstream.
>  
> The issue is described here:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504
> 
> Debian has been shipping the following patch from Andres Salomon. I
> tried contacting the listed maintainer a few months ago but received
> no response.

       case MOXA_LOAD_BIOS:
        case MOXA_FIND_BOARD:
        case MOXA_LOAD_C320B:
        case MOXA_LOAD_CODE:
                if (!capable(CAP_SYS_RAWIO))
                        return -EPERM;
                break;

At the point you abuse these calls you can already just load arbitary
data from userspace anyway.
Permalink | Reply | 6 comments |
headers
Rafael J. Wysocki | 1 May 2007 01:08
Picon
Gravatar

Re: Linux 2.6.21

On Monday, 30 April 2007 08:30, Andrew Morton wrote:
> On Mon, 30 Apr 2007 00:09:06 +0200 "Rafael J. Wysocki" <rjw <at> sisk.pl> wrote:
> 
> > On Sunday, 29 April 2007 22:52, Alexey Dobriyan wrote:
> > > On Sun, Apr 29, 2007 at 10:18:10PM +0200, Rafael J. Wysocki wrote:
> > > > [For example, you can create a bugzilla entry with a link to the lkml.org copy
> > > > of the relevant message, so why to require the reporter to file the report with
> > > > the bugzilla himself?]
> > > 
> > > Last time I did this, bugzilla at osdl.org won't let me add original
> > > reporter to goddamn CC list. It would be el neat, because not everyone
> > > followed instructions and forwarding emails between reporter and
> > > bugzilla sucks.
> > 
> > That's related to what I said before.  The requirement that the addresses on
> > the CC list must be 'known' to bugzilla is deadly wrong in every case I can
> > imagine.
> 
> But unknown-to-bugzilla email addresses are accepted when they're sent to
> bugme-daemon <at> kernel-bugs.osdl.org.  This is why I'll very often switch a
> bug report to email, copying individuals and mailing lists and
> bugme-daemon.  Then bugzilla just sits silently in the background recording
> everything.

If I wanted to do this, what would I have to do?  I mean, assume I have a bug
report that I want to send to someone whom the bugzilla doesn't like.
What's the right procedure in such a case?

> But once a bug has switched to email, it needs to stay there - it would be
> bad if someone were to update the bug via the web UI because none of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Uwe Bugla | 1 May 2007 01:05
Picon
Picon

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities


-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT)
Von: Trent Piepho <xyzzy <at> speakeasy.org>
An: Linus Torvalds <torvalds <at> linux-foundation.org>
CC: Linux Kernel Mailing list <linux-kernel <at> vger.kernel.org>, Michael Krufky
<mkrufky <at> linuxtv.org>, akpm <at> linux-foundation.org, Linux DVB <linux-dvb <at> linuxtv.org>
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities

> On Mon, 30 Apr 2007, Linus Torvalds wrote:
> > Anyway, I'll get out of the discussion. There's clearly some personality
> > issues in the DVB area, and I don't know quite _why_ that is, but Uwe,
> > you're definitely not helping.
> 
> There isn't a problem here, just a lot of noise coming from one source.  I
> have no problem with Mauro and think he does a good job and is an
> extremely
> reasonable person.  He is just getting Uwe's thesaurus thrown at him
> because he's the closest target.
> 
> Sure there are disagreements sometimes, but this is always the case.  I
> can
> think of plenty of lists far more full of flames and personality conflicts
> than linux-dvb.
> 
> The issue with dst is just a minor missing feature to fully support the
> dvb
> helper module customization system.  So nobody needs to worry about this
> anymore, the last two patches in this repository will fix it correctly.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Rechberger | 1 May 2007 01:08
Picon

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

On 5/1/07, Manu Abraham <abraham.manu <at> gmail.com> wrote:
> Trent Piepho wrote:
>
> > The issue with dst is just a minor missing feature to fully support the
> dvb
> > helper module customization system.  So nobody needs to worry about this
> > anymore, the last two patches in this repository will fix it correctly.
>
> With regards to the dst, i have explained earlier to you that
>
> 1) the dst is not a frontend
> 2) i do not wish to use the frontend attach methods with regards to
> dst/dst_ca
>
> To mention, we had these discussions much long back how to go about it
> and don't think that every time a new developer get's an account with
> linuxtv.org, this has to be a matter that has to discussed to death
>
> http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup
>
> (eventhough of not much concern) If you now see most of the code in
> dvb-bt8xx especially the DMA stuff was refactored from the dst driver.
>
> But that said, the dst *is* different, so WTH ?
>

Please show me where this change makes your work more difficult,
Trent's change is small and I don't see the problem where it seriously
affects your work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 May 2007 01:10
Picon
Gravatar

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

>
> A few easy and simple comments based on looking at this for 5 minutes:
>   - drop the typedefs.  Yeah, they might be a drm thing, but we don't
>     need them here.

Okay I think in-kernel typedefs have to go, but we have a defined DRM
interface like it or not and I'd like to be consistent on the
userspace interface and continue to use typedefs, I don't want to have
a major inconsistency like half the interface in typedefs the other
half in non-typedefs, considering the old interface is frozen...

>   - the comment style for the functions is "odd" and not in kerneldoc
>     form, but something else.  Either use kerneldoc or nothing, don't
>     invent something new please.

Most likely in doxygen as that is what Mesa uses and the intersection
of developers is higher in that area, I'll take it as a task to try
and kerneldoc the drm at some stage..

>   - what's with the /proc interface?  Don't add new proc code for
>     non-process related things.  This should all go into sysfs
>     somewhere.  And yes, I know /proc/dri/ is there today, but don't add
>     new stuff please.

Well we should move all that stuff to sysfs, but we have all the
infrastructure for publishing this stuff under /proc/dri and adding
new files doesn't take a major amount, as much as I appreciate sysfs,
it isn't suitable for this sort of information dump, the whole one
value per file is quite useless to provide this sort of information
which is uni-directional for users to send to us for debugging without
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric W. Biederman | 1 May 2007 01:10
Favicon

Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

Jeremy Fitzhardinge <jeremy <at> goop.org> writes:

> Eric W. Biederman wrote:
>>> I think I'd prefer to have the domain builder decompress/relocate the
>>> kernel from the bzImage and start it directly, rather than have it
>>> decompress/relocate itself, but I'm not really set on that.
>>>     
>>
>> We can change a lot more implementation details arbitrarily if you don't
>> know what needs to happen for decompression and relocation.
>
> Yes, and if it can be made to work, it ultimately means less work
> for me ;)

Now you are beginning to sound like a bootloader author.
Make it work and forget about it :)

>> We have to avoid the writes decompressor-prinnt routines 
>
> At worst, we could set up chunk of memory as a dummy framebuffer.  That
> might be useful for debugging anyway.

I'm trying to recall how we handle this on the LinuxBIOS side.
Because we have machines without a framebuffer setup.  Oh yeah,
we started in 32bit mode...

I do have some parameters to parse the command line in misc.c that
would accomplish this goal.

>> and
(Continue reading)

Permalink | Reply | 8 comments |
headers
Chris Friesen | 1 May 2007 01:15
Favicon

Re: SMB2 file system - should it be a distinct module

Steve French wrote:

> ...we need to decide whether the kernel
> implementation of SMB2 client should be a distinct module or just part
> of the cifs.ko module.

<snip>

> My guess is that less than 1/3 of the cifs module would overlap - but
> that overlap is enough that it would be easier to do smb2 as part of
> cifs (although it would make the cifs module somewhat larger).

What about pulling out the common code into a helper module, which can 
then be used by both cifs and smb2?

Chris
Permalink | Reply | 0 comments |
headers
H. Peter Anvin | 1 May 2007 01:16
Favicon

Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

Eric W. Biederman wrote:
> 
> I'm tempted to just reload the segments in setup.S, but that might
> break loadlin support or one of the other bootloaders that starts the
> kernel in 32bit mode so we need to be careful.
> 

We already load all the segments in setup.S.  I'm retaining this in my
rewrite.

Given that I'm rewriting the whole thing, if there are things you want
setup.S to do, now is the time to ask.

	-hpa
Permalink | Reply | 6 comments |
headers
hermann pitton | 1 May 2007 01:20
Picon
Favicon

Re: Re: Critical points about kernel 2.6.21 and pseudo-authorities

Am Dienstag, den 01.05.2007, 01:05 +0200 schrieb Uwe Bugla:
> -------- Original-Nachricht --------
> Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT)
> Von: Trent Piepho <xyzzy <at> speakeasy.org>
> An: Linus Torvalds <torvalds <at> linux-foundation.org>
> CC: Linux Kernel Mailing list <linux-kernel <at> vger.kernel.org>, Michael Krufky
<mkrufky <at> linuxtv.org>, akpm <at> linux-foundation.org, Linux DVB <linux-dvb <at> linuxtv.org>
> Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities
> 
> > On Mon, 30 Apr 2007, Linus Torvalds wrote:
> > > Anyway, I'll get out of the discussion. There's clearly some personality
> > > issues in the DVB area, and I don't know quite _why_ that is, but Uwe,
> > > you're definitely not helping.
> > 
> > There isn't a problem here, just a lot of noise coming from one source.  I
> > have no problem with Mauro and think he does a good job and is an
> > extremely
> > reasonable person.  He is just getting Uwe's thesaurus thrown at him
> > because he's the closest target.
> > 
> > Sure there are disagreements sometimes, but this is always the case.  I
> > can
> > think of plenty of lists far more full of flames and personality conflicts
> > than linux-dvb.
> > 
> > The issue with dst is just a minor missing feature to fully support the
> > dvb
> > helper module customization system.  So nobody needs to worry about this
> > anymore, the last two patches in this repository will fix it correctly.
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Hancock | 1 May 2007 01:20
Picon
Favicon

Re: [PATCH] support PCI MCFG space on Intel i915 bridges

Jesse Barnes wrote:
> On Sunday, April 29, 2007 7:10 pm Robert Hancock wrote:
>> Jesse Barnes wrote:
>>> Add support for Intel 915 bridge chips to the new PCI MMConfig
>>> detection code.  Tested and works on my sole 915 based platform (a
>>> Toshiba laptop).  I added register masking per Oliver's suggestion,
>>> and moved the __init qualifier to after the 'static const char' to
>>> match Ogawa-san's recent cleanup patches.
>>>
>>> Signed-off-by:  Jesse Barnes <jesse.barnes <at> intel.com>
>>>
>>> diff --git a/arch/i386/pci/mmconfig-shared.c
>>> b/arch/i386/pci/mmconfig-shared.c index 747d8c6..1339d31 100644
>>> --- a/arch/i386/pci/mmconfig-shared.c
>>> +++ b/arch/i386/pci/mmconfig-shared.c
>>>  <at>  <at>  -72,6 +72,26  <at>  <at>  static const char __init *pci_mmcfg_e7520(void)
>>>  	return "Intel Corporation E7520 Memory Controller Hub";
>>>  }
>>>
>>> +static const char __init *pci_mmcfg_intel_915(void)
>>> +{
>>> +       u32 pciexbar, len = 0;
>>> +
>>> +       pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0x48, 4, &pciexbar);
>>> +
>>> +       /* No enable bit or size field, so assume 256M range is
>>> enabled. */ +       len = 0x10000000U;
>> Check the 915 spec more carefully, there is an enable bit, it's in
>> the DEVEN register offset 54h, the bit is called PCIEXBAREN (bit 31).
>> If that is not set you should be setting pci_mmcfg_config_num to 0
(Continue reading)

Permalink | Reply | 2 comments |

Gmane