linux-kernel - Re: [PATCH v2 11/20] arm64: capabilities: Add support for features enabled early

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:   Thu, 8 Feb 2018 11:43:44 +0000
From:   Suzuki K Poulose <Suzuki.Poulose@....com>
To:     Dave Martin <Dave.Martin@....com>
Cc:     mark.rutland@....com, ckadabi@...eaurora.org,
        ard.biesheuvel@...aro.org, marc.zyngier@....com,
        catalin.marinas@....com, Julien Thierry <julien.thierry@....com>,
        will.deacon@....com, linux-kernel@...r.kernel.org,
        jnair@...iumnetworks.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 11/20] arm64: capabilities: Add support for features
 enabled early

On 08/02/18 11:35, Dave Martin wrote:
> On Wed, Feb 07, 2018 at 06:34:37PM +0000, Suzuki K Poulose wrote:
>> On 07/02/18 10:38, Dave Martin wrote:
>>> On Wed, Jan 31, 2018 at 06:27:58PM +0000, Suzuki K Poulose wrote:

>>>>    * 3) Verification: When a CPU is brought online (e.g, by user or by the kernel),
>>>>    *    the kernel should make sure that it is safe to use the CPU, by verifying
>>>> @@ -139,11 +148,22 @@ extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
>>>>    *
>>>>    *    As explained in (2) above, capabilities could be finalised at different
>>>>    *    points in the execution. Each CPU is verified against the "finalised"
>>>> - *    capabilities and if there is a conflict, the kernel takes an action, based
>>>> - *    on the severity (e.g, a CPU could be prevented from booting or cause a
>>>> - *    kernel panic). The CPU is allowed to "affect" the state of the capability,
>>>> - *    if it has not been finalised already. See section 5 for more details on
>>>> - *    conflicts.
>>>> + *    capabilities.
>>>> + *
>>>> + *	x------------------------------------------------------------------- x
>>>> + *	| Verification:       | Boot CPU | SMP CPUs by kernel | CPUs by user |
>>>> + *	|--------------------------------------------------------------------|
>>>> + *	| Primary boot CPU    |          |                    |              |
>>>> + *	|  capability         |   n      |      y             |       y      |
>>>> + *	|--------------------------------------------------------------------|
>>>> + *	| All others          |   n      |      n             |       y      |
>>>> + *	x--------------------------------------------------------------------x
>>>
>>> Minor clarify nit: it's not obvious that "n" means "no conflict" and "y"
>>> means "conflict".
>>>
>>> Could we have blank cell versus "X" (with a note saying what that
>>> means), or "ok" versus "CONFLICT"?
>>
>> This is not strictly about conflicts, but about what each CPU get
>> verified against.  Since there are multiple stages of "finalisation"
> 
> You're right: I meant something like "potential conflict", but I hadn't
> read the previous paragraph carefully enough and didn't explain what I
> meant very well.
> 
>> for the capabilities, the table shows how the CPUs get verified.
>>
>> Would it help if I changed the description above the table to :
>>
>>   *    As explained in (2) above, capabilities could be finalised at different
>>   *    points in the execution. Each CPU is verified against the "finalised"
>>   *    capabilities. The following table shows, the capabilities verified
>>   *    against each CPU in the system.
>>   *
>>   *      x------------------------------------------------------------------- x
>>   *      | Verified against:   | Boot CPU | SMP CPUs by kernel | CPUs by user |
> 
> I still find it a bit cryptic.
> 
> Would it be simpler just to write this out in prose, with reference to
> the actual capability types?  I feel that things have to be abbreviated
> a bit to fit nicely into the table otherwise.
> 
> What about:
> 
>   * As explained in (2) above, capabilities could be finalised at different
>   * points in the execution, depending on the capability type. Each newly booted
>   * CPU is verified against those capabilities that have been finalised by the
>   * time that CPU boots:
>   *
>   *	* SCOPE_BOOT_CPU: all CPUs are verified against the capability except
>   *	  for the primary boot CPU.
>   *
>   *	* SCOPE_LOCAL_CPU, SCOPE_SYSTEM: all CPUs hotplugged on by the user
>   *	  after kernel boot are verified against the capability.

Sure, looks better.