en I enabled
MODULE_SIG_KEY_TYPE_ECDSA I get a "Unsupported pkey algo: 5" error on
module load, which goes away after fixing my config and selecting
MODULE_SIG_SHA256.
Thanks,
Jessica
s!
Great, thanks a lot Stephen!
Jessica
__arm64_sys_write+0x24/0x30
el0_svc_common+0xf4/0x1c0
do_el0_svc_compat+0x28/0x3c
el0_svc_compat+0x10/0x1c
el0_sync_compat_handler+0xa8/0xcc
el0_sync_compat+0x178/0x180
---[ end trace f89bc7f5417cbcc6 ]---
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsi
+++ 周传高 [13/04/21 15:21 +0800]:
+++ zhouchuangao [30/03/21 05:07 -0700]:
It can be optimized at compile time.
Signed-off-by: zhouchuangao
Hi,
Could you please provide a more descriptive changelog? I.e., Is this
a fix for a cocinelle warning? What are the optimization(s)?
Thanks,
First,
+++ zhouchuangao [30/03/21 05:07 -0700]:
It can be optimized at compile time.
Signed-off-by: zhouchuangao
Hi,
Could you please provide a more descriptive changelog? I.e., Is this
a fix for a cocinelle warning? What are the optimization(s)?
Thanks,
Jessica
---
kernel/module.c | 4 ++--
1
sechdr->sh_size))
+ break;
+ }
+}
Why not just look for the .note.gnu.build-id section instead of trying
to parse each note section? Doesn't it always contain the build id? At
least the ld man page seems to suggest this section name should be
consistent.
Jessica
+++ Stephen Boyd [30/03/21 20:05 -0700]:
[snipped]
diff --git a/lib/buildid.c b/lib/buildid.c
index 010ab0674cb9..b939bbc59233 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
#include
#include
@@ -171,3 +172,19 @
correct __cfi_check() location and
alignment. It also discards the .eh_frame section, which Clang can
generate with certain sanitizers, such as CFI.
Link: https://bugs.llvm.org/show_bug.cgi?id=46293
Signed-off-by: Sami Tolvanen
Acked-by: Jessica Yu
Thanks!
.data
.gnu.linkonce.this_module
Init section allocation order:
.init.text
.exit.text
.symtab
.strtab
[jeyu: thanks to Peter Zijlstra for most of the changelog]
Link: https://lore.kernel.org/lkml/YFiuphGw0RKehWsQ@gunter/
Signed-off-by: Jessica Yu
---
Do you want to take
+++ Peter Zijlstra [22/03/21 17:54 +0100]:
On Mon, Mar 22, 2021 at 03:50:14PM +0100, Jessica Yu wrote:
It should be doable. If you want the exit sections to be treated the same as
module init, the following patch should stuff any exit sections into the module
init "region" (completel
t code when UNLOAD is not set, appears appropriate.
Jessica, please correct me if I'm wrong.
It should be doable. If you want the exit sections to be treated the same as
module init, the following patch should stuff any exit sections into the module
init "region" (completely
+++ Steven Rostedt [19/03/21 14:00 -0400]:
On Fri, 19 Mar 2021 13:57:38 +0100
Peter Zijlstra wrote:
Jessica, can you explain how !MODULE_UNLOAD is supposed to work?
Alternatives, jump_labels and static_call all can have relocations into
__exit code. Not loading it at all would be BAD
Villemoes
Acked-by: Jessica Yu
Thanks!
n?
Hm, something like this maybe? (untested)
---
From 08bc08229fc3801b1a580a07ce7ff3e806b3fe90 Mon Sep 17 00:00:00 2001
From: Jessica Yu
Date: Wed, 24 Feb 2021 14:54:09 +0100
Subject: [PATCH] Kconfig: invert TRIM_UNUSED_SYMBOLS option and rename it to
KEEP_UNUSED_SYMBOLS
Removing CONFIG_UNUSED_SY
+++ Linus Torvalds [23/02/21 12:03 -0800]:
On Tue, Feb 23, 2021 at 12:01 PM Christoph Hellwig wrote:
Does your build now enable TRIM_UNUSED_KSYMS but previously didn't by
chance?
Crossed emails.
This is plain "make allmodconfig", so yes, now it will enable TRIM_UNUSED_KSYMS.
This is unacce
Hi Linus,
Please pull below to receive modules updates for the v5.12 merge window.
A summary can be found in the signed tag.
Thank you,
Jessica
---
The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31:
Linux 5.11-rc4 (2021-01-17 16:37:05 -0800)
are available in the
+++ Masahiro Yamada [11/02/21 15:14 +0900]:
Stephen Rothwell reported a build error on ppc64 when
CONFIG_TRIM_UNUSED_KSYMS is enabled.
Jessica Yu pointed out the cause of the error with the reference to the
ppc64 elf ABI:
"Symbol names with a dot (.) prefix are reserved for holding
;kallsyms: refactor {,module_}kallsyms_on_each_symbol")
Signed-off-by: Dan Carpenter
Applied, thanks!
Jessica
+++ Stephen Rothwell [10/02/21 23:21 +1100]:
Hi Jessica,
On Wed, 10 Feb 2021 09:06:48 +0100 Jessica Yu wrote:
Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
option was introduced around v4.7. If simply enabling it produces
these compilation errors I was wonde
+++ Stephen Rothwell [10/02/21 08:50 +1100]:
Hi Jessica,
On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu wrote:
Hmm, these errors don't look like it's related to that particular commit. I was
I found this commit by bisection and then tested by reverting it.
Before t
tion "FN".
I guess the presence of the extra dot symbols is confusing
scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which the
preprocessor doesn't like. I am wondering how this was never caught until now
and also now curious if this feature was ever functional on powerpc..
Thanks,
Jessica
).
Thanks everyone,
Jessica
e contested all the way up to
the merge window. So this boils down to whether Christoph (and maybe Greg) are
fine with this being a debug option that's not enabled by default.
Thanks,
Jessica
I can take the first
two patches as well provided the acks are there (I think patch 2 is
missing Daniel Vetter's ack from v1 of the series, but I'll add that
back in).
Thanks,
Jessica
+++ Miroslav Benes [29/01/21 16:29 +0100]:
On Thu, 28 Jan 2021, Christoph Hellwig wrote:
Allow for a RCU-sched critical section around find_module, following
the lower level find_module_all helper, and switch the two callers
outside of module.c to use such a RCU-sched critical section instead
o
+++ Christoph Hellwig [21/01/21 08:49 +0100]:
EXPORT_UNUSED_SYMBOL* is not actually used anywhere. Remove the
unused functionality as we generally just remove unused code anyway.
Signed-off-by: Christoph Hellwig
---
arch/arm/configs/bcm2835_defconfig | 1 -
arch/arm/configs/mxs_defcon
ING and cannot be GOING until it
acquires the klp_mutex again in klp_module_going(). So does that hunk
really need to be under module_mutex? It has been a long time since
I've looked at livepatch code so it would be great if someone could
double check.
Jessica
r Linden
Queued on modules-next.
Thanks Frank!
Jessica
rnel/git/jeyu/linux.git/commit/?h=modules-next&id=ebfac7b778fac8b0e8e92ec91d0b055f046b4604
Thanks!
Jessica
to me.
Thanks Fangrui!
Jessica
ong
Thanks for the patch.
Reviewed-by: Nick Desaulniers
Jessica, would you mind adding when applying:
Cc:
as I suspect we might want this fixed in stable tree's branches, too.
It might of interest to add:
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27178
too.
Sure, will do!
Thanks,
Jessica
+++ Fāng-ruì Sòng [14/01/21 08:57 -0800]:
On Thu, Jan 14, 2021 at 6:06 AM Jessica Yu wrote:
+++ Fangrui Song [13/01/21 21:48 -0800]:
>clang-12 -fno-pic (since
>https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de008232da3f1d6)
>can emit `call __stack_chk_fail@PLT
ore _GLOBAL_OFFSET_TABLE_
has been there long before my time. Let's properly mirror modpost
then, and create a similar helper function ignore_undef_symbol() (and
stick the _GLOBAL_OFFSET_TABLE_ check in there) to account for future
cases like this.
Thanks,
Jessica
ame);
return -ENOPKG;
}
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 9d9fc678c91d..9a057c5d1d4d 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -30,7 +30,7 @@ int mod_verify_sig(const void *mod, struct load_info *info)
memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
- ret = mod_check_sig(&ms, modlen, info->name);
+ ret = mod_check_sig(&ms, modlen, info->name ?: "module");
Since info->name is not expected to be valid anymore, as we're back to
calling mod_sig_check() first thing, perhaps just stick with
"module"? Or was there another reason for checking info->name here?
Thanks,
Jessica
ately.
In any case, since there was pushback in our earlier discussions, I'd
like to ask if there are any remaining objections to this patch.
Masahiro, are you fine with the Makefile and modpost changes?
Thanks,
Jessica
---
Documentation/ABI/stable/sysfs-module | 18 ++
i
+++ Adam Zabrocki [12/01/21 01:15 +0100]:
Hello,
On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:
+++ Adam Zabrocki [10/01/21 18:54 +0100]:
> Hello,
>
> I believe that the following commit does introduce a gentle "functionality
> bug":
>
> "module:
the newly loaded module is ready.
Hm, could you please explain specifically what is the issue you're seeing?
What projects is it breaking?
Thanks,
Jessica
[1] https://github.com/systemd/systemd/issues/17586
+++ Will McVicker [06/01/21 10:44 -0800]:
Thanks for the vacation notice Jessica! I'm just letting you know I'm
back as well and am happy to respond to any concerns regarding v4 when
you get all caught up.
I hope you had a relaxing holiday :)
Hi Will - thanks, same to you!
On F
it awkwardly. Maybe
something like "Invalid ELF section in module (section ndx %u type %u)"?
+ return err;
+ }
+
+ if (shdr->sh_flags & SHF_ALLOC) {
+ if (shdr->sh_name >= strhdr->sh_size) {
+ pr_err("invalid ELF section name in module
num %u type %u\n",
+ i, shdr->sh_type);
Same here.
Thanks!
Jessica
. Just wanted to give you a heads up.
Thanks and happy holidays!
Jessica
Hi Linus,
Please pull below to receive modules updates for the v5.11 merge window.
A summary can be found in the signed tag.
Thank you,
Jessica
---
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the
+++ Peter Zijlstra [16/12/20 14:23 +0100]:
On Wed, Dec 16, 2020 at 02:10:16PM +0100, Jessica Yu wrote:
+++ Peter Zijlstra [16/12/20 13:47 +0100]:
> Only because we're having .init=false, incorrectly. See the other email.
Ah yeah, you're right. I also misread the intent
+++ Peter Zijlstra [16/12/20 13:47 +0100]:
On Wed, Dec 16, 2020 at 12:55:25PM +0100, Jessica Yu wrote:
+++ Peter Zijlstra [16/12/20 10:26 +0100]:
[snip]
> > PS, I originally found: in arch/x86/kvm/vmx/vmx.c: vmx_init(), it looks
> > like the line "static_branch_enable(&ena
+++ Peter Zijlstra [16/12/20 10:26 +0100]:
On Wed, Dec 16, 2020 at 03:54:29AM +, Dexuan Cui wrote:
PS, I originally found: in arch/x86/kvm/vmx/vmx.c: vmx_init(), it looks
like the line "static_branch_enable(&enable_evmcs);" does not take effect
in a v5.4-based kernel, but does take effect in
+++ Peter Zijlstra [16/12/20 10:26 +0100]:
[snip]
PS, I originally found: in arch/x86/kvm/vmx/vmx.c: vmx_init(), it looks
like the line "static_branch_enable(&enable_evmcs);" does not take effect
in a v5.4-based kernel, but does take effect in the v5.10 kernel in the
same x86-64 virtual machine o
On Mon, Dec 14, 2020 at 11:15:12AM -0500, Steven Rostedt wrote:
> On Mon, 14 Dec 2020 18:59:02 +0300
> Anatoly Pugachev wrote:
>
> > Hello!
> >
> > Enabled ftrace startup tests on a sparc64 test VM/LDOM:
> >
> > $ diff -u <(gzip -dc ~/dmesg/config-5.10.0.gz) <(gzip -dc /proc/config.gz)
> > ---
Hi Will,
+++ Will McVicker [08/12/20 20:05 +]:
Getting the scmversion using scripts/setlocalversion currently only
works when run at the root of a git or mecurial project. This was
introduced in commit 8558f59edf93 ("setlocalversion: Ignote SCMs above
the linux source tree") so that if one i
+++ Jessica Yu [03/12/20 14:51 +0100]:
Apparently there has been a longstanding race between udev/systemd and
the module loader. Currently, the module loader sends a uevent right
after sysfs initialization, but before the module calls its init
function. However, some udev rules expect that the
option i.e. CONFIG_MODULE_SCMVERSION with a
depends on CONFIG_LOCALVERSION_AUTO. That way the dependency is
explicitly specified and the option could be enabled for distros that
want this.
[1] https://lore.kernel.org/lkml/20201123221338.ga2726...@google.com/
Thanks,
Jessica
---
Documentation/ABI/
+++ Johan Hovold [07/12/20 10:13 +0100]:
Drop the trailing semicolon from the MODULE_VERSION() macro definition
which was left when removing the array-of-pointer indirection.
Signed-off-by: Johan Hovold
Applied, thanks!
Jessica
---
include/linux/module.h | 2 +-
1 file changed, 1 insertion
On 16 Nov 2020, at 00:55, Jessica Clarke wrote:
>
> On 1 Nov 2020, at 21:01, Rich Felker wrote:
>>
>> On Sun, Nov 01, 2020 at 06:27:10PM +, Jessica Clarke wrote:
>>> On 1 Nov 2020, at 18:15, Jessica Clarke wrote:
>>>>
>>>> On 1 Nov 2020
https://github.com/systemd/systemd/issues/17586
Signed-off-by: Jessica Yu
---
kernel/module.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index a40ec708f8f2..e1dd0df57244 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1897,7 +1
More testing
would be greatly appreciated.
Thanks,
Jessica
Jessica Yu (1):
module: delay kobject uevent until after module init call
kernel/module.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
+++ Johan Hovold [27/11/20 10:59 +0100]:
On Wed, Nov 25, 2020 at 03:51:20PM +0100, Jessica Yu wrote:
I've queued up patches 3, 4, 6, 7, 8 for testing before pushing them
out to modules-next.
Thanks, Jessica.
Perhaps you can consider taking also the one for setup parameters (patc
+++ Johan Hovold [23/11/20 11:39 +0100]:
On Fri, Nov 13, 2020 at 03:18:36PM +0100, Johan Hovold wrote:
On Wed, Nov 11, 2020 at 04:47:16PM +0100, Jessica Yu wrote:
> Thanks for providing the links and references. Your explanation and
> this reply from Jakub [1] clarified things for me.
had to account for
scripts/module.lds recently on openSUSE for example:
https://github.com/openSUSE/kernel-source/commit/fe37c160c33dc09edff1781810aa098a2c316e20
Jessica
(like a security
vulnerability) but don't need to update the full kernel.
Hi Will,
If this were also intended for in-tree kernel modules, then why do
intree modules only get the UTS_RELEASE string in their scmversion
field, which basically already exists in the vermagic? Or do you plan
to change that?
Jessica
Hi dear,
I'm Jessica Vail, from the United States,please i wish to have a
communication with you.
I wait for your answer.
Jessica Vail.
On 1 Nov 2020, at 21:01, Rich Felker wrote:
>
> On Sun, Nov 01, 2020 at 06:27:10PM +, Jessica Clarke wrote:
>> On 1 Nov 2020, at 18:15, Jessica Clarke wrote:
>>>
>>> On 1 Nov 2020, at 18:07, Andy Lutomirski wrote:
>>>>
>>>&
+++ Andrii Nakryiko [11/11/20 12:11 -0800]:
On Wed, Nov 11, 2020 at 2:13 AM Jessica Yu wrote:
+++ Andrii Nakryiko [09/11/20 17:19 -0800]:
[snipped]
>diff --git a/kernel/module.c b/kernel/module.c
>index a4fa44a652a7..f2996b02ab2e 100644
>--- a/kernel/module.c
>+++ b/kernel/module.
+++ Johan Hovold [06/11/20 17:45 +0100]:
On Fri, Nov 06, 2020 at 05:03:45PM +0100, Jessica Yu wrote:
+++ Johan Hovold [03/11/20 18:57 +0100]:
>We rely on the linker to create arrays for a number of things including
>kernel parameters and device-tree-match entries.
>
>The stride of
in module memory,
that might save you the memcpy() to btf->data in btf_parse_module()
(unless that is still needed for some reason).
Thanks,
Jessica
/* Provided by the linker */
extern const struct kernel_symbol __start___ksymtab[];
extern const struct kernel_symbol __stop___ksymtab[];
@@ -
+++ Sergey Shtylyov [04/11/20 23:33 +0300]:
Here are 2 patches against the 'modules-next' branch of Jessica Yu's
'linux.git' repo.
I'm cleaning up the 'kernel-doc' function comments...
[1/2] module: fix up 'kernel-doc' comments
[2/2] module
Fix those comments, along with (unreported for some reason?) the starts
of the multi-line comments not being /* on their own line...
Signed-off-by: Sergey Shtylyov
---
This patch is against the 'modules-next' branch of Jessica Yu's 'linux.git'
repo plus my 2 patches
m to clarify this
unfortunately.
Thanks,
Jessica
+++ Sergey Shtylyov [31/10/20 23:05 +0300]:
Here are 3 patches against the 'modules-next' branch of Jessica Yu's
'linux.git' repo.
I'm doing some refactoring in module_sig_check()...
[1/3] module: merge repetitive strings in module_sig_check()
[2/3] module: avo
On 1 Nov 2020, at 18:15, Jessica Clarke wrote:
>
> On 1 Nov 2020, at 18:07, Andy Lutomirski wrote:
>>
>> On Sat, Oct 31, 2020 at 6:50 PM Rich Felker wrote:
>>>
>>> On Sun, Nov 01, 2020 at 01:27:35AM +, Jessica Clarke wrote:
>>>> On 1 Nov
On 1 Nov 2020, at 18:07, Andy Lutomirski wrote:
>
> On Sat, Oct 31, 2020 at 6:50 PM Rich Felker wrote:
>>
>> On Sun, Nov 01, 2020 at 01:27:35AM +, Jessica Clarke wrote:
>>> On 1 Nov 2020, at 01:22, Rich Felker wrote:
>>>> On Sat, Oct 31, 2020 at
On 1 Nov 2020, at 01:22, Rich Felker wrote:
> On Sat, Oct 31, 2020 at 04:30:44PM -0700, Andy Lutomirski wrote:
>> cc: some libc folks
>>
>> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
>>>
>>> POSIX specifies that the first field of the supplied
On 31 Oct 2020, at 23:30, Andy Lutomirski wrote:
>
> cc: some libc folks
>
> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
>>
>> POSIX specifies that the first field of the supplied msgp, namely mtype,
>> is a long, not a __kernel_long_t, and it's
> On 12 Oct 2020, at 14:44, Jessica Clarke wrote:
>
> POSIX specifies that the first field of the supplied msgp, namely mtype,
> is a long, not a __kernel_long_t, and it's a user-defined struct due to
> the variable-length mtext field so we can't even bend
+++ Miroslav Benes [29/10/20 13:31 +0100]:
On Wed, 28 Oct 2020, Jessica Yu wrote:
+++ Miroslav Benes [27/10/20 15:03 +0100]:
>If a module fails to load due to an error in prepare_coming_module(),
>the following error handling in load_module() runs with
>MODULE_STATE_COMING in modul
+++ Miroslav Benes [27/10/20 15:03 +0100]:
If a module fails to load due to an error in prepare_coming_module(),
the following error handling in load_module() runs with
MODULE_STATE_COMING in module's state. Fix it by correctly setting
MODULE_STATE_GOING under "bug_cleanup" label.
Signed-off-by:
e target address from the associated
> > GOT entry.
> >
> > Given that such GOT and PLT entries are unnecessary for fully linked
> > binaries such as the kernel, let's give these weak symbol references
> > hidden visibility, so that the linker knows that the weak r
+++ Sergey Shtylyov [13/10/20 23:32 +0300]:
Here are 2 patches against the 'modules-next' branch of Jessica Yu's
'linux.git' repo.
I'm doing some little refactoring in module_sig_check()...
[1/2] module: merge repetitive strings in module_sig_check()
[2/2
Hi Linus,
Please pull below to receive modules updates for the v5.10 merge window.
Details can be found in the signed tag.
Thank you,
Jessica
--
The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:
Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)
are available in the Git
1a7b7d922081 ("modules: Use vmalloc special flag")
Reported-by: Corentin Labbe
Tested-by: Corentin Labbe
Tested-on: sun50i-h6-pine-h64
Tested-on: imx8mn-ddr4-evk
Tested-on: sun50i-a64-bananapi-m64
Signed-off-by: Daniel Jordan
Applied, thanks!
Jessica
en x32
and non-x32 (i386 or x86_64) processes this would previously cause mtext
to "move" and, depending on the direction and ABI combination, lose the
first 4 bytes.
Signed-off-by: Jessica Clarke
---
I have verified that the test at the end of [1] now gives the correct
result on x32 (&
On 12 Oct 2020, at 04:02, Andy Lutomirski wrote:
> On Sun, Oct 11, 2020 at 6:48 PM Jessica Clarke wrote:
>>
>> POSIX specifies that the first field of the supplied msgp, namely mtype,
>> is a long, not a __kernel_long_t, and it's a user-defined struct due to
>>
en x32
and non-x32 (i386 or x86_64) processes this would previously cause mtext
to "move" and, depending on the direction and ABI combination, lose the
first 4 bytes.
Signed-off-by: Jessica Clarke
---
arch/x86/entry/syscalls/syscall_64.tbl | 6 --
1 file changed, 4 insertions(+),
Hi dear,
I'm Jessica Vail, from the United States,please i wish to have a
communication with you.
I wait for your answer.
Jessica Vail.
asm/module.lds.h, which is included from
scripts/module.lds.S.
scripts/module.lds is fine because 'make clean' keeps all the
build artifacts under scripts/.
You can add arch-specific sections in .
Signed-off-by: Masahiro Yamada
Tested-by: Jessica Yu
Acked-by: Will Deacon
Acked-by: Jessica Yu
Thanks for working on this!
Hi dear,
I'm Jessica Vail, from the United States,please i wish to have a
communication with you.
I wait for your answer.
Jessica Vail.
with CONFIG_DYNAMIC_FTRACE=n as well:
SECTIONS {
.plt (NOLOAD) : { BYTE(0) }
.init.plt (NOLOAD) : { BYTE(0) }
}
I will test on more arches in the next days but in the meantime you could add my
Tested-by: Jessica Yu
Thank you for working on this!
will take extra time
communicating to get extra info.
So this patch will add extra error messages for -ENOEXEC and -EPERM
errors, allowing user to do better debugging and reporting.
Signed-off-by: Qu Wenruo
Reviewed-by: Lucas De Marchi
Applied, thanks.
Jessica
F_WRITE.
Link: http://lore.kernel.org/r/20200831094651.GA16385@linux-8ccs
Acked-by: Will Deacon
Signed-off-by: Jessica Yu
---
arch/arm64/kernel/module-plts.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
index 0ce3a2
ex %d) has invalid WRITE|EXEC flags",
mod->name, secstrings + sechdrs[i].sh_name, i)
The rest looks fine to me. Thanks!
Jessica
+++ Ard Biesheuvel [31/08/20 16:25 +0300]:
On Mon, 31 Aug 2020 at 13:43, Masahiro Yamada wrote:
On Mon, Aug 31, 2020 at 6:47 PM Jessica Yu wrote:
>
> +++ Will Deacon [21/08/20 13:30 +0100]:
> [snipped]
> >> > > > So module_enforce_rwx_section
chdrs[i].sh_name,
+ else if (!strcmp(secstrings + sechdrs[i].sh_name,
".text.ftrace_trampoline"))
tramp = sechdrs + i;
else if (sechdrs[i].sh_type == SHT_SYMTAB)
If so I'll turn it into a formal patch and we can get that merged in the next
-rc.
Thanks,
Jessica
iesheuvel wrote:
> > > On Thu, 13 Aug 2020 at 15:04, Jessica Yu wrote:
> > > >
> > > > +++ Ard Biesheuvel [13/08/20 10:36 +0200]:
> > > > >On Wed, 12 Aug 2020 at 22:00, Peter Zijlstra
wrote:
> > > > >>
> > > > >>
GPL symbols and proprietary
symbols. A recent example cited from the discussion can be found here:
https://lore.kernel.org/netdev/6376ca34-bc6f-45de-9ffd-7e32664c7...@fb.com/T/#md514322fdfa212afe9f1d3eb4e5f7eaefece36eb
Thank you,
Jessica
--
The following changes since commit b3a9e3b9622ae10064826dccb
+++ Ard Biesheuvel [13/08/20 10:36 +0200]:
On Wed, 12 Aug 2020 at 22:00, Peter Zijlstra wrote:
On Wed, Aug 12, 2020 at 06:37:57PM +0200, Ard Biesheuvel wrote:
> I know there is little we can do at this point, apart from ignoring
> the permissions - perhaps we should just defer the w^x check un
{
.plt (NOLOAD) : { BYTE(0) }
.init.plt (NOLOAD) : { BYTE(0) }
.text.ftrace_trampoline (NOLOAD) : { BYTE(0) }
}
It appears that the name of the section influences the behaviour, as
Jessica observed [1] that sections named .text.* end up with PROGBITS,
whereas random naming s
. I am not sure if this is a bug in binutils or if this
behavior is intentional.
I tried to grok the changelog between 2.34 and 2.35 but could not find
anything glaringly obvious that would cause this change. CC'ing the
binutils mailing list, hopefully that's the right place to ask.
Jessica
uired implementation detail.
Fixes: 974b9b2c68 ("mm: consolidate pte_index() and pte_offset_*() definitions")
Reported-by: John Paul Adrian Glaubitz
Signed-off-by: Jessica Clarke
Tested-by: John Paul Adrian Glaubitz
---
Changes since v1:
* Fixed typo in commit message
* Slightly re
(since we know it's in region number 5). */
> #define pgd_offset_k(addr) \
> (init_mm.pgd + (((addr) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1)))
But now it's the generic:
> #define pgd_offset_k(address) pgd_offset(&init_mm, (addres
tive will mark a section to not be
loaded at run time." But these sections are marked SHF_ALLOC and are referenced
to in the module plt code. Or does it just tell the linker to not initialize it?
Adding Ard to CC, I'm sure he'd know more about the section flag specifics.
Jessica
+++ Jessica Yu [10/08/20 11:25 +0200]:
+++ Mauro Carvalho Chehab [08/08/20 10:12 +0200]:
[snip]
Right now, what happens is:
# modprobe wlcore
modprobe: ERROR: could not insert 'wlcore': Exec format error
This seems to be failing for all modules, as doesn't show
+#endif
return 0;
}
All this hunk does it reject loading modules that have any sections
that have both the writable and executable flags. You're saying it's
happening for all modules on your setup - I am curious as to which
sections have both these flags - what does readelf -S tell you?
Thanks,
Jessica
ection attr into bin attribute")
Cc: sta...@vger.kernel.org
Cc: Jessica Yu
Signed-off-by: Kees Cook
Oof, thanks for fixing this!
Acked-by: Jessica Yu
---
kernel/module.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/kernel/module.c b/kernel/mo
1 - 100 of 689 matches
Mail list logo
