Re: security issue: hard disk lock
Hi Alan! Thanks for the info Am Montag 11. April 2005 17:36 schrieb Alan Cox: > It makes little difference as the attacker can replace the kernel and > reboot. > Anyway they can flash erase your video card bios, your IDE firmware, > your BIOS > and far more just as easily. Yes, but a new video-card or Motherboard can be easily bought (although it costs), but the data on a locked disk is lost forever, unless you pay for professional recovery (which is also a time-issue, if time critical data is stored on the disk). Of course, this can be solved with a good backup strategy... I agree with you though, that this really isn't a kernel issue, but a BIOS thing. Distributors should/could provide additional security by freezing the security-features early during boot, until BIOS vendors do their homework. regards, Jonas PS: Still not on the list, so please CC me in an eventual reply. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: security issue: hard disk lock
Hi Alan! Thanks for the info Am Montag 11. April 2005 17:36 schrieb Alan Cox: It makes little difference as the attacker can replace the kernel and reboot. Anyway they can flash erase your video card bios, your IDE firmware, your BIOS and far more just as easily. Yes, but a new video-card or Motherboard can be easily bought (although it costs), but the data on a locked disk is lost forever, unless you pay for professional recovery (which is also a time-issue, if time critical data is stored on the disk). Of course, this can be solved with a good backup strategy... I agree with you though, that this really isn't a kernel issue, but a BIOS thing. Distributors should/could provide additional security by freezing the security-features early during boot, until BIOS vendors do their homework. regards, Jonas PS: Still not on the list, so please CC me in an eventual reply. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: security issue: hard disk lock
Am Dienstag 05. April 2005 17:41 schrieb Vernon Mauery: > This makes sense because a particularly malicious > place to put something like this is a worm that attaches to your boot > loader. Then, even doing it in the kernel at boot time is too late. I understand... Didn't know that worms could attach to the bootloader :-) Well, then even fixing this in the bootloader would be too late, if the worm could simply replace the bootloader. I guess it's not a kernel-issue then and should really be addressed in the boot-up sequence (as long as BIOS vendors fail to fix it), be it with or without initrd. regards, Jonas PS: Still not in list, so please CC me on eventual replies. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: security issue: hard disk lock
Am Dienstag 05. April 2005 17:41 schrieb Vernon Mauery: This makes sense because a particularly malicious place to put something like this is a worm that attaches to your boot loader. Then, even doing it in the kernel at boot time is too late. I understand... Didn't know that worms could attach to the bootloader :-) Well, then even fixing this in the bootloader would be too late, if the worm could simply replace the bootloader. I guess it's not a kernel-issue then and should really be addressed in the boot-up sequence (as long as BIOS vendors fail to fix it), be it with or without initrd. regards, Jonas PS: Still not in list, so please CC me on eventual replies. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
security issue: hard disk lock
Hello! I don't know if you guys already know, there is a possible security risk with all modern desktop-pcs and ata hard drives. In short: Modern ata drives can be locked by password. This lock could be set by a malicous software. This security feature can be frozen, so no programs can set a lock until the next reboot. Ususally, the BIOS should take care of locking the security feature, but most desktop BIOSes (unlike laptop BIOSes) fail to do so. Once a lock is set and the password is unknown, the drive is trash. See http://www.heise.de/ct/english/05/08/172/ for more details. In the above article, a patched hdparm is used to freeze the drive's security features. This can be used during boot to prevent programs from setting a password. However, a malicous program could infect the computer and install itself in the boot sequence prior to the execution of hdparm... I figured there could be a kernel compiled-in option that will make the kernel lock all drives found during bootup. then, a malicous program would need to install a different kernel in order to harm the drive, which would be much more secure. What do you think of this? Regards, Jonas PS: Please CC me in replies, I am not subscribed to the list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
security issue: hard disk lock
Hello! I don't know if you guys already know, there is a possible security risk with all modern desktop-pcs and ata hard drives. In short: Modern ata drives can be locked by password. This lock could be set by a malicous software. This security feature can be frozen, so no programs can set a lock until the next reboot. Ususally, the BIOS should take care of locking the security feature, but most desktop BIOSes (unlike laptop BIOSes) fail to do so. Once a lock is set and the password is unknown, the drive is trash. See http://www.heise.de/ct/english/05/08/172/ for more details. In the above article, a patched hdparm is used to freeze the drive's security features. This can be used during boot to prevent programs from setting a password. However, a malicous program could infect the computer and install itself in the boot sequence prior to the execution of hdparm... I figured there could be a kernel compiled-in option that will make the kernel lock all drives found during bootup. then, a malicous program would need to install a different kernel in order to harm the drive, which would be much more secure. What do you think of this? Regards, Jonas PS: Please CC me in replies, I am not subscribed to the list. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA timer bugfix, patch for 2.4.5
Hi!
I have compiled a little patch that contains the VIA timer bugfix (from the ac
kernel). the patch is against linus' 2.4.5 kernel. I have compiled and ran the patched
kernel sucessfully.
the only changes made by this patch are done to linux/arch/i386/kernel/timer.c
I would like to have this patch applied to linus' kernel tree (so that it comes in
2.4.6), because alan's kernel has USB problems on my machine.
Here's the patch:
--- arch/i386/kernel/time.c.origSat Jun 2 16:06:59 2001
+++ arch/i386/kernel/time.c Sat Jun 2 16:07:20 2001
@@ -178,6 +178,15 @@
jiffies_t = jiffies;
count |= inb_p(0x40) << 8;
+
+/* VIA686a test code... reset the latch if count > max + 1 */
+if (count > LATCH) {
+outb_p(0x34, 0x43);
+outb_p(LATCH & 0xff, 0x40);
+outb(LATCH >> 8, 0x40);
+count = LATCH - 1;
+}
+
spin_unlock(_lock);
/*
@@ -413,7 +422,7 @@
if (!user_mode(regs))
x86_do_profile(regs->eip);
#else
- if (!smp_found_config)
+ if (!using_apic_timer)
smp_local_timer_interrupt(regs);
#endif
@@ -492,6 +501,24 @@
count = inb_p(0x40);/* read the latched count */
count |= inb(0x40) << 8;
+
+
+/* VIA686a test code... reset the latch if count > max */
+if (count > LATCH-1) {
+static int last_whine;
+outb_p(0x34, 0x43);
+outb_p(LATCH & 0xff, 0x40);
+outb(LATCH >> 8, 0x40);
+count = LATCH - 1;
+if(time_after(jiffies, last_whine))
+{
+printk(KERN_WARNING "probable hardware bug: clock
+timer configuration lost - probably a VIA686a motherboard.\n");
+printk(KERN_WARNING "probable hardware bug: restoring
+chip configuration.\n");
+last_whine = jiffies + HZ;
+}
+}
+
+
spin_unlock(_lock);
count = ((LATCH-1) - count) * TICK_SIZE;
--end of patch---
This is my first patch, i hope it is ok. i followed the instructions in
Documentation/SubmittingPatches to create it.
- Jonas
PS: please CC me any reply, i haven't registered to the mailinglist.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
usb mouse problem
Hi! I just installed 2.4.5-ac6 (from 2.4.5). I needed the ac kernel to fix my VIA timer bug. Now, my Intellimouse Explorer (USB) seems to have problems. It doesn't go smooth anymore. when i move the mouse slowly, it does not continually go on the screen. sometimes it stops for some time, just like a dirty ball mouse (mine is an optical one). is there something wrong with the ac kernels? - Jonas. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usb mouse problem
Hi! I just installed 2.4.5-ac6 (from 2.4.5). I needed the ac kernel to fix my VIA timer bug. Now, my Intellimouse Explorer (USB) seems to have problems. It doesn't go smooth anymore. when i move the mouse slowly, it does not continually go on the screen. sometimes it stops for some time, just like a dirty ball mouse (mine is an optical one). is there something wrong with the ac kernels? - Jonas. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA timer bugfix, patch for 2.4.5
Hi!
I have compiled a little patch that contains the VIA timer bugfix (from the ac
kernel). the patch is against linus' 2.4.5 kernel. I have compiled and ran the patched
kernel sucessfully.
the only changes made by this patch are done to linux/arch/i386/kernel/timer.c
I would like to have this patch applied to linus' kernel tree (so that it comes in
2.4.6), because alan's kernel has USB problems on my machine.
Here's the patch:
--- arch/i386/kernel/time.c.origSat Jun 2 16:06:59 2001
+++ arch/i386/kernel/time.c Sat Jun 2 16:07:20 2001
@@ -178,6 +178,15 @@
jiffies_t = jiffies;
count |= inb_p(0x40) 8;
+
+/* VIA686a test code... reset the latch if count max + 1 */
+if (count LATCH) {
+outb_p(0x34, 0x43);
+outb_p(LATCH 0xff, 0x40);
+outb(LATCH 8, 0x40);
+count = LATCH - 1;
+}
+
spin_unlock(i8253_lock);
/*
@@ -413,7 +422,7 @@
if (!user_mode(regs))
x86_do_profile(regs-eip);
#else
- if (!smp_found_config)
+ if (!using_apic_timer)
smp_local_timer_interrupt(regs);
#endif
@@ -492,6 +501,24 @@
count = inb_p(0x40);/* read the latched count */
count |= inb(0x40) 8;
+
+
+/* VIA686a test code... reset the latch if count max */
+if (count LATCH-1) {
+static int last_whine;
+outb_p(0x34, 0x43);
+outb_p(LATCH 0xff, 0x40);
+outb(LATCH 8, 0x40);
+count = LATCH - 1;
+if(time_after(jiffies, last_whine))
+{
+printk(KERN_WARNING probable hardware bug: clock
+timer configuration lost - probably a VIA686a motherboard.\n);
+printk(KERN_WARNING probable hardware bug: restoring
+chip configuration.\n);
+last_whine = jiffies + HZ;
+}
+}
+
+
spin_unlock(i8253_lock);
count = ((LATCH-1) - count) * TICK_SIZE;
--end of patch---
This is my first patch, i hope it is ok. i followed the instructions in
Documentation/SubmittingPatches to create it.
- Jonas
PS: please CC me any reply, i haven't registered to the mailinglist.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
VIA timer bug
Hello! I hope this is the right place for my request. I have heard about a VIA sytem timer bug. I have a Via KX-133 (for athlon) board and the following problem: Once the bug is triggered, the system timer goes crazy (i think it is the system timer, i am not sure). following things happen then: X blanks the screen all the time, licq auto-aways or auto-disconnects... the bug is triggered by high disk throughput (copying large amounts of data from one hd to another) and it often occurs during open-gl. I have heard, that there is a patch since 2.4.4-ac?, so i upgraded to 2.4.5, but the bug still occurs. do i have to set up something in make menuconfig? if so, what? -regards, Jonas Diemer PS: I have NOT subscribed to the list, so please CC me your response. PPS: Sorry for posting twice, the first posting lacked a subject entry. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA timer bug
Hello! I hope this is the right place for my request. I have heard about a VIA sytem timer bug. I have a Via KX-133 (for athlon) board and the following problem: Once the bug is triggered, the system timer goes crazy (i think it is the system timer, i am not sure). following things happen then: X blanks the screen all the time, licq auto-aways or auto-disconnects... the bug is triggered by high disk throughput (copying large amounts of data from one hd to another) and it often occurs during open-gl. I have heard, that there is a patch since 2.4.4-ac?, so i upgraded to 2.4.5, but the bug still occurs. do i have to set up something in make menuconfig? if so, what? -regards, Jonas Diemer PS: I have NOT subscribed to the list, so please CC me your response. PPS: Sorry for posting twice, the first posting lacked a subject entry. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
Hello! I hope this is the right place for my request. I have heard about a VIA sytem timer bug. I have a Via KX-133 (for athlon) board and the following problem: Once the bug is triggered, the system timer goes crazy (i think it is the system timer, i am not sure). following things happen then: X blanks the screen all the time, licq auto-aways or auto-disconnects... the bug is triggered by high disk throughput (copying large amounts of data from one hd to another) and it often occurs during open-gl. I have heard, that there is a patch since 2.4.4-ac?, so i upgraded to 2.4.5, but the bug still occurs. do i have to set up something in make menuconfig? if so, what? -regards, Jonas Diemer PS: I have NOT subscribed to the list, so please CC me your response. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
Hello! I hope this is the right place for my request. I have heard about a VIA sytem timer bug. I have a Via KX-133 (for athlon) board and the following problem: Once the bug is triggered, the system timer goes crazy (i think it is the system timer, i am not sure). following things happen then: X blanks the screen all the time, licq auto-aways or auto-disconnects... the bug is triggered by high disk throughput (copying large amounts of data from one hd to another) and it often occurs during open-gl. I have heard, that there is a patch since 2.4.4-ac?, so i upgraded to 2.4.5, but the bug still occurs. do i have to set up something in make menuconfig? if so, what? -regards, Jonas Diemer PS: I have NOT subscribed to the list, so please CC me your response. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
