floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
Floridaboy schrieb: Also beim Rechner meiner Freundin sind die CPU-Bugs noch da, wenn ich das richtig verstehe:
[...]
Der CPUID-Befehl wirft bei mir nur ein "false" aus. Bei IUCODE_TOOL könnte man die ID herauslesen...: $ cpuid | grep "processor serial number" | head -n1
processor serial number = false
$ dpkg -l intel-microcode | grep ^ii
ii intel-microcode 3.20180108.1 amd64 Processor microcode firmware for Intel CPUs
$ iucode_tool -S -l /lib/firmware/intel-ucode/
iucode_tool: system has processor(s) with signature 0x00030678 Aber wie du schon geschrieben hast, ist da wohl noch kein Patch draußen.
Ja, deshalb hatte ich auch noch nicht geantwortet, da mir während des postens auffiel, dass in Deinem Post schon Hinweise auf die ID vorhanden waren. Dementsprechend hatte ich das schon vorher beantwortet. Wir müssen noch auf weitere patches (aka kernel und software updates) und microcodes warten.
|
Rosika
Anmeldungsdatum: 26. Februar 2016
Beiträge: 1355
|
Hallo floogy, danke für Deine Einschätzung und die Links. Es sind wirklich vertrauenswürdige Quellen, die das Skript referenzieren. Auch ich habe solche Querverweise bereits öfters gefunden.
Vielleicht bin auch etwas übervorsichtig. 😳 Ohne sudo scheint´s wohl nicht (richtig) zu funktionieren.... Ich habe mir das Skript mal angesehen, obwohl ich nicht allzuviel davon verstehe. So habe ich mich lediglich auf die Suche nach dem "rm"-Befehl gemacht und nur zwei Stellen gefunden:
539 trap "rm -f $vmlinuxtmp" EXIT
1650 [ -n "$dumped_config" ] && [ -f "$dumped_config" ] && rm -f "$dumped_config"
In beiden Fällen wurden die entsprechenden Variablen vorher definiert, so wie´s ausschaut. Ich denke (und hoffe) also auch, daß das
Skript sicherheitstechnisch unproblematisch ist. LG und ein schönes Rest-Wochenende. Rosika ☺
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
Zeile 539 stellt sicher, dass, falls das Skript unerwartet unterbrochen wird, dass das EXIT Signal aufgefangen wird um das vorher angelegte temporäre Datei wieder zu löschen. http://redsymbol.net/articles/bash-exit-traps/ Zeile 1650 löscht die Dumps der Kernel-Konfiguration, um die relevanten Optionen auszulesen mit denen der Kernel kompiliert wurde. Diese wurden etwa in Zeile 782 angelegt und später wurden sie ausgewertet. Es handelt sich also um Aufräumarbeiten um temporäre Daten, die das Skript zur Auswertung vorher selbst anlegte, wieder zu beseitigen. Das gleiche findet sich auch zu geladenen Kernel-Modulen. Es wird festgestellt, ob das Skript die entsprechenden Module selbst geladen hatte. Wenn ja werden sie, nachdem sie nicht mehr benötigt werden, mit rmmod wieder entfernt. Auch andere Auswertungen wie
| dd if=/dev/cpu/0/cpuid bs=16 skip=2147483656 iflag=skip_bytes count=1 >/dev/null 2>/dev/null
|
benötigen u.U. root-Rechte(?). In diesem Beispiel aus Zeile 974 werden wohl die return codes dd's ausgewertet. Damit werden z.B. das IBPB_SUPPORT und das SPEC_CTRL feature bit ausgelesen. In Zeile 1219 wird z.B. cat verwendet.
| ibpb_enabled=$(cat "$dir/ibpb_enabled" 2>/dev/null)
|
Die Umleitung (>, redirection) geht aber nach /dev/null und der Inhalt der Datei wird ausgewertet, ob ibpb eingeschaltet ist. Um sich alle Zeilen anzeigen zu lassen, die Umleitungen, Moduloperationen, rm oder cat enhalten anzeigen zu lassen, um zu kontrollieren, was sie machen, bzw. ob nach /dev/null oder in eine temporäre Datei umgeleitet wird kann man sich so behelfen:
| wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
egrep --color -n '>|<|^cat |cat |rm |^rm |mk|modpr|rmmod|dd.*of=|dd |^dd ' spectre-meltdown-checker.sh
|
Allerdings fehlen da wahrscheinlich noch viel Möglichkeiten ... Wie gesagt, flüchtig betrachtet konnte ich nichts finden, aber ich bin auch kein Experte im bash-Skripting.
|
Rosika
Anmeldungsdatum: 26. Februar 2016
Beiträge: 1355
|
Hi floogy, danke für die Aufklärung.
Es handelt sich also um Aufräumarbeiten um temporäre Daten, die das Skript zur Auswertung vorher selbst anlegte, wieder zu beseitigen.
So ungefähr habe ich das auch interpretiert, allerdings ohne die genauen Erklärungen, die Du gegeben hast, zu kennen. 😳 Jetzt wird auch besser verständlich, warum root-Rechte gebraucht werden. Danke auch für die Befehle, mit welchem man das Skript selbst versuchen kann zu analysieren. Auf jeden Fall verstehst Du eine Menge mehr als ich von der ganzen Sache. Letzten Endes ging es mir ja darum, sicherzustellen, dass das Skript mit den erhöhten Rechten nichts Systemrelevantes anstellt.
Aber da es ja allerorten empfohlen wird und auch nichts Negatives bekannt geworden ist, denke ich auch, dass man es wohl benutzen können wird. Viele Grüsse nochmals. Rosika ☺
|
Floridaboy
Anmeldungsdatum: 13. Februar 2015
Beiträge: Zähle...
|
floogy schrieb: Ja, deshalb hatte ich auch noch nicht geantwortet, da mir während des postens auffiel, dass in Deinem Post schon Hinweise auf die ID vorhanden waren. Dementsprechend hatte ich das schon vorher beantwortet. Wir müssen noch auf weitere patches (aka kernel und software updates) und microcodes warten.
Alles klar! Danke für die Rückmeldung! Floridaboy
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
Hier die Ausgabe der letzten beiden Skript-Versionen. v0.32
floogy@ubuntu:~$ sudo ./spectre-meltdown-checker_v32.sh
Spectre and Meltdown mitigation detection tool v0.32
Checking for vulnerabilities against running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i5-3475S CPU @ 2.90GHz
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 33 opcodes found, should be >= 70, heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available: NO
* The SPEC_CTRL CPUID feature bit is set: NO
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Checking if we're running under Xen PV (64 bits): NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
A false sense of security is worse than no security at all, see --disclaimer
v0.33
Hilfe
floogy@ubuntu:~$ sudo spectre-meltdown-checker/spectre-meltdown-checker.sh --help
Spectre and Meltdown mitigation detection tool v0.33
Usage:
Live mode: spectre-meltdown-checker.sh [options] [--live]
Offline mode: spectre-meltdown-checker.sh [options] [--kernel <vmlinux_file>] [--config <kernel_config>] [--map <kernel_map_file>]
Modes:
Two modes are available.
First mode is the "live" mode (default), it does its best to find information about the currently running kernel.
To run under this mode, just start the script without any option (you can also use --live explicitly)
Second mode is the "offline" mode, where you can inspect a non-running kernel.
You'll need to specify the location of the vmlinux file, config and System.map files:
--kernel vmlinux_file Specify a (possibly compressed) vmlinux file
--config kernel_config Specify a kernel config file
--map kernel_map_file Specify a kernel System.map file
Options:
--no-color Don't use color codes
--verbose, -v Increase verbosity level
--no-sysfs Don't use the /sys interface even if present
--sysfs-only Only use the /sys interface, don't run our own checks
--coreos Special mode for CoreOS (use an ephemeral toolbox to inspect kernel)
--batch text Produce machine readable output, this is the default if --batch is specified alone
--batch json Produce JSON output formatted for Puppet, Ansible, Chef...
--batch nrpe Produce machine readable output formatted for NRPE
--variant [1,2,3] Specify which variant you'd like to check, by default all variants are checked
Can be specified multiple times (e.g. --variant 2 --variant 3)
Return codes:
0 (not vulnerable), 2 (vulnerable), 3 (unknown), 255 (error)
IMPORTANT:
A false sense of security is worse than no security at all.
Please use the --disclaimer option to understand exactly what this script does. Ausgabe
floogy@ubuntu:~$ sudo spectre-meltdown-checker/spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.33
Checking for vulnerabilities on current system
Kernel is Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i5-3475S CPU @ 2.90GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 33 opcodes found, should be >= 70, heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
* Retpoline enabled: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
A false sense of security is worse than no security at all, see --disclaimer Batch-Mode (text)
floogy@ubuntu:~$ sudo spectre-meltdown-checker/spectre-meltdown-checker.sh --live --batch
CVE-2017-5753: VULN (only 33 opcodes found, should be >= 70, heuristic to be improved when official patches become available)
CVE-2017-5715: VULN (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754: OK (PTI mitigates the vulnerability) Mit 4.4.0-112-generic
floogy@ubuntu:~$ sudo spectre-meltdown-checker/spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.33
Checking for vulnerabilities on current system
Kernel is Linux 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i5-3475S CPU @ 2.90GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES
> STATUS: NOT VULNERABLE (115 opcodes found, which is >= 70, heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: YES
* Currently enabled features
* IBRS enabled for Kernel space: NO (echo 1 > /proc/sys/kernel/ibrs_enabled)
* IBRS enabled for User space: NO (echo 2 > /proc/sys/kernel/ibrs_enabled)
* IBPB enabled: NO (echo 1 > /proc/sys/kernel/ibpb_enabled)
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
* Retpoline enabled: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
A false sense of security is worse than no security at all, see --disclaimer
Batch-Mode (text)
floogy@ubuntu:~$ sudo spectre-meltdown-checker/spectre-meltdown-checker.sh --batch
CVE-2017-5753: OK (115 opcodes found, which is >= 70, heuristic to be improved when official patches become available)
CVE-2017-5715: VULN (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754: OK (PTI mitigates the vulnerability) A false sense of security is worse than no security at all, see --disclaimer
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
Das Skript, das an früherer Stelle, hier im Thread auch schon von fandPfand referenziert wurde, ist in debian-sid. Ich halte es daher für unbedenklich und brauchbar. https://packages.debian.org/sid/spectre-meltdown-checker copyright
Format : https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: spectre-meltdown-checker Source: https://github.com/speed47/spectre-meltdown-checker Files :* Copyright: 2018 Stéphane Lesimple
License : GPL-3+
Files : debian/* Copyright : 2018 Sylvestre Ledru <sylvestre@debian.org>
License : GPL-3+ License : GPL-3+ This program is free software : you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
. This package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details. . You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. . On Debian systems, the complete text of the GNU General
Public License version 3 can be found in "/usr/share/common-licenses/GPL-3".
README.md
Spectre & Meltdown Checker
A simple shell script to tell if your Linux installation is vulnerable against the 3 "speculative execution" CVEs that were made public early 2018.
Without options, it'll inspect your currently running kernel.
You can also specify a kernel image on the command line, if you'd like to inspect a kernel you're not running.
The script will do its best to detect mitigations, including backported non-vanilla patches, regardless of the advertised kernel version number.
![checker](https://framapic.org/6O4v4AAwMenv/M6J4CFWwsB3z.png)
**CVE-2017-5753** bounds check bypass (Spectre Variant 1)
Impact: Kernel & all software Mitigation: recompile software *and* kernel with a modified compiler that introduces the LFENCE opcode at the proper positions in the resulting code Performance impact of the mitigation: negligible
**CVE-2017-5715** branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
**CVE-2017-5754** rogue data cache load (Meltdown) Impact: Kernel Mitigation: updated kernel (with PTI/KPTI patches), updating the kernel is enough Performance impact of the mitigation: low to medium
This tool does its best to determine whether your system is immune (or has proper mitigations in place) for the collectively named "speculative execution" vulnerabilities. It doesn't attempt to run any kind of exploit, and can't guarantee that your system is secure, but rather helps you verifying whether your system has the known correct mitigations in place. However, some mitigations could also exist in your kernel that this script doesn't know (yet) how to detect, or it might falsely detect mitigations that in the end don't work as expected (for example, on backported or modified kernels).
Your system exposure also depends on your CPU. As of now, AMD and ARM processors are marked as immune to some or all of these vulnerabilities (except some specific ARM models). All Intel processors manufactured since circa 1995 are thought to be vulnerable. Whatever processor one uses, one might seek more information from the manufacturer of that processor and/or of the device in which it runs.
The nature of the discovered vulnerabilities being quite new, the landscape of vulnerable processors can be expected to change over time, which is why this script makes the assumption that all CPUs are vulnerable, except if the manufacturer explicitly stated otherwise in a verifiable public announcement.
This tool has been released in the hope that it'll be useful, but don't use it to jump to conclusions about your security.
spectre-meltdown-checker (head)
#! /bin/sh
# Spectre & Meltdown checker
#
# Check for the latest version at:
# https://github.com/speed47/spectre-meltdown-checker
# git clone https://github.com/speed47/spectre-meltdown-checker.git
# or wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
#
# Stephane Lesimple
#
VERSION=0.33
show_usage()
[...]
changelog.Debian.gz
spectre-meltdown-checker (0.33-1) unstable; urgency=medium
* New upstream release
-- Sylvestre Ledru <sylvestre@debian.org> Sat, 27 Jan 2018 14:48:27 +0100
spectre-meltdown-checker (0.32-1) unstable; urgency=medium
* New uptream release
-- Sylvestre Ledru <sylvestre@debian.org> Mon, 22 Jan 2018 11:57:20 +0100
spectre-meltdown-checker (0.31-1) unstable; urgency=medium
* New upstream release
- Return sensible exit code (Closes: #887077)
-- Sylvestre Ledru <sylvestre@debian.org> Mon, 15 Jan 2018 08:56:11 +0100
spectre-meltdown-checker (0.29-1) unstable; urgency=medium
* New upstream release
-- Sylvestre Ledru <sylvestre@debian.org> Sun, 14 Jan 2018 12:19:45 +0100
spectre-meltdown-checker (0.28-1) unstable; urgency=medium
* New upstream release
* Add a watch file
* Move to "Architecture: all"
* New the option --version for help2man
* Remove a full path in the manpage
-- Sylvestre Ledru <sylvestre@debian.org> Sat, 13 Jan 2018 12:45:55 +0100
spectre-meltdown-checker (0.27-1) unstable; urgency=medium
* Initial release (Closes: #887033)
-- Sylvestre Ledru <sylvestre@debian.org> Thu, 11 Jan 2018 11:58:36 +0100
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
Das zeigt sehr gut, was für ein Chaos bei Intel herrscht.
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
aiaiai, ich geb hier mal ein nicht verifiziertes Gerücht weiter: https://blog.fefe.de/?ts=a485e7ee Mir wird gerade ein Gerücht zugetragen, das ich hier mal unverifiziert weitergebe. Und zwar soll Intel das Microcode-Update zurückgezogen haben, nicht weil es zu Crashes kommt, sondern weil der Microcode zu Überhitzungen führt, die sogar den Sockel beschädigen können. Die "unexpected reboots" in der Intel-Pressemitteilung sind laut dieses Gerüchtes dann nicht "oh hups ich boote mal" sondern ein "ach du Scheiße der Prozessor ist viel zu heiß, Not-Aus". Der Prozessor soll bei der Stelle aber schon über 150% des TDP gezogen haben. Angeblich soll das bei Amazon in der Cloud schon zu Hardware-Ausfällen geführt haben. Wow, das würde erklären, wieso Intel die Updates so hastig zurückgezogen hat.
Ich hatte einer meiner Dell Kisten hier auch schon mit einem BIOS update versorgt, allerdings hatte Dell das jetzt auch wieder zurückgezogen. Ich hatte keine Reboots oder Temperaturprobleme gemerkt, hatte aber bei Last jetzt regelmässig: | mce: [Hardware Error]: Machine check events logged
|
in den logs. Ich flashe jetzt mal das vorherige BIOS wieder zurück. EDIT:
Anstatt dem 0x23 hab ich jetzt wieder den 0x22 microcode für meinen Haswell Xenon. Und die mce Fehler treten unter Last auch nicht mehr auf.
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
|
Floridaboy
Anmeldungsdatum: 13. Februar 2015
Beiträge: 184
|
Hm..., geht ja alles recht zäh von statten. Eigentlich absolut inakzeptabel!!! Bin echt sauer!!!
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
Einfach direkt bei Intel melden. Und beim nächsten Chip-Kauf als Faktor mit einrechnen. Der Geschwindigkeits-Vorteil von Intel gegenüber AMD ist seit den Meltdown-Patches auch eigentlich nicht mehr da. Hat schon seinen Grund gehabt, warum die Intel Manager während des 6 monatigem Embargo ihre Aktien auf den Minimalanteil reduziert haben.
|
Floridaboy
Anmeldungsdatum: 13. Februar 2015
Beiträge: 184
|
1. Die werden auf meine Meldung einen Schei** geben.
2. Vielleicht ist beim nächsten Chipkauf INTEL gar nicht mehr vertreten. Zumindest bei mir. Mal sehen wie sich ARM entwickelt...
|
Knarf68
Anmeldungsdatum: 14. Mai 2013
Beiträge: 2701
|
Da ist die Opensource Kommunity flotter. Mit Kernel 4.15 ist scheinbar alles wieder paletti ( mit Software Tricks ). Momentan sehe ich Intel auch als nicht kaufbar.
|