linux-kernel - Re: [PATCH] PCI: Clear Bus Master bit only on kexec reboot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20131128141513.3de95d04@alan.etchedpixels.co.uk>
Date:	Thu, 28 Nov 2013 14:15:13 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Khalid Aziz <khalid.aziz@...cle.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>, bhelgaas@...gle.com,
	cl91tp@...il.com, tianyu.lan@...el.com, khlebnikov@...nvz.org,
	indou.takao@...fujitsu.com, jility09@...il.com, f.otti@....at,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	kexec@...ts.infradead.org, stable@...r.kernel.org
Subject: Re: [PATCH] PCI: Clear Bus Master bit only on kexec reboot

> Anyway, I really don't care either way, but this seems like something
> that the drivers should be doing.  What suddenly changed that caused
> this problem to occur that hasn't happened in the years prior to now
> that drives this to be a stable-kernel issue?

When this first went in I pointed out it was an utterly stupid idea.
Since it went in lots of machines haven't rebooted properly or powered
off right.

There are two problems

1. Clearing the busmaster bit is not well defined behaviour. It even
freezes some hardware.

2. Lots of PC class hardware has firmware which believes that it can
access the hardware as it goes to reboot or poweroff and that someone
won't have shut it down.

Like it or not the firmware expected behaviour for such things is "what
Windows did". The expected PC behaviour is subtle and magic - eg the fact
D3 on some IDE disk controllers is terminal until power cycled because
Windows didn't do that or that the BIOS goes off and chats to the disks
in reboot without assuming the disk controller is completely
uninitialized.

kexec is a special cornercase and handling is as such (knowing it will
bother to re-init appropriate devices) is very different to the current
broken behaviour for PC systems.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/