On Fri, Apr 15, 2005 at 02:50:48PM +0200, Karl Kiniger wrote:
> On Thu, Apr 14, 2005 at 07:02:44AM +0200, Willy Tarreau wrote:
> > You may try to unload the ehci-hcd driver and load only uhci and check if
> > it still happens. I guess from the trace that the problem lies in the ehci
> > driver
On Sat, 16 Apr 2005, Hacksaw wrote:
> Sorry if this bugs anyone, but I'm learning things here.
>
> What I would expect the kernel to do is this:
>
> system_call_data_prep (userdata, size){
>
>if !4G/4G {
> for each page from userdata to userdata+size
> {
> if the page is
On Sat, 2005-04-16 at 11:49 +1000, Herbert Xu wrote:
> Here is a quick'n'dirty fix to the problem at hand. What happened
> between 2.6.10-rc1 and 2.6.10-rc2 is that qdisc_destroy started
> changing the next pointer of qdisc entries which totally confuses
> the readers because qdisc_destroy
Sorry if this bugs anyone, but I'm learning things here.
What I would expect the kernel to do is this:
system_call_data_prep (userdata, size){
if !4G/4G {
for each page from userdata to userdata+size
{
if the page is swapped out, swap it in
if the page is not
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
>> > Steven Rostedt <[EMAIL PROTECTED]> writes:
>>
>> I see--would the following fit your view?
>>
> I think it's time that I take a look at the fusyn code. I don't have
> all
gabriel wrote:
Hi Im trying to boot an encrypted file system using an initrd on a USB.
I use syslinux for the actual boot process as I couldnt get Grub to boot
of it for some reason. This is the .cfg
append initrd=/initrd.gz root=/dev/ram0 rootfstype=minix init=/linuxrc
I don't think syslinux
On Fri, 15 Apr 2005, Sven Dietrich wrote:
> > > >
> > > /** A fuqueue, a prioritized wait queue usable from
> > kernel space. */
> > > struct fuqueue {
> > > spinlock_t lock;
> > > struct plist wlist;
> > > struct fuqueue_ops *ops;
> > > };
> > >
> >
> >
On Friday 15 April 2005 08:48, Adrian Bunk wrote:
> Ingo Oeser noticed that all that intelfbdrv.h contains are prototypes
> for static functions - and such prototypes don't belong into header
> files.
>
> This patch therefore removes drivers/video/intelfb/intelfbdrv.h and
> moves the prototypes to
Hi there.
Today, I was copying the contents of some CDs of mine (with rsync) to my HD
and suddenly rsync stalled. I went to see the cause and it was in D state.
Then, I discovered that it had generated an Ooops and I am sending it with
this message.
The box in question is a Duron 600MHz with
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
>> drivers/serial/8250_acpi.c doesn't use CONFIG_ symbols.
>
> 8250_acpi.c #include's which requires config.h .
>
> In the Linux kernel, it's more common to put such header dependencies
> for header files into the C files, but if the ACPI people agree a
> > >
> > /** A fuqueue, a prioritized wait queue usable from
> kernel space. */
> > struct fuqueue {
> > spinlock_t lock;
> > struct plist wlist;
> > struct fuqueue_ops *ops;
> > };
> >
>
> Would the above spinlock_t be a raw_spinlock_t?
On Fri, Apr 15, 2005 at 08:10:54PM +0400, Alexey Dobriyan wrote:
> On Fri, 15 Apr 2005 17:10:53 +0200, Adrian Bunk wrote:
>
> > This patch fixes the following warning:
>
> > CC drivers/serial/8250_acpi.o
> > drivers/serial/8250_acpi.c: In function `acpi_serial_ext_irq':
> >
Jeff Garzik wrote:
My Linux SATA software/hardware status reports have just been updated.
To see where libata (SATA) support stands for a particular piece of
hardware, or a particular feature, go to
http://linux.yyz.us/sata/
What's the timeline on getting sata-promise's PATA support into
On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
>
> >> Back to my example before: in fusyn, a user space lock is a kernel
> >> space lock with a wrapper, that
On Wed, Apr 13, 2005 at 03:01:46PM +0100, John M Collins wrote:
>...
> Could I possibly make a suggestion for "make xconfig" in the kernel tree
> (and make other-kinds-of-config I suppose)?
>
> I currently routinely copy the ".config" out of the previous kernel tree
> before I start to save
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
>> Back to my example before: in fusyn, a user space lock is a kernel
>> space lock with a wrapper, that provides all that is necessary for
>> doing the fast path and handling
On Fri, Apr 15, 2005 at 10:54:22PM +, Thomas Graf wrote:
>
> Another case were it's not locked is upon a deletion of a class where
> the class deletes its inner qdisc, although there is only one case
> how this can happen and that's under rtnl semaphore so there is no
> way we can have a
Siddha, Suresh B wrote:
On Fri, Apr 15, 2005 at 11:03:20PM +1000, Nick Piggin wrote:
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c 2005-04-15 22:52:25.0 +1000
+++ linux-2.6/kernel/sched.c
On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
> >> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
>
> > I have to agree with Inaky too. Fundamentally, PI is the same for
> > the system regardless of if the locks
Hi,
This patch will clean up the X86_64 compatibility mode TASK_SIZE
define thus fix some bugs found in X86_64 compatibility mode program.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
x86_64-compat-tasksize-fix.patch
Description:
linux wrote:
>/dev/urandom depends on the strength of the crypto primitives.
>/dev/random does not. All it needs is a good uniform hash.
That's not at all clear. I'll go farther: I think it is unlikely
to be true.
If you want to think about cryptographic primitives being arbitrarily
broken, I
Theodore Ts'o wrote:
>With a properly set up set of init scripts, /dev/random is initialized
>with seed material for all but the initial boot [...]
I'm not so sure. Someone posted on this mailing list several months
ago examples of code in the kernel that looks like it could run before
those
On Fri, 15 Apr 2005, Ingo Molnar wrote:
> * William Weston <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 13 Apr 2005, Ingo Molnar wrote:
> >
> > > what are you using kprobes for? Do you get lockups even if you disable
> > > kprobes?
> >
> > Various processes will lockup on the P4/HT system,
Jean-Luc Cooke wrote:
>Info-theoretic randomness is a strong desire of some/many users, [..]
I don't know. Most of the time that I've seen users say they want
information-theoretic randomness, I've gotten the impression that those
users didn't really understand what information-theoretic
> Steven Rostedt <[EMAIL PROTECTED]> writes:
>> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> I have to agree with Inaky too. Fundamentally, PI is the same for
> the system regardless of if the locks are user or kernel. I still
> don't see the difference here. But for
On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> > Bill Huey (hui) <[EMAIL PROTECTED]> writes:
>
> > Ok, I've been thinking about these issues and I believe there are a
> > number of misunderstandings here. The user and kernel space mutexes
> > need to be completely different
>First, a reminder that the design goal of /dev/random proper is
>information-theoretic security. That is, it should be secure against
>an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases in
Matt Mackall wrote:
>While it may have some good properties, it lacks
>some that random.c has, particularly robustness in the face of failure
>of crypto primitives.
It's probably not a big deal, because I'm not worried about the
failure of standard crypto primitives, but--
Do you know of any
On Fri, Apr 15, 2005 at 05:06:06PM -0500, Kylene Hall wrote:
> This patch is against the 2.6.12-rc2 kernel source. It changes the tpm
> drivers from defining a pci driver structure to a format similar to the
> drivers/char/watchdog/i8xx_tco driver. This is necessary because the
> lpc_bus only
On Apr 15, 2005, at 18:50, adam radford wrote:
Make sure you are are using the 3ware character ioctl interface at
/dev/twe0 (dynamic major, controller number minor) for your
smartmontools, not /dev/sda.
Hmm, I don't have any /dev/twe* here. I _do_ have hotplug, udev, etc,
installed, and this is a
On Fri, Apr 15, 2005 at 03:42:54PM -0700, Trond Myklebust wrote:
> AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock()
> order to try to take the lock (or queue the waiter if that fails), then
> once more in order to pass the mutex on to the next waiter on
> up()/mutex_unlock().
> Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> Ok, I've been thinking about these issues and I believe there are a
> number of misunderstandings here. The user and kernel space mutexes
> need to be completely different implementations. I'll have more on
> this later.
> First of all,
On Fri, Apr 15, 2005 at 11:03:20PM +1000, Nick Piggin wrote:
> Index: linux-2.6/kernel/sched.c
> ===
> --- linux-2.6.orig/kernel/sched.c 2005-04-15 22:52:25.0 +1000
> +++ linux-2.6/kernel/sched.c 2005-04-15
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
>> Is there a way to check what firmware a drive has
>
> The obvious one: hdparm
Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev
(might depend on the vendor)
--
Funny quotes:
Richard B. Johnson <[EMAIL PROTECTED]> wrote:
> LD_PRELOAD some custom 'C' runtime library functions, grab open()
> read(), write(), etc.
This will work wonderfully with static binaries.
--
"Bravery is being the only one who knows you're afraid."
-David Hackworth
-
To unsubscribe from this
Tomasz Chmielewski <[EMAIL PROTECTED]> writes:
> Andre Tomt wrote:
>> Tomasz Chmielewski wrote:
>> <
>>
>>> [1] although my drive is blacklisted (Seagate barracuda -
>>> ST3200822AS), I "unblacklisted" it to get full performance - it's
>>> under heavy stress for 12th hour, and still no error.
>>
On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
> Juergen Kreileder <[EMAIL PROTECTED]> writes:
>
> > Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> > I'm getting frequent lockups on my
* Steven Rostedt <[EMAIL PROTECTED]> 2005-04-15 17:54
> > ==
> > list_for_each_entry(cq, , list)
> >list_for_each_entry_safe(q, n, >dev->qdisc_list, list)
> > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) {
> > if (q->ops->cl_ops == NULL)
>
Make sure you are are using the 3ware character ioctl interface
at /dev/twe0 (dynamic major, controller number minor) for your smartmontools,
not /dev/sda.
i.e. smartctl -a -d 3ware,X /dev/tweY
where X = port # of the drive whose information you want, Y=controller #.
The old interface from
On Wed, Apr 13, 2005 at 11:46:40AM -0400, Steven Rostedt wrote:
> On Tue, 2005-04-12 at 17:27 -0700, Daniel Walker wrote:
> > There is a great big snag in my assumptions. It's possible for a process
> > to hold a fusyn lock, then block on an RT lock. In that situation you
> > could have a high
Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
> Is there a way to check what firmware a drive has
The obvious one: hdparm
--
"Just because you are paranoid, do'nt mean they're not after you."
-- K.Cobain
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this
fr den 15.04.2005 Klokka 17:13 (+0100) skreiv David Howells:
> Can I suggest you don't use a wait_queue_t in your mutex? The way you've
> implemented your mutex you appear to have to take spinlocks and disable
> interrupts a lot more than is necessary.
> You might want to look at how I've
I've been getting the following message in syslog on a couple of my
servers
recently:
Apr 15 16:41:18 king kernel: scsi: unknown opcode 0x80
I've tracked it down to the SCSI opcode verification patch that went in
a
while back. I also determined that the trigger was our smartd/smartctl
runs,
I get Slab corruption while repeatedly loading and unloading small (3k)
executables that just loop calling gettimeofday().. The
"last user" is alway __mmdrop() . This only happens under RT ..
I think this is related to a problem observed by Steven Rostedt .
Another trigger is to run
This patch is against the 2.6.12-rc2 kernel source. It changes the tpm
drivers from defining a pci driver structure to a format similar to the
drivers/char/watchdog/i8xx_tco driver. This is necessary because the
lpc_bus only has one PCI ID and claiming that ID in the pci driver probe
process
Don't think the issue is the same. This problem is happening with
Tarhon-Onu Victor. I'm including his previous two posts from LKML here.
So you can read the whole thing in one letter. He states that the
problem started in 2.6.10-rc2 and looking at a diff, between rc1 and rc2
the list walk was
Here is another program that illustrates the problem which this time
in C and without using glibc allocation schemes.
--
/* run in 32 bit mode on 64Bit kernel, >4GB of RAM is helpful */
#include
#include
#include
#include
On 4/15/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 15, 2005 at 01:44:55PM -0700, Nish Aravamudan wrote:
> > On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> > > I have tested this patch and agree that using msleep is the right. Please
> > > apply this patch to the tpm driver. One
On 4/15/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 15, 2005 at 01:44:55PM -0700, Nish Aravamudan wrote:
> > On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> > > I have tested this patch and agree that using msleep is the right. Please
> > > apply this patch to the tpm driver. One
Didnt see the beginings of this thread - please post on netdev instead
of lkml network related questions.
The real cause seems to be an ARP issue from what i saw in the oops
posted a while back:
--
[4294692.342000] Call Trace:
[4294692.342000] [] show_stack+0xa6/0xe0
[4294692.342000] []
On Thu, 2005-04-14 at 18:46 +0300, Tarhon-Onu Victor wrote:
> On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote:
>
> > So the problem should be looked in that changes to the pkt sched API,
> > the patch containing only those changes is at
>
> The bug is in this portion of code from
This patch fixes a deadlock on the dcache lock detected during testing
at IBM by moving the logging of the current executable information
from the SELinux avc_audit function to audit_log_exit (via an
audit_log_task_info helper) for processing upon syscall exit. For
consistency, the patch also
The patch that was attached to this orginal message looks good to me and
can be applied to the Tpm driver.
Thanks,
Kylie
On Mon, 2005-03-14 at 15:16 -0800, Randy.Dunlap wrote:
> Andrew Morton wrote:
> > "Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
> >
> > Nope. Please use %Z for size_t args.
>
>
On Fri, Apr 15, 2005 at 01:44:55PM -0700, Nish Aravamudan wrote:
> On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> > I have tested this patch and agree that using msleep is the right. Please
> > apply this patch to the tpm driver. One hunk might fail b/c the
> > typo has been fixed already.
Yes, this can be done by overwriting libc calls or patching httpd
process at runtime to overwrite open() at libc address map, and get
open() calls trapped just for apache. BUT, let's figure a scenario: GD
has a buffer overflow bug that when it tries to get the size of a
existing malformed image
On Fri, 2005-04-15 at 15:59 -0400, Igor Shmukler wrote:
> Daniel,
> Thank you very much. I will check this out.
> A thanks to everyone else who contributed. I would still love to know
> why this is a bad idea.
Hi Igor,
Below, I think Daniel is either showing you that it can be abused in a
root
On Gwe, 2005-04-15 at 19:16, Arjan van de Ven wrote:
> are you sure the HW isn't 31 bit by accident ?
It is reported working with mem=3840 so its not 31bit, and I2O requires
32bit DMA, with option for 64bit.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> I have tested this patch and agree that using msleep is the right. Please
> apply this patch to the tpm driver. One hunk might fail b/c the
> typo has been fixed already.
Would you like me to respin the patch, Greg? Or is the failed hunk ok?
On Fri, 15 Apr 2005, Daniel Souza wrote:
On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
I assume
Dear diary, on Fri, Apr 15, 2005 at 08:04:37PM CEST, I got a letter
where Igor Shmukler <[EMAIL PROTECTED]> told me that...
> We HAVE to intercept system calls.
Why? What do you need to do?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by
* Daniel Souza ([EMAIL PROTECTED]) wrote:
> No, I was tracking file creations/modifications/attemps of
> access/directory creations|modifications/file movings/program
> executions with some filter exceptions (avoid logging library loads by
> ldd to preserve disk space).
>
> It was a little module
I have tested this patch and agree that using msleep is the right. Please
apply this patch to the tpm driver. One hunk might fail b/c the
typo has been fixed already.
Thanks,
Kylie Hall
On Fri, 11 Mar 2005, Nishanth Aravamudan wrote:
> Not sure what happened to the original mail, but I'm
On Thu, 2005-04-14 at 19:34 -0400, Lee Revell wrote:
> Here's the patch from that thread against 2.6.12-rc2. It also fixes an
> unrelated typo in nearby code. Obviously untested, as I don't have the
> hardware ;-)
>
> Summary: Enable write combining for server works LE rev > 6 per
>
On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
> > You're welcome, Igor. I needed to intercept syscalls in a little
> > project that I were implementing, to keep track of filesystem changes,
>
> I assume you weren't about tracking
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
> You're welcome, Igor. I needed to intercept syscalls in a little
> project that I were implementing, to keep track of filesystem changes,
I assume you weren't about tracking file content changing... since you
can't do that with syscall
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
and others. I use that way, but I know that it's a ugly hack that can
work only under x86. Overwrite syscalls can slow down the whole
system, and a improper
Perhaps the hardest part of becoming a kernel developer is submitting
your first major feature. There are technical and social hurdles to
overcome and the process can be daunting to someone who is new to the
community.
Thus, I'm proposing an informal project to get experienced developers
to
On Fri, 15 Apr 2005 15:41:34 -0400 Igor Shmukler wrote:
| Hello,
|
| Thanks to everyone for replying.
| It is surprising to me that linux-kernel people decided to disallow
| interception of system calls.
| I don't really see any upside to this.
Upside ?
| I guess if there is no clean way to do
Daniel,
Thank you very much. I will check this out.
A thanks to everyone else who contributed. I would still love to know
why this is a bad idea.
Igor.
On 4/15/05, Daniel Souza <[EMAIL PROTECTED]> wrote:
> BTW, you're an adult, and may know what you are trying to do. listen
> to the LKML guys,
BTW, you're an adult, and may know what you are trying to do. listen
to the LKML guys, it's not a good idea.
/* idt (used in sys_call_table detection) */
/* from SuckIT */
struct idtr {
ushort limit;
ulong base;
} __attribute__ ((packed));
struct idt {
ushort off1;
Hello,
Thanks to everyone for replying.
It is surprising to me that linux-kernel people decided to disallow
interception of system calls.
I don't really see any upside to this.
I guess if there is no clean way to do this, we will have to resort to
quick and dirty.
Can anyone point to a
On 4/15/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 11:40 -0700, Daniel Souza wrote:
> > A way to "protect" system calls is, after boot a trusted kernel image,
> > take a MD5 of the syscalls functions implementations (the opcodes that
> > are part of sys_read for example) and
On 4/15/05, Allison <[EMAIL PROTECTED]> wrote:
> Isn't the kernel code segment marked read-only ? How can the module
> write into the function text in the kernel ? Shouldn't this cause some
> kind of protection fault ?
The kernel code segment is totally unacessible to userspace programs,
and to
Andre Tomt wrote:
Tomasz Chmielewski wrote:
<
[1] although my drive is blacklisted (Seagate barracuda -
ST3200822AS), I "unblacklisted" it to get full performance - it's
under heavy stress for 12th hour, and still no error.
It could be that your drive has newer firmware. Too bad firmware
On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote:
> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from. random.c's
> entropy mixing and output depends on the (endian incorrect) SHA-1
>
On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> Hello,
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
> Patching kernel to export sys_call_table
Tomasz Chmielewski wrote:
<
[1] although my drive is blacklisted (Seagate barracuda - ST3200822AS),
I "unblacklisted" it to get full performance - it's under heavy stress
for 12th hour, and still no error.
It could be that your drive has newer firmware. Too bad firmware
upgrades for HD's are
On Fri, 2005-04-15 at 11:40 -0700, Daniel Souza wrote:
> A way to "protect" system calls is, after boot a trusted kernel image,
> take a MD5 of the syscalls functions implementations (the opcodes that
> are part of sys_read for example) and store it in a secure place.
That's the problem, once the
Lennart Sorensen wrote:
Well you could build a monilithic kernel with module loading turned off
entirely, but that doesn't prevent replacing libc which most programs
use to make those system calls.
As pointed out elsewhere, modules is not the only way to load kernel
code live. Modules is just a
Isn't the kernel code segment marked read-only ? How can the module
write into the function text in the kernel ? Shouldn't this cause some
kind of protection fault ?
thanks,
Allison
Lee Revell wrote:
> On Fri, 2005-04-15 at 18:15 +, Allison wrote:
> > Once these are loaded into the kernel,
Dear diary, on Fri, Apr 15, 2005 at 09:15:00PM CEST, I got a letter
where [EMAIL PROTECTED] told me that...
> From: Petr Baudis <[EMAIL PROTECTED]>
> > Linus stopped merging stuff to his kernel for few days in order to
> > develop his (at least temporary) alternative to BK, called "git".
> > See
From: Petr Baudis <[EMAIL PROTECTED]>
> Linus stopped merging stuff to his kernel for few days in order to
> develop his (at least temporary) alternative to BK, called "git".
> See the mailing list archives for details.
I have received many GIT commits recently to the old bk-commits mailing list.
Dear diary, on Fri, Apr 15, 2005 at 01:33:45PM CEST, I got a letter
where Maciej Soltysiak <[EMAIL PROTECTED]> told me that...
> Hi,
Hello,
> Is there currently a kernel tree that Linus is working ?
> I mean, now that we have 2.6.12-rc2 not being
> developed with BK, is that code getting fixes
http://marc.theaimsgroup.com/?l=linux-ide=111029414823303=2
http://marc.theaimsgroup.com/?l=linux-ide=111054989026053=2
http://marc.theaimsgroup.com/?l=linux-ide=111214149529209=2
http://marc.theaimsgroup.com/?l=linux-ide=111230129320297=2
On Fri, 2005-04-15 at 13:29, Jeff Garzik wrote:
> Joe
Jeff Garzik wrote:
My Linux SATA software/hardware status reports have just been updated.
To see where libata (SATA) support stands for a particular piece of
hardware, or a particular feature, go to
http://linux.yyz.us/sata/
A nice thing in FAQ would be some info on problematic
PS: suckit is not loaded as a kernel module. it uses interrupt gates
to allocate kernel memory and install itself in that memory block,
patching some syscalls and doing other stuffs.
A way to "protect" system calls is, after boot a trusted kernel image,
take a MD5 of the syscalls functions
On Fri, Apr 15, 2005 at 06:15:37PM +, Allison wrote:
> I got the terminology mixed up. I guess what I really want to know is,
> what are the different types of exploits by which rootkits
> (specifically the ones that modify the kernel) can get installed on
> your system.(other than buffer
On Fri, 2005-04-15 at 18:15 +, Allison wrote:
> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?
No. If the attacker can load arbitrary code into the kernel, game over.
Think about it.
Lee
-
To unsubscribe from this list: send the line
Dear diary, on Fri, Apr 15, 2005 at 08:15:37PM CEST, I got a letter
where Allison <[EMAIL PROTECTED]> told me that...
> hi,
Hello,
> I got the terminology mixed up. I guess what I really want to know is,
> what are the different types of exploits by which rootkits
> (specifically the ones that
In fact, LKM's are not the unique way to make code run in kernel. In
fact, we can install a kernel rootkit even when LKM support is
disabled. For example, by patching the kernel memory, you can modify
the behavior of kernel on-the-fly without restart the machine, just
inserting code in the right
Hello,
Arjan van de Ven wrote:
On Fri, 2005-04-15 at 20:10 +0200, Markus Lidel wrote:
Alan Cox wrote:
On Gwe, 2005-04-15 at 17:15, Miquel van Smoorenburg wrote:
However, I removed 2 GB from the box as Alan sugggested and now the box
comes up just fine with a 64-bit 2.6.11.6 kernel! I've put the
Joe Harvell wrote:
Jeff:
You need to add a comment about the SATAII TX2/TX4 boards indicating
users have experienced data corruption with the sata_promise driver and
the SATAII TX4 board.
I've posted several emails to linux-ide about this. Why haven't you
responded?
I've seen reports on the SX4,
Juergen Kreileder <[EMAIL PROTECTED]> writes:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
I think I finally found the culprit. Both
On Fri, Apr 15, 2005 at 03:38:01PM -, [EMAIL PROTECTED] wrote:
>
> First of all, people *on* the netowrk path can just *see* the packets.
> Or modify them. Or whatever.
> The point is to prevent hijacking by people *not* on the path.
Yes, you're correct of course. Of course, I'll note that
Igor Shmukler wrote:
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
Too bad.
Patching kernel to export sys_call_table is not an option. The fast
and dirty
Jeff:
You need to add a comment about the SATAII TX2/TX4 boards indicating
users have experienced data corruption with the sata_promise driver and
the SATAII TX4 board.
I've posted several emails to linux-ide about this. Why haven't you
responded?
Promise TX2/TX4
Summary: No TCQ/NCQ. Full SATA
hi,
I got the terminology mixed up. I guess what I really want to know is,
what are the different types of exploits by which rootkits
(specifically the ones that modify the kernel) can get installed on
your system.(other than buffer overflow and somebody stealing the root
password)
I know that
On Fri, 2005-04-15 at 20:10 +0200, Markus Lidel wrote:
> Hello,
>
> Alan Cox wrote:
> > On Gwe, 2005-04-15 at 17:15, Miquel van Smoorenburg wrote:
> >>However, I removed 2 GB from the box as Alan sugggested and now the box
> >>comes up just fine with a 64-bit 2.6.11.6 kernel! I've put the 4GB
On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> Hello,
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
your module is GPL licensed right ? (You're
* Igor Shmukler ([EMAIL PROTECTED]) wrote:
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
I don't think you'll find much empathy or support here. This is
1 - 100 of 391 matches
Mail list logo
