What license agreement? This isn't some PC game where you have to run an install program and click "I accept" to a EULA document before installation will continue. You just put the disc in the PS2 and it runs.
Contrary to popular belief, not every piece of software in the world has a "license agreement" attached to it. That's a trick used by some software vendors to impose additional restrictions on you, above and beyond copyright law, by making you agree to those restrictions in a contract before you can use their software.
Sony will be able to sue this guy for violating their EULA by disassembling their game.
Ico has no EULA. Ordinary copyright law applies, and under ordinary copyright law, disassembling a small portion of the game code to investigate this matter almost certainly qualifies as fair use. (And Sony allegedly doesn't hold copyright on the code that was disassembled anyway.)
I don't know what distro you're using that's upgrading the kernel on a stable release, but if you want a distro that's actually stable, try Debian. Updates are for critical flaws only and they do nothing but patch the bug in question. No random new versions of things.
BTW, I've been running Debian's development branch ("unstable", which does get new versions of things on a daily basis) full-time for about six-and-a-half years, and the only reinstall I did was when I bought a whole new computer last year. Even with daily incremental upgrades in the unstable branch, noticeable breakage is uncommon and major breakage is rare, and with a bit of maintenance it's quite maintainable in the long term.
SELinux is not a distribution, it's a security module in the kernel. These days it's part of the standard kernel.org tree, and some distributions (such as Fedora/RHEL) enable it by default.
Sure, Tomboy could be reimplemented in C, but people are trying to move away from C, and toward higher-level languages, for application development. That's why GNOME provides bindings for a variety of higher-level languages, including the Mono platform.
As for being able to "get any old thing in there", take a look at the GNOME mailing lists sometime. Anyone can write an application using the GNOME libraries, of course, but it takes consensus to get it into the official GNOME release.
If you're referring to Cisco Clean Access, I've heard there's a way to work around that from a Linux machine, but I don't know the details. Might be worth looking into.
Oops, correction: interrupts probably aren't used anymore for invoking system calls. On x86, at least, there's a machine instruction called sysenter that's designed specifically for this sort of thing and does it much more efficiently than int, and I'm sure most other architectures have something similar.
My main point still stands, though: Invoking real Linux system calls directly requires writing assembly code. Very few programs do that; everything uses the wrappers provided by libc.
Not much effective, since most of secure software is written in special scripting languages (e.g. perl -T) and uses analogue of '/usr/bin/env -' to clean environment before doing anything. And has bunch of secure wrappers before doing anything serious.
By the time the script is running, the malicious library would already have been preloaded by the script interpreter. The script could unset LD_PRELOAD prior to launching any sub-processes, but a well-written preload rootkit would intercept execve() calls and put the variable back before allowing the exec to happen. It might also be possible to alter the environment data passed to the program when it starts, to hide the LD_PRELOAD setting.
And do not forget, that with ld_preload you can overload libc calls - but it all fails if application calls syscalls directly.
The "system calls" you're thinking of are libc functions. The kernel's system-call interface works by loading parameters into specific CPU registers and invoking a software interrupt, much like the "int 21h" mechanism used by DOS, so to truly invoke system calls directly, you have to write assembly code. The C-callable "system calls" we normally think of, like execve(), read(), and write(), are provided by libc as convenient wrappers which invoke the real system call on your behalf. Those can be intercepted by a preload rootkit.
And well, user can always do manually in terminal 'unset LD_PRELOAD'... How would you protect root-kit against that? Environment is just lump of RAM with bunch of strings in it - application (consequently user) can do with it whatever it/s/he likes to.
As mentioned above: sure, you can remove LD_PRELOAD from the environment in your shell, but the shell already has the rootkit library loaded. When you run a program from the shell, the shell fork()s and the child process calls execve(), passing the desired environment (sans LD_PRELOAD) as a parameter. The execve() that gets called is the preloaded malicious one, though, which just puts LD_PRELOAD back into the given environment before passing it along to the real system call.
Since environments are passed down from parent process to child, a preload-based rootkit would need to replace/sbin/init with a wrapper that sets LD_PRELOAD prior to running the real init, to make sure that every process on the system preloads the malicious library. And being based entirely in userspace, it wouldn't be able to conceal itself quite as completely as one which patches the kernel; it could be completely bypassed by a program that directly invokes the real assembly system calls, for example. Still, it could be fairly effective if done right.
On other side, Linux file system API does support so called namespaces (or what windows calls mount points). IOW it is possible to remove something so it would be invisible to user and his/her applications.
A mountpoint in Windows means basically the same thing that it does in Linux: a place where the root of one filesystem appears to be a subdirectory on another filesystem.
A namespace is something different: it's the set of all mounts seen by a running process. If you launch a program in a new namespace, it can mount a filesystem and see its contents without making the filesystem appear mounted (and therefore the contents visible) to the rest of the system. (Or, it can unmount a filesystem that's already mounted, and it'll no longer be able to access those files, but everything else on the system will. But that's less interesting.)
So, a malicious program running with root privileges (CLONE_NEWNS is a privileged operation) could mount a ramdisk that nothing else can see, and store files there. (Using a real disk partition is trickier, since it'd have to find a partition that isn't already in use.) However, the program itself would still be running as an ordinary process, visible with "ps" and similar tools, and able to be killed by the administrator. It could patch the kernel (a rootkit technique) to hide its presence, but if it's sophisticated enough to do that, it could also just patch the kernel to hide files, and wouldn't need to bother with namespaces and hidden mounts.
In general, though, the conservative assumption is that if a malicious program manages to run with root privileges on your system, you're hosed. The front lines of defense are avoiding letting malicious code run in the first place, or if it does, making sure it can't get root. (That's why we use non-privileged accounts for day-to-day work; compare to Windows, where users on most desktop systems have Administrator rights all the time. Combined with Autorun, you can be rooted just by putting a malicious CD in your drive, or plugging in a malicious flash drive.)
People prefer all-in-one kernel patches that just turns on the feature they are interested in.
I have mixed feelings about this. On one hand, I feel that the default should be the standards-compliant behavior, and deviations from standards-compliance should be made explicit in/etc/fstab. On the other hand, not everything that's mounted is in fstab anyway -- I'm thinking of auto-mounting of hotplugged USB devices, whose mount options are chosen by some volume-manager program. (Though, these are usually FAT filesystems, which doesn't support atime anyway, AFAIK.)
Reading through the thread, the idea that caught my attention the most was Arjan van de Ven's suggestion of adding an "atime-dirty" state for inodes, which by itself won't trigger any disk I/O. Theodore Tso pointed out in a reply that this would be tricky to implement "right", but in a long-term sense it seems like the best solution, since it avoids the current atime problems, while still being completely standards-compliant. noatime and relatime both seem like interim hacks in comparison.
How do you think that would help with the problem of writing lots of unnecessary atime updates to disk?
It could help if you're repeatedly re-reading the same file, because most of the file's atime changes will just overwrite each other in RAM and only the last one will be flushed to disk, but the real problem is when a bunch of different files are being read, and you have to update the atime on all of them. I don't see soft updates helping with that.
Linux has the "noatime" option too; it's been there for ages. The problem being discussed is that noatime isn't the default in most distros, and many people don't know about it, so a majority of Linux systems are suffering an I/O performance hit due to atime updates that they don't really need.
Most of the debate centers around whether the kernel should provide a configuration setting to mount everything noatime automatically, without having to specify it in/etc/fstab for each filesystem.
That idea was brought up in the discussion on the list, but Theodore Tso pointed out "that it will keep a large number of inodes pinned in memory, which is its own problem. So there would have to be some way to force the atime updates to be merged when under memory pressure, and and perhaps on some much longer background interval (i.e., every hour or so)."
So, it's possible, but not as straightforward to implement as one might think.
ClearType's "rainbows" are an optimization meant specifically for LCD monitors, to gain a bit of extra sharpness. It doesn't work on CRTs; you see the colors but you don't gain the sharpness.
Windows has had "standard" anti-aliasing (using only shades of grey, no "rainbows") since Windows 95, much longer than ClearType has been around. However, for some reason, the "standard" AA only kicks in at larger sizes; typical sizes (12pt, etc.) are left with the jaggies. That's why many people think the only options are ClearType or no AA at all.
Microsoft has a "ClearType Tuner" program that you can use to adjust how the ClearType font rasterizer works. I haven't used it, but it probably has a "contrast" slider for adjusting the amount of coloration used. Turn that down to zero, and you'll get what the "standard" AA ought to be, smoothed at all sizes but without the LCD-specific coloration trick.
According to the paper, the reason Mac OS X is not vulnerable is that it uses one-shot timers scheduled for exactly when the next event needs to occur, rather than periodic "ticks" with a fixed interval between them. The "tickless idle" feature introduced in Linux 2.6.21 (currently only on x86, I believe) takes the same approach, and very possibly makes Linux immune too.
(Ironically, immediately after discussing OSX's ticklessness, the paper mentions that "the Linux 2.6.16 kernel source tree contains 8,997 occurrences of the tick frequency HZ macro, spanning 3,199 files", to illustrate how difficult it is to take a tick-based kernel and make it tickless. But those kernel hackers went and did it anyway.)
The tickless feature isn't yet implemented on all architectures that Linux supports, though. I think AMD64 support for it is supposed to come in 2.6.23, along with the new CFS scheduler.
Keep in mind that Theo is speaking theoretically here, about potential vulnerabilities -- there are no actual working exploits for this stuff in the wild, and if/when there are, you'll hear about them through normal security advisories and Intel will probably release microcode updates to fix them, just like they did with this TLB bug when it proved to be a real-world problem.
There may be (in fact, probably are) workable exploits known to the ultra-secretive intelligence organizations of the world, but for most people that's not a concern -- you're unlikely to be the target of an individualized attack, and if you are, you'd better have your computer watched 24/7 by some highly-paid armed guards, because it's much cheaper and easier to just break in and use your computer directly than to pull off an attack based on buggy CPU opcodes.
Also keep in mind that AMD's processors aren't bug-free either: their errata list is here.
Why wouldn't they be loading the microcode update that Intel has already issued? There's no need for a software workaround when the processor's erroneous behavior can be fixed directly.
Windows most likely already has a driver for loading new microcode into an Intel processor -- I'd be surprised if it didn't, since it's been supported by hardware as far back as the Pentium Pro -- so this update is presumably just a new microcode file to be loaded by that driver.
However, it would be interesting to know if this is only on systems from big vendors that also ship windows software (i.e. Dell), because the microsoft update filenames all have the word "genuine" in them.
"GenuineIntel" is the vendor string reported by Intel's processors. Do a "cat/proc/cpuinfo" on a Linux box sometime and look at the vendor_id field. This is not a DRM thing, and not related to Windows Genuine Advantage.
I believe the use of the word "genuine" in the vendor string was for trademark reasons, to distinguish Intel's chips from compatible ones made by AMD, VIA, Cyrix, and the like. I don't know the details though.
Anyway, since I refuse on principle to let Windows Genuine Advantage creep onto my computer, no patch for me. This is where Linux could really shine.
A microcode update is volatile and has to be re-applied by the OS each time it boots. Installing the update in Linux won't give you updated microcode in Linux.
However, some (most?) BIOSes do microcode updates, so your motherboard's next BIOS update might give you the fix for all OSes.
However, it defaults to x87 math on 32-bit processors, unless you tell it otherwise with "-mfpmath=sse". (And SSE math isn't even an option unless you tell it to compile for an SSE-capable target, with an option such as "-march=686"; the default is generic 386.)
SSE math is the default on 64-bit systems, though.
It's a ~300k file that sits harmlessly on disk when not in use. It's not some big piece of infrastructure that's wasting resources even when disabled.
Operating systems contain lots of features that are always or usually installed even when they're not being used. Things like USB support, even on older systems that don't have USB ports, and RS-232 support even on newer systems that lack serial ports. CD burning support, even if the machine doesn't have a burner. Support for MP3/Vorbis/WMA audio even if you don't use all of those formats. The idea of "uninstall it if you're not using it" makes sense with big applications, but not little things like these.
How would you completely remove (not just disable) IPv6 support from Windows Vista, btw?
Slashdot Mirror
What license agreement? This isn't some PC game where you have to run an install program and click "I accept" to a EULA document before installation will continue. You just put the disc in the PS2 and it runs.
Contrary to popular belief, not every piece of software in the world has a "license agreement" attached to it. That's a trick used by some software vendors to impose additional restrictions on you, above and beyond copyright law, by making you agree to those restrictions in a contract before you can use their software.
Ico has no EULA. Ordinary copyright law applies, and under ordinary copyright law, disassembling a small portion of the game code to investigate this matter almost certainly qualifies as fair use. (And Sony allegedly doesn't hold copyright on the code that was disassembled anyway.)
I don't know what distro you're using that's upgrading the kernel on a stable release, but if you want a distro that's actually stable, try Debian. Updates are for critical flaws only and they do nothing but patch the bug in question. No random new versions of things.
BTW, I've been running Debian's development branch ("unstable", which does get new versions of things on a daily basis) full-time for about six-and-a-half years, and the only reinstall I did was when I bought a whole new computer last year. Even with daily incremental upgrades in the unstable branch, noticeable breakage is uncommon and major breakage is rare, and with a bit of maintenance it's quite maintainable in the long term.
SELinux is not a distribution, it's a security module in the kernel. These days it's part of the standard kernel.org tree, and some distributions (such as Fedora/RHEL) enable it by default.
Sure, Tomboy could be reimplemented in C, but people are trying to move away from C, and toward higher-level languages, for application development. That's why GNOME provides bindings for a variety of higher-level languages, including the Mono platform.
As for being able to "get any old thing in there", take a look at the GNOME mailing lists sometime. Anyone can write an application using the GNOME libraries, of course, but it takes consensus to get it into the official GNOME release.
If you're referring to Cisco Clean Access, I've heard there's a way to work around that from a Linux machine, but I don't know the details. Might be worth looking into.
That means my twelve-year-old HP48 calculator has a 64-bit processor, despite having a 4-bit bus and 20-bit addresses. :-)
Oops, correction: interrupts probably aren't used anymore for invoking system calls. On x86, at least, there's a machine instruction called sysenter that's designed specifically for this sort of thing and does it much more efficiently than int, and I'm sure most other architectures have something similar.
My main point still stands, though: Invoking real Linux system calls directly requires writing assembly code. Very few programs do that; everything uses the wrappers provided by libc.
By the time the script is running, the malicious library would already have been preloaded by the script interpreter. The script could unset LD_PRELOAD prior to launching any sub-processes, but a well-written preload rootkit would intercept execve() calls and put the variable back before allowing the exec to happen. It might also be possible to alter the environment data passed to the program when it starts, to hide the LD_PRELOAD setting.
The "system calls" you're thinking of are libc functions. The kernel's system-call interface works by loading parameters into specific CPU registers and invoking a software interrupt, much like the "int 21h" mechanism used by DOS, so to truly invoke system calls directly, you have to write assembly code. The C-callable "system calls" we normally think of, like execve(), read(), and write(), are provided by libc as convenient wrappers which invoke the real system call on your behalf. Those can be intercepted by a preload rootkit.
As mentioned above: sure, you can remove LD_PRELOAD from the environment in your shell, but the shell already has the rootkit library loaded. When you run a program from the shell, the shell fork()s and the child process calls execve(), passing the desired environment (sans LD_PRELOAD) as a parameter. The execve() that gets called is the preloaded malicious one, though, which just puts LD_PRELOAD back into the given environment before passing it along to the real system call.
Since environments are passed down from parent process to child, a preload-based rootkit would need to replace /sbin/init with a wrapper that sets LD_PRELOAD prior to running the real init, to make sure that every process on the system preloads the malicious library. And being based entirely in userspace, it wouldn't be able to conceal itself quite as completely as one which patches the kernel; it could be completely bypassed by a program that directly invokes the real assembly system calls, for example. Still, it could be fairly effective if done right.
A mountpoint in Windows means basically the same thing that it does in Linux: a place where the root of one filesystem appears to be a subdirectory on another filesystem.
A namespace is something different: it's the set of all mounts seen by a running process. If you launch a program in a new namespace, it can mount a filesystem and see its contents without making the filesystem appear mounted (and therefore the contents visible) to the rest of the system. (Or, it can unmount a filesystem that's already mounted, and it'll no longer be able to access those files, but everything else on the system will. But that's less interesting.)
So, a malicious program running with root privileges (CLONE_NEWNS is a privileged operation) could mount a ramdisk that nothing else can see, and store files there. (Using a real disk partition is trickier, since it'd have to find a partition that isn't already in use.) However, the program itself would still be running as an ordinary process, visible with "ps" and similar tools, and able to be killed by the administrator. It could patch the kernel (a rootkit technique) to hide its presence, but if it's sophisticated enough to do that, it could also just patch the kernel to hide files, and wouldn't need to bother with namespaces and hidden mounts.
In general, though, the conservative assumption is that if a malicious program manages to run with root privileges on your system, you're hosed. The front lines of defense are avoiding letting malicious code run in the first place, or if it does, making sure it can't get root. (That's why we use non-privileged accounts for day-to-day work; compare to Windows, where users on most desktop systems have Administrator rights all the time. Combined with Autorun, you can be rooted just by putting a malicious CD in your drive, or plugging in a malicious flash drive.)
I have mixed feelings about this. On one hand, I feel that the default should be the standards-compliant behavior, and deviations from standards-compliance should be made explicit in /etc/fstab. On the other hand, not everything that's mounted is in fstab anyway -- I'm thinking of auto-mounting of hotplugged USB devices, whose mount options are chosen by some volume-manager program. (Though, these are usually FAT filesystems, which doesn't support atime anyway, AFAIK.)
Reading through the thread, the idea that caught my attention the most was Arjan van de Ven's suggestion of adding an "atime-dirty" state for inodes, which by itself won't trigger any disk I/O. Theodore Tso pointed out in a reply that this would be tricky to implement "right", but in a long-term sense it seems like the best solution, since it avoids the current atime problems, while still being completely standards-compliant. noatime and relatime both seem like interim hacks in comparison.
How do you think that would help with the problem of writing lots of unnecessary atime updates to disk?
It could help if you're repeatedly re-reading the same file, because most of the file's atime changes will just overwrite each other in RAM and only the last one will be flushed to disk, but the real problem is when a bunch of different files are being read, and you have to update the atime on all of them. I don't see soft updates helping with that.
Linux has the "noatime" option too; it's been there for ages. The problem being discussed is that noatime isn't the default in most distros, and many people don't know about it, so a majority of Linux systems are suffering an I/O performance hit due to atime updates that they don't really need.
Most of the debate centers around whether the kernel should provide a configuration setting to mount everything noatime automatically, without having to specify it in /etc/fstab for each filesystem.
That idea was brought up in the discussion on the list, but Theodore Tso pointed out "that it will keep a large number of inodes pinned in memory, which is its own problem. So there would have to be some way to force the atime updates to be merged when under memory pressure, and and perhaps on some much longer background interval (i.e., every hour or so)."
So, it's possible, but not as straightforward to implement as one might think.
ClearType's "rainbows" are an optimization meant specifically for LCD monitors, to gain a bit of extra sharpness. It doesn't work on CRTs; you see the colors but you don't gain the sharpness.
Windows has had "standard" anti-aliasing (using only shades of grey, no "rainbows") since Windows 95, much longer than ClearType has been around. However, for some reason, the "standard" AA only kicks in at larger sizes; typical sizes (12pt, etc.) are left with the jaggies. That's why many people think the only options are ClearType or no AA at all.
Microsoft has a "ClearType Tuner" program that you can use to adjust how the ClearType font rasterizer works. I haven't used it, but it probably has a "contrast" slider for adjusting the amount of coloration used. Turn that down to zero, and you'll get what the "standard" AA ought to be, smoothed at all sizes but without the LCD-specific coloration trick.
That was the NSA, not the FBI.
(The Federal Bureau of Investigation is a bunch of detectives, not spies. Their job is to help the police in solving crimes.)
According to the paper, the reason Mac OS X is not vulnerable is that it uses one-shot timers scheduled for exactly when the next event needs to occur, rather than periodic "ticks" with a fixed interval between them. The "tickless idle" feature introduced in Linux 2.6.21 (currently only on x86, I believe) takes the same approach, and very possibly makes Linux immune too.
(Ironically, immediately after discussing OSX's ticklessness, the paper mentions that "the Linux 2.6.16 kernel source tree contains 8,997 occurrences of the tick frequency HZ macro, spanning 3,199 files", to illustrate how difficult it is to take a tick-based kernel and make it tickless. But those kernel hackers went and did it anyway.)
The tickless feature isn't yet implemented on all architectures that Linux supports, though. I think AMD64 support for it is supposed to come in 2.6.23, along with the new CFS scheduler.
Keep in mind that Theo is speaking theoretically here, about potential vulnerabilities -- there are no actual working exploits for this stuff in the wild, and if/when there are, you'll hear about them through normal security advisories and Intel will probably release microcode updates to fix them, just like they did with this TLB bug when it proved to be a real-world problem.
There may be (in fact, probably are) workable exploits known to the ultra-secretive intelligence organizations of the world, but for most people that's not a concern -- you're unlikely to be the target of an individualized attack, and if you are, you'd better have your computer watched 24/7 by some highly-paid armed guards, because it's much cheaper and easier to just break in and use your computer directly than to pull off an attack based on buggy CPU opcodes.
Also keep in mind that AMD's processors aren't bug-free either: their errata list is here.
Why wouldn't they be loading the microcode update that Intel has already issued? There's no need for a software workaround when the processor's erroneous behavior can be fixed directly.
Windows most likely already has a driver for loading new microcode into an Intel processor -- I'd be surprised if it didn't, since it's been supported by hardware as far back as the Pentium Pro -- so this update is presumably just a new microcode file to be loaded by that driver.
"GenuineIntel" is the vendor string reported by Intel's processors. Do a "cat /proc/cpuinfo" on a Linux box sometime and look at the vendor_id field. This is not a DRM thing, and not related to Windows Genuine Advantage.
I believe the use of the word "genuine" in the vendor string was for trademark reasons, to distinguish Intel's chips from compatible ones made by AMD, VIA, Cyrix, and the like. I don't know the details though.
A microcode update is volatile and has to be re-applied by the OS each time it boots. Installing the update in Linux won't give you updated microcode in Linux.
However, some (most?) BIOSes do microcode updates, so your motherboard's next BIOS update might give you the fix for all OSes.
However, it defaults to x87 math on 32-bit processors, unless you tell it otherwise with "-mfpmath=sse". (And SSE math isn't even an option unless you tell it to compile for an SSE-capable target, with an option such as "-march=686"; the default is generic 386.)
SSE math is the default on 64-bit systems, though.
It's a ~300k file that sits harmlessly on disk when not in use. It's not some big piece of infrastructure that's wasting resources even when disabled.
Operating systems contain lots of features that are always or usually installed even when they're not being used. Things like USB support, even on older systems that don't have USB ports, and RS-232 support even on newer systems that lack serial ports. CD burning support, even if the machine doesn't have a burner. Support for MP3/Vorbis/WMA audio even if you don't use all of those formats. The idea of "uninstall it if you're not using it" makes sense with big applications, but not little things like these.
How would you completely remove (not just disable) IPv6 support from Windows Vista, btw?
99% of Mac users don't "need" Bonjour either, but it's convenient to have anyway. Avahi is another implementation of the same thing.
Since Avahi only resolves names in the ".local" zone, what are the "lot of problems with DNS" you're referring to?
If you don't want to use IPv6, disabling it by blacklisting the module is all you need to do. Why would you need to go as far as deleting the .ko file?