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: <44297716-74aa-1f14-67be-3594b5244b74@arm.com>
Date:   Fri, 23 Nov 2018 11:57:31 +0000
From:   Julien Thierry <julien.thierry@....com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>, hpa@...or.com
Cc:     Ingo Molnar <mingo@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        James Morse <james.morse@....com>
Subject: Re: Sleeping in user_access section



On 23/11/18 10:50, Russell King - ARM Linux wrote:
> On Fri, Nov 23, 2018 at 01:57:12AM -0800, hpa@...or.com wrote:
>> You should never call a sleeping function from a user_access section.
>> It is intended for very limited regions.
> 
> So, what happens if the "unsafe" user access causes a page fault that
> ends up sleeping?
> 

Thanks for pointing that out.

On the arm64 side, PAN state is saved in spsr and (if PAN feature is 
enabled in SCTLR) PAN bit gets set (disabling the user accesses). For 
software PAN we follow the same behaviour on exception entry. So upon 
exception we implicitly exit user_access mode and then re-enter it when 
returning from the exception.

On x86, the EFLAGS.AC bit is also saved upon exception and I think it is 
cleared upon exception entry so there is implicit exit from the 
user_access mode when taking exception/interrupt.

This however is just how those two architectures happen to behave and 
doesn't seem to be specified as part of the user_access API...

Which is why I'd like to clarify the semantics of user_access region wrt 
sleeping functions.

Thanks,

-- 
Julien Thierry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ