Until commit 7306e83ccf5c ("powerpc: Don't use CURRENT_THREAD_INFO to
find the stack"), the current stack base address was obtained by
calling current_thread_info(). That inline function was simply masking
out the value of r1.
In that commit, it was changed to using current_stack_pointer(), which
Instead of #ifdef, use IS_ENABLED(CONFIG_DEBUG_STACKOVERFLOW).
This enable GCC to check for code validity even when the option
is not selected.
---
v2: rebased
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/a
current_stack_pointer() doesn't return the stack pointer, but the
caller's stack frame. See commit bfe9a2cfe91a ("powerpc: Reimplement
__get_SP() as a function not a define") and commit acf620ecf56c
("powerpc: Rename __get_SP() to current_stack_pointer()") for details.
The purpose of check_stack_o
On 01/24/2020 06:19 AM, Christophe Leroy wrote:
Le 24/01/2020 à 06:46, Michael Ellerman a écrit :
If I do this it seems to work, but feels a little dicey:
asm ("" : "=r" (r1));
sp = r1 & (THREAD_SIZE - 1);
Or we could do add in asm/reg.h what we have in boot/reg.h:
register vo
Le 23/01/2020 à 19:47, Linus Torvalds a écrit :
On Thu, Jan 23, 2020 at 12:34 AM Christophe Leroy
wrote:
The range passed to user_access_begin() by strncpy_from_user() and
strnlen_user() starts at 'src' and goes up to the limit of userspace
allthough reads will be limited by the 'count' par
Le 24/01/2020 à 06:46, Michael Ellerman a écrit :
Christophe Leroy writes:
current_stack_pointer() doesn't return the stack pointer, but the
caller's stack frame. See commit bfe9a2cfe91a ("powerpc: Reimplement
__get_SP() as a function not a define") and commit acf620ecf56c
("powerpc: Rename
Christophe Leroy writes:
> current_stack_pointer() doesn't return the stack pointer, but the
> caller's stack frame. See commit bfe9a2cfe91a ("powerpc: Reimplement
> __get_SP() as a function not a define") and commit acf620ecf56c
> ("powerpc: Rename __get_SP() to current_stack_pointer()") for det
On January 23, 2020 11:57:57 AM PST, Linus Torvalds
wrote:
>On Thu, Jan 23, 2020 at 11:47 AM christophe leroy
> wrote:
>>
>> I'm going to leave it aside, at least for the time being, and do it
>as a
>> second step later after evaluating the real performance impact. I'll
>> respin tomorrow in that
[ add Aneesh ]
On Tue, Dec 3, 2019 at 4:10 PM Dan Williams wrote:
>
> On Mon, Dec 2, 2019 at 7:48 PM Alastair D'Silva wrote:
> >
> > From: Alastair D'Silva
> >
> > These functions don't exist, so remove the prototypes for them.
> >
> > Signed-off-by: Alastair D'Silva
> > Reviewed-by: Frederic
On Thu, Jan 23, 2020 at 11:47 AM christophe leroy
wrote:
>
> I'm going to leave it aside, at least for the time being, and do it as a
> second step later after evaluating the real performance impact. I'll
> respin tomorrow in that way.
Ok, good.
>From a "narrow the access window type" standpoint
Le 23/01/2020 à 19:02, Linus Torvalds a écrit :
On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy
wrote:
On 32 bits powerPC (book3s/32), only write accesses to user are
protected and there is no point spending time on unlocking for reads.
Honestly, I'm starting to think that 32-bit ppc jus
On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy
wrote:
>
> On 32 bits powerPC (book3s/32), only write accesses to user are
> protected and there is no point spending time on unlocking for reads.
Honestly, I'm starting to think that 32-bit ppc just needs to look
more like everybody else, than mak
On Thu, Jan 23, 2020 at 12:34 AM Christophe Leroy
wrote:
>
> The range passed to user_access_begin() by strncpy_from_user() and
> strnlen_user() starts at 'src' and goes up to the limit of userspace
> allthough reads will be limited by the 'count' param.
>
> On 32 bits powerpc (book3s/32) access h
On Thu, Jan 23, 2020 at 4:00 AM Michael Ellerman wrote:
>
> So I guess I'll wait and see what happens with patch 1.
I've committed my fixes to filldir[64]() directly - they really were
fixing me being lazy about the range, and the name length checking
really is a theoretical "access wrong user sp
Instead of opencoding, use probe_user_read() to failessly read
a user location and probe_user_write() for writing to user.
Signed-off-by: Christophe Leroy
---
Link to v3: https://patchwork.ozlabs.org/patch/1026042/
v4: Reviving this patch after one year. Now probe_user_read/write() is in the
ker
On Thu, Jan 23, 2020 at 09:56:10AM -0600, Nathan Lynch wrote:
> Hello and thanks for the patch.
>
> Libor Pechacek writes:
> > In KVM guests drmem structure is only zero initialized. Trying to
> > manipulate DLPAR parameters results in a crash in this environment.
>
> I think this statement need
Hello and thanks for the patch.
Libor Pechacek writes:
> In KVM guests drmem structure is only zero initialized. Trying to
> manipulate DLPAR parameters results in a crash in this environment.
I think this statement needs qualification. Unless I'm mistaken, this
happens only when you boot a gues
On Tue, 21 Jan 2020 at 04:30, Michael Ellerman wrote:
>
> From: Joel Stanley
>
> This turns on HARDENED_USERCOPY with HARDENED_USERCOPY_PAGESPAN, and
> FORTIFY_SOURCE.
>
> It also enables SECURITY_LOCKDOWN_LSM with _EARLY and
> LOCK_DOWN_KERNEL_FORCE_INTEGRITY options enabled. This still allows
>
On Thu, 23 Jan 2020, Christophe Leroy wrote:
> On 32 bits powerPC (book3s/32), only write accesses to user are
> protected and there is no point spending time on unlocking for reads.
>
> On 64 bits powerpc (book3s/64 at least), access can be granted
> read only, write only or read/write.
>
> Add a
Today, when a function like strncpy_from_user() is called,
the userspace access protection is de-activated and re-activated
for every word read.
By implementing user_access_begin and friends, the protection
is de-activated at the beginning of the copy and re-activated at the
end.
Implement user_a
In preparation of implementing user_access_begin and friends
on powerpc, allow_user_access() need to be prepared for
user_access_begin()
user_access_end() doesn't provide the address and size which
were passed to user_access_begin(), required by prevent_user_access()
to know which segment to modif
At the moment, bad_kuap_fault() reports a fault only if a bad access
to userspace occurred while access to userspace was not granted.
But if a fault occurs for a write outside the allowed userspace
segment(s) that have been unlocked, bad_kuap_fault() fails to
detect it and the kernel loops forever
On 32 bits powerPC (book3s/32), only write accesses to user are
protected and there is no point spending time on unlocking for reads.
On 64 bits powerpc (book3s/64 at least), access can be granted
read only, write only or read/write.
Add an argument to user_access_begin() to tell when it's for wr
__builtin_constant_p() always return 0 for pointers, so on RADIX
we always end up opening both direction (by writing 0 in SPR29):
0170 <._copy_to_user>:
...
1b0: 4c 00 01 2c isync
1b4: 39 20 00 00 li r9,0
1b8: 7d 3d 03 a6 mtspr 29,r9
1bc: 4c 00 01 2c
Some architectures grant full access to userspace regardless of the
address/len passed to user_access_begin(), but other architectures
only grant access to the requested area.
For example, on 32 bits powerpc (book3s/32), access is granted by
segments of 256 Mbytes.
Modify filldir() and filldir64(
NULL addr is a user address. Don't waste time checking it. If
someone tries to access it, it will SIGFAULT the same way as for
address 1, so no need to make it special.
The special case is when not doing a write, in that case we want
to drop the entire function. This is now handled by 'dir' param
Le 23/01/2020 à 13:00, Michael Ellerman a écrit :
Michael Ellerman writes:
Hi Christophe,
This patch is independent of the rest of the series AFAICS
And of course having hit send I immediately realise that's not true.
Without this, book3s/32 fails booting. (And without patch 2, it even
Michael Ellerman writes:
> Christophe Leroy writes:
>> Today, when a function like strncpy_from_user() is called,
>> the userspace access protection is de-activated and re-activated
>> for every word read.
>>
>> By implementing user_access_begin and friends, the protection
>> is de-activated at t
Christophe Leroy writes:
> Today, when a function like strncpy_from_user() is called,
> the userspace access protection is de-activated and re-activated
> for every word read.
>
> By implementing user_access_begin and friends, the protection
> is de-activated at the beginning of the copy and re-ac
Michael Ellerman writes:
> Hi Christophe,
>
> This patch is independent of the rest of the series AFAICS
And of course having hit send I immediately realise that's not true.
> So I'll take patches 2-6 via powerpc and assume this patch will go via
> Linus or Al or elsewhere.
So I guess I'll wait
Hi Christophe,
This patch is independent of the rest of the series AFAICS, and it looks
like Linus has modified it quite a bit down thread.
So I'll take patches 2-6 via powerpc and assume this patch will go via
Linus or Al or elsewhere.
Also a couple of minor spelling fixes below.
cheers
Chris
In the current implementation, the call to loadcam_multi() is wrapped
between switch_to_as1() and restore_to_as0() calls so, when it tries
to create its own temporary AS=1 TLB1 entry, it ends up duplicating the
existing one created by switch_to_as1(). Add a check to skip creating
the temporary entr
Christophe Leroy writes:
> In preparation of implementing user_access_begin and friends
> on powerpc, the book3s/32 version of prevent_user_access() need
> to be prepared for user_access_end().
>
> user_access_end() doesn't provide the address and size which
> were passed to user_access_begin(), r
From: "Aneesh Kumar K.V"
Commit 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in
the same 0xc range") has a bug in the definition of MIN_USER_CONTEXT.
The result is that the context id used for the vmemmap and the lowest
context id handed out to userspace are the same. The context
From: Heiner Kallweit
Date: Tue, 21 Jan 2020 22:09:33 +0100
> Convert suitable drivers to use new helper phy_do_ioctl_running.
>
> Signed-off-by: Heiner Kallweit
> ---
> v2: I forgot the netdev mailing list
Applied to net-next.
On 23/01/2020 12:17, David Gibson wrote:
> On Thu, Jan 23, 2020 at 11:53:32AM +1100, Alexey Kardashevskiy wrote:
>> Anyone, ping?
>
> Sorry, I've totally lost track of this one. I think you'll need to
> repost.
It has not changed and still applies, and the question is more about how
we proc
The range passed to user_access_begin() by strncpy_from_user() and
strnlen_user() starts at 'src' and goes up to the limit of userspace
allthough reads will be limited by the 'count' param.
On 32 bits powerpc (book3s/32) access has to be granted for each 256Mbytes
segment and the cost increases wi
37 matches
Mail list logo
