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]
Message-ID: <b5d9bbb2-a575-ee47-33aa-11994edef702@oracle.com>
Date:   Wed, 30 Aug 2017 17:23:37 -0600
From:   Khalid Aziz <khalid.aziz@...cle.com>
To:     David Miller <davem@...emloft.net>
Cc:     anthony.yznaga@...cle.com, dave.hansen@...ux.intel.com,
        corbet@....net, bob.picco@...cle.com, steven.sistare@...cle.com,
        pasha.tatashin@...cle.com, mike.kravetz@...cle.com,
        mingo@...nel.org, nitin.m.gupta@...cle.com,
        kirill.shutemov@...ux.intel.com, tom.hromatka@...cle.com,
        eric.saint.etienne@...cle.com, allen.pais@...cle.com,
        cmetcalf@...lanox.com, akpm@...ux-foundation.org,
        geert@...ux-m68k.org, tklauser@...tanz.ch, atish.patra@...cle.com,
        vijay.ac.kumar@...cle.com, peterz@...radead.org, mhocko@...e.com,
        jack@...e.cz, lstoakes@...il.com, hughd@...gle.com,
        thomas.tai@...cle.com, paul.gortmaker@...driver.com,
        ross.zwisler@...ux.intel.com, dave.jiang@...el.com,
        willy@...radead.org, ying.huang@...el.com, zhongjiang@...wei.com,
        minchan@...nel.org, vegard.nossum@...cle.com,
        imbrenda@...ux.vnet.ibm.com, aneesh.kumar@...ux.vnet.ibm.com,
        aarcange@...hat.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org,
        linux-mm@...ck.org, khalid@...ehiking.org
Subject: Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data
 Integrity)

On 08/30/2017 04:38 PM, David Miller wrote:
> From: Khalid Aziz <khalid.aziz@...cle.com>
> Date: Wed, 30 Aug 2017 16:27:54 -0600
> 
>>>> +#define arch_calc_vm_prot_bits(prot, pkey)
>>>> sparc_calc_vm_prot_bits(prot)
>>>> +static inline unsigned long sparc_calc_vm_prot_bits(unsigned long
>>>> prot)
>>>> +{
>>>> +	if (prot & PROT_ADI) {
>>>> +		struct pt_regs *regs;
>>>> +
>>>> +		if (!current->mm->context.adi) {
>>>> +			regs = task_pt_regs(current);
>>>> +			regs->tstate |= TSTATE_MCDE;
>>>> +			current->mm->context.adi = true;
>>> If a process is multi-threaded when it enables ADI on some memory for
>>> the first time, TSTATE_MCDE will only be set for the calling thread
>>> and it will not be possible to enable it for the other threads.
>>> One possible way to handle this is to enable TSTATE_MCDE for all user
>>> threads when they are initialized if adi_capable() returns true.
>>>
>>
>> Or set TSTATE_MCDE unconditionally here by removing "if
>> (!current->mm->context.adi)"?
> 
> I think you have to make "ADI enabled" a property of the mm_struct.
> 
> Then you can broadcast to mm->cpu_vm_mask a per-cpu interrupt that
> updates regs->tstate of a thread using 'mm' is currently executing.
> 
> And in the context switch code you set TSTATE_MCDE if it's not set
> already.
> 
> That should cover all threaded case.

That is an interesting idea. This would enable TSTATE_MCDE on all 
threads of a process as soon as one thread enables it. If we consider 
the case where the parent creates a shared memory area and spawns a 
bunch of threads. These threads access the shared memory without ADI 
enabled. Now one of the threads decides to enable ADI on the shared 
memory. As soon as it does that, we enable TSTATE_MCDE across all 
threads and since threads are all using the same TTE for the shared 
memory, every thread becomes subject to ADI verification. If one of the 
other threads was in the middle of accessing the shared memory, it will 
get a sigsegv. If we did not enable TSTATE_MCDE across all threads, it 
could have continued execution without fault. In other words, updating 
TSTATE_MCDE across all threads will eliminate the option of running some 
threads with ADI enabled and some not while accessing the same shared 
memory. This could be necessary at least for short periods of time 
before threads can communicate with each other and all switch to 
accessing shared memory with ADI enabled using same tag. Does that sound 
like a valid use case or am I off in the weeds here?

Thanks,
Khalid

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ