* Re: It is correct to introduce new sys calls to stable versions?
From: Miao Wang @ 2024-08-20 19:24 UTC (permalink / raw)
To: Willy Tarreau
Cc: Greg Kroah-Hartman, Xi Ruoyao, Huacai Chen, loongarch,
Sasha Levin, stable, WANG Xuerui, linux-api
In-Reply-To: <ZsTgxUndhb04snd6@1wt.eu>
> 2024年8月21日 02:30，Willy Tarreau <w@1wt.eu> 写道：
>
> On Wed, Aug 21, 2024 at 12:09:41AM +0800, Miao Wang wrote:
>> However, my original question is whether it is expected to include new
>> syscalls in kernel stable tree. According to the document "stable-kernel-
>> rules", if I'm interpreting it correctly, I expect only bug fixes and small
>> driver enhancements from stable releases. I understand the patch in question
>> is actually introducing new syscalls, which is beyond my expectation. So I
>> wonder the consideration of including this patch in stable releases.
>
> When you maintain stable software you quickly realize that everything
> is not just pure white or black but a shade of gray and that if it can
> be considered as a bug to miss a syscall in certain environments for
> example, then it can become a valid fix to add it. I don't have any
> opinion on this particular one, but since your question is broader I'm
> trying to explain.
>
> Different people have different expectations about what needs to be
> fixed, that's even why some people will choose a distro over another
> one (prefer to fix only critical bugs over fixing all bugs for example),
> but there's no point restarting a philosophical on this topic which has
> already been rehashed too many times in the past.
>
> As a rule of thumb, just keep in mind that anything that needs to get
> fix will eventually be fixed.
Many thanks for your explanation!
Cheers,
Miao Wang
>
> Thanks,
> Willy
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Willy Tarreau @ 2024-08-20 18:30 UTC (permalink / raw)
To: Miao Wang
Cc: Greg Kroah-Hartman, Xi Ruoyao, Huacai Chen, loongarch,
Sasha Levin, stable, WANG Xuerui, linux-api
In-Reply-To: <46C6EB05-1AA2-42BF-82BF-3B99CCA57439@gmail.com>
On Wed, Aug 21, 2024 at 12:09:41AM +0800, Miao Wang wrote:
> However, my original question is whether it is expected to include new
> syscalls in kernel stable tree. According to the document "stable-kernel-
> rules", if I'm interpreting it correctly, I expect only bug fixes and small
> driver enhancements from stable releases. I understand the patch in question
> is actually introducing new syscalls, which is beyond my expectation. So I
> wonder the consideration of including this patch in stable releases.
When you maintain stable software you quickly realize that everything
is not just pure white or black but a shade of gray and that if it can
be considered as a bug to miss a syscall in certain environments for
example, then it can become a valid fix to add it. I don't have any
opinion on this particular one, but since your question is broader I'm
trying to explain.
Different people have different expectations about what needs to be
fixed, that's even why some people will choose a distro over another
one (prefer to fix only critical bugs over fixing all bugs for example),
but there's no point restarting a philosophical on this topic which has
already been rehashed too many times in the past.
As a rule of thumb, just keep in mind that anything that needs to get
fix will eventually be fixed.
Thanks,
Willy
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Miao Wang @ 2024-08-20 16:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Willy Tarreau, Xi Ruoyao, Huacai Chen, loongarch, Sasha Levin,
stable, WANG Xuerui, linux-api
In-Reply-To: <ZsSwnPfyOvdSBMOC@1wt.eu>
> 2024年8月20日 23:05，Willy Tarreau <w@1wt.eu> 写道：
>
> On Tue, Aug 20, 2024 at 10:00:35PM +0800, Greg Kroah-Hartman wrote:
>> On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
>>> Hi,
>>>
>>>> 2024?8?20? 21:36,Greg Kroah-Hartman <gregkh@linuxfoundation.org> ??:
>>>>
>>>> On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
>>>>> Hi, Greg
>>>>>
>>>>> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
>>>>> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
>>>>> actually introduced new sys calls newfstatat and fstat to Loongarch.
>>>>
>>>> See the documentation in that commit for why it was done.
>>>
>>> Thanks for your explanation. I totally understand the necessity of
>>> re-introducing thees two syscalls. I just wonder whether there is any
>>> limitation on what can be included in to the stable trees. If there
>>> was no limitation, theoretically, I could also maintain a so-called
>>> stable tree by applying all the patches from torvalds' tree, except
>>> those that bumps the version number. Apparently such a "stable" tree
>>> is far from stable.
>>
>> Or you could do the opposite, something that I have seen vendors do, and
>> just bump the kernel version number to try to "claim" they updated their
>> kernel to a more secure one (i.e. one that fixed loads of known issues),
>> but they really didn't.
>
> Some of those who do that don't even notice what they're missing. I've
> seen some BSP kernels "forward-ported" by merging the next bunch of
> stable versions, trying to fix rejects by hand with the usual ratio of
> failures, but after that since that version is part of the history, it's
> impossible to figure what's really missing or not. Some people don't seem
> to realize that *merging* code can actually result in *removing* fixes.
> So they don't even need cheat on their versions, they're genuinely
> believing they're OK... which is worse!
>
> Willy
Thank you all for sharing experiences with vendors messing up kernel
version numbers.
However, my original question is whether it is expected to include new
syscalls in kernel stable tree. According to the document "stable-kernel-
rules", if I'm interpreting it correctly, I expect only bug fixes and small
driver enhancements from stable releases. I understand the patch in question
is actually introducing new syscalls, which is beyond my expectation. So I
wonder the consideration of including this patch in stable releases.
Cheers,
Miao Wang
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Willy Tarreau @ 2024-08-20 15:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Miao Wang, Xi Ruoyao, Huacai Chen, loongarch, Sasha Levin, stable,
WANG Xuerui, linux-api
In-Reply-To: <2024082027-deskbound-rumbling-b96f@gregkh>
On Tue, Aug 20, 2024 at 10:00:35PM +0800, Greg Kroah-Hartman wrote:
> On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
> > Hi,
> >
> > > 2024?8?20? 21:36,Greg Kroah-Hartman <gregkh@linuxfoundation.org> ??:
> > >
> > > On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
> > >> Hi, Greg
> > >>
> > >> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
> > >> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
> > >> actually introduced new sys calls newfstatat and fstat to Loongarch.
> > >
> > > See the documentation in that commit for why it was done.
> >
> > Thanks for your explanation. I totally understand the necessity of
> > re-introducing thees two syscalls. I just wonder whether there is any
> > limitation on what can be included in to the stable trees. If there
> > was no limitation, theoretically, I could also maintain a so-called
> > stable tree by applying all the patches from torvalds' tree, except
> > those that bumps the version number. Apparently such a "stable" tree
> > is far from stable.
>
> Or you could do the opposite, something that I have seen vendors do, and
> just bump the kernel version number to try to "claim" they updated their
> kernel to a more secure one (i.e. one that fixed loads of known issues),
> but they really didn't.
Some of those who do that don't even notice what they're missing. I've
seen some BSP kernels "forward-ported" by merging the next bunch of
stable versions, trying to fix rejects by hand with the usual ratio of
failures, but after that since that version is part of the history, it's
impossible to figure what's really missing or not. Some people don't seem
to realize that *merging* code can actually result in *removing* fixes.
So they don't even need cheat on their versions, they're genuinely
believing they're OK... which is worse!
Willy
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Theodore Ts'o @ 2024-08-20 14:44 UTC (permalink / raw)
To: Miao Wang
Cc: Greg Kroah-Hartman, Xi Ruoyao, Huacai Chen, loongarch,
Sasha Levin, stable, WANG Xuerui, linux-api
In-Reply-To: <D19DB99F-B5D9-49A6-BCF8-A5980A9BC1A0@gmail.com>
On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
>
> I agree with you and Cyril on the version numbers, recalling that kernels
> on RHEL numbered on 3.10 contains various new features.
Some enterprise kernel versions have also been known to completely
take code whole from some subsystem (like, for example, a file system
like ext4 or xfs) from much newer upstream kernel version and backport
it into a very old "enterprise" kernel, with massive work to deal with
the dependencies that might be needed by the newer code, and
additional massive work so that structures and function signatures
stay the same so that binary out-of-tree kernel modules can continue
to load on that "stable" enterprise kernel.
That might take huge amounts of effort from a quality assurance
perspective, but that's might some enterprise customers are willing to
pay $$$$ for that frankenkernel and support for that frankenkernel....
This is also why when I get a bug report relating a distro kernel, I
tell bug reporters to go back to the distro for support. Basically,
you can't really take anything for granted when you're dealing with a
non-upstream kernel, and that includes the version number.
Personally, I think this is a really bad idea, but distros and their
customers have the freedom to do what they want. And this is why
those customers pay the distro the big bucks. :-)
- Ted
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Greg Kroah-Hartman @ 2024-08-20 14:00 UTC (permalink / raw)
To: Miao Wang
Cc: Xi Ruoyao, Huacai Chen, loongarch, Sasha Levin, stable,
WANG Xuerui, linux-api
In-Reply-To: <D19DB99F-B5D9-49A6-BCF8-A5980A9BC1A0@gmail.com>
On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
> Hi,
>
> > 2024年8月20日 21:36，Greg Kroah-Hartman <gregkh@linuxfoundation.org> 写道：
> >
> > On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
> >> Hi, Greg
> >>
> >> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
> >> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
> >> actually introduced new sys calls newfstatat and fstat to Loongarch.
> >
> > See the documentation in that commit for why it was done.
>
> Thanks for your explanation. I totally understand the necessity of
> re-introducing thees two syscalls. I just wonder whether there is any
> limitation on what can be included in to the stable trees. If there
> was no limitation, theoretically, I could also maintain a so-called
> stable tree by applying all the patches from torvalds' tree, except
> those that bumps the version number. Apparently such a "stable" tree
> is far from stable.
Or you could do the opposite, something that I have seen vendors do, and
just bump the kernel version number to try to "claim" they updated their
kernel to a more secure one (i.e. one that fixed loads of known issues),
but they really didn't.
Either way, it's your kernel, you are free to do whatever you want with
it, have fun! :)
greg k-h
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Miao Wang @ 2024-08-20 13:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Xi Ruoyao, Huacai Chen, loongarch, Sasha Levin, stable,
WANG Xuerui, linux-api
In-Reply-To: <2024082057-coherence-lethargy-3513@gregkh>
Hi,
> 2024年8月20日 21:36，Greg Kroah-Hartman <gregkh@linuxfoundation.org> 写道：
>
> On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
>> Hi, Greg
>>
>> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
>> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
>> actually introduced new sys calls newfstatat and fstat to Loongarch.
>
> See the documentation in that commit for why it was done.
Thanks for your explanation. I totally understand the necessity of
re-introducing thees two syscalls. I just wonder whether there is any
limitation on what can be included in to the stable trees. If there
was no limitation, theoretically, I could also maintain a so-called
stable tree by applying all the patches from torvalds' tree, except
those that bumps the version number. Apparently such a "stable" tree
is far from stable.
>
>> I wonder if it is correct to add new syscalls, which actually changes
>> the kernel features, in stable releases, as it might confuse downstream
>> developers because they may assume the existence of a certain feature
>> after a certain version.
>
> Version numbers should never be used to be checked for anything as they
> are only a "moment in time" stamp. They do not reflect features or
> capabilities or anything else.
I agree with you and Cyril on the version numbers, recalling that kernels
on RHEL numbered on 3.10 contains various new features.
> Test for functionality if you want to check for something, that's the
> only way it will ever work on all of the variants of different
> "enterprise" kernels.
Thanks again for your quick reply.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Greg Kroah-Hartman @ 2024-08-20 13:36 UTC (permalink / raw)
To: Miao Wang
Cc: Xi Ruoyao, Huacai Chen, loongarch, Sasha Levin, stable,
WANG Xuerui, linux-api
In-Reply-To: <DF762B6F-360A-4C0C-8C85-55686417209B@gmail.com>
On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
> Hi, Greg
>
> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
> actually introduced new sys calls newfstatat and fstat to Loongarch.
See the documentation in that commit for why it was done.
> I wonder if it is correct to add new syscalls, which actually changes
> the kernel features, in stable releases, as it might confuse downstream
> developers because they may assume the existence of a certain feature
> after a certain version.
Version numbers should never be used to be checked for anything as they
are only a "moment in time" stamp. They do not reflect features or
capabilities or anything else.
Test for functionality if you want to check for something, that's the
only way it will ever work on all of the variants of different
"enterprise" kernels.
thanks,
greg k-h
^ permalink raw reply
* Re: It is correct to introduce new sys calls to stable versions?
From: Cyril Hrubis @ 2024-08-20 13:29 UTC (permalink / raw)
To: Miao Wang
Cc: Greg Kroah-Hartman, Xi Ruoyao, Huacai Chen, loongarch,
Sasha Levin, stable, WANG Xuerui, linux-api
In-Reply-To: <DF762B6F-360A-4C0C-8C85-55686417209B@gmail.com>
Hi!
> I wonder if it is correct to add new syscalls, which actually changes
> the kernel features, in stable releases, as it might confuse downstream
> developers because they may assume the existence of a certain feature
> after a certain version.
Just a side note, one thing I've learned by maintaining the Linux Test
Project is that the kernel version is a lie. You should not use the
kernel version for anything, never. All distributions rutinely backport
various new functionalities to older kernels and only reliable way how
to make sure something is implemented is to call the syscall and check
the return value.
That being said I have no idea what rules apply to stable trees.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* It is correct to introduce new sys calls to stable versions?
From: Miao Wang @ 2024-08-20 13:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Xi Ruoyao, Huacai Chen, loongarch, Sasha Levin, stable,
WANG Xuerui, linux-api
Hi, Greg
I saw you have included commit 7697a0fe0154 ("LoongArch: Define
__ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
actually introduced new sys calls newfstatat and fstat to Loongarch.
I wonder if it is correct to add new syscalls, which actually changes
the kernel features, in stable releases, as it might confuse downstream
developers because they may assume the existence of a certain feature
after a certain version.
Cheers,
Miao Wang
^ permalink raw reply
* Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available
From: Charlie Jenkins @ 2024-08-20 2:43 UTC (permalink / raw)
To: Levi Zim
Cc: Palmer Dabbelt, cyy, alexghiti, Paul Walmsley, aou, shuah, corbet,
linux-mm, linux-riscv, linux-kernel, linux-kselftest, linux-doc,
linux-api
In-Reply-To: <MEYP282MB2312FDB8F4AA7A76884081ADC68D2@MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM>
On Tue, Aug 20, 2024 at 09:48:50AM +0800, Levi Zim wrote:
> On 2024-08-20 01:00, Charlie Jenkins wrote:
> > On Mon, Aug 19, 2024 at 01:55:57PM +0800, Levi Zim wrote:
> > > On 2024-03-22 22:06, Palmer Dabbelt wrote:
> > > > On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote:
> > > > > On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote:
> > > > > > On Wed, 2024-01-31 at 22:41 +0800, Yangyu Chen wrote:
> > > > > > > On Tue, 2024-01-30 at 17:07 -0800, Charlie Jenkins wrote:
> > > > > > > > On riscv it is guaranteed that the address returned by mmap is less
> > > > > > > > than
> > > > > > > > the hint address. Allow mmap to return an address all the way up to
> > > > > > > > addr, if provided, rather than just up to the lower address space.
> > > > > > > > > > This provides a performance benefit as well, allowing
> > > > > > mmap to exit
> > > > > > > > after
> > > > > > > > checking that the address is in range rather than searching for a
> > > > > > > > valid
> > > > > > > > address.
> > > > > > > > > > It is possible to provide an address that uses at most the same
> > > > > > > > number
> > > > > > > > of bits, however it is significantly more computationally expensive
> > > > > > > > to
> > > > > > > > provide that number rather than setting the max to be the hint
> > > > > > > > address.
> > > > > > > > There is the instruction clz/clzw in Zbb that returns the highest
> > > > > > > > set
> > > > > > > > bit
> > > > > > > > which could be used to performantly implement this, but it would
> > > > > > > > still
> > > > > > > > be slower than the current implementation. At worst case, half of
> > > > > > > > the
> > > > > > > > address would not be able to be allocated when a hint address is
> > > > > > > > provided.
> > > > > > > > > > Signed-off-by: Charlie Jenkins<charlie@rivosinc.com>
> > > > > > > > ---
> > > > > > > > arch/riscv/include/asm/processor.h | 27 +++++++++++---------------
> > > > > > > > -
> > > > > > > > 1 file changed, 11 insertions(+), 16 deletions(-)
> > > > > > > > > > diff --git a/arch/riscv/include/asm/processor.h
> > > > > > > > b/arch/riscv/include/asm/processor.h
> > > > > > > > index f19f861cda54..8ece7a8f0e18 100644
> > > > > > > > --- a/arch/riscv/include/asm/processor.h
> > > > > > > > +++ b/arch/riscv/include/asm/processor.h
> > > > > > > > @@ -14,22 +14,16 @@
> > > > > > > >
> > > > > > > > #include <asm/ptrace.h>
> > > > > > > >
> > > > > > > > -#ifdef CONFIG_64BIT
> > > > > > > > -#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
> > > > > > > > -#define STACK_TOP_MAX TASK_SIZE_64
> > > > > > > > -
> > > > > > > > #define arch_get_mmap_end(addr, len, flags) \
> > > > > > > > ({ \
> > > > > > > > unsigned long
> > > > > > > > mmap_end; \
> > > > > > > > typeof(addr) _addr = (addr); \
> > > > > > > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
> > > > > > > > is_compat_task())) \
> > > > > > > > + if ((_addr) == 0 || \
> > > > > > > > + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
> > > > > > > > + ((_addr + len) > BIT(VA_BITS -
> > > > > > > > 1))) \
> > > > > > > > mmap_end = STACK_TOP_MAX; \
> > > > > > > > - else if ((_addr) >= VA_USER_SV57) \
> > > > > > > > - mmap_end = STACK_TOP_MAX; \
> > > > > > > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
> > > > > > > > VA_BITS_SV48)) \
> > > > > > > > - mmap_end = VA_USER_SV48; \
> > > > > > > > else \
> > > > > > > > - mmap_end = VA_USER_SV39; \
> > > > > > > > + mmap_end = (_addr + len); \
> > > > > > > > mmap_end; \
> > > > > > > > })
> > > > > > > >
> > > > > > > > @@ -39,17 +33,18 @@
> > > > > > > > typeof(addr) _addr = (addr); \
> > > > > > > > typeof(base) _base = (base); \
> > > > > > > > unsigned long rnd_gap = DEFAULT_MAP_WINDOW - (_base); \
> > > > > > > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
> > > > > > > > is_compat_task())) \
> > > > > > > > + if ((_addr) == 0 || \
> > > > > > > > + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
> > > > > > > > + ((_addr + len) > BIT(VA_BITS -
> > > > > > > > 1))) \
> > > > > > > > mmap_base = (_base); \
> > > > > > > > - else if (((_addr) >= VA_USER_SV57) && (VA_BITS >=
> > > > > > > > VA_BITS_SV57)) \
> > > > > > > > - mmap_base = VA_USER_SV57 - rnd_gap; \
> > > > > > > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
> > > > > > > > VA_BITS_SV48)) \
> > > > > > > > - mmap_base = VA_USER_SV48 - rnd_gap; \
> > > > > > > > else \
> > > > > > > > - mmap_base = VA_USER_SV39 - rnd_gap; \
> > > > > > > > + mmap_base = (_addr + len) - rnd_gap; \
> > > > > > > > mmap_base; \
> > > > > > > > })
> > > > > > > >
> > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > +#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
> > > > > > > > +#define STACK_TOP_MAX TASK_SIZE_64
> > > > > > > > #else
> > > > > > > > #define DEFAULT_MAP_WINDOW TASK_SIZE
> > > > > > > > #define STACK_TOP_MAX TASK_SIZE
> > > > > > > > > > I have carefully tested your patch on qemu with sv57. A
> > > > > > bug that
> > > > > > > needs
> > > > > > > to be solved is that mmap with the same hint address without
> > > > > > > MAP_FIXED
> > > > > > > set will fail the second time.
> > > > > > > > Userspace code to reproduce the bug:
> > > > > > > > #include <sys/mman.h>
> > > > > > > #include <stdio.h>
> > > > > > > #include <stdint.h>
> > > > > > > > void test(char *addr) {
> > > > > > > char *res = mmap(addr, 4096, PROT_READ | PROT_WRITE,
> > > > > > > MAP_ANONYMOUS
> > > > > > > > MAP_PRIVATE, -1, 0);
> > > > > > > printf("hint %p got %p.\n", addr, res);
> > > > > > > }
> > > > > > > > int main (void) {
> > > > > > > test(1<<30);
> > > > > > > test(1<<30);
> > > > > > > test(1<<30);
> > > > > > > return 0;
> > > > > > > }
> > > > > > > > output:
> > > > > > > > hint 0x40000000 got 0x40000000.
> > > > > > > hint 0x40000000 got 0xffffffffffffffff.
> > > > > > > hint 0x40000000 got 0xffffffffffffffff.
> > > > > > > > output on x86:
> > > > > > > > hint 0x40000000 got 0x40000000.
> > > > > > > hint 0x40000000 got 0x7f9171363000.
> > > > > > > hint 0x40000000 got 0x7f9171362000.
> > > > > > > > It may need to implement a special arch_get_unmapped_area and
> > > > > > > arch_get_unmapped_area_topdown function.
> > > > > > >
> > > > > > This is because hint address < rnd_gap. I have tried to let mmap_base =
> > > > > > min((_addr + len), (base) + TASK_SIZE - DEFAULT_MAP_WINDOW). However it
> > > > > > does not work for bottom-up while ulimit -s is unlimited. You said this
> > > > > > behavior is expected from patch v2 review. However it brings a new
> > > > > > regression even on sv39 systems.
> > > > > >
> > > > > > I still don't know the reason why use addr+len as the upper-bound. I
> > > > > > think solution like x86/arm64/powerpc provide two address space switch
> > > > > > based on whether hint address above the default map window is enough.
> > > > > >
> > > > > Yep this is expected. It is up to the maintainers to decide.
> > > > Sorry I forgot to reply to this, I had a buffer sitting around somewhere
> > > > but I must have lost it.
> > > >
> > > > I think Charlie's approach is the right way to go. Putting my userspace
> > > > hat on, I'd much rather have my allocations fail rather than silently
> > > > ignore the hint when there's memory pressure.
> > > >
> > > > If there's some real use case that needs these low hints to be silently
> > > > ignored under VA pressure then we can try and figure something out that
> > > > makes those applications work.
> > > I could confirm that this patch has broken chromium's partition allocator on
> > > riscv64. The minimal reproduction I use is chromium-mmap.c:
> > >
> > > #include <stdio.h>
> > > #include <sys/mman.h>
> > >
> > > int main() {
> > > void* expected = (void*)0x400000000;
> > > void* addr = mmap(expected, 17179869184, PROT_NONE,
> > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
> > > if (addr != expected) {
> > It is not valid to assume that the address returned by mmap will be the
> > hint address. If the hint address is not available, mmap will return a
> > different address.
>
> Oh, sorry I didn't make it clear what is the expected behavior.
> The printf here is solely for debugging purpose and I don't mean that
> chromium expect it will get the hint address. The expected behavior is that
> both the two mmap calls will succeed.
>
> > > printf("Not expected address: %p != %p\n", addr, expected);
> > > }
> > > expected = (void*)0x3fffff000;
> > > addr = mmap(expected, 17179873280, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
> > > -1, 0);
> > > if (addr != expected) {
> > > printf("Not expected address: %p != %p\n", addr, expected);
> > > }
> > > return 0;
> > > }
> > >
> > > The second mmap fails with ENOMEM. Manually reverting this commit fixes the
> > > issue for me. So I think it's clearly a regression and breaks userspace.
> > >
> > The issue here is that overlapping memory is being requested. This
> > second mmap will never be able to provide an address at 0x3fffff000 with
> > a size of 0x400001000 since mmap just provided an address at 0x400000000
> > with a size of 0x400000000.
> >
> > Before this patch, this request causes mmap to return a completely
> > arbitrary value. There is no reason to use a hint address in this manner
> > because the hint can never be respected. Since an arbitrary address is
> > desired, a hint of zero should be used.
> >
> > This patch causes the behavior to be more deterministic. Instead of
> > providing an arbitrary address, it causes the address to be less than or
> > equal to the hint address. This allows for applications to make
> > assumptions about the returned address.
>
> About the overlap, of course the partition allocator's request for
> overlapped vma seems unreasonable.
>
> But I still don't quite understand why mmap cannot use an address higher
> than the hint address.
> The hint address, after all, is a hint, not a requirement.
Yes that is fair. A "hint" that does not guarantee anything is
useless so architectures have abused the term quite a bit.
>
> Quoting the man page:
>
> > If another mapping already exists there, the kernel picks
> > a new address that may or may not depend on the hint. The
> > address of the new mapping is returned as the result of the call.
> So for casual programmers that only reads man page but not architecture
> specific kernel
> documentation, the current behavior of mmap on riscv64 failing on overlapped
> address ranges
> are quite surprising IMO.
The man pages for riscv are in desperate need of attention. I have
submitted a couple of updates to them recently, but there is a lot more
work to be done to help developers.
>
> And quoting the man page again about the errno:
>
> > ENOMEM No memory is available.
> >
> > ENOMEM The process's maximum number of mappings would have been
> > exceeded. This error can also occur for munmap(), when
> > unmapping a region in the middle of an existing mapping,
> > since this results in two smaller mappings on either side
> > of the region being unmapped.
> >
> > ENOMEM (since Linux 4.7) The process's RLIMIT_DATA limit,
> > described in getrlimit(2), would have been exceeded.
> >
> > ENOMEM We don't like addr, because it exceeds the virtual address
> > space of the CPU.
> >
>
> There's no matching description for the ENOMEM returned here.
> I would suggest removing "because it exceeds the virtual address
> space of the CPU." from the last item if the ENOMEM behavior here
> is expected.
This ENOMEM means something like "no memory available in the requested
region".
>
> > This code is unfortunately relying on the previously mostly undefined
> > behavior of the hint address in mmap.
> Although I haven't read the code of chromium's partition allocator to judge
> whether it should
> be improved or fixed for riscv64, I do know that the kernel "don't break
> userspace" and
> "never EVER blame the user programs".
The hint address design of mmap is a tricky one because it is largely
implementation defined and what the man pages say is not how it is
implemented in most architectures!
> > The goal of this patch is to help
> > developers have more consistent mmap behavior, but maybe it is necessary
> > to hide this behavior behind an mmap flag.
> Thank you for helping to shape a more consistent mmap behavior.
> I think this should be fixed ASAP either by allowing the hint address to be
> ignored
> (as suggested by the Linux man page), or hide this behavior behind an mmap
> flag as you said.
Having a flag could also lead to a generic way of defining this
behavior. Other architectures do not provide a way for applications to
guarantee that some number of bits are left unused in a virtual address,
and that was one of the motivating design goals here.
- Charlie
>
> > - Charlie
> >
> > > See alsohttps://github.com/riscv-forks/electron/issues/4
> > >
> > > > > - Charlie
> > > Sincerely,
> > > Levi
> > >
^ permalink raw reply
* Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available
From: Levi Zim @ 2024-08-20 1:58 UTC (permalink / raw)
To: Charlie Jenkins
Cc: Palmer Dabbelt, cyy, alexghiti, Paul Walmsley, aou, shuah, corbet,
linux-mm, linux-riscv, linux-kernel, linux-kselftest, linux-doc,
linux-api
In-Reply-To: <ZsN6R8IliKzAKKMb@ghost>
On 2024-08-20 01:00, Charlie Jenkins wrote:
> On Mon, Aug 19, 2024 at 01:55:57PM +0800, Levi Zim wrote:
>> On 2024-03-22 22:06, Palmer Dabbelt wrote:
>>> On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote:
>>>> On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote:
>>>>> On Wed, 2024-01-31 at 22:41 +0800, Yangyu Chen wrote:
>>>>>> On Tue, 2024-01-30 at 17:07 -0800, Charlie Jenkins wrote:
>>>>>>> On riscv it is guaranteed that the address returned by mmap is less
>>>>>>> than
>>>>>>> the hint address. Allow mmap to return an address all the way up to
>>>>>>> addr, if provided, rather than just up to the lower address space.
>>>>>>>>> This provides a performance benefit as well, allowing
>>>>> mmap to exit
>>>>>>> after
>>>>>>> checking that the address is in range rather than searching for a
>>>>>>> valid
>>>>>>> address.
>>>>>>>>> It is possible to provide an address that uses at most the same
>>>>>>> number
>>>>>>> of bits, however it is significantly more computationally expensive
>>>>>>> to
>>>>>>> provide that number rather than setting the max to be the hint
>>>>>>> address.
>>>>>>> There is the instruction clz/clzw in Zbb that returns the highest
>>>>>>> set
>>>>>>> bit
>>>>>>> which could be used to performantly implement this, but it would
>>>>>>> still
>>>>>>> be slower than the current implementation. At worst case, half of
>>>>>>> the
>>>>>>> address would not be able to be allocated when a hint address is
>>>>>>> provided.
>>>>>>>>> Signed-off-by: Charlie Jenkins<charlie@rivosinc.com>
>>>>>>> ---
>>>>>>> arch/riscv/include/asm/processor.h | 27 +++++++++++---------------
>>>>>>> -
>>>>>>> 1 file changed, 11 insertions(+), 16 deletions(-)
>>>>>>>>> diff --git a/arch/riscv/include/asm/processor.h
>>>>>>> b/arch/riscv/include/asm/processor.h
>>>>>>> index f19f861cda54..8ece7a8f0e18 100644
>>>>>>> --- a/arch/riscv/include/asm/processor.h
>>>>>>> +++ b/arch/riscv/include/asm/processor.h
>>>>>>> @@ -14,22 +14,16 @@
>>>>>>>
>>>>>>> #include <asm/ptrace.h>
>>>>>>>
>>>>>>> -#ifdef CONFIG_64BIT
>>>>>>> -#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
>>>>>>> -#define STACK_TOP_MAX TASK_SIZE_64
>>>>>>> -
>>>>>>> #define arch_get_mmap_end(addr, len, flags) \
>>>>>>> ({ \
>>>>>>> unsigned long
>>>>>>> mmap_end; \
>>>>>>> typeof(addr) _addr = (addr); \
>>>>>>> - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
>>>>>>> is_compat_task())) \
>>>>>>> + if ((_addr) == 0 || \
>>>>>>> + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
>>>>>>> + ((_addr + len) > BIT(VA_BITS -
>>>>>>> 1))) \
>>>>>>> mmap_end = STACK_TOP_MAX; \
>>>>>>> - else if ((_addr) >= VA_USER_SV57) \
>>>>>>> - mmap_end = STACK_TOP_MAX; \
>>>>>>> - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
>>>>>>> VA_BITS_SV48)) \
>>>>>>> - mmap_end = VA_USER_SV48; \
>>>>>>> else \
>>>>>>> - mmap_end = VA_USER_SV39; \
>>>>>>> + mmap_end = (_addr + len); \
>>>>>>> mmap_end; \
>>>>>>> })
>>>>>>>
>>>>>>> @@ -39,17 +33,18 @@
>>>>>>> typeof(addr) _addr = (addr); \
>>>>>>> typeof(base) _base = (base); \
>>>>>>> unsigned long rnd_gap = DEFAULT_MAP_WINDOW - (_base); \
>>>>>>> - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
>>>>>>> is_compat_task())) \
>>>>>>> + if ((_addr) == 0 || \
>>>>>>> + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
>>>>>>> + ((_addr + len) > BIT(VA_BITS -
>>>>>>> 1))) \
>>>>>>> mmap_base = (_base); \
>>>>>>> - else if (((_addr) >= VA_USER_SV57) && (VA_BITS >=
>>>>>>> VA_BITS_SV57)) \
>>>>>>> - mmap_base = VA_USER_SV57 - rnd_gap; \
>>>>>>> - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
>>>>>>> VA_BITS_SV48)) \
>>>>>>> - mmap_base = VA_USER_SV48 - rnd_gap; \
>>>>>>> else \
>>>>>>> - mmap_base = VA_USER_SV39 - rnd_gap; \
>>>>>>> + mmap_base = (_addr + len) - rnd_gap; \
>>>>>>> mmap_base; \
>>>>>>> })
>>>>>>>
>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>> +#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
>>>>>>> +#define STACK_TOP_MAX TASK_SIZE_64
>>>>>>> #else
>>>>>>> #define DEFAULT_MAP_WINDOW TASK_SIZE
>>>>>>> #define STACK_TOP_MAX TASK_SIZE
>>>>>>>>> I have carefully tested your patch on qemu with sv57. A
>>>>> bug that
>>>>>> needs
>>>>>> to be solved is that mmap with the same hint address without
>>>>>> MAP_FIXED
>>>>>> set will fail the second time.
>>>>>>> Userspace code to reproduce the bug:
>>>>>>> #include <sys/mman.h>
>>>>>> #include <stdio.h>
>>>>>> #include <stdint.h>
>>>>>>> void test(char *addr) {
>>>>>> char *res = mmap(addr, 4096, PROT_READ | PROT_WRITE,
>>>>>> MAP_ANONYMOUS
>>>>>>> MAP_PRIVATE, -1, 0);
>>>>>> printf("hint %p got %p.\n", addr, res);
>>>>>> }
>>>>>>> int main (void) {
>>>>>> test(1<<30);
>>>>>> test(1<<30);
>>>>>> test(1<<30);
>>>>>> return 0;
>>>>>> }
>>>>>>> output:
>>>>>>> hint 0x40000000 got 0x40000000.
>>>>>> hint 0x40000000 got 0xffffffffffffffff.
>>>>>> hint 0x40000000 got 0xffffffffffffffff.
>>>>>>> output on x86:
>>>>>>> hint 0x40000000 got 0x40000000.
>>>>>> hint 0x40000000 got 0x7f9171363000.
>>>>>> hint 0x40000000 got 0x7f9171362000.
>>>>>>> It may need to implement a special arch_get_unmapped_area and
>>>>>> arch_get_unmapped_area_topdown function.
>>>>>>
>>>>> This is because hint address < rnd_gap. I have tried to let mmap_base =
>>>>> min((_addr + len), (base) + TASK_SIZE - DEFAULT_MAP_WINDOW). However it
>>>>> does not work for bottom-up while ulimit -s is unlimited. You said this
>>>>> behavior is expected from patch v2 review. However it brings a new
>>>>> regression even on sv39 systems.
>>>>>
>>>>> I still don't know the reason why use addr+len as the upper-bound. I
>>>>> think solution like x86/arm64/powerpc provide two address space switch
>>>>> based on whether hint address above the default map window is enough.
>>>>>
>>>> Yep this is expected. It is up to the maintainers to decide.
>>> Sorry I forgot to reply to this, I had a buffer sitting around somewhere
>>> but I must have lost it.
>>>
>>> I think Charlie's approach is the right way to go. Putting my userspace
>>> hat on, I'd much rather have my allocations fail rather than silently
>>> ignore the hint when there's memory pressure.
>>>
>>> If there's some real use case that needs these low hints to be silently
>>> ignored under VA pressure then we can try and figure something out that
>>> makes those applications work.
>> I could confirm that this patch has broken chromium's partition allocator on
>> riscv64. The minimal reproduction I use is chromium-mmap.c:
>>
>> #include <stdio.h>
>> #include <sys/mman.h>
>>
>> int main() {
>> void* expected = (void*)0x400000000;
>> void* addr = mmap(expected, 17179869184, PROT_NONE,
>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
>> if (addr != expected) {
> It is not valid to assume that the address returned by mmap will be the
> hint address. If the hint address is not available, mmap will return a
> different address.
Oh, sorry I didn't make it clear what is the expected behavior.
The printf here is solely for debugging purpose and I don't mean that
chromium expect it will get the hint address. The expected behavior is
that both the two mmap calls will succeed.
>> printf("Not expected address: %p != %p\n", addr, expected);
>> }
>> expected = (void*)0x3fffff000;
>> addr = mmap(expected, 17179873280, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
>> -1, 0);
>> if (addr != expected) {
>> printf("Not expected address: %p != %p\n", addr, expected);
>> }
>> return 0;
>> }
>>
>> The second mmap fails with ENOMEM. Manually reverting this commit fixes the
>> issue for me. So I think it's clearly a regression and breaks userspace.
>>
> The issue here is that overlapping memory is being requested. This
> second mmap will never be able to provide an address at 0x3fffff000 with
> a size of 0x400001000 since mmap just provided an address at 0x400000000
> with a size of 0x400000000.
>
> Before this patch, this request causes mmap to return a completely
> arbitrary value. There is no reason to use a hint address in this manner
> because the hint can never be respected. Since an arbitrary address is
> desired, a hint of zero should be used.
>
> This patch causes the behavior to be more deterministic. Instead of
> providing an arbitrary address, it causes the address to be less than or
> equal to the hint address. This allows for applications to make
> assumptions about the returned address.
About the overlap, of course the partition allocator's request for
overlapped vma seems unreasonable.
But I still don't quite understand why mmap cannot use an address higher
than the hint address.
The hint address, after all, is a hint, not a requirement.
Quoting the man page:
> If another mapping already exists there, the kernel picks
> a new address that may or may not depend on the hint. The
> address of the new mapping is returned as the result of the call.
So for casual programmers that only reads man page but not architecture
specific kernel documentation, the current behavior of mmap on riscv64
failing on overlapped address ranges are quite surprising IMO.
And quoting the man page again about the errno:
> ENOMEM No memory is available.
>
> ENOMEM The process's maximum number of mappings would have been
> exceeded. This error can also occur for munmap(), when
> unmapping a region in the middle of an existing mapping,
> since this results in two smaller mappings on either side
> of the region being unmapped.
>
> ENOMEM (since Linux 4.7) The process's RLIMIT_DATA limit,
> described in getrlimit(2), would have been exceeded.
>
> ENOMEM We don't like addr, because it exceeds the virtual address
> space of the CPU.
>
There's no matching description for the ENOMEM returned here.
I would suggest removing "because it exceeds the virtual address
space of the CPU." from the last item if the ENOMEM behavior here
is expected.
> This code is unfortunately relying on the previously mostly undefined
> behavior of the hint address in mmap.
Although I haven't read the code of chromium's partition allocator to
judge whether it should
be improved or fixed for riscv64, I do know that the kernel "don't break
userspace" and "never EVER blame the user programs".
> The goal of this patch is to help
> developers have more consistent mmap behavior, but maybe it is necessary
> to hide this behavior behind an mmap flag.
Thank you for helping to shape a more consistent mmap behavior.
I think this should be fixed ASAP either by allowing the hint address to
be ignored
(as suggested by the Linux man page), or hide this behavior behind an
mmap flag as you said.
> - Charlie
>
>> See alsohttps://github.com/riscv-forks/electron/issues/4
>>
>>>> - Charlie
>> Sincerely,
>> Levi
>>
I accidentally introduced some HTML into this reply so this reply is
resent as plain text.
Sincerely,
Levi
^ permalink raw reply
* [PATCH RFT v9 8/8] selftests/clone3: Test shadow stack support
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, Shuah Khan
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
Add basic test coverage for specifying the shadow stack for a newly
created thread via clone3(), including coverage of the newly extended
argument structure. We check that a user specified shadow stack can be
provided, and that invalid combinations of parameters are rejected.
In order to facilitate testing on systems without userspace shadow stack
support we manually enable shadow stacks on startup, this is architecture
specific due to the use of an arch_prctl() on x86. Due to interactions with
potential userspace locking of features we actually detect support for
shadow stacks on the running system by attempting to allocate a shadow
stack page during initialisation using map_shadow_stack(), warning if this
succeeds when the enable failed.
In order to allow testing of user configured shadow stacks on
architectures with that feature we need to ensure that we do not return
from the function where the clone3() syscall is called in the child
process, doing so would trigger a shadow stack underflow. To do this we
use inline assembly rather than the standard syscall wrapper to call
clone3(). In order to avoid surprises we also use a syscall rather than
the libc exit() function., this should be overly cautious.
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/clone3/clone3.c | 147 +++++++++++++++++++++-
tools/testing/selftests/clone3/clone3_selftests.h | 38 ++++++
2 files changed, 184 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/clone3/clone3.c b/tools/testing/selftests/clone3/clone3.c
index 5b8b7d640e70..f64fe5cd701d 100644
--- a/tools/testing/selftests/clone3/clone3.c
+++ b/tools/testing/selftests/clone3/clone3.c
@@ -3,6 +3,7 @@
/* Based on Christian Brauner's clone3() example */
#define _GNU_SOURCE
+#include <asm/mman.h>
#include <errno.h>
#include <inttypes.h>
#include <linux/types.h>
@@ -11,6 +12,7 @@
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
+#include <sys/mman.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/un.h>
@@ -19,8 +21,12 @@
#include <sched.h>
#include "../kselftest.h"
+#include "../ksft_shstk.h"
#include "clone3_selftests.h"
+static bool shadow_stack_supported;
+static size_t max_supported_args_size;
+
enum test_mode {
CLONE3_ARGS_NO_TEST,
CLONE3_ARGS_ALL_0,
@@ -28,6 +34,11 @@ enum test_mode {
CLONE3_ARGS_INVAL_EXIT_SIGNAL_NEG,
CLONE3_ARGS_INVAL_EXIT_SIGNAL_CSIG,
CLONE3_ARGS_INVAL_EXIT_SIGNAL_NSIG,
+ CLONE3_ARGS_SHADOW_STACK,
+ CLONE3_ARGS_SHADOW_STACK_NO_SIZE,
+ CLONE3_ARGS_SHADOW_STACK_NO_POINTER,
+ CLONE3_ARGS_SHADOW_STACK_NO_TOKEN,
+ CLONE3_ARGS_SHADOW_STACK_NORMAL_MEMORY,
};
typedef bool (*filter_function)(void);
@@ -44,6 +55,44 @@ struct test {
filter_function filter;
};
+
+/*
+ * We check for shadow stack support by attempting to use
+ * map_shadow_stack() since features may have been locked by the
+ * dynamic linker resulting in spurious errors when we attempt to
+ * enable on startup. We warn if the enable failed.
+ */
+static void test_shadow_stack_supported(void)
+{
+ long ret;
+
+ ret = syscall(__NR_map_shadow_stack, 0, getpagesize(), 0);
+ if (ret == -1) {
+ ksft_print_msg("map_shadow_stack() not supported\n");
+ } else if ((void *)ret == MAP_FAILED) {
+ ksft_print_msg("Failed to map shadow stack\n");
+ } else {
+ ksft_print_msg("Shadow stack supportd\n");
+ shadow_stack_supported = true;
+
+ if (!shadow_stack_enabled)
+ ksft_print_msg("Mapped but did not enable shadow stack\n");
+ }
+}
+
+static unsigned long long get_shadow_stack_page(unsigned long flags)
+{
+ unsigned long long page;
+
+ page = syscall(__NR_map_shadow_stack, 0, getpagesize(), flags);
+ if ((void *)page == MAP_FAILED) {
+ ksft_print_msg("map_shadow_stack() failed: %d\n", errno);
+ return 0;
+ }
+
+ return page;
+}
+
static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
{
struct __clone_args args = {
@@ -89,6 +138,24 @@ static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
case CLONE3_ARGS_INVAL_EXIT_SIGNAL_NSIG:
args.exit_signal = 0x00000000000000f0ULL;
break;
+ case CLONE3_ARGS_SHADOW_STACK:
+ args.shadow_stack = get_shadow_stack_page(SHADOW_STACK_SET_TOKEN);
+ args.shadow_stack_size = getpagesize();
+ break;
+ case CLONE3_ARGS_SHADOW_STACK_NO_POINTER:
+ args.shadow_stack_size = getpagesize();
+ break;
+ case CLONE3_ARGS_SHADOW_STACK_NO_SIZE:
+ args.shadow_stack = get_shadow_stack_page(SHADOW_STACK_SET_TOKEN);
+ break;
+ case CLONE3_ARGS_SHADOW_STACK_NORMAL_MEMORY:
+ args.shadow_stack = (unsigned long long)malloc(getpagesize());
+ args.shadow_stack_size = getpagesize();
+ break;
+ case CLONE3_ARGS_SHADOW_STACK_NO_TOKEN:
+ args.shadow_stack = get_shadow_stack_page(0);
+ args.shadow_stack_size = getpagesize();
+ break;
}
memcpy(&args_ext.args, &args, sizeof(struct __clone_args));
@@ -102,7 +169,12 @@ static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
if (pid == 0) {
ksft_print_msg("I am the child, my PID is %d\n", getpid());
- _exit(EXIT_SUCCESS);
+ /*
+ * Use a raw syscall to ensure we don't get issues
+ * with manually specified shadow stack and exit handlers.
+ */
+ syscall(__NR_exit, EXIT_SUCCESS);
+ ksft_print_msg("CHILD FAILED TO EXIT PID is %d\n", getpid());
}
ksft_print_msg("I am the parent (%d). My child's pid is %d\n",
@@ -184,6 +256,26 @@ static bool no_timenamespace(void)
return true;
}
+static bool have_shadow_stack(void)
+{
+ if (shadow_stack_supported) {
+ ksft_print_msg("Shadow stack supported\n");
+ return true;
+ }
+
+ return false;
+}
+
+static bool no_shadow_stack(void)
+{
+ if (!shadow_stack_supported) {
+ ksft_print_msg("Shadow stack not supported\n");
+ return true;
+ }
+
+ return false;
+}
+
static size_t page_size_plus_8(void)
{
return getpagesize() + 8;
@@ -327,6 +419,56 @@ static const struct test tests[] = {
.expected = -EINVAL,
.test_mode = CLONE3_ARGS_NO_TEST,
},
+ {
+ .name = "Shadow stack on system with shadow stack",
+ .size = 0,
+ .expected = 0,
+ .e2big_valid = true,
+ .test_mode = CLONE3_ARGS_SHADOW_STACK,
+ .filter = no_shadow_stack,
+ },
+ {
+ .name = "Shadow stack with no pointer",
+ .size = 0,
+ .expected = -EINVAL,
+ .e2big_valid = true,
+ .test_mode = CLONE3_ARGS_SHADOW_STACK_NO_POINTER,
+ },
+ {
+ .name = "Shadow stack with no size",
+ .size = 0,
+ .expected = -EINVAL,
+ .e2big_valid = true,
+ .test_mode = CLONE3_ARGS_SHADOW_STACK_NO_SIZE,
+ .filter = no_shadow_stack,
+ },
+ {
+ .name = "Shadow stack with no token",
+ .flags = CLONE_VM,
+ .size = 0,
+ .expected = -EINVAL,
+ .e2big_valid = true,
+ .test_mode = CLONE3_ARGS_SHADOW_STACK_NO_TOKEN,
+ .filter = no_shadow_stack,
+ },
+ {
+ .name = "Shadow stack with normal memory",
+ .flags = CLONE_VM,
+ .size = 0,
+ .expected = -EFAULT,
+ .e2big_valid = true,
+ .test_mode = CLONE3_ARGS_SHADOW_STACK_NORMAL_MEMORY,
+ .filter = no_shadow_stack,
+ },
+ {
+ .name = "Shadow stack on system without shadow stack",
+ .flags = CLONE_VM,
+ .size = 0,
+ .expected = -EINVAL,
+ .e2big_valid = true,
+ .test_mode = CLONE3_ARGS_SHADOW_STACK,
+ .filter = have_shadow_stack,
+ },
};
int main(int argc, char *argv[])
@@ -334,9 +476,12 @@ int main(int argc, char *argv[])
size_t size;
int i;
+ enable_shadow_stack();
+
ksft_print_header();
ksft_set_plan(ARRAY_SIZE(tests));
test_clone3_supported();
+ test_shadow_stack_supported();
for (i = 0; i < ARRAY_SIZE(tests); i++)
test_clone3(&tests[i]);
diff --git a/tools/testing/selftests/clone3/clone3_selftests.h b/tools/testing/selftests/clone3/clone3_selftests.h
index 39b5dcba663c..38d82934668a 100644
--- a/tools/testing/selftests/clone3/clone3_selftests.h
+++ b/tools/testing/selftests/clone3/clone3_selftests.h
@@ -31,12 +31,50 @@ struct __clone_args {
__aligned_u64 set_tid;
__aligned_u64 set_tid_size;
__aligned_u64 cgroup;
+#ifndef CLONE_ARGS_SIZE_VER2
+#define CLONE_ARGS_SIZE_VER2 88 /* sizeof third published struct */
+#endif
+ __aligned_u64 shadow_stack;
+ __aligned_u64 shadow_stack_size;
+#ifndef CLONE_ARGS_SIZE_VER3
+#define CLONE_ARGS_SIZE_VER3 104 /* sizeof fourth published struct */
+#endif
};
+/*
+ * For architectures with shadow stack support we need to be
+ * absolutely sure that the clone3() syscall will be inline and not a
+ * function call so we open code.
+ */
+#ifdef __x86_64__
+static pid_t __always_inline sys_clone3(struct __clone_args *args, size_t size)
+{
+ long ret;
+ register long _num __asm__ ("rax") = __NR_clone3;
+ register long _args __asm__ ("rdi") = (long)(args);
+ register long _size __asm__ ("rsi") = (long)(size);
+
+ __asm__ volatile (
+ "syscall\n"
+ : "=a"(ret)
+ : "r"(_args), "r"(_size),
+ "0"(_num)
+ : "rcx", "r11", "memory", "cc"
+ );
+
+ if (ret < 0) {
+ errno = -ret;
+ return -1;
+ }
+
+ return ret;
+}
+#else
static pid_t sys_clone3(struct __clone_args *args, size_t size)
{
return syscall(__NR_clone3, args, size);
}
+#endif
static inline void test_clone3_supported(void)
{
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 7/8] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, Kees Cook, Shuah Khan
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
The clone_args structure is extensible, with the syscall passing in the
length of the structure. Inside the kernel we use copy_struct_from_user()
to read the struct but this has the unfortunate side effect of silently
accepting some overrun in the structure size providing the extra data is
all zeros. This means that we can't discover the clone3() features that
the running kernel supports by simply probing with various struct sizes.
We need to check this for the benefit of test systems which run newer
kselftests on old kernels.
Add a flag which can be set on a test to indicate that clone3() may return
-E2BIG due to the use of newer struct versions. Currently no tests need
this but it will become an issue for testing clone3() support for shadow
stacks, the support for shadow stacks is already present on x86.
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Kees Cook <kees@kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/clone3/clone3.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/clone3/clone3.c b/tools/testing/selftests/clone3/clone3.c
index e066b201fa64..5b8b7d640e70 100644
--- a/tools/testing/selftests/clone3/clone3.c
+++ b/tools/testing/selftests/clone3/clone3.c
@@ -39,6 +39,7 @@ struct test {
size_t size;
size_function size_function;
int expected;
+ bool e2big_valid;
enum test_mode test_mode;
filter_function filter;
};
@@ -146,6 +147,11 @@ static void test_clone3(const struct test *test)
ksft_print_msg("[%d] clone3() with flags says: %d expected %d\n",
getpid(), ret, test->expected);
if (ret != test->expected) {
+ if (test->e2big_valid && ret == -E2BIG) {
+ ksft_print_msg("Test reported -E2BIG\n");
+ ksft_test_result_skip("%s\n", test->name);
+ return;
+ }
ksft_print_msg(
"[%d] Result (%d) is different than expected (%d)\n",
getpid(), ret, test->expected);
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 6/8] selftests/clone3: Factor more of main loop into test_clone3()
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, Kees Cook, Shuah Khan
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
In order to make it easier to add more configuration for the tests and
more support for runtime detection of when tests can be run pass the
structure describing the tests into test_clone3() rather than picking
the arguments out of it and have that function do all the per-test work.
No functional change.
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Kees Cook <kees@kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/clone3/clone3.c | 77 ++++++++++++++++-----------------
1 file changed, 37 insertions(+), 40 deletions(-)
diff --git a/tools/testing/selftests/clone3/clone3.c b/tools/testing/selftests/clone3/clone3.c
index e61f07973ce5..e066b201fa64 100644
--- a/tools/testing/selftests/clone3/clone3.c
+++ b/tools/testing/selftests/clone3/clone3.c
@@ -30,6 +30,19 @@ enum test_mode {
CLONE3_ARGS_INVAL_EXIT_SIGNAL_NSIG,
};
+typedef bool (*filter_function)(void);
+typedef size_t (*size_function)(void);
+
+struct test {
+ const char *name;
+ uint64_t flags;
+ size_t size;
+ size_function size_function;
+ int expected;
+ enum test_mode test_mode;
+ filter_function filter;
+};
+
static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
{
struct __clone_args args = {
@@ -109,30 +122,40 @@ static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
return 0;
}
-static bool test_clone3(uint64_t flags, size_t size, int expected,
- enum test_mode test_mode)
+static void test_clone3(const struct test *test)
{
+ size_t size;
int ret;
+ if (test->filter && test->filter()) {
+ ksft_test_result_skip("%s\n", test->name);
+ return;
+ }
+
+ if (test->size_function)
+ size = test->size_function();
+ else
+ size = test->size;
+
+ ksft_print_msg("Running test '%s'\n", test->name);
+
ksft_print_msg(
"[%d] Trying clone3() with flags %#" PRIx64 " (size %zu)\n",
- getpid(), flags, size);
- ret = call_clone3(flags, size, test_mode);
+ getpid(), test->flags, size);
+ ret = call_clone3(test->flags, size, test->test_mode);
ksft_print_msg("[%d] clone3() with flags says: %d expected %d\n",
- getpid(), ret, expected);
- if (ret != expected) {
+ getpid(), ret, test->expected);
+ if (ret != test->expected) {
ksft_print_msg(
"[%d] Result (%d) is different than expected (%d)\n",
- getpid(), ret, expected);
- return false;
+ getpid(), ret, test->expected);
+ ksft_test_result_fail("%s\n", test->name);
+ return;
}
- return true;
+ ksft_test_result_pass("%s\n", test->name);
}
-typedef bool (*filter_function)(void);
-typedef size_t (*size_function)(void);
-
static bool not_root(void)
{
if (getuid() != 0) {
@@ -160,16 +183,6 @@ static size_t page_size_plus_8(void)
return getpagesize() + 8;
}
-struct test {
- const char *name;
- uint64_t flags;
- size_t size;
- size_function size_function;
- int expected;
- enum test_mode test_mode;
- filter_function filter;
-};
-
static const struct test tests[] = {
{
.name = "simple clone3()",
@@ -319,24 +332,8 @@ int main(int argc, char *argv[])
ksft_set_plan(ARRAY_SIZE(tests));
test_clone3_supported();
- for (i = 0; i < ARRAY_SIZE(tests); i++) {
- if (tests[i].filter && tests[i].filter()) {
- ksft_test_result_skip("%s\n", tests[i].name);
- continue;
- }
-
- if (tests[i].size_function)
- size = tests[i].size_function();
- else
- size = tests[i].size;
-
- ksft_print_msg("Running test '%s'\n", tests[i].name);
-
- ksft_test_result(test_clone3(tests[i].flags, size,
- tests[i].expected,
- tests[i].test_mode),
- "%s\n", tests[i].name);
- }
+ for (i = 0; i < ARRAY_SIZE(tests); i++)
+ test_clone3(&tests[i]);
ksft_finished();
}
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 5/8] selftests/clone3: Remove redundant flushes of output streams
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, Kees Cook, Shuah Khan
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
Since there were widespread issues with output not being flushed the
kselftest framework was modified to explicitly set the output streams
unbuffered in commit 58e2847ad2e6 ("selftests: line buffer test
program's stdout") so there is no need to explicitly flush in the clone3
tests.
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Kees Cook <kees@kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/clone3/clone3_selftests.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/testing/selftests/clone3/clone3_selftests.h b/tools/testing/selftests/clone3/clone3_selftests.h
index 3d2663fe50ba..39b5dcba663c 100644
--- a/tools/testing/selftests/clone3/clone3_selftests.h
+++ b/tools/testing/selftests/clone3/clone3_selftests.h
@@ -35,8 +35,6 @@ struct __clone_args {
static pid_t sys_clone3(struct __clone_args *args, size_t size)
{
- fflush(stdout);
- fflush(stderr);
return syscall(__NR_clone3, args, size);
}
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3()
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
Unlike with the normal stack there is no API for configuring the the shadow
stack for a new thread, instead the kernel will dynamically allocate a new
shadow stack with the same size as the normal stack. This appears to be due
to the shadow stack series having been in development since before the more
extensible clone3() was added rather than anything more deliberate.
Add parameters to clone3() specifying the location and size of a shadow
stack for the newly created process. If no shadow stack is specified
then the existing implicit allocation behaviour is maintained.
If a stack is specified then it is required to have an architecture
defined token placed on the stack, this will be consumed by the new
task. If the token is not provided then this will be reported as a
segmentation fault with si_code SEGV_CPERR, as a runtime shadow stack
protection error would be. This allows architectures to implement the
validation of the token in the child process context.
If the architecture does not support shadow stacks the shadow stack
parameters must be zero, architectures that do support the feature are
expected to enforce the same requirement on individual systems that lack
shadow stack support.
Update the existing x86 implementation to pay attention to the newly added
arguments, in order to maintain compatibility we use the existing behaviour
if no shadow stack is specified. Minimal validation is done of the supplied
parameters, detailed enforcement is left to when the thread is executed.
Since we are now using more fields from the kernel_clone_args we pass that
into the shadow stack code rather than individual fields.
At present this implementation does not consume the shadow stack token
atomically as would be desirable, it uses a separate read and write.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/x86/include/asm/shstk.h | 11 +++--
arch/x86/kernel/process.c | 2 +-
arch/x86/kernel/shstk.c | 103 +++++++++++++++++++++++++++++---------
include/linux/sched/task.h | 18 +++++++
include/uapi/linux/sched.h | 13 +++--
kernel/fork.c | 114 ++++++++++++++++++++++++++++++++++++++-----
6 files changed, 219 insertions(+), 42 deletions(-)
diff --git a/arch/x86/include/asm/shstk.h b/arch/x86/include/asm/shstk.h
index 4cb77e004615..252feeda6999 100644
--- a/arch/x86/include/asm/shstk.h
+++ b/arch/x86/include/asm/shstk.h
@@ -6,6 +6,7 @@
#include <linux/types.h>
struct task_struct;
+struct kernel_clone_args;
struct ksignal;
#ifdef CONFIG_X86_USER_SHADOW_STACK
@@ -16,8 +17,8 @@ struct thread_shstk {
long shstk_prctl(struct task_struct *task, int option, unsigned long arg2);
void reset_thread_features(void);
-unsigned long shstk_alloc_thread_stack(struct task_struct *p, unsigned long clone_flags,
- unsigned long stack_size);
+unsigned long shstk_alloc_thread_stack(struct task_struct *p,
+ const struct kernel_clone_args *args);
void shstk_free(struct task_struct *p);
int setup_signal_shadow_stack(struct ksignal *ksig);
int restore_signal_shadow_stack(void);
@@ -28,8 +29,10 @@ static inline long shstk_prctl(struct task_struct *task, int option,
unsigned long arg2) { return -EINVAL; }
static inline void reset_thread_features(void) {}
static inline unsigned long shstk_alloc_thread_stack(struct task_struct *p,
- unsigned long clone_flags,
- unsigned long stack_size) { return 0; }
+ const struct kernel_clone_args *args)
+{
+ return 0;
+}
static inline void shstk_free(struct task_struct *p) {}
static inline int setup_signal_shadow_stack(struct ksignal *ksig) { return 0; }
static inline int restore_signal_shadow_stack(void) { return 0; }
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index f63f8fd00a91..59456ab8d93f 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -207,7 +207,7 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
* is disabled, new_ssp will remain 0, and fpu_clone() will know not to
* update it.
*/
- new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->stack_size);
+ new_ssp = shstk_alloc_thread_stack(p, args);
if (IS_ERR_VALUE(new_ssp))
return PTR_ERR((void *)new_ssp);
diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
index 059685612362..42b2b18de20d 100644
--- a/arch/x86/kernel/shstk.c
+++ b/arch/x86/kernel/shstk.c
@@ -191,44 +191,103 @@ void reset_thread_features(void)
current->thread.features_locked = 0;
}
-unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long clone_flags,
- unsigned long stack_size)
+int arch_shstk_validate_clone(struct task_struct *t,
+ struct vm_area_struct *vma,
+ struct page *page,
+ struct kernel_clone_args *args)
+{
+ /*
+ * SSP is aligned, so reserved bits and mode bit are a zero, just mark
+ * the token 64-bit.
+ */
+ void *maddr = kmap_local_page(page);
+ int offset;
+ unsigned long addr, ssp;
+ u64 expected;
+ u64 val;
+
+ if (!features_enabled(ARCH_SHSTK_SHSTK))
+ return 0;
+
+ ssp = args->shadow_stack + args->shadow_stack_size;
+ addr = ssp - SS_FRAME_SIZE;
+ expected = ssp | BIT(0);
+ offset = offset_in_page(ssp);
+
+ /* This should really be an atomic cmpxchg. It is not. */
+ copy_from_user_page(vma, page, addr, &val, maddr + offset,
+ sizeof(val));
+
+ if (val != expected)
+ return false;
+ val = 0;
+
+ copy_to_user_page(vma, page, addr, maddr + offset, &val, sizeof(val));
+ set_page_dirty_lock(page);
+
+ return 0;
+}
+
+unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
+ const struct kernel_clone_args *args)
{
struct thread_shstk *shstk = &tsk->thread.shstk;
+ unsigned long clone_flags = args->flags;
unsigned long addr, size;
/*
* If shadow stack is not enabled on the new thread, skip any
- * switch to a new shadow stack.
+ * implicit switch to a new shadow stack and reject attempts to
+ * explicitly specify one.
*/
- if (!features_enabled(ARCH_SHSTK_SHSTK))
+ if (!features_enabled(ARCH_SHSTK_SHSTK)) {
+ if (args->shadow_stack || args->shadow_stack_size)
+ return (unsigned long)ERR_PTR(-EINVAL);
+
return 0;
+ }
/*
- * For CLONE_VFORK the child will share the parents shadow stack.
- * Make sure to clear the internal tracking of the thread shadow
- * stack so the freeing logic run for child knows to leave it alone.
+ * If the user specified a shadow stack then do some basic
+ * validation and use it, otherwise fall back to a default
+ * shadow stack size if the clone_flags don't indicate an
+ * allocation is unneeded.
*/
- if (clone_flags & CLONE_VFORK) {
+ if (args->shadow_stack) {
+ addr = args->shadow_stack;
+ size = args->shadow_stack_size;
shstk->base = 0;
shstk->size = 0;
- return 0;
- }
+ } else {
+ /*
+ * For CLONE_VFORK the child will share the parents
+ * shadow stack. Make sure to clear the internal
+ * tracking of the thread shadow stack so the freeing
+ * logic run for child knows to leave it alone.
+ */
+ if (clone_flags & CLONE_VFORK) {
+ shstk->base = 0;
+ shstk->size = 0;
+ return 0;
+ }
- /*
- * For !CLONE_VM the child will use a copy of the parents shadow
- * stack.
- */
- if (!(clone_flags & CLONE_VM))
- return 0;
+ /*
+ * For !CLONE_VM the child will use a copy of the
+ * parents shadow stack.
+ */
+ if (!(clone_flags & CLONE_VM))
+ return 0;
- size = adjust_shstk_size(stack_size);
- addr = alloc_shstk(0, size, 0, false);
- if (IS_ERR_VALUE(addr))
- return addr;
+ size = args->stack_size;
+ size = adjust_shstk_size(size);
+ addr = alloc_shstk(0, size, 0, false);
+ if (IS_ERR_VALUE(addr))
+ return addr;
- shstk->base = addr;
- shstk->size = size;
+ /* We allocated the shadow stack, we should deallocate it. */
+ shstk->base = addr;
+ shstk->size = size;
+ }
return addr + size;
}
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index d362aacf9f89..c818efdd57af 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -16,6 +16,7 @@ struct task_struct;
struct rusage;
union thread_union;
struct css_set;
+struct vm_area_struct;
/* All the bits taken by the old clone syscall. */
#define CLONE_LEGACY_FLAGS 0xffffffffULL
@@ -43,6 +44,8 @@ struct kernel_clone_args {
void *fn_arg;
struct cgroup *cgrp;
struct css_set *cset;
+ unsigned long shadow_stack;
+ unsigned long shadow_stack_size;
};
/*
@@ -230,4 +233,19 @@ static inline void task_unlock(struct task_struct *p)
DEFINE_GUARD(task_lock, struct task_struct *, task_lock(_T), task_unlock(_T))
+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
+int arch_shstk_validate_clone(struct task_struct *p,
+ struct vm_area_struct *vma,
+ struct page *page,
+ struct kernel_clone_args *args);
+#else
+static inline int arch_shstk_validate_clone(struct task_struct *p,
+ struct vm_area_struct *vma,
+ struct page *page,
+ struct kernel_clone_args *args)
+{
+ return 0;
+}
+#endif
+
#endif /* _LINUX_SCHED_TASK_H */
diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
index 3bac0a8ceab2..8b7af52548fd 100644
--- a/include/uapi/linux/sched.h
+++ b/include/uapi/linux/sched.h
@@ -84,6 +84,10 @@
* kernel's limit of nested PID namespaces.
* @cgroup: If CLONE_INTO_CGROUP is specified set this to
* a file descriptor for the cgroup.
+ * @shadow_stack: Pointer to the memory allocated for the child
+ * shadow stack.
+ * @shadow_stack_size: Specify the size of the shadow stack for
+ * the child process.
*
* The structure is versioned by size and thus extensible.
* New struct members must go at the end of the struct and
@@ -101,12 +105,15 @@ struct clone_args {
__aligned_u64 set_tid;
__aligned_u64 set_tid_size;
__aligned_u64 cgroup;
+ __aligned_u64 shadow_stack;
+ __aligned_u64 shadow_stack_size;
};
#endif
-#define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
-#define CLONE_ARGS_SIZE_VER1 80 /* sizeof second published struct */
-#define CLONE_ARGS_SIZE_VER2 88 /* sizeof third published struct */
+#define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
+#define CLONE_ARGS_SIZE_VER1 80 /* sizeof second published struct */
+#define CLONE_ARGS_SIZE_VER2 88 /* sizeof third published struct */
+#define CLONE_ARGS_SIZE_VER3 104 /* sizeof fourth published struct */
/*
* Scheduling policies
diff --git a/kernel/fork.c b/kernel/fork.c
index cc760491f201..275d8cf3f66b 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -128,6 +128,11 @@
*/
#define MAX_THREADS FUTEX_TID_MASK
+/*
+ * Require that shadow stacks can store at least one element
+ */
+#define SHADOW_STACK_SIZE_MIN sizeof(void *)
+
/*
* Protected counters by write_lock_irq(&tasklist_lock)
*/
@@ -2107,6 +2112,56 @@ static void rv_task_fork(struct task_struct *p)
#define rv_task_fork(p) do {} while (0)
#endif
+static int shstk_validate_clone(struct task_struct *p,
+ struct kernel_clone_args *args)
+{
+ struct mm_struct *mm;
+ struct vm_area_struct *vma;
+ struct page *page;
+ unsigned long addr;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_ARCH_HAS_USER_SHADOW_STACK))
+ return 0;
+
+ if (!args->shadow_stack)
+ return 0;
+
+ mm = get_task_mm(p);
+ if (!mm)
+ return -EFAULT;
+
+ mmap_read_lock(mm);
+
+ /*
+ * All current shadow stack architectures have tokens at the
+ * top of a downward growing shadow stack.
+ */
+ addr = args->shadow_stack + args->shadow_stack_size - 1;
+ addr = untagged_addr_remote(mm, addr);
+
+ page = get_user_page_vma_remote(mm, addr, FOLL_FORCE | FOLL_WRITE,
+ &vma);
+ if (IS_ERR(page)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ if (!(vma->vm_flags & VM_SHADOW_STACK)) {
+ ret = -EFAULT;
+ goto out_page;
+ }
+
+ ret = arch_shstk_validate_clone(p, vma, page, args);
+
+out_page:
+ put_page(page);
+out:
+ mmap_read_unlock(mm);
+ mmput(mm);
+ return ret;
+}
+
/*
* This creates a new process as a copy of the old one,
* but does not actually start it yet.
@@ -2381,6 +2436,9 @@ __latent_entropy struct task_struct *copy_process(
if (retval)
goto bad_fork_cleanup_namespaces;
retval = copy_thread(p, args);
+ if (retval)
+ goto bad_fork_cleanup_io;
+ retval = shstk_validate_clone(p, args);
if (retval)
goto bad_fork_cleanup_io;
@@ -2939,7 +2997,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
CLONE_ARGS_SIZE_VER1);
BUILD_BUG_ON(offsetofend(struct clone_args, cgroup) !=
CLONE_ARGS_SIZE_VER2);
- BUILD_BUG_ON(sizeof(struct clone_args) != CLONE_ARGS_SIZE_VER2);
+ BUILD_BUG_ON(offsetofend(struct clone_args, shadow_stack_size) !=
+ CLONE_ARGS_SIZE_VER3);
+ BUILD_BUG_ON(sizeof(struct clone_args) != CLONE_ARGS_SIZE_VER3);
if (unlikely(usize > PAGE_SIZE))
return -E2BIG;
@@ -2972,16 +3032,18 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
return -EINVAL;
*kargs = (struct kernel_clone_args){
- .flags = args.flags,
- .pidfd = u64_to_user_ptr(args.pidfd),
- .child_tid = u64_to_user_ptr(args.child_tid),
- .parent_tid = u64_to_user_ptr(args.parent_tid),
- .exit_signal = args.exit_signal,
- .stack = args.stack,
- .stack_size = args.stack_size,
- .tls = args.tls,
- .set_tid_size = args.set_tid_size,
- .cgroup = args.cgroup,
+ .flags = args.flags,
+ .pidfd = u64_to_user_ptr(args.pidfd),
+ .child_tid = u64_to_user_ptr(args.child_tid),
+ .parent_tid = u64_to_user_ptr(args.parent_tid),
+ .exit_signal = args.exit_signal,
+ .stack = args.stack,
+ .stack_size = args.stack_size,
+ .tls = args.tls,
+ .set_tid_size = args.set_tid_size,
+ .cgroup = args.cgroup,
+ .shadow_stack = args.shadow_stack,
+ .shadow_stack_size = args.shadow_stack_size,
};
if (args.set_tid &&
@@ -3022,6 +3084,34 @@ static inline bool clone3_stack_valid(struct kernel_clone_args *kargs)
return true;
}
+/**
+ * clone3_shadow_stack_valid - check and prepare shadow stack
+ * @kargs: kernel clone args
+ *
+ * Verify that shadow stacks are only enabled if supported.
+ */
+static inline bool clone3_shadow_stack_valid(struct kernel_clone_args *kargs)
+{
+ if (kargs->shadow_stack) {
+ if (!kargs->shadow_stack_size)
+ return false;
+
+ if (kargs->shadow_stack_size < SHADOW_STACK_SIZE_MIN)
+ return false;
+
+ if (kargs->shadow_stack_size > rlimit(RLIMIT_STACK))
+ return false;
+
+ /*
+ * The architecture must check support on the specific
+ * machine.
+ */
+ return IS_ENABLED(CONFIG_ARCH_HAS_USER_SHADOW_STACK);
+ } else {
+ return !kargs->shadow_stack_size;
+ }
+}
+
static bool clone3_args_valid(struct kernel_clone_args *kargs)
{
/* Verify that no unknown flags are passed along. */
@@ -3044,7 +3134,7 @@ static bool clone3_args_valid(struct kernel_clone_args *kargs)
kargs->exit_signal)
return false;
- if (!clone3_stack_valid(kargs))
+ if (!clone3_stack_valid(kargs) || !clone3_shadow_stack_valid(kargs))
return false;
return true;
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 3/8] mm: Introduce ARCH_HAS_USER_SHADOW_STACK
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, David Hildenbrand, Mike Rapoport (IBM),
Kees Cook, Shuah Khan
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
Since multiple architectures have support for shadow stacks and we need to
select support for this feature in several places in the generic code
provide a generic config option that the architectures can select.
Suggested-by: David Hildenbrand <david@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Deepak Gupta <debug@rivosinc.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Kees Cook <kees@kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/x86/Kconfig | 1 +
fs/proc/task_mmu.c | 2 +-
include/linux/mm.h | 2 +-
mm/Kconfig | 6 ++++++
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 007bab9f2a0e..320e1f411163 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1957,6 +1957,7 @@ config X86_USER_SHADOW_STACK
depends on AS_WRUSS
depends on X86_64
select ARCH_USES_HIGH_VMA_FLAGS
+ select ARCH_HAS_USER_SHADOW_STACK
select X86_CET
help
Shadow stack protection is a hardware feature that detects function
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 5f171ad7b436..0ea49725f524 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -984,7 +984,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
[ilog2(VM_UFFD_MINOR)] = "ui",
#endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
-#ifdef CONFIG_X86_USER_SHADOW_STACK
+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
[ilog2(VM_SHADOW_STACK)] = "ss",
#endif
#ifdef CONFIG_64BIT
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c4b238a20b76..3357625c1db3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -342,7 +342,7 @@ extern unsigned int kobjsize(const void *objp);
#endif
#endif /* CONFIG_ARCH_HAS_PKEYS */
-#ifdef CONFIG_X86_USER_SHADOW_STACK
+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
/*
* VM_SHADOW_STACK should not be set with VM_SHARED because of lack of
* support core mm.
diff --git a/mm/Kconfig b/mm/Kconfig
index b72e7d040f78..3167be663bca 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1263,6 +1263,12 @@ config IOMMU_MM_DATA
config EXECMEM
bool
+config ARCH_HAS_USER_SHADOW_STACK
+ bool
+ help
+ The architecture has hardware support for userspace shadow call
+ stacks (eg, x86 CET, arm64 GCS or RISC-V Zicfiss).
+
source "mm/damon/Kconfig"
endmenu
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 2/8] selftests: Provide helper header for shadow stack testing
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, Kees Cook, Shuah Khan
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
While almost all users of shadow stacks should be relying on the dynamic
linker and libc to enable the feature there are several low level test
programs where it is useful to enable without any libc support, allowing
testing without full system enablement. This low level testing is helpful
during bringup of the support itself, and also in enabling coverage by
automated testing without needing all system components in the target root
filesystems to have enablement.
Provide a header with helpers for this purpose, intended for use only by
test programs directly exercising shadow stack interfaces.
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Kees Cook <kees@kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/ksft_shstk.h | 63 ++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/tools/testing/selftests/ksft_shstk.h b/tools/testing/selftests/ksft_shstk.h
new file mode 100644
index 000000000000..85d0747c1802
--- /dev/null
+++ b/tools/testing/selftests/ksft_shstk.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Helpers for shadow stack enablement, this is intended to only be
+ * used by low level test programs directly exercising interfaces for
+ * working with shadow stacks.
+ *
+ * Copyright (C) 2024 ARM Ltd.
+ */
+
+#ifndef __KSFT_SHSTK_H
+#define __KSFT_SHSTK_H
+
+#include <asm/mman.h>
+
+/* This is currently only defined for x86 */
+#ifndef SHADOW_STACK_SET_TOKEN
+#define SHADOW_STACK_SET_TOKEN (1ULL << 0)
+#endif
+
+static bool shadow_stack_enabled;
+
+#ifdef __x86_64__
+#define ARCH_SHSTK_ENABLE 0x5001
+#define ARCH_SHSTK_SHSTK (1ULL << 0)
+
+#define ARCH_PRCTL(arg1, arg2) \
+({ \
+ long _ret; \
+ register long _num asm("eax") = __NR_arch_prctl; \
+ register long _arg1 asm("rdi") = (long)(arg1); \
+ register long _arg2 asm("rsi") = (long)(arg2); \
+ \
+ asm volatile ( \
+ "syscall\n" \
+ : "=a"(_ret) \
+ : "r"(_arg1), "r"(_arg2), \
+ "0"(_num) \
+ : "rcx", "r11", "memory", "cc" \
+ ); \
+ _ret; \
+})
+
+#define ENABLE_SHADOW_STACK
+static inline __attribute__((always_inline)) void enable_shadow_stack(void)
+{
+ int ret = ARCH_PRCTL(ARCH_SHSTK_ENABLE, ARCH_SHSTK_SHSTK);
+ if (ret == 0)
+ shadow_stack_enabled = true;
+}
+
+#endif
+
+#ifndef __NR_map_shadow_stack
+#define __NR_map_shadow_stack 453
+#endif
+
+#ifndef ENABLE_SHADOW_STACK
+static inline void enable_shadow_stack(void) { }
+#endif
+
+#endif
+
+
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 1/8] Documentation: userspace-api: Add shadow stack API documentation
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, Kees Cook, Shuah Khan
In-Reply-To: <20240819-clone3-shadow-stack-v9-0-962d74f99464@kernel.org>
There are a number of architectures with shadow stack features which we are
presenting to userspace with as consistent an API as we can (though there
are some architecture specifics). Especially given that there are some
important considerations for userspace code interacting directly with the
feature let's provide some documentation covering the common aspects.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Kees Cook <kees@kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/shadow_stack.rst | 41 ++++++++++++++++++++++++++++
2 files changed, 42 insertions(+)
diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst
index 274cc7546efc..c39709bfba2c 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -59,6 +59,7 @@ Everything else
ELF
netlink/index
+ shadow_stack
sysfs-platform_profile
vduse
futex2
diff --git a/Documentation/userspace-api/shadow_stack.rst b/Documentation/userspace-api/shadow_stack.rst
new file mode 100644
index 000000000000..c576ad3d7ec1
--- /dev/null
+++ b/Documentation/userspace-api/shadow_stack.rst
@@ -0,0 +1,41 @@
+=============
+Shadow Stacks
+=============
+
+Introduction
+============
+
+Several architectures have features which provide backward edge
+control flow protection through a hardware maintained stack, only
+writeable by userspace through very limited operations. This feature
+is referred to as shadow stacks on Linux, on x86 it is part of Intel
+Control Enforcement Technology (CET), on arm64 it is Guarded Control
+Stacks feature (FEAT_GCS) and for RISC-V it is the Zicfiss extension.
+It is expected that this feature will normally be managed by the
+system dynamic linker and libc in ways broadly transparent to
+application code, this document covers interfaces and considerations.
+
+
+Enabling
+========
+
+Shadow stacks default to disabled when a userspace process is
+executed, they can be enabled for the current thread with a syscall:
+
+ - For x86 the ARCH_SHSTK_ENABLE arch_prctl()
+
+It is expected that this will normally be done by the dynamic linker.
+Any new threads created by a thread with shadow stacks enabled will
+themselves have shadow stacks enabled.
+
+
+Enablement considerations
+=========================
+
+- Returning from the function that enables shadow stacks without first
+ disabling them will cause a shadow stack exception. This includes
+ any syscall wrapper or other library functions, the syscall will need
+ to be inlined.
+- A lock feature allows userspace to prevent disabling of shadow stacks.
+- Those that change the stack context like longjmp() or use of ucontext
+ changes on signal return will need support from libc.
--
2.39.2
^ permalink raw reply related
* [PATCH RFT v9 0/8] fork: Support shadow stacks in clone3()
From: Mark Brown @ 2024-08-19 19:24 UTC (permalink / raw)
To: Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy, H.J. Lu,
Florian Weimer, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh, bsegall,
Yury Khrustalev, Wilco Dijkstra, linux-kselftest, linux-api,
Mark Brown, Kees Cook, Kees Cook, Shuah Khan, David Hildenbrand,
Mike Rapoport (IBM)
The kernel has recently added support for shadow stacks, currently
x86 only using their CET feature but both arm64 and RISC-V have
equivalent features (GCS and Zicfiss respectively), I am actively
working on GCS[1]. With shadow stacks the hardware maintains an
additional stack containing only the return addresses for branch
instructions which is not generally writeable by userspace and ensures
that any returns are to the recorded addresses. This provides some
protection against ROP attacks and making it easier to collect call
stacks. These shadow stacks are allocated in the address space of the
userspace process.
Our API for shadow stacks does not currently offer userspace any
flexiblity for managing the allocation of shadow stacks for newly
created threads, instead the kernel allocates a new shadow stack with
the same size as the normal stack whenever a thread is created with the
feature enabled. The stacks allocated in this way are freed by the
kernel when the thread exits or shadow stacks are disabled for the
thread. This lack of flexibility and control isn't ideal, in the vast
majority of cases the shadow stack will be over allocated and the
implicit allocation and deallocation is not consistent with other
interfaces. As far as I can tell the interface is done in this manner
mainly because the shadow stack patches were in development since before
clone3() was implemented.
Since clone3() is readily extensible let's add support for specifying a
shadow stack when creating a new thread or process in a similar manner
to how the normal stack is specified, keeping the current implicit
allocation behaviour if one is not specified either with clone3() or
through the use of clone(). The user must provide a shadow stack
address and size, this must point to memory mapped for use as a shadow
stackby map_shadow_stack() with a shadow stack token at the top of the
stack.
Please note that the x86 portions of this code are build tested only, I
don't appear to have a system that can run CET avaible to me, I have
done testing with an integration into my pending work for GCS. There is
some possibility that the arm64 implementation may require the use of
clone3() and explicit userspace allocation of shadow stacks, this is
still under discussion.
Please further note that the token consumption done by clone3() is not
currently implemented in an atomic fashion, Rick indicated that he would
look into fixing this if people are OK with the implementation.
A new architecture feature Kconfig option for shadow stacks is added as
here, this was suggested as part of the review comments for the arm64
GCS series and since we need to detect if shadow stacks are supported it
seemed sensible to roll it in here.
[1] https://lore.kernel.org/r/20231009-arm64-gcs-v6-0-78e55deaa4dd@kernel.org/
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Changes in v9:
- Pull token validation earlier and report problems with an error return
to parent rather than signal delivery to the child.
- Verify that the top of the supplied shadow stack is VM_SHADOW_STACK.
- Rework token validation to only do the page mapping once.
- Drop no longer needed support for testing for signals in selftest.
- Fix typo in comments.
- Link to v8: https://lore.kernel.org/r/20240808-clone3-shadow-stack-v8-0-0acf37caf14c@kernel.org
Changes in v8:
- Fix token verification with user specified shadow stack.
- Don't track user managed shadow stacks for child processes.
- Link to v7: https://lore.kernel.org/r/20240731-clone3-shadow-stack-v7-0-a9532eebfb1d@kernel.org
Changes in v7:
- Rebase onto v6.11-rc1.
- Typo fixes.
- Link to v6: https://lore.kernel.org/r/20240623-clone3-shadow-stack-v6-0-9ee7783b1fb9@kernel.org
Changes in v6:
- Rebase onto v6.10-rc3.
- Ensure we don't try to free the parent shadow stack in error paths of
x86 arch code.
- Spelling fixes in userspace API document.
- Additional cleanups and improvements to the clone3() tests to support
the shadow stack tests.
- Link to v5: https://lore.kernel.org/r/20240203-clone3-shadow-stack-v5-0-322c69598e4b@kernel.org
Changes in v5:
- Rebase onto v6.8-rc2.
- Rework ABI to have the user allocate the shadow stack memory with
map_shadow_stack() and a token.
- Force inlining of the x86 shadow stack enablement.
- Move shadow stack enablement out into a shared header for reuse by
other tests.
- Link to v4: https://lore.kernel.org/r/20231128-clone3-shadow-stack-v4-0-8b28ffe4f676@kernel.org
Changes in v4:
- Formatting changes.
- Use a define for minimum shadow stack size and move some basic
validation to fork.c.
- Link to v3: https://lore.kernel.org/r/20231120-clone3-shadow-stack-v3-0-a7b8ed3e2acc@kernel.org
Changes in v3:
- Rebase onto v6.7-rc2.
- Remove stale shadow_stack in internal kargs.
- If a shadow stack is specified unconditionally use it regardless of
CLONE_ parameters.
- Force enable shadow stacks in the selftest.
- Update changelogs for RISC-V feature rename.
- Link to v2: https://lore.kernel.org/r/20231114-clone3-shadow-stack-v2-0-b613f8681155@kernel.org
Changes in v2:
- Rebase onto v6.7-rc1.
- Remove ability to provide preallocated shadow stack, just specify the
desired size.
- Link to v1: https://lore.kernel.org/r/20231023-clone3-shadow-stack-v1-0-d867d0b5d4d0@kernel.org
---
Mark Brown (8):
Documentation: userspace-api: Add shadow stack API documentation
selftests: Provide helper header for shadow stack testing
mm: Introduce ARCH_HAS_USER_SHADOW_STACK
fork: Add shadow stack support to clone3()
selftests/clone3: Remove redundant flushes of output streams
selftests/clone3: Factor more of main loop into test_clone3()
selftests/clone3: Allow tests to flag if -E2BIG is a valid error code
selftests/clone3: Test shadow stack support
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/shadow_stack.rst | 41 ++++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/shstk.h | 11 +-
arch/x86/kernel/process.c | 2 +-
arch/x86/kernel/shstk.c | 103 +++++++---
fs/proc/task_mmu.c | 2 +-
include/linux/mm.h | 2 +-
include/linux/sched/task.h | 18 ++
include/uapi/linux/sched.h | 13 +-
kernel/fork.c | 114 +++++++++--
mm/Kconfig | 6 +
tools/testing/selftests/clone3/clone3.c | 230 ++++++++++++++++++----
tools/testing/selftests/clone3/clone3_selftests.h | 40 +++-
tools/testing/selftests/ksft_shstk.h | 63 ++++++
15 files changed, 560 insertions(+), 87 deletions(-)
---
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
change-id: 20231019-clone3-shadow-stack-15d40d2bf536
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available
From: Charlie Jenkins @ 2024-08-19 17:00 UTC (permalink / raw)
To: Levi Zim
Cc: Palmer Dabbelt, cyy, alexghiti, Paul Walmsley, aou, shuah, corbet,
linux-mm, linux-riscv, linux-kernel, linux-kselftest, linux-doc,
linux-api
In-Reply-To: <MEYP282MB2312106710775098261AB348C68C2@MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM>
On Mon, Aug 19, 2024 at 01:55:57PM +0800, Levi Zim wrote:
> On 2024-03-22 22:06, Palmer Dabbelt wrote:
> > On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote:
> > > On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote:
> > > > On Wed, 2024-01-31 at 22:41 +0800, Yangyu Chen wrote:
> > > > > On Tue, 2024-01-30 at 17:07 -0800, Charlie Jenkins wrote:
> > > > > > On riscv it is guaranteed that the address returned by mmap is less
> > > > > > than
> > > > > > the hint address. Allow mmap to return an address all the way up to
> > > > > > addr, if provided, rather than just up to the lower address space.
> > > > > > > > This provides a performance benefit as well, allowing
> > > > mmap to exit
> > > > > > after
> > > > > > checking that the address is in range rather than searching for a
> > > > > > valid
> > > > > > address.
> > > > > > > > It is possible to provide an address that uses at most the same
> > > > > > number
> > > > > > of bits, however it is significantly more computationally expensive
> > > > > > to
> > > > > > provide that number rather than setting the max to be the hint
> > > > > > address.
> > > > > > There is the instruction clz/clzw in Zbb that returns the highest
> > > > > > set
> > > > > > bit
> > > > > > which could be used to performantly implement this, but it would
> > > > > > still
> > > > > > be slower than the current implementation. At worst case, half of
> > > > > > the
> > > > > > address would not be able to be allocated when a hint address is
> > > > > > provided.
> > > > > > > > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> > > > > > ---
> > > > > > arch/riscv/include/asm/processor.h | 27 +++++++++++---------------
> > > > > > -
> > > > > > 1 file changed, 11 insertions(+), 16 deletions(-)
> > > > > > > > diff --git a/arch/riscv/include/asm/processor.h
> > > > > > b/arch/riscv/include/asm/processor.h
> > > > > > index f19f861cda54..8ece7a8f0e18 100644
> > > > > > --- a/arch/riscv/include/asm/processor.h
> > > > > > +++ b/arch/riscv/include/asm/processor.h
> > > > > > @@ -14,22 +14,16 @@
> > > > > >
> > > > > > #include <asm/ptrace.h>
> > > > > >
> > > > > > -#ifdef CONFIG_64BIT
> > > > > > -#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
> > > > > > -#define STACK_TOP_MAX TASK_SIZE_64
> > > > > > -
> > > > > > #define arch_get_mmap_end(addr, len, flags) \
> > > > > > ({ \
> > > > > > unsigned long
> > > > > > mmap_end; \
> > > > > > typeof(addr) _addr = (addr); \
> > > > > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
> > > > > > is_compat_task())) \
> > > > > > + if ((_addr) == 0 || \
> > > > > > + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
> > > > > > + ((_addr + len) > BIT(VA_BITS -
> > > > > > 1))) \
> > > > > > mmap_end = STACK_TOP_MAX; \
> > > > > > - else if ((_addr) >= VA_USER_SV57) \
> > > > > > - mmap_end = STACK_TOP_MAX; \
> > > > > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
> > > > > > VA_BITS_SV48)) \
> > > > > > - mmap_end = VA_USER_SV48; \
> > > > > > else \
> > > > > > - mmap_end = VA_USER_SV39; \
> > > > > > + mmap_end = (_addr + len); \
> > > > > > mmap_end; \
> > > > > > })
> > > > > >
> > > > > > @@ -39,17 +33,18 @@
> > > > > > typeof(addr) _addr = (addr); \
> > > > > > typeof(base) _base = (base); \
> > > > > > unsigned long rnd_gap = DEFAULT_MAP_WINDOW - (_base); \
> > > > > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
> > > > > > is_compat_task())) \
> > > > > > + if ((_addr) == 0 || \
> > > > > > + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
> > > > > > + ((_addr + len) > BIT(VA_BITS -
> > > > > > 1))) \
> > > > > > mmap_base = (_base); \
> > > > > > - else if (((_addr) >= VA_USER_SV57) && (VA_BITS >=
> > > > > > VA_BITS_SV57)) \
> > > > > > - mmap_base = VA_USER_SV57 - rnd_gap; \
> > > > > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
> > > > > > VA_BITS_SV48)) \
> > > > > > - mmap_base = VA_USER_SV48 - rnd_gap; \
> > > > > > else \
> > > > > > - mmap_base = VA_USER_SV39 - rnd_gap; \
> > > > > > + mmap_base = (_addr + len) - rnd_gap; \
> > > > > > mmap_base; \
> > > > > > })
> > > > > >
> > > > > > +#ifdef CONFIG_64BIT
> > > > > > +#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
> > > > > > +#define STACK_TOP_MAX TASK_SIZE_64
> > > > > > #else
> > > > > > #define DEFAULT_MAP_WINDOW TASK_SIZE
> > > > > > #define STACK_TOP_MAX TASK_SIZE
> > > > > > > > I have carefully tested your patch on qemu with sv57. A
> > > > bug that
> > > > > needs
> > > > > to be solved is that mmap with the same hint address without
> > > > > MAP_FIXED
> > > > > set will fail the second time.
> > > > > > Userspace code to reproduce the bug:
> > > > > > #include <sys/mman.h>
> > > > > #include <stdio.h>
> > > > > #include <stdint.h>
> > > > > > void test(char *addr) {
> > > > > char *res = mmap(addr, 4096, PROT_READ | PROT_WRITE,
> > > > > MAP_ANONYMOUS
> > > > > > MAP_PRIVATE, -1, 0);
> > > > > printf("hint %p got %p.\n", addr, res);
> > > > > }
> > > > > > int main (void) {
> > > > > test(1<<30);
> > > > > test(1<<30);
> > > > > test(1<<30);
> > > > > return 0;
> > > > > }
> > > > > > output:
> > > > > > hint 0x40000000 got 0x40000000.
> > > > > hint 0x40000000 got 0xffffffffffffffff.
> > > > > hint 0x40000000 got 0xffffffffffffffff.
> > > > > > output on x86:
> > > > > > hint 0x40000000 got 0x40000000.
> > > > > hint 0x40000000 got 0x7f9171363000.
> > > > > hint 0x40000000 got 0x7f9171362000.
> > > > > > It may need to implement a special arch_get_unmapped_area and
> > > > > arch_get_unmapped_area_topdown function.
> > > > >
> > > > This is because hint address < rnd_gap. I have tried to let mmap_base =
> > > > min((_addr + len), (base) + TASK_SIZE - DEFAULT_MAP_WINDOW). However it
> > > > does not work for bottom-up while ulimit -s is unlimited. You said this
> > > > behavior is expected from patch v2 review. However it brings a new
> > > > regression even on sv39 systems.
> > > >
> > > > I still don't know the reason why use addr+len as the upper-bound. I
> > > > think solution like x86/arm64/powerpc provide two address space switch
> > > > based on whether hint address above the default map window is enough.
> > > >
> > >
> > > Yep this is expected. It is up to the maintainers to decide.
> >
> > Sorry I forgot to reply to this, I had a buffer sitting around somewhere
> > but I must have lost it.
> >
> > I think Charlie's approach is the right way to go. Putting my userspace
> > hat on, I'd much rather have my allocations fail rather than silently
> > ignore the hint when there's memory pressure.
> >
> > If there's some real use case that needs these low hints to be silently
> > ignored under VA pressure then we can try and figure something out that
> > makes those applications work.
>
> I could confirm that this patch has broken chromium's partition allocator on
> riscv64. The minimal reproduction I use is chromium-mmap.c:
>
> #include <stdio.h>
> #include <sys/mman.h>
>
> int main() {
> void* expected = (void*)0x400000000;
> void* addr = mmap(expected, 17179869184, PROT_NONE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
> if (addr != expected) {
It is not valid to assume that the address returned by mmap will be the
hint address. If the hint address is not available, mmap will return a
different address.
> printf("Not expected address: %p != %p\n", addr, expected);
> }
> expected = (void*)0x3fffff000;
> addr = mmap(expected, 17179873280, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0);
> if (addr != expected) {
> printf("Not expected address: %p != %p\n", addr, expected);
> }
> return 0;
> }
>
> The second mmap fails with ENOMEM. Manually reverting this commit fixes the
> issue for me. So I think it's clearly a regression and breaks userspace.
>
The issue here is that overlapping memory is being requested. This
second mmap will never be able to provide an address at 0x3fffff000 with
a size of 0x400001000 since mmap just provided an address at 0x400000000
with a size of 0x400000000.
Before this patch, this request causes mmap to return a completely
arbitrary value. There is no reason to use a hint address in this manner
because the hint can never be respected. Since an arbitrary address is
desired, a hint of zero should be used.
This patch causes the behavior to be more deterministic. Instead of
providing an arbitrary address, it causes the address to be less than or
equal to the hint address. This allows for applications to make
assumptions about the returned address.
This code is unfortunately relying on the previously mostly undefined
behavior of the hint address in mmap. The goal of this patch is to help
developers have more consistent mmap behavior, but maybe it is necessary
to hide this behavior behind an mmap flag.
- Charlie
> See also https://github.com/riscv-forks/electron/issues/4
>
> > >
> > > - Charlie
>
> Sincerely,
> Levi
>
^ permalink raw reply
* Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available
From: Levi Zim @ 2024-08-19 5:55 UTC (permalink / raw)
To: Palmer Dabbelt, Charlie Jenkins
Cc: cyy, alexghiti, Paul Walmsley, aou, shuah, corbet, linux-mm,
linux-riscv, linux-kernel, linux-kselftest, linux-doc, linux-api
In-Reply-To: <mhng-5d9bb6c0-9f40-44b2-b9dc-3823cf6dbdef@palmer-ri-x1c9>
On 2024-03-22 22:06, Palmer Dabbelt wrote:
> On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote:
>> On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote:
>>> On Wed, 2024-01-31 at 22:41 +0800, Yangyu Chen wrote:
>>> > On Tue, 2024-01-30 at 17:07 -0800, Charlie Jenkins wrote:
>>> > > On riscv it is guaranteed that the address returned by mmap is less
>>> > > than
>>> > > the hint address. Allow mmap to return an address all the way up to
>>> > > addr, if provided, rather than just up to the lower address space.
>>> > > > > This provides a performance benefit as well, allowing mmap
>>> to exit
>>> > > after
>>> > > checking that the address is in range rather than searching for a
>>> > > valid
>>> > > address.
>>> > > > > It is possible to provide an address that uses at most the same
>>> > > number
>>> > > of bits, however it is significantly more computationally expensive
>>> > > to
>>> > > provide that number rather than setting the max to be the hint
>>> > > address.
>>> > > There is the instruction clz/clzw in Zbb that returns the highest
>>> > > set
>>> > > bit
>>> > > which could be used to performantly implement this, but it would
>>> > > still
>>> > > be slower than the current implementation. At worst case, half of
>>> > > the
>>> > > address would not be able to be allocated when a hint address is
>>> > > provided.
>>> > > > > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
>>> > > ---
>>> > > arch/riscv/include/asm/processor.h | 27 +++++++++++---------------
>>> > > -
>>> > > 1 file changed, 11 insertions(+), 16 deletions(-)
>>> > > > > diff --git a/arch/riscv/include/asm/processor.h
>>> > > b/arch/riscv/include/asm/processor.h
>>> > > index f19f861cda54..8ece7a8f0e18 100644
>>> > > --- a/arch/riscv/include/asm/processor.h
>>> > > +++ b/arch/riscv/include/asm/processor.h
>>> > > @@ -14,22 +14,16 @@
>>> > >
>>> > > #include <asm/ptrace.h>
>>> > >
>>> > > -#ifdef CONFIG_64BIT
>>> > > -#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
>>> > > -#define STACK_TOP_MAX TASK_SIZE_64
>>> > > -
>>> > > #define arch_get_mmap_end(addr, len, flags) \
>>> > > ({ \
>>> > > unsigned long
>>> > > mmap_end; \
>>> > > typeof(addr) _addr = (addr); \
>>> > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
>>> > > is_compat_task())) \
>>> > > + if ((_addr) == 0 || \
>>> > > + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
>>> > > + ((_addr + len) > BIT(VA_BITS -
>>> > > 1))) \
>>> > > mmap_end = STACK_TOP_MAX; \
>>> > > - else if ((_addr) >= VA_USER_SV57) \
>>> > > - mmap_end = STACK_TOP_MAX; \
>>> > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
>>> > > VA_BITS_SV48)) \
>>> > > - mmap_end = VA_USER_SV48; \
>>> > > else \
>>> > > - mmap_end = VA_USER_SV39; \
>>> > > + mmap_end = (_addr + len); \
>>> > > mmap_end; \
>>> > > })
>>> > >
>>> > > @@ -39,17 +33,18 @@
>>> > > typeof(addr) _addr = (addr); \
>>> > > typeof(base) _base = (base); \
>>> > > unsigned long rnd_gap = DEFAULT_MAP_WINDOW - (_base); \
>>> > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
>>> > > is_compat_task())) \
>>> > > + if ((_addr) == 0 || \
>>> > > + (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \
>>> > > + ((_addr + len) > BIT(VA_BITS -
>>> > > 1))) \
>>> > > mmap_base = (_base); \
>>> > > - else if (((_addr) >= VA_USER_SV57) && (VA_BITS >=
>>> > > VA_BITS_SV57)) \
>>> > > - mmap_base = VA_USER_SV57 - rnd_gap; \
>>> > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
>>> > > VA_BITS_SV48)) \
>>> > > - mmap_base = VA_USER_SV48 - rnd_gap; \
>>> > > else \
>>> > > - mmap_base = VA_USER_SV39 - rnd_gap; \
>>> > > + mmap_base = (_addr + len) - rnd_gap; \
>>> > > mmap_base; \
>>> > > })
>>> > >
>>> > > +#ifdef CONFIG_64BIT
>>> > > +#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
>>> > > +#define STACK_TOP_MAX TASK_SIZE_64
>>> > > #else
>>> > > #define DEFAULT_MAP_WINDOW TASK_SIZE
>>> > > #define STACK_TOP_MAX TASK_SIZE
>>> > > > > I have carefully tested your patch on qemu with sv57. A bug
>>> that
>>> > needs
>>> > to be solved is that mmap with the same hint address without
>>> > MAP_FIXED
>>> > set will fail the second time.
>>> > > Userspace code to reproduce the bug:
>>> > > #include <sys/mman.h>
>>> > #include <stdio.h>
>>> > #include <stdint.h>
>>> > > void test(char *addr) {
>>> > char *res = mmap(addr, 4096, PROT_READ | PROT_WRITE,
>>> > MAP_ANONYMOUS
>>> > > MAP_PRIVATE, -1, 0);
>>> > printf("hint %p got %p.\n", addr, res);
>>> > }
>>> > > int main (void) {
>>> > test(1<<30);
>>> > test(1<<30);
>>> > test(1<<30);
>>> > return 0;
>>> > }
>>> > > output:
>>> > > hint 0x40000000 got 0x40000000.
>>> > hint 0x40000000 got 0xffffffffffffffff.
>>> > hint 0x40000000 got 0xffffffffffffffff.
>>> > > output on x86:
>>> > > hint 0x40000000 got 0x40000000.
>>> > hint 0x40000000 got 0x7f9171363000.
>>> > hint 0x40000000 got 0x7f9171362000.
>>> > > It may need to implement a special arch_get_unmapped_area and
>>> > arch_get_unmapped_area_topdown function.
>>> >
>>> This is because hint address < rnd_gap. I have tried to let mmap_base =
>>> min((_addr + len), (base) + TASK_SIZE - DEFAULT_MAP_WINDOW). However it
>>> does not work for bottom-up while ulimit -s is unlimited. You said this
>>> behavior is expected from patch v2 review. However it brings a new
>>> regression even on sv39 systems.
>>>
>>> I still don't know the reason why use addr+len as the upper-bound. I
>>> think solution like x86/arm64/powerpc provide two address space switch
>>> based on whether hint address above the default map window is enough.
>>>
>>
>> Yep this is expected. It is up to the maintainers to decide.
>
> Sorry I forgot to reply to this, I had a buffer sitting around
> somewhere but I must have lost it.
>
> I think Charlie's approach is the right way to go. Putting my
> userspace hat on, I'd much rather have my allocations fail rather than
> silently ignore the hint when there's memory pressure.
>
> If there's some real use case that needs these low hints to be
> silently ignored under VA pressure then we can try and figure
> something out that makes those applications work.
I could confirm that this patch has broken chromium's partition
allocator on riscv64. The minimal reproduction I use is chromium-mmap.c:
#include <stdio.h>
#include <sys/mman.h>
int main() {
void* expected = (void*)0x400000000;
void* addr = mmap(expected, 17179869184, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
if (addr != expected) {
printf("Not expected address: %p != %p\n", addr, expected);
}
expected = (void*)0x3fffff000;
addr = mmap(expected, 17179873280, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
if (addr != expected) {
printf("Not expected address: %p != %p\n", addr, expected);
}
return 0;
}
The second mmap fails with ENOMEM. Manually reverting this commit fixes
the issue for me. So I think it's clearly a regression and breaks
userspace.
See also https://github.com/riscv-forks/electron/issues/4
>>
>> - Charlie
Sincerely,
Levi
^ permalink raw reply
* Re: [PATCHv8 9/9] man2: Add uretprobe syscall page
From: Jiri Olsa @ 2024-08-17 8:58 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Jiri Olsa, Steven Rostedt, Masami Hiramatsu, Oleg Nesterov,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
linux-kernel, linux-trace-kernel, linux-api, linux-man, x86, bpf,
Song Liu, Yonghong Song, John Fastabend, Peter Zijlstra,
Thomas Gleixner, Borislav Petkov (AMD), Ingo Molnar,
Andy Lutomirski, Edgecombe, Rick P, Deepak Gupta
In-Reply-To: <ht6hc5dbvgx3ny22pvhiazs7vxjhiockr6glpho5bpp6hrwn4f@oew3iu7a62j2>
On Fri, Aug 16, 2024 at 11:56:39PM +0200, Alejandro Colomar wrote:
> Hi Jiri, Steven,
>
> On Fri, Aug 16, 2024 at 08:55:47PM GMT, Alejandro Colomar wrote:
> > > hi,
> > > there are no args for x86.. it's there just to note that it might
> > > be different on other archs, so not sure what man page should say
> > > in such case.. keeping (void) is fine with me
> >
> > Hmmm, then I'll remove that paragraph. If that function is implemented
> > in another arch and the args are different, we can change the manual
> > page then.
> >
> > >
> > > >
> > > > Please add the changes proposed below to your patch, tweak anything if
> > > > you consider it appropriate) and send it as v10.
> > >
> > > it looks good to me, thanks a lot
> > >
> > > Acked-by: From: Jiri Olsa <jolsa@kernel.org>
>
> I have applied your patch with the tweaks I mentioned, and added several
> tags to the commit message.
>
> It's currently here:
> <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=977e3eecbb81b7398defc4e4f41810ca31d63c1b>
>
> and will $soon be pushed to master.
>
> Have a lovely night!
> Alex
great, thanks
jirka
^ permalink raw reply
* Re: [PATCHv8 9/9] man2: Add uretprobe syscall page
From: Alejandro Colomar @ 2024-08-16 21:56 UTC (permalink / raw)
To: Jiri Olsa
Cc: Steven Rostedt, Masami Hiramatsu, Oleg Nesterov,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
linux-kernel, linux-trace-kernel, linux-api, linux-man, x86, bpf,
Song Liu, Yonghong Song, John Fastabend, Peter Zijlstra,
Thomas Gleixner, Borislav Petkov (AMD), Ingo Molnar,
Andy Lutomirski, Edgecombe, Rick P, Deepak Gupta
In-Reply-To: <c7v4einpsvpswvj3rqn5esap2e5lpeiwacylqlzwdcp7slsgvg@jfmchkiqru4u>
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
Hi Jiri, Steven,
On Fri, Aug 16, 2024 at 08:55:47PM GMT, Alejandro Colomar wrote:
> > hi,
> > there are no args for x86.. it's there just to note that it might
> > be different on other archs, so not sure what man page should say
> > in such case.. keeping (void) is fine with me
>
> Hmmm, then I'll remove that paragraph. If that function is implemented
> in another arch and the args are different, we can change the manual
> page then.
>
> >
> > >
> > > Please add the changes proposed below to your patch, tweak anything if
> > > you consider it appropriate) and send it as v10.
> >
> > it looks good to me, thanks a lot
> >
> > Acked-by: From: Jiri Olsa <jolsa@kernel.org>
I have applied your patch with the tweaks I mentioned, and added several
tags to the commit message.
It's currently here:
<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=977e3eecbb81b7398defc4e4f41810ca31d63c1b>
and will $soon be pushed to master.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox