[gelöst] Secure Erase nicht möglich bei SSD?

[Houbey]

Moin Debianer und Debianerinnen!

Ich habe da mal eine kurze Frage, da mir heute etwas aufgefallen ist. Wir haben mehrere SSD's, alle von Patriot, jeweils von den Modellen "Burst Elite".Zwei von denen haben 240 GB.

Die eine im Rechner ist laut hdparm diese hier:

Code: Alles auswählen

hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
	Model Number:       Patriot Burst Elite 240GB               
	Serial Number:      PBEABBB211125083021 
	Firmware Revision:  U1124A0 
	Media Serial Num:   
	Media Manufacturer: 
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
	Used: unknown (minor revision code 0x0110) 
	Supported: 9 8 7 6 5 
	Likely used: 9
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:    16514064
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:   468862128
	Logical  Sector size:                   512 bytes
	Physical Sector size:                   512 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:      228936 MBytes
	device size with M = 1000*1000:      240057 MBytes (240 GB)
	cache/buffer size  = unknown
	Form Factor: 2.5 inch
	Nominal Media Rotation Rate: Solid State Device
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 1	Current = 1
	Advanced power management level: 254
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	DOWNLOAD_MICROCODE
	   *	Advanced Power Management feature set
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
	   *	WRITE_UNCORRECTABLE_EXT command
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Gen3 signaling speed (6.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Phy event counters
	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
	   *	DMA Setup Auto-Activate optimization
	   *	Software settings preservation
	   *	SANITIZE feature set
	   *	BLOCK_ERASE_EXT command
	   *	DOWNLOAD MICROCODE DMA command
	   *	WRITE BUFFER DMA command
	   *	READ BUFFER DMA command
	   *	Data Set Management TRIM supported (limit 8 blocks)
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
Checksum: correct

Die Seriennummer und die Firmware ist etwas anders. Diese kann aber Secure Erase.

Die andere, die ich als externe nutzen wollte, hat folgende Ausgabe bei hdparm:

Code: Alles auswählen

hdparm -I /dev/sdd

/dev/sdd:

ATA device, with non-removable media
	Model Number:       Patriot Burst Elite 240GB               
	Serial Number:      PBEHHBB240815001478 
	Firmware Revision:  HDFED1.2
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
	Supported: 11 10 9 8 7 6 5 
	Likely used: 11
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:    16514064
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:   468862128
	Logical  Sector size:                   512 bytes
	Physical Sector size:                   512 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:      228936 MBytes
	device size with M = 1000*1000:      240057 MBytes (240 GB)
	cache/buffer size  = unknown
	Form Factor: 2.5 inch
	Nominal Media Rotation Rate: Solid State Device
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
	   *	64-bit World wide name
	   *	WRITE_UNCORRECTABLE_EXT command
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	    	unknown 119[8]
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Gen3 signaling speed (6.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Phy event counters
	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
	   *	DMA Setup Auto-Activate optimization
	   *	Software settings preservation
	   *	DOWNLOAD MICROCODE DMA command
	   *	WRITE BUFFER DMA command
	   *	READ BUFFER DMA command
	   *	DEVICE CONFIGURATION SET/IDENTIFY DMA commands
	   *	Data Set Management TRIM supported (limit 1 block)
Logical Unit WWN Device Identifier: 0000000000000000
	NAA		: 0
	IEEE OUI	: 000000
	Unique ID	: 000000000
Checksum: correct

Diese widerum schein kein Secure Erase zu können.
Könnte das ein Fehler sein, oder habe ich irgendwas übersehen? Ich meine, unten müsste ja auch etwas mit "not enabled, not frozen, not locked" etc. stehen dann. Tut res aber gar nicht.

Hat so etwas jemand auch bei sich einmal gehabt und weiß was da los sein könnte?

[kalle123]

Die beiden Platten unterscheiden sich doch ziemlich.

Hier mal der Bereich Commands/features > 'Enabled Supported'

gallery/image/5193/medium

cu KH

[Houbey]

Oh kalle, das ist mir gar nicht so bewusst gewesen, dass die sich doch so ziemlich unterscheiden. Das da ein bisschen was fehlte habe ich gesehen, aber ea das doch so viel ist, nicht.

Mir fiel halt auf, dass da nichts mit Security Erase stand. Was habe ich mir da denn bloß gekauft? War ja der gleiche Händler. Aber dann muss da ja irgendetwas bei der Produktion anders gemacht worden sein.

Dann gehe ich davon aus, dass die Platte eher "wertlos" ist?

[kalle123]

Hi Houbey.

Bei mir steht Patriot ähnlich wie Intenso auf der 'no-go' Liste, aber das war hier eine Patriot 210, die schlagartig den Geist aufgegeben hatte.

Gruß KH

[cosinus]

Dann gehe ich davon aus, dass die Platte eher "wertlos" ist?

Wieso ist die deiner Meinung nach denn deswegen gleich wertlos und warum überhaupt soll das ein Problem sein?
Probier den secure erase doch einfach mit hdparm aus. Ansonsten: Platte nur mit verschlüsseltem Dateisystem beutzen und optional gern noch ein Disk-Passwort. Kann man auch mit hdparm setzen.

[MSfree]

Probier den secure erase doch einfach mit hdparm aus.

Die SSD kann man auch mit

Code: Alles auswählen

dd if=/dev/zero of=/dev/sd?

nullen. Das entspricht einem secure Erase, dauert aber etwas länger.

[kreuzschnabel]

Das entspricht einem secure Erase, dauert aber etwas länger.

Bei 500 MB/s sind 2 TB rechnerisch in 1¼ Stunden geschrieben. Das nur als Anhaltspunkt für das „etwas“

Edit: Sehe gerade, es geht ja nur um 240 GB. Dann entsprechend kürzer.

--ks

[MSfree]

Bei 500 MB/s sind 2 TB rechnerisch in 1¼ Stunden geschrieben.

Seit wann geht ess hier um 2TB? Die fragliche SSD hat 240GB!
Folglich wäre die in 8 Minuten genullt.
Wo ist das Problem? Das kann man im Hintergrunf laufen lassen, während man ein paar Minuten im Debianforum surft.

[Houbey]

Die SSD kann man auch mit

Code: Alles auswählen

dd if=/dev/zero of=/dev/sd?

nullen. Das entspricht einem secure Erase, dauert aber etwas länger.

Hi MSfree,

seit wann ist es denn möglich eine SSD zu nullen oder mit Zufallszeichen zu überschreiben? Ich ging davon aus, weil es immer so gesagt und geschrieben wurde, dass man das Überschreiben nur bei HDD's also magnetische Platten und USB-Sticks könne. Bei einer SSD muss doch dann das Secure Erase Verfahren angewandt werden, was ja quasi nur ein Zurücksetzen in den Werkszustand darstellt. Deswegen funktioniert doch auch DBAN nicht bei SSD's. Oder habe ich da jetzt etwas falsch verstanden?

Mit dd arbeite ich schon lange nicht mehr seitdem wanne damals in einem früheren Beitrag von mir empfohlen hatte, mit cat zu arbeiten. Seitdem mache ich das immer mit

Code: Alles auswählen

cat /dev/zero > /dev/sdX
oder
cat /dev/urandom > /dev/sdX

Aber trotzdem sehr gut das du dd nochmal erwähnst, denn gerade Neulinge wissen das vielleicht nicht, mit was man alles überschrieben kann.

Wieso ist die deiner Meinung nach denn deswegen gleich wertlos und warum überhaupt soll das ein Problem sein?
Probier den secure erase doch einfach mit hdparm aus. Ansonsten: Platte nur mit verschlüsseltem Dateisystem beutzen und optional gern noch ein Disk-Passwort. Kann man auch mit hdparm setzen.

Naja weißt du, wenn man seine Daten nicht vollständig und sicher vernichten kann, anstatt sie erstmal verschlüsseln zu müssen, wäre das ja eher wertlos oder? Also nicht jeder kann eine Platte verschlüsseln, daher hatte ich auch nur von dem Secure Erase gesprochen. wanne hatte damals auch irgendwo in einem Beitrag von mir glaube ich war es sogar geschrieben, dass man auch mittels openssl verschlüsseln könnte.

Und der Secure Erase mit hdparm habe ich versucht gehabt bevor ich den Beitrag hier geschrieben hatte, aber die Platte war nicht angerührt worden, es war alles noch drauf, auch das Dateisystem und die Partitionstabelle war alles noch da.

[MSfree]

seit wann ist es denn möglich eine SSD zu nullen oder mit Zufallszeichen zu überschreiben?

Öhm, wie sonst sollte man Daten auf die SSD bringen können? Nullen sind letztlich auch nur Daten.

Ich ging davon aus, weil es immer so gesagt und geschrieben wurde, dass man das Überschreiben nur bei HDD's also magnetische Platten und USB-Sticks könne.

Man kann SSDs genauso überschreiben. Es gibt bei SSDs aber eine kleine Besonderheit, in der Regel ist ein gewisser Anteil an Flashspeicher als Reserve deklariert. Man kauft also keine 240GB-SSD sondern eine mit 242GB, von der nur 240 genutzt werden. Die extra 2GB nehmen aber am Wearlevelling teil und sie werden genutzt, falls mal ein Sektor endgültig verschlissen ist.

Beim Überschreiben mit Nullen wird dieser kleine Anteil an Extraspeicher natürlich nicht überschrieben. Man kann diesen Teil aber auch nicht direkt auslesen. Theoretisch ergibt sich dadurch die Möglichkeit, daß zufälligerweise in diesem Extrateil mal eine Klartext Passwortdatei gelagert wurde, die irgendwann dann Mal wieder in den genutzten Teil eingeblendet wird (Waerlevelling tut sowas) und man dann "Geheimnisse" offenlegen kann.

Secure Erase soll das Problem beheben und auch die Reservesektoren nullen. Nachprüfen läßt sich das allerdings für Normalnuzer nicht. Bei schlampiger Implementierung hätte man damit das gleiche Problem.

[hikaru]

Die SSD kann man auch mit

Code: Alles auswählen

dd if=/dev/zero of=/dev/sd?

nullen. Das entspricht einem secure Erase, dauert aber etwas länger.

Nein, ein manuelles Überschreiben mit Nullen entspricht bei einer SSD nicht dem Secure Erase, und zwar aus zwei Gründen:
1. Secure Erase erfasst die gesamte SSD, das Nullen nur den momentan "sichtbaren" Bereich. Flashzellen die gerade im Overprovisioning sind, werden also bei Letzterem nicht erfasst. aher wäre es theoretisch denkbar, wenn auch praktisch äußerst unwahrscheinlich, dass kleine Überreste der ursprünglichen Daten erhalten bleiben.

2. Secure Erase ist eine "Black-Box-Magie". Was die Firmware dabei tatsächlich macht ist Geheimnis des jeweiligen Herstellers. Allgemein geht man allerdings davon aus, dass dabei zumindest die Adressierungstabelle der Firmware gelöscht wird, möglicherweise auch die Daten selbst.
Wohlgemerkt: Ein Überschreiben mit Nullen ist aus Sicht der Firmware kein Löschen (auch "0" ist eine Information). Daher kann ein Löschen bei einer SSD prinzipiell schneller gehen als ein Neuschreiben von Nullen.

Fazit:
Sowohl Nullen (wg. Overprovisioning) als auch Secure Erase (wg. Black Box) sind bei SSDs nicht als völlig sichere Löschmethoden anzusehen. Eine SSD die einmal wirklich kritische Daten im Klartext gesehen hat, sollte man daher nie funktionstüchtig weitergeben.

[kreuzschnabel]

Ich ging davon aus, weil es immer so gesagt und geschrieben wurde, dass man das Überschreiben nur bei HDD's also magnetische Platten und USB-Sticks könne.

Da verwexelste wahrscheinlich was:

Es ist bei einer SSD technisch nicht möglich, einen bestimmten Datenbereich gezielt zu überschreiben (etwa um eine einzelne Datei sicher zu löschen), weil die Überschreibung wegen des Wearleveling mit praktisch 100-prozentiger Sicherheit an einer anderen physischen Stelle auf dem Datenträger landen wird, worüber das Betriebssystem auch keine Kontrolle hat.

Aber natürlich kann man eine SSD wie eine HDD mit Nullen oder Zufallsdaten vollschreiben, um den Inhalt des (nahezu, wegen Overprovisioning) gesamten Speicherbereichs zuverlässig zu löschen. Entweder mit dd oder – wenn du das Dateisystem behalten willst – durch Schreiben einer Riesendatei auf das gemountete Dateisystem, etwa mit

Code: Alles auswählen

cat /dev/zero >/media/ssd/nulldatei

Letzteres überschreibt auch einigermaßen vollständig den freien Speicherbereich. Vor Anwendung in der Rootpartition im Betrieb wird gewarnt

--ks

[hikaru]

Aber natürlich kann man eine SSD wie eine HDD mit Nullen oder Zufallsdaten vollschreiben, um den Inhalt des gesamten Speicherbereichs zuverlässig zu löschen.

Nein, eben das funktioniert wegen des Overprovisionings nicht zuverlässig.

[kreuzschnabel]

Nein, eben das funktioniert wegen des Overprovisionings nicht zuverlässig.

Ja, aber diese Einschränkung wurde oben schon erwähnt, das muss ich nicht wiederholen. Meine Antwort bezog sich auf die Annahme, es gehe überhaupt nicht.

--ks

[cosinus]

Man kann SSDs genauso überschreiben. Es gibt bei SSDs aber eine kleine Besonderheit, in der Regel ist ein gewisser Anteil an Flashspeicher als Reserve deklariert. Man kauft also keine 240GB-SSD sondern eine mit 242GB, von der nur 240 genutzt werden. Die extra 2GB nehmen aber am Wearlevelling teil und sie werden genutzt, falls mal ein Sektor endgültig verschlissen ist.

Und was ist daran anders als bei normalen HDDs?
Die haben auch nen Reservebereich, dahin werden bad sectors hingemappt. Auch dieser Bereich ist nicht gezielt ansprechbar.

[cosinus]

Naja weißt du, wenn man seine Daten nicht vollständig und sicher vernichten kann, anstatt sie erstmal verschlüsseln zu müssen, wäre das ja eher wertlos oder? Also nicht jeder kann eine Platte verschlüsseln,

Was soll das heißen, man kann weder sicher löschen noch vorher verschlüsseln? Das was du da bezeichnest ist doch eine Wissenslücke und kein technischer Mangel. V.a. wenn man so wie du solchen Wert drauf legt verstehe ich nicht, dass du weder was von cryptsetup/LUKS noch von dd gehört hast

[MSfree]

Und was ist daran anders als bei normalen HDDs?

Bei Festplatten werden die Reservesektoren erst dann verwendet, wenn die die originalen nicht mehr lesbar sind. An die umgemapten Sektoren kommst du also schon deshalb nicht mehr ran, weil sie schlicht im Eimer sind.

Bei SSDs nehmen die Reserveblöcke immer und ständig am Wearlevelling teil. Es besteht also die theoretische Gefahr, daß irgendwann Daten wieder in den normalen Bereich gelangen, auf denen worher mal schützenswerte Daten lagen. Letzten Endes wirst du da aber keine vollständigen Dateien finden sondern nur Fragmente, die selbst James Bond nicht weiterbringen.

Natürlich ist man mit Verschlüsselung auf der sicheren Seite, weil dann auch die hin und her gemappten Reservesektoren nur zufälliges Rauschen beinhalten.

[kreuzschnabel]

sondern nur Fragmente, die selbst James Bond nicht weiterbringen.

Da verwexelste was. James Bond ist derjenige, der die SSD aus der Höhle des Bösen holt, sich den Weg durch tausend technisch überlegene Security-Leute bei nur minimaler Verschmutzung seines Anzuges freischießt, dann auf einem Ackergaul 50 Ferraris abhängt, M die SSD lächelnd auf den Schreibtisch legt und sich dann unerreichbar in $WELTMETROPOLE auf Kosten Ihrer Majestät wochenlang mit der Ex des Bösen im Bett räkelt. Kryptoanalyse ist eher nicht so seins.

--ks

[cosinus]

Bei Festplatten werden die Reservesektoren erst dann verwendet, wenn die die originalen nicht mehr lesbar sind. An die umgemapten Sektoren kommst du also schon deshalb nicht mehr ran, weil sie schlicht im Eimer sind.

Ok, ja, das stimmt. Ist in diesem Fall irrelevant, oder kannst du ausschließen, dass nicht mehr ansprechbarere Sektoren doch noch irgendwie lesbare Daten enthalten?

Natürlich ist man mit Verschlüsselung auf der sicheren Seite, weil dann auch die hin und her gemappten Reservesektoren nur zufälliges Rauschen beinhalten.

Dan ist die Diskussion um den Reservebereich aber eh unnötig

[wanne]

Zuerst mal:
SSDs haben meistens mehr als 0 und 1 als State. Gelöscht ist nicht unbedingt äquivalent mit 0. blkdiscard kann deswegen Blöcke löschen oder nullen (-z).
Daneben: "Moderne" SSDs können blkdiscard --secure das löscht auch Blöcke die ehemals der Block mit der passenden Adresse war aber noch nicht überschrieben wurde. Damit kann man jetzt sicher Partitionen löschen. (Prinzipiell sogar Dateien, da die beim ändern aber eventuell verschoben werden und Kopieen in diversen journals/caches haben ist das keine sehr zuverlässige Variante.)

Ok, ja, das stimmt. Ist in diesem Fall irrelevant, oder kannst du ausschließen, dass nicht mehr ansprechbarere Sektoren doch noch irgendwie lesbare Daten enthalten?

Genau deswegen versucht secure-erease da nochmal drüber zu bügeln.

[cosinus]

Genau deswegen versucht secure-erease da nochmal drüber zu bügeln.

War aber nicht das Fazit, dass es im Prinzip doch egal ist? Egal ob HDD oder SSD? Man bekommt wenn überhaupt nur Fragmente, mit denen James Bond was anzufangen weiß.

[Houbey]

Moin an alle.

Vielen Dank für eure weiteren Antworten zu meinem Anliegen bezüglich der SSD von uns, die anscheinend kein Secure Erase kann oder dieses nicht aktiviert ist. Ich habe mit dem Verkäufer einmal Kontakt aufgenommen, wo ich diese damals gekauft habe, dieser hat mich zum Hersteller Patriot weitergeleitet und ich solle dies dem Hersteller bitte mitteilen. Also muss ich jetzt bei SSD's immer hoffen das die in der Lage sind, Secure Erase zu nutzen? Ich meine, hdparm selber kann das ja dann ausführen. Ist schon sehr komisch, dass diese eine besagte SSD es nicht kann. Das ein hersteller da solch Unterschiede macht.

Damit kann man jetzt sicher Partitionen löschen.

Lieber wanne, schön das man dich mal wieder liest.
Also sollte ich die SSD mit blkdiscard --secure versuchen zu löschen oder am besten gleich eine neue kaufen und hoffen, dass diese wie meine anderen Patriot Burst Elites auch Secure Erase können?

Meine Antwort bezog sich auf die Annahme, es gehe überhaupt nicht.

Da hat man mich anscheinend falsch verstanden. Ich habe damit nicht gemeint, dass man eine SSD nicht mit Nullen und Zufallszahlen überschreiben kann. Das dies geht, weiß ich natürlich. Meine Aussage mit dem gar nicht gehen, war aber darauf bezogen, dass es bei einer SSD nichts bringen würde.

[FBT]

Mit ein Grund warum ich privat seit Jahren ausschließlich Samsung SATA SSDs verwende. Die unterstützen alle Secure Erase und mit dem Samsung Magican Tool kann man am Windows PC einen bootbaren USB Stick bruzeln und dann die SSD in der dos command line zurücksetzen. Damit sind dann auch Windows User gut bedient.

[MSfree]

Meine Aussage mit dem gar nicht gehen, war aber darauf bezogen, dass es bei einer SSD nichts bringen würde.

Es ist eben nicht so, daß das Überschreiben mit Nullen "nichts bringt". Es bringt sogar sehr viel, denn damit löschst du 99% der Daten auf der SSD. Die restlichen 1%, die nur mit secure Erase erreichbar sind, beinhalten nur Dateifragmente, mit denen man nichts anfängt (was willst du mit 512 Bytes einer JPG-Datei denn anfangen?). Selbst ein 512 Bytes großes Fragment eines SSH-Schlüssels bringt dich nicht weiter.

Davon abgeshen unterstützen inzwischen namhafte Hersteller (z.B. Kioxia ehemals Toshiba, Samsung, Seagate, Solidigm ehemals Intel, SanDisk = WD, WD) secure Erase.

[rhHeini]

Ist schon sehr komisch, dass diese eine besagte SSD es nicht kann. Das ein hersteller da solch Unterschiede macht.

Ich würd jetzt Patriot nicht ganz oben in die Reihe der besten Hersteller einordnen. Die stellen nichts selber her, sondern kaufen Kontroller und Speicherchips und bauen da irgendetwas zusammen, ähnlich wie Intensio. Wenn ich die Daten der beiden Laufwerke ansehe und die Firmware sowie die Seriennummern: ganz anders. Für mich nicht verwunderlich das hier etwas geht und an der anderen dasselbe eben nicht.