LN-Waschpress

Kategorie: Hardware

  • Prozessor-Bug: Schadensbegrenzung beim Super-Gau

    Prozessor-Bug
    Bild: „CPU“ von Jaroslaw W Lizenz: CC-By-2.0

     

    Am dritten Tag nach der Veröffentlichung des mit Fug und Recht als Super-GAU bezeichneten Bugs in den meisten seit 1995 produzierten Prozessoren wird das gesamte Ausmaß des katastrophalen Fehlers klar: es handelt sich um einen in Silizium gegossenen Design-Fehler, der Milliarden von Geräten betrifft, von denen viele niemals einen Fix sehen werden. Dazu zählen vor allem viele Android-Smartphones. Über den Umfang der Auswirkungen auf AMD-Prozessoren besteht weiterhin Unklarheit. AMD selbst hatte die Chance, die Lücken beträfen auch AMD-CPUs als nahe Null bezeichnet.

    Entwarnung für Heimanwender

    Etwas Entwarnung gibt es dagegen bei den zu erwartenden Performance-Einbrüchen für durchschnittliche Heimanwender. Wer an seinem Rechner hauptsächliche surft, spielt und Office-Aufgaben erledigt, wird kaum einen Verlust an Geschwindigkeit verspüren, die Werte sollten im niedrigen einstelligen Bereich liegen. Anders kann das im Büro aussehen, wenn etwa große Datenbanken betrieben werden. Hier kann die Höchststrafe unter Umständen bei bis zu 30 Prozent liegen. Das liegt hauptsächlich daran, dass die Fixes für die Lücken die I/O-Last nach oben treiben.

    Intel in bekannter Manier

    Viele Hersteller haben sich zu Wort gemeldet, Intel gleich zwei Mal. Die Nachricht aus dem Intel Newsroom ist ähnlich vage und nichtssagend wie die vom Vortag. Dort heißt es:

    »Intel hat Updates für alle Arten von Intel-basierten Computersystemen – einschließlich PCs und Servern – entwickelt und veröffentlicht, die diese Systeme gegen beide von Google Project Zero gemeldeten Exploits (als „Spectre“ und „Meltdown“ bezeichnet) immun machen. Intel und seine Partner haben bedeutende Fortschritte bei der Bereitstellung von Updates erzielt, sowohl bei Software-Patches als auch bei Firmware-Updates.«

    In weiteren Verlauf der Verlautbarung stellt sich Intel an die Speerspitze derer, die Lösungen für das Problem anbieten, ohne dabei konkret zu sagen, was Intel den Betroffenen anbietet. Am Ende gibt es einen Link, der zumindest weitere technische Einzelheiten enthält, aber nichts an den Tag bringt, was nicht bereits bekannt war und von anderer Seite mit wesentlich mehr Details veröffentlicht wurde. Zudem behauptet Intel dort weiterhin, es handle sich nicht um einen Fehler in Intels Hardware. Die Begründung lautet, es seien auch andere Hersteller betroffen. Diese Logik wirkt zumindest befremdlich.

    Betroffene Intel-CPUs aufgelistet

    Die zweite Veröffentlichung von Intel stammt aus dem hauseigenen Security Center und erweist sich als nützlicher, denn sie nennt im Detail die betroffenen Plattformen und Prozessoren aus eigener Produktion. Zudem bedankt sich Intel bei den Forschern von Google und der Universität Graz, die die Lücke in etwa zeitgleich entdeckt hatten.

    ARM reagiert vorbildlich

    ARM hat ausführlich und übersichtlich Stellung zu den betroffenen Prozessoren und dem, was ein Anwender zur Absicherung tun sollte Stellung bezogen. Dabei wird pro betroffenem Prozessor dargestellt, welche der drei Varianten auf den jeweiligen Cortex-Kern zutrifft. Leider wird das vielen betroffenen Smartphone- und Tablet-Besitzern nicht viel nützen, da es vom Hersteller des Geräts abhängt, wann ein Update angeboten wird. Für viele Geräte wird das heißen: niemals. Googles eigene Baureihen Nexus und Pixel haben bereits ein Update für Januar erhalten oder es ist in der Auslieferung und wird zeitnah aufgespielt.

    Google stellt Retpoline vor

    Google hat ebenfalls am gestrigen Tag weitere Details veröffentlicht. Darin geht es hauptsächlich um die von Google erstellten Gegenmaßnahmen und die zu erwartenden Leistungseinbußen. Dabei stellt Google eine neue Technik zur Entschärfung namens Retpoline vor, die gegen Spectre, auch als »Branch Target Injection« bezeichnet, eingesetzt werden kann und wenig Leistungseinbußen nach sich ziehen soll. Retropline ist ein zusammengesetzter Begriff aus den Worten »return trampoline«. Die Technik verwendet eine Endlosschleife, die nie ausgeführt wird, um die CPU daran zu hindern, auf das Ziel eines indirekten Sprunges zu spekulieren. Entwickler Paul Turner hat die Technik gestern auch den Kernel-Entwicklern vorgestellt.

    Distributionen verteilen KPTI-Patches

    Die großen Linux-Distributionen haben Kernel veröffentlicht, die die KPTI-Patches gegen die Lücken verteilen. Microsoft hat wegen der Brisanz der Lücken die Auslieferung weiterer Patches für Windows 10 vorgezogen, die ab dem 03. Januar 2018 ab 22 Uhr verteilt werden sollen. Patches für ältere Versionen wie Windows 7 und  8 sollen zum nächsten Microsoft Patchday folgen. Bei den jetzt für Windows 10 angebotenen Updates gab es vereinzelt Kompatibilitätsprobleme mit Anti-Viren-Software. Microsoft rät dringend dazu, das Update nicht manuell zu forcieren, sondern erst einzuspielen wenn es über die Update-Funktion angeboten wird.

    Firefox vorerst abgesichert

    Mozilla hat als Reaktion auf die Lücke Firefox 57.0.4 veröffentlicht. Als vorübergehende Maßnahme, bis die genaue Funktionalität der Lücken bekannt sei, hat Mozilla die Genauigkeit der Zeitintervalle über die Funktion performance.now() von 5μs auf 20μs heraufgesetzt, um Javascript-Angriffe zu erschweren, die auf die Messung präziser Zeitintervalle angewiesen sind. Zudem wurde der SharedArrayBuffer-Standard deaktiviert, um die Verwendung höher auflösender Timer zu verhindern. Auch Google, Apple und Microsoft haben ihre Browser entsprechend gepatched. Diese sind allerdinmgs im Gegensatz zu Firefox noch nicht veröffentlicht. Micosoft wird Edge am 9. Januar aktualisieren, Google Chrome 64 erscheint am 23. Januar.

    Mitlesen von der Tastatur

    Auf LWN gibt es einen  Überblick über weitere interessante Links zum Thema. Auch ein Interview der Berliner Zeitung  »Der Tagesspiegel« mit einem der Entdecker der Lücken von der Universität Graz lohnt das Lesen. Michael Schwarz erläutert darin, man könnte theoretisch alles mitlesen, was gerade auf der Tastatur eingegeben wird. Die Lücken können allerdings nur ausgenutzt werden, wenn bereits Zugriff auf den Rechner besteht.

    Das trifft allerdings nur für Meltdown zu, Spectre kann bereits über den Browser ausgenutzt werden. Allerdings ist es mit Spectre wesentlich schwerer, Daten auszulesen. Hierbei müssen sehr präzise Timings eingehalten werden, zudem muss der Angreifer wissen, welche Prozesse gerade laufen und welche Daten sich im Speicher befinden. Schwarz bestätigt, dass Meltdown bisher nur auf Intel-Prozessoren reproduziert wurde. Spectre schließt auch alle Smartphones mit ARM-Prozessoren ein.

    Linus Torvalds not amused

    Die Kernel-Entwickler bei Linux sind alles andere als erfreut über die Art und Weise, wie die Informationspolitik im Hinblick auf die Lücken gehandhabt wurden, die Intel seit Juni 2017 bekannt waren. Linus Torvalds äußert sich für seine Verhältnisse sehr zurückhaltend zu Intels PR:

    »Ich denke, dass jemand innerhalb von Intel wirklich einen langen harten Blick auf ihre CPUs werfen muss, und tatsächlich zugeben muss, dass sie Probleme haben, anstatt PR-Blurbs zu schreiben, die besagen, dass alles so funktioniert, wie es entworfen wurde….

    …Oder sagt Intel im Grunde genommen, dass sie darauf abonniert sind, uns für immer und ewig Scheiße zu verkaufen und nie etwas zu reparieren? Denn wenn das der Fall ist, sollten wir vielleicht anfangen, uns mehr auf die ARM64-Leute zu konzentrieren.«

    Zu spät informiert

    Andere Entwickler monieren, dass die Betriebssystemhersteller viel zu spät über die Vorgänge informiert worden seien und nun zum Schutz ihrer Anwender unter Zeitdruck Gegenmaßnahmen entwerfen mussten. Nach Aussagen von Mounir Hahad, Chef der Sicherheitsanalyse bei Juniper Networks, konnte bisher in freier Wildbahn kein Fall entdeckt werden, der die Lücken ausnutzt. Da diese Lücken aber schon seit rund 20 Jahren bestehen, kann niemand mit Bestimmtheit sagen, ob sie nicht in der Vergangenheit bereits von Geheimdiensten oder Kriminellen ausgenutzt wurden.

    Eines ist jedoch bereits jetzt klar: Die Auswirkungen dieses Design-Fehlers werden uns noch lange begleiten und beschäftigen. Ganz besonders im Fall von Spectre, da hier jede Anwendung einzeln gegen die Lücke abgeichert werden muss. die Kernel-Patches reichen hier nicht aus.

  • CPU-Fehler: Intel wiegelt ab

    Bild: „Intel@Sandybridge@Ivy_Bridge-EX_(Ivytown)@Xeon_E7_V2@QDPJ_ES___Stack-DSC07905-DSC07945_-_ZS-retouched“Fritzchens Fritz Lizenz: CC0

     

    Mittlerweile ist etwas Licht in das Dunkel um den vermeintlichen Fehler in Intel-CPUs gekommen, der gestern für mächtiges Rauschen im digitalen Blätterwald sorgte. Das ist allerdings nicht Intel zu verdanken, die sich gestern Abend zu Wort meldeten. Eigentlich sei eine Stellungnahme erst später geplant gewesen, im Licht der fehlerhaften Pressemitteilungen sehe man sich aber veranlasst, sich bereits jetzt zu äußern.

    Intel wiegelt ab

    Zunächst wird einmal die Gefährlichkeit der Sicherheitslücke heruntergespielt wenn Intel schreibt, nach Unternehmensansicht hätten diese Exploits nicht das Potential, Daten zu beschädigen, zu verändern oder zu löschen. Des Weiteren sei es nicht korrekt, das der Fehler, der solche Exploits erlaube, nur bei Intel-Produkten anzutreffen sei. Nach jetzigem Sachstand seien »viele Arten von Computergeräten – mit Prozessoren und Betriebssystemen verschiedener Hersteller – anfällig für diese Angriffe.« Man arbeite eng mit anderen Unternehmen, unter anderem auch AMD und ARM Holdings und mit Betriebssystemherstellern zusammen um dieses Problem schnell und konstruktiv zu beseitigen.

    Die zu erwartenden Performance-Einbussen spielt Intel herunter, diese seien für Privatanwender nicht signifikant und würden mit der Zeit abgeschwächt. Hier hat Intel vermutlich sogar recht, denn die vereinzelt gemeldeten Werte von 30 bis 50 Prozent entsprechen nicht dem zu erwartenden Einbruch. Aber selbst Werte um fünf Prozent und bei NVMe-SSDs auch mehr sind nicht hinnehmbar.

    Google redet Klartext

    Etwas klarer wird das Bild, liest man sich die kurz darauf veröffentlichte Erklärung von Google durch, die auch mit technischen Einzelheiten aufwartet. Die Lücke sei letztes Jahr im Rahmen von Googles Forschung im Rahmen von Project Zero entdeckt worden. Dabei handelt es sich um ein Forschungsprojekt zur Sicherheit und Verhinderung von Angriffen auf Computer und Netzwerke. Bereits im zweiten Satz wird klar, dass die Aussage von Kernel-Entwickler Thomas Lendacky zutreffend war und der Hase bei der speculative execution begraben liegt. Die spekulative Ausführung verwendet untätige Ressourcen der CPU,  um den folgenden Programmfluss vorauszusagen und Daten spekulativ vorzuhalten, die vermutlich demnächst gebraucht werden. Wo der bei AMD angestellte Kernel-Entwickler Lendacky – vorsichtig formuliert – vermutlich falsch lag, ist, dass AMD nicht betroffen ist.

    Google stellt klar, dass fast alle modernen CPUs die »spekulative Ausführung« einsetzen. Zudem habe Jann Horn, einer der Forscher des Project Zero, demonstriert, dass Angreifer die spekulative Ausführung dafür nutzen könnten um Bereiche des Kernelspeichers auszulesen, die unprivilegiert nicht im Zugriff sein sollten. Dabei könnten Passwörter, Schlüssel und weitere Daten aus offenen Anwendungen gestohlen werden. Google widerspricht damit klar der Aussage von Intel, dass Daten nicht gefährdet seien.

    Alle Hersteller betroffen

    Google sagt auch klar, die Verwundbarkeit betreffe viele CPUs, unter anderem auch die von Intel, AMD und ARM. Man habe sowohl die eigenen Produkte abgesichert als auch anderen Betroffenen geholfen, deren Anwender zu schützen. Bei Android sei darauf zu achten, dass die letzten Sicherheits-Updates eingespielt seien. Das dürfte allerdings nur für Besitzer von Nexus- und Pixel-Phones so einfach zu befolgen sein. Die meisten anderen Hersteller hängen um Monate hinterher. Bei Google Chrome sei darauf zu achten, dass die aktuelle Version des Browsers genutzt wird.

    Technische Ausarbeitung

    Mittlerweile liegt auch Googles Papier mit der technischen Ausarbeitung der Lücke vor. Daraus geht hervor, dass Google seine Forschungsergebnisse sowie erfolgreiche Exploits gegen einige CPUs von Intel, AMD und ARM den Herstellern bereits am 1. Juni 2017 bekanntgegeben hat. Auch IBMs System Z, POWER8 (Big Endian und Little Endian) und POWER9 (Little Endian) sollen betroffen sein. Zudem wird klar, dass es mehrere Varianten gibt, die die Kennzeichnungen CVE-2017-5753, CVE-2017-5715 und CVE-2017-5754 erhalten haben. Wie mittlerweile üblich erhielt die Lücke auch Namen und drollige Icons.  Dabei sind unter Spectre CVE-2017-5753 und CVE-2017-5715 zusammengefasst, Meltdown steht für CVE-2017-5754

    Meltdown scheint nach jetzigem Stand Intel-CPUs seit 1995 zu betreffen, Ausgenommen sind lediglich Itanium und Atom-CPUs vor 2013. Spectre sei schwerer auszunutzen, aber auch schwerer zu stopfen. Hiervon sind laut Google alle modernen CPUS von Intel, AMD und ARM betroffen. So kann Spectre durch Page-Table Isolation im Kernel nicht ausreichend behoben werden sondern muss in vielen Anwendungen aktiv verhindert werden. Hier sieht Google die Entwicklergemeinde noch eine ganze Weile mit der Sache befasst.

    Amazon, Apple, AMD

    Auch Amazon meldete sich am gestrigen Abend zu Wort. AWS sei sich der Verwundbarkeiten bewusst. Die Lücke existiere seit über 20 Jahrfen in modernen Prozessor-Architekturen von  Intel, AMD und ARM auf Severn, Desktops und Mobilgeräten. Der überwiegende Teil der Amazon EC2-Flotte sei bereits gegen den Fehler gepatched, die verbleibenden Server würden in den nächsten Stunden abgesichert. Für Amazon Linux liegt ein aktualisierter Kernel bereits vor. Apple meldete gestern auf Twitter, die Lücke sei teilweise bereits am 6. Dezember mit macOS 10.13.2 geschlossen worden. Die komplette Absicherung werde mit macOS 10.13.3 ausgeliefert, dass sich derzeit in der Beta-Phase befinde.

    Zu guter letzt meldete sich auch AMD mit einer Stellungnahme. Der Sender CNBC meldete, AMD sehe sich nicht von allen drei Varianten der Lücke betroffen und das Risiko für AMD-Kunden sei aufgrund einer anderen Implementierung der Funktion der spekulativen Ausführung derzeit »nahe Null«. Mittlerweile hat AMD seine Ausführungen weiter konkretisiert. Linus Torvalds fordert Intel auf, die Fehler zuzugeben anstatt weiter zu leugnen

     

  • Gefährlicher Design-Fehler in Intel CPUs

    Fehler in Intel CPUs
    Bild: „Intel“ von Christian Rasmussen Lizenz: CC By-SA-2.0

     

    Nach den Erkenntnissen der letzten Wochen zu Intel ME scheint Intel auch 2018 nicht aus den negativen Schlagzeilen herauszukommen. In einem Blog erschien am 1. Januar  ein Artikel, der Hinweise auf einen Fehler sammelte, der anscheinend alle Intel-CPUs der letzten Jahre betrifft. Der Artikel weist zwar einige Fehler und vorschnelle Annahmen auf, folgt aber generell der richtigen Spur. Eine Beseitigung der Sicherheitslücke dahinter ist nur durch teils massive Änderungen an den einzelnen Betriebssystemen möglich, er kann anscheinend nicht in Intels Microcode repariert werden.

    Linux- und Windows-Patches vorhanden

    Bei Linux sind die Patches teilweise in Kernel 4.15 integriert und weitere für 4.16 geplant. Seit gestern abend ist bereits Kernel 4.14.11 gepatched. Bei Windows wurden sie den Benutzern des Fast Ring bereits im alten Jahr ausgeliefert und sollen an einem der nächsten Microsoft-Patchdays offiziell ausgeliefert werden. Apple schweigt sich wie üblich aus. Aber auch Intel hüllt sich über den Fehler in Schweigen. Die Kommentare in den Patches, die die Sicherheitslücke stopfen, verschleiern die technischen Hintergründe.

    Viel geteilter Blogeintrag

    Aufmerksam war der Autor des ersten Berichts durch hektisches Treiben bei den Kernel-Entwicklern in den letzten Wochen und über die Feiertage geworden. Tiefgreifende Änderungen am Virtual-Memory-Subsystem des Kernels, die ansonsten oft über Monate und Jahre diskutiert werden, bevor eine Zeile Code einfließt, brauchten nur wenige Wochen um in Kernel 4.15 einzufließen, der vermutlich in zwei Wochen veröffentlicht wird.

    Hektik bereits seit Oktober

    Der entsprechende Bug hat derzeit den Status embargoed, was bedeutet, dass betroffene Institutionen Kenntnis davon haben, der Fehler aber noch nicht veröffentlicht ist. Die zugrundeliegende Sicherheitslücke und die seit Oktober einfließenden Patches wurden zuerst am 20. Dezember auf LWN näher gewichtet. Der dortige Artikel ist derzeit aber nur für Abonnenten zugänglich und wird erst in den nächsten Tagen freigegeben.

    Torvalds lässt Patches für 4.15-rc4 zu

    Linus Torvalds hatte sich zu den sogenannten KAISER-Patches, die seitdem in KPTI für Kernel-Page-Table-Isolation umbenannt wurden, am 27. November dahingehend geäußert, er würde die Patches lieber in 4.16 sehen, wies aber auch gleich auf die Notwendigkeit der Portierung in die zurückliegenden LTS-Kernel 4.9 und 4.14 hin. Trotzdem flossen in 4.15-rc4 vorbereitende Patches ein, der Großteil wird, der gebotenen Sorgfalt bei solch tiefgreifenden Änderungen geschuldet,  erst mit 4.16 ausgeliefert.

    Künftig getrennte Page-Table-Bereiche

    Was steckt nun hinter dem ganzen geschäftigen Treiben? Die Kernel-Entwickler trennen damit strikt die Page Tables, die derzeit noch von Kernel- und User-Space gemeinsam genutzt werden, in zwei völlig getrennte Sätze auf. Damit wollen sie verhindern, dass ein unprivilegierter Prozess auf den Speicherbereich im Kernel-Space zugreifen kann. Nach bisherigem Erkenntnisstand kann ein Prozess eine Intel-CPU durch Ausnutzen der Sicherheitslücke dazu bringen, Speicherbereiche zu prefetchen und dann durch Aushebeln der Zugriffskontrolle direkten Zugriff auf den Kernel-Bereich zu erhalten. Zudem könnte auch der Sicherheitsmechanismus ASLR ausgehebelt werden. Die auslösenden Prozesse können von normalen Anwendungen wie Office-Anwendungen bis hin zum JavaScript in Web-Browsern stammen. Im schlimmsten Fall könnten manipulierte Anwendungen oder Anwender den Kernelspeicher auslesen, der alle möglichen Geheimnisse wie Passwörter und weitere Zugangsdaten enthalten kann. Stellt man sich das auf öffentlichen Cloud-Servern vor, wird das mögliche Ausmaß klar.

    Systemaufrufe bald langsamer

    Wenn eine Anwendung in eine Datei schreiben oder eine Netzwerkverbindung öffnen will, muss sie dazu vorübergehend die Kontrolle über den Prozessor an den Kernel abgeben. Um den Übergang vom User-Modus in den Kernel-Modus und zurück so schnell und effizient wie möglich zu gestalten, hat der Kernel Zugriff auf den  virtuellen Adressraum aller Prozesse, obwohl dieser für die Anwendung unsichtbar ist. Wenn der Kernel benötigt wird, führt das Programm einen Systemaufruf (syscall) durch, der Prozessor wechselt in den Kernel-Modus und hat Zugriff auf den Kernel. Wenn das erledigt ist, wird die CPU aufgefordert, in den Benutzermodus zurückzukehren und den Prozess erneut zu starten. Im Benutzermodus bleiben der Code und die Daten des Kernels für die Anwendung unsichtbar, ist aber in den Page Tables des Prozesses vorhanden.

    AMD vermutlich nicht betroffen

    Diese Sicherheitslücke ist in hohem Maße für virtuelle Maschinen und Container relevant, wo Bereiche mit Kernel-Techniken isoliert werden und ein Ausbrechen daraus kritisch sein kann. Nach Angaben des Kernel-Entwicklers Thomas Lendacky, der bei AMD beschäftigt ist, sind AMD-CPUs nicht betroffen. Er schreibt dazu auf LKML: » Die AMD-Mikroarchitektur erlaubt keine Speicherreferenzen, einschließlich spekulativer Verweise, die auf höher privilegierte Daten zugreifen, wenn sie in einem weniger privilegierten Modus ausgeführt werden, wenn der Zugriff zu einem Seitenfehler führen würde.«

    Mindestens 5 Prozent Strafe

    Also kann, wenn sich das bewahrheitet, für AMD-Prozessoren der KPTI-Patchset entfallen. Das könnte sich als Wettbewerbsvorteil herausstellen, da mit der Trennung der Page Tables ein anwendungsabhängiger Performance-Verlust von derzeit geschätzten mindestens fünf Prozent einhergeht. Diese Geschwindigkeitseinbußen entstehen dadurch, dass pro Syscall-Kontextwechsel ein TLB-Flush notwendig wäre. In Phasen ohne Syscall soll der TLB weiter wie gewohnt arbeiten. Modernere Intel-CPUs können dem TLB-Flush mit der PCID-Technik etwas entgegenwirken. Auf Phoronix gibt es erste Benchmarks dazu.

    Des Pudels Kern?

    Eines der Schlüsselwörter in der Aussage von Lendacky ist »spekulative Referenzen«. Bereits bei der Durchsicht der ursprünglichen KAISER-Patches von Sicherheitsforschern der Universität zu Graz stellte der Reviewer Anders Fogh in seinem Bericht fest: »Meine Ergebnisse zeigen, dass die spekulative Ausführung trotz Verstößen gegen die Isolation zwischen Kernel- und Benutzermodus tatsächlich weiter ausgeführt wird.« Hier könnte nach heutiger Erkenntnis der auslösende Fehler in Intels Silizium liegen.

    Intel schweigt

    Im Moment ist vieles an dieser Sicherheitslücke noch recht spekulativ, vor allem fehlen Informationen von Intel selbst. Klar ist, dass die Lücke besonders im Unternehmensumfeld ausgenutzt werden könnte. Große Cloud-Anbieter wie Amazon und Microsoft Azure haben bereits kurzfristig Wartungsmaßnahmen und Reboots angekündigt, ohne dabei jedoch ein mögliches Problem zu erwähnen.

    Klar scheint auch zu sein, dass der Patch erst beim Booten aktiviert wird und somit AMD-CPUs von dem Performance-Verlust nicht betroffen sein werden. Unklar ist noch, wie weit genau die Lücke bei Intel-CPUs zurückreicht. Bisher sieht es aber so aus, als seien mindestens alle Intel-CPUs der letzten zehn Jahre betroffen.