linux-kernel - Re: [PATCH 00/14] Introduce cpu_enabled

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Jul 2008 17:54:01 -0600
From:	Alex Chiang <achiang@...com>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	linux-ia64@...r.kernel.org
Subject: Re: [PATCH 00/14] Introduce cpu_enabled_map and friends

I didn't include linux-ia64 originally. Sorry about that.

Here is the 00/14 cover email describing the patch series:

	http://lkml.org/lkml/2008/7/14/468

Here is the 12/14 ia64 specific bit:

	http://lkml.org/lkml/2008/7/14/478

Here is the 14/14 patch that Tony is referring to:

	http://lkml.org/lkml/2008/7/14/482

* Luck, Tony <tony.luck@...el.com>:
> > Patch 14 is the money patch. It demonstrates why we might
> > want to go through all these gyrations. Now that ia64 presents
> > *all* physically present CPUs in sysfs, even if they have been
> > disabled by firmware, we give userspace a way to poke at those
> > CPUs.
> 
> There's only the one bit for "disabled by firmware" ... no extra
> space for any extra information.  How would userspace know that
> it was safe to poke at a disabled cpu?  Perhaps firmware disabled
> it for some very good reason, and poking at it could cause system
> instability.

My thought here was that it would be a vendor-specific thing. In
patch 14/14 I created:

	/sys/devices/system/cpu/cpuN/deconfigure

(although /sys/device/system/cpu/cpuN/enabled would probably be
better)

I set up 'deconfigure' to have different implementations based on
a DMI, so it is very much an opt-in (especially since it's a
Kconfig option).

It would be the responsibility of the vendor to provide something
safe to poke at. In the sample implementation I gave, nothing
happens to the system until the *next* reboot, so it shouldn't
cause the current boot any distress.

A different implementation of deconfigure/enabled could return
an error to userspace if an operation was unsafe.

/ac

--
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/