From: "John Andre Taule" <post@johnandre.net>
To: linux-raid@vger.kernel.org
Subject: SV: mdadm raid 5 one disk overwritten file system failed
Date: Thu, 19 Feb 2015 15:00:06 +0100 [thread overview]
Message-ID: <021f01d04c4c$5def1740$19cd45c0$@johnandre.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1502191218140.4007@uplift.swm.pp.se>
The array was not stopped before dd was running. The "hacker" logged on,
left the command running and logged of. It was discovered the next morning
about 5 hours later, and there was very high load on the server, I think
this is why the command where discovered at all. This is how that raid have
performed earlier when a drive have failed.
I'm a bit surprised that overwriting anything on the physical disk should
corrupt the file system on the raid. I would think that would be similar to
a disk crashing or failing in other ways.
What you say that Linux might not have seen the disk as failing is
interesting. This could explain why the file system got corrupted.
-----Opprinnelig melding-----
Fra: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
Sendt: 19. februar 2015 12:20
Til: John Andre Taule
Kopi: linux-raid@vger.kernel.org
Emne: Re: mdadm raid 5 one disk overwritten file system failed
On Thu, 19 Feb 2015, John Andre Taule wrote:
> Hi!
>
> Case: mdadm Raid 5 4 2TB disks. ext4 formatted spanning the raid.
> Attack: dd if=/dev/zero of=/dev/sdb bs=1M
>
> Expected result would be a raid that could be recovered without data loss.
>
> Result was that the file system failed and not possible to recover.
>
> As I understand it if this was a "hardware type fake" raid controller,
> the outcome would be uncertain. However I'm a bit confused as to why
> the raid (or more specifically the file system) would fail so horrible
> when losing one disk. Is there perhaps critical information written
> "outside" the raid on the physical disk, and this where overwritten in the
attack?
Did you stop the array before you did the dd command, or you just did it?
If you just did it, most likely you overwrote the superblock on the drive
(located near the beginning of the drive by recent default), plus part of
the file system.
> It would be nice to have an exact idea as to why it failed so hard,
> and how obvious it should be that this attack would have more
> consequence then a degraded raid.
Because if the drive was active then the operating system most likely didn't
notice that you overwrote part of the data on the disk and the drive wasn't
failed.
--
Mikael Abrahamsson email: swmike@swm.pp.se
next prev parent reply other threads:[~2015-02-19 14:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 7:38 mdadm raid 5 one disk overwritten file system failed John Andre Taule
2015-02-19 11:20 ` Mikael Abrahamsson
2015-02-19 14:00 ` John Andre Taule [this message]
2015-02-19 14:23 ` Mikael Abrahamsson
2015-02-19 14:39 ` Adam Goryachev
2015-02-19 16:21 ` SV: " John Andre Taule
2015-02-19 22:15 ` Wols Lists
2015-04-15 11:47 ` SV: " John Andre Taule
2015-04-15 12:38 ` Mikael Abrahamsson
2015-04-15 18:27 ` Wols Lists
2015-02-19 17:15 ` Piergiorgio Sartor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='021f01d04c4c$5def1740$19cd45c0$@johnandre.net' \
--to=post@johnandre.net \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.