Linux Flame

Naja man brauchs ja nich übertreiben.

Realistisch betrachtet sieht es doch so aus:
  • Für den Serverbereich (Web, File, Univ usw.) ist es das beste am Markt. Windows dominiert da nur bei unternehmensinternen Servern. OSX läuft nur auf Consumer-Hardware und fällt damit raus. BSD wird auch gerne genommen, sofern die nötige Software und Expertise vorhanden ist.
  • HPC ist es einfach ganz klar Linux, weil es bei Systemen mit vielen Sockeln und noch mehr Cores, hohen Workloads und I/O Lasten am besten skaliert und am flexibelsten ist.
  • Embedded ist Linux auch sehr verbreitet, weil das Know-How, wie man es anpasst, vorhanden ist und für relevante Hardware ausgereifte Treiber vorliegen. Windows spielt da eher eine Rolle im PoS-Bereich.
  • Smartphones: Linux und (effektiv) BSD, wobei Linux den größeren Anteil hat und auf sehr unterschiedlicher Hardware gut läuft.
  • Desktop: Windows.

Der Kernel an sich ist denke ich bei Linux auch am seltensten das Problem.
 
Linux wurde und wird aus einer Not heraus oftmals in Bereichen eingesetzt, wo man es besser lassen sollte. Das bedeutet aber noch lange nicht, dass es in technischer Hinsicht die bessere Wahl ist:

- Lizenzgebühren
- Performance

Das sind die wesentliche Faktoren. Die genutzten Produkte sind meistens Anwendungen, die mit Linux wenig zu tun haben, siehe http, DNS, E-Mail, Datenbank (und GNU überhaupt). Gefördert wurde diese Entwicklung durch die hoffnungslose Überbuchung im Web Bereich und BWLer, die auf Kosten schielen (Performance und Lizenzen). Nichts davon ist ein Garant für Qualität und schon gar nicht für Sicherheit. Für UNternehmen ist Linux u.a. auch deshalb so attraktiv, weil sie ihren Schrott (zb diverse controller Treiber oder Graka Treiber) einfach als BLOBS in eine Distribution kippen können, ohne dass sich jemand beklagt, was letztendlich in der Inkonsequenz der Linuxgemeinde begründet liegt, die lieber nach Verbreitung statt Qualität strebt.
 
Die Fälle in denen der Linux-Kernel schlechtere Perfomance liefert als vergleichbares, sind doch eigentlich eher nicht so viele?
Zum Thema "Blobs reinkippen"... joar... so wird es schließlich bei allen anderen Betriebssystemen auch gemacht, oder kennst du viele OSS-Treiber für Windows oder OS X oder Solaris oder $OS?... Die im Kernel gelieferten Treiber sind halt OSS (sinnigerweise), was darüber hinaus geht, ist (wenn man von den unsäglichen GPL absieht) alleinig Sache des Entwicklers...

Worauf ich hinaus will ist, dass ein Großteil der Kritik am Kernel rein ideologischer Natur ist und nur ein sehr kleiner Teil tatsächlich technisch fundiert ist.
Das wichtigste technische Argument dürfte der monolithische Kernel sein. Ja, das war keine gute Idee. Aber: kein anderes Mainstream-OS setzt was anderes ein, es mangelt also ganz klar an alternativen und da somit dieses Argument auf allen Seiten der argumentativen Gleichung zum Tragen kommt, annulliert es sich selbst.
 
black magic!!11!

Code:
./NVIDIA-Linux-x86-310.19.run -x
ls NVIDIA-Linux-x86-310.19/kernel/
Makefile.kbuild        nv-chrdev.c        nv-mlock.c        nv-vm.c            os-smp.c
Makefile.nvidia        nv-cray.c        nv-mmap.c        nv-vtophys.c        os-usermap.c
conftest.sh        nv-gvi.c        nv-p2p.c        nv.c            rmil.h
cpuopsys.h        nv-i2c.c        nv-p2p.h        nv.h            rmretval.h
dkms.conf        nv-kernel.o        nv-pat.c        nverror.h        xapi-sdk.h
g_nvreadme.h        nv-linux.h        nv-procfs.c        nvtypes.h
gcc-version-check.c    nv-memdbg.h        nv-proto.h        os-interface.c
makefile        nv-mempool.c        nv-reg.h        os-interface.h
nv-acpi.c        nv-misc.h        nv-usermap.c        os-registry.c
oder auch nicht ;)
Oha, das ist heftig. Egal, ich benutze trotzdem Linux, auch wenn du es scheiße findest :wink:.
 
Das man keine Treiber als Binaries liefern kann, sondern für jeden Kernelbuild den Treiber extra neukompilieren muss, sollte auch einen Kritikpunkt wert sein.
Für jeden Kernelbuild? Nö, aber für jede Version, wo sich die internen Interfaces geändert haben. Windows bietet halt 15+ Jahre an Binärkompatiblität im Kernel, das ist schon was. Dafür ist Treiberentwicklung unter Windows halt ne richtig gute Runde abgefuckter als unter Linux.
 
Worauf ich eigentlich hinauswollte ist der Umstand, dass Linux (bzw. an dieser Stelle die grossen Distributoren) mit jedem Hardwarehersteller ins Bett geht, anstatt mal konsequent zu sagen: Wir werden Treiber XYZ in Zukunft nicht mehr als BLOB integrieren.

Die Linux Gemeinde könnte seine Marktmacht nutzen um Hersteller zur Offenlegung des Codes zu bewegen.

Stattdessen ist es der Gemeinde aber wichtiger das System zu verbreiten - egal wie hoch der Preis ist.

Der Preis sind BLOBs und bytecodes, die nur vom Hersteller (wenn überhaupt) verstanden werden und die OSS Gemeinde keine Chance hat die Qualität und auch Sicherheit zu überprüfen. Solche Fälle sind vorgekommen und hinlänglich belegt.
Das ist dem mickrigen Ego der Linuxer geschuldet, die lieber die IT Welt mit mangelhafter Ware überschwemmt, anstatt halt auf die Masse und jeden Trend zu verzichten und lieber solide Arbeit liefert.

Aus meiner eigenen 15 Jährigen Erfahrung im IT Geschäft kann ich Linux zumindest in Bereichen der Sicherheit und (ganz besonders) der Filesysteme höchstens die Note 4- geben. Was mir an ext* und reiser an FS schon kaputtgegangen ist, kriege ich nicht mit NTFS und UFS zusammen. (UFS, locker 100 Installationen im Produktivumfeld über einen Zeitraum von über 10 Jahren und es ging nicht ein einziges Byte verloren).

Aber ja - eine OpenBSD Maschine mit UFS ist nicht so schnell ...
 
Das heutige Kernel-Update bei Debian spricht ja auch mal wieder Bände...

Code:
CVE-2012-2121

   Benjamin Herrenschmidt and Jason Baron discovered issues with the IOMMU
   mapping of memory slots used in KVM device assignment. Local users with
   the ability to assign devices could cause a denial of service due to a
   memory page leak.

CVE-2012-3552

   Hafid Lin reported an issue in the IP networking subsystem. A remote user
   can cause a denial of service (system crash) on servers running
   applications that set options on sockets which are actively being
   processed.

CVE-2012-4461

   Jon Howell reported a denial of service issue in the KVM subsystem.
   On systems that do not support the XSAVE feature, local users with
   access to the /dev/kvm interface can cause a system crash.

CVE-2012-4508

   Dmitry Monakhov and Theodore Ts'o reported a race condition in the ext4
   filesystem. Local users could gain access to sensitive kernel memory.

CVE-2012-6537

   Mathias Krause discovered information leak issues in the Transformation
   user configuration interface. Local users with the CAP_NET_ADMIN capability
   can gain access to sensitive kernel memory.

CVE-2012-6539

   Mathias Krause discovered an issue in the networking subsystem. Local
   users on 64-bit systems can gain access to sensitive kernel memory.

CVE-2012-6540

   Mathias Krause discovered an issue in the Linux virtual server subsystem.
   Local users can gain access to sensitive kernel memory. Note: this issue
   does not affect Debian provided kernels, but may affect custom kernels
   built from Debian's linux-source-2.6.32 package.

CVE-2012-6542

   Mathias Krause discovered an issue in the LLC protocol support code.
   Local users can gain access to sensitive kernel memory.

CVE-2012-6544

   Mathias Krause discovered issues in the Bluetooth subsystem.
   Local users can gain access to sensitive kernel memory.

CVE-2012-6545

   Mathias Krause discovered issues in the Bluetooth RFCOMM protocol
   support. Local users can gain access to sensitive kernel memory.

CVE-2012-6546

   Mathias Krause discovered issues in the ATM networking support. Local
   users can gain access to sensitive kernel memory.

CVE-2012-6548

   Mathias Krause discovered an issue in the UDF file system support.
   Local users can obtain access to sensitive kernel memory.

CVE-2012-6549

   Mathias Krause discovered an issue in the isofs file system support.
   Local users can obtain access to sensitive kernel memory.

CVE-2013-0349

   Anderson Lizardo discovered an issue in the Bluetooth Human Interface
   Device Protocol (HIDP) stack. Local users can obtain access to sensitive
   kernel memory.

CVE-2013-0914

   Emese Revfy discovered an issue in the signal implementation. Local
   users maybe able to bypass the address space layout randomization (ASLR)
   facility due to a leaking of information to child processes.

CVE-2013-1767

   Greg Thelen reported an issue in the tmpfs virtual memory filesystem.
   Local users with sufficient privilege to mount filesystems can cause
   a denial of service or possibly elevated privileges due to a use-after-
   free defect.

CVE-2013-1773

   Alan Stern provided a fix for a defect in the UTF8->UTF16 string conversion
   facility used by the VFAT filesystem. A local user could cause a buffer
   overflow condition, resulting in a denial of service or potentially
   elevated privileges.

CVE-2013-1774

   Wolfgang Frisch provided a fix for a NULL-pointer dereference defect
   in the driver for some serial USB devices from Inside Out Networks.
   Local users with permission to access these devices can create a denial
   of service (kernel oops) by causing the device to be removed while it is
   in use.

CVE-2013-1792

   Mateusz Guzik of Red Hat EMEA GSS SEG Team discovered a race condition
   in the access key retention support in the kernel. A local user could
   cause a denial of service (NULL pointer dereference).

CVE-2013-1796

   Andrew Honig of Google reported an issue in the KVM subsystem. A user in
   a guest operating system could corrupt kernel memory, resulting in a
   denial of service.

CVE-2013-1798

   Andrew Honig of Google reported an issue in the KVM subsystem. A user in
   a guest operating system could cause a denial of service due to a use-
   after-free defect.

CVE-2013-1826

   Mathias Krause discovered an issue in the Transformation (XFRM) user
   configuration interface of the networking stack. A user with the
   CAP_NET_ADMIN capability maybe able to gain elevated privileges.

CVE-2013-1860

   Oliver Neukum discovered an issue in the USB CDC WCM Device Management
   driver. Local users with the ability to attach devices can cause a
   denial of service (kernel crash) or potentially gain elevated privileges.

CVE-2013-1928

   Kees Cook provided a fix for an information leak in the
   VIDEO_SET_SPU_PALETTE ioctl for 32-bit applications running on a 64-bit
   kernel. Local users can gain access to sensitive kernel memory.

CVE-2013-1929

   Oded Horovitz and Brad Spengler reported an issue in the device driver for
   Broadcom Tigon3 based gigabit Ethernet. Users with the ability to attach
   untrusted devices can create an overflow condition, resulting in a denial
   of service or elevated privileges.

CVE-2013-2015

   Theodore Ts'o provided a fix for an issue in the ext4 filesystem. Local
   users with the ability to mount a specially crafted filesystem can cause
   a denial of service (infinite loop).

CVE-2013-2634

   Mathias Krause discovered a few issues in the Data Center Bridging (DCB)
   netlink interface. Local users can gain access to sensitive kernel memory.

CVE-2013-3222

   Mathias Krauss discovered an issue in the Asynchronous Transfer Mode (ATM)
   protocol support. Local users can gain access to sensitive kernel memory.

CVE-2013-3223

   Mathias Krauss discovered an issue in the Amateur Radio AX.25 protocol
   support. Local users can gain access to sensitive kernel memory.

CVE-2013-3224

   Mathias Krauss discovered an issue in the Bluetooth subsystem. Local users
   can gain access to sensitive kernel memory.

CVE-2013-3225

   Mathias Krauss discovered an issue in the Bluetooth RFCOMM protocol
   support. Local users can gain access to sensitive kernel memory.

CVE-2013-3228

   Mathias Krauss discovered an issue in the IrDA (infrared) subsystem
   support. Local users can gain access to sensitive kernel memory.

CVE-2013-3229

   Mathias Krauss discovered an issue in the IUCV support on s390 systems.
   Local users can gain access to sensitive kernel memory.

CVE-2013-3231

   Mathias Krauss discovered an issue in the ANSI/IEEE 802.2 LLC type 2
   protocol support. Local users can gain access to sensitive kernel memory.

CVE-2013-3234

   Mathias Krauss discovered an issue in the Amateur Radio X.25 PLP (Rose)
   protocol support. Local users can gain access to sensitive kernel memory.

CVE-2013-3235

   Mathias Krauss discovered an issue in the Transparent Inter Process
   Communication (TIPC) protocol support. Local users can gain access to
   sensitive kernel memory.
 
Hihi, was habe ich gelacht. :D

Reporting 1.2K crashes

Aber Linux ist ja sooo stabil.
rofl.gif
 
ich würd das gerne mal sehen, wenn die solche tools gegen andere system laufen lassen :D

ist das eigentlich was neuartiges, was die da mit mayhem entwickelt haben? wie genau geht so ein programm vor?
 
X11 hat nun endlich einen Grund zu Ruhm zu gelangen. ;)

This bug appears to have been introduced in the initial RCS version 1.1
checked in on 1991/05/10, and is thus believed to be present in every X11
release starting with X11R5 up to the current libXfont 1.4.6.
(Manual inspection shows it is present in the sources from the X11R5
tarballs, but not in those from the X11R4 tarballs.)

X.Org Security Advisory: CVE-2013-6462: Stack buffer overflow in parsing of BDF font files in libXfont
 
und das hat jetzt mit dem Topic gleich was zu tun

Das ist ganz einfach. Ein Fehler in (beliebiger) GNU, oder anderer (freier) Software, führt _speziell_ unter Linux zu verheerenden Problemen.

Während man z.B. unter iOS und der BSD Familie durch einen Fehler vielleicht mal eine Schriftar ändern kann (whoahh), bekommt man unter dem selben Fehler unter Linux die ganze Kiste gerootet.

Sicher. In erster Linie ist es ein Fehler in einer OS unabhängigen Software. Unter Linux jedoch, erblüht jeder kleine Bug oftmals zu einem bunten Supergau.
 
der BSD Familie durch einen Fehler vielleicht mal eine Schriftar ändern kann (whoahh),
Huch - wird NetBSD neuerdings irgendwo außerhalb des Geekkellers verwendet?
Sind die BSDler schon ansatzweise bei GRSecurity angekommen (google "BSD grsecurity" liefert nur Forenbeiträge/Mailinglisten :) )? Hat FreeBSD zumindest schon ASLR implementiert (außerhalb komischer Mailinglistenpatchs) oder sind die immer noch dabei, das gute alte APT abzukupfern?
Nur paar Popelfirmen wie Netflix lassen heutzutage FreeBSD auf ihrem Garagenserver laufen :).
Man braucht sich doch nur paar Tests bei phoronix anzuschauen, wie lahm BSD bzw. die Komponenten (z.B ZFS - siehe moronix: ZFS on a notebook hdd is lam3 | [Phoronix] Benchmarks Of ZFS-FUSE On Linux Against EXT4, Btrfs )
 
Ich kenne auch einige grössere Webplattformen, die FreeBSD einsetzen. Von den ganzen Loadbalancern und Firewall-Appliances, die FreeBSD-Derivate drauf haben, reden wir gar nicht erst.

Davon abgesehen hatte FreeBSD viele Funktionen von GRSecurity schon seit langem drin (über MAC und diverse Auditing-Tools) und in Linux ist GRSecurity auch keineswegs Standard sondern eher in Ausnahmefällen anzutreffen. Linuxer supporten ja lieber den NSA und ihr SELinux. ;)
 
Zurück
Oben