On 3/10/21 2:48 PM, Jakub Kicinski wrote:
> On Wed, 10 Mar 2021 14:12:43 -0800 Florian Fainelli wrote:
>> phydev::dev_flags contains a bitmask of configuration bits requested by
>> the consumer of a PHY device (Ethernet MAC or switch) towards the PHY
>> driver. Since these flags are often used for
On Wed, 10 Mar 2021 14:12:43 -0800 Florian Fainelli wrote:
> phydev::dev_flags contains a bitmask of configuration bits requested by
> the consumer of a PHY device (Ethernet MAC or switch) towards the PHY
> driver. Since these flags are often used for requesting LED or other
> type of
> On Mar 10, 2021, at 2:08 PM, David Howells wrote:
>
> Can you check this patch? I rolled your changes into it.
Looks good to me, thanks.
On Wed, Mar 10, 2021 at 11:41:24PM +0100, Rafał Miłecki wrote:
> See inline
>
> On 10.03.2021 22:08, Ansuel Smith wrote:
> > Document nvmem-cells compatible used to treat mtd partitions as a
> > nvmem provider.
> >
> > Signed-off-by: Ansuel Smith
> > ---
> >
On Thu, Mar 11, 2021 at 12:55:09AM +0900, Masami Hiramatsu wrote:
> Hi Josh and Daniel,
<...>
> commit aa452d999b524b1851f69cc947be3e1a2f3ca1ec
> Author: Masami Hiramatsu
> Date: Sat Mar 6 08:34:51 2021 +0900
>
> x86/unwind/orc: Fixup kretprobe trampoline entry
>
> Since the
On Wed, Mar 10, 2021 at 10:27:53PM +, Eric Curtin wrote:
> Hi Fabio,
>
> > I am sorry, I fear I don't understand, checkpatch.sh script says the patch
> > is ok.
> > Where have I to add a ' ' (a blank?)?
> >
> > thank you,
> >
> > fabio
> >
>
> I'm only responding to this because this email
On Wed, Mar 10, 2021 at 4:25 PM Abel Vesa wrote:
>
> On 21-03-03 10:31:19, Abel Vesa wrote:
> > On 21-03-02 13:03:04, Adam Ford wrote:
> > > On Mon, Feb 15, 2021 at 7:06 AM Abel Vesa wrote:
> > > >
> > > > On 21-02-13 08:44:28, Adam Ford wrote:
> > > > > On Wed, Feb 3, 2021 at 3:22 PM Adam Ford
On Thu, 2021-03-11 at 00:35 +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 11, 2021 at 12:12:17AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Mar 11, 2021 at 12:10:56AM +0200, Jarkko Sakkinen wrote:
> > > On Thu, Mar 11, 2021 at 09:36:15AM +1300, Kai Huang wrote:
> > > > On Wed, 2021-03-10 at 17:11
On 3/10/21 9:15 AM, Masahiro Yamada wrote:
> On Wed, Mar 10, 2021 at 11:47 PM Viresh Kumar wrote:
>>
>> On 10-03-21, 20:24, Masahiro Yamada wrote:
>>> On Wed, Mar 10, 2021 at 2:35 PM Viresh Kumar
>>> wrote:
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index
On Wed, 2021-03-10 at 14:25 -0800, Ricardo Neri wrote:
> On Wed, Mar 10, 2021 at 09:01:47PM +0100, Borislav Petkov wrote:
> > On Wed, Mar 10, 2021 at 11:46:44AM -0800, Ricardo Neri wrote:
> > > But this series provides the use case, right? Kan's patches
> > > handle PMU counters
> > > that may
On 2021-03-10, Nicolas Pitre wrote:
On Mon, 1 Mar 2021, Nicholas Piggin wrote:
Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
> Unlike what Nick expected in his submission, I now think the annotations
> will be needed for LTO just like they are for --gc-sections.
Yeah I
On Wed, Mar 10, 2021 at 1:41 PM Yang Shi wrote:
>
> On Wed, Mar 10, 2021 at 1:08 PM Shakeel Butt wrote:
> >
> > On Wed, Mar 10, 2021 at 10:54 AM Yang Shi wrote:
> > >
> > > On Wed, Mar 10, 2021 at 10:24 AM Shakeel Butt wrote:
> > > >
> > > > On Wed, Mar 10, 2021 at 9:46 AM Yang Shi wrote:
> >
See inline
On 10.03.2021 22:08, Ansuel Smith wrote:
Document nvmem-cells compatible used to treat mtd partitions as a
nvmem provider.
Signed-off-by: Ansuel Smith
---
.../bindings/mtd/partitions/nvmem-cells.yaml | 96 +++
1 file changed, 96 insertions(+)
create mode
Jim Newsome writes:
> do_wait is an internal function used to implement waitpid, waitid,
> wait4, etc. To handle the general case, it does an O(n) linear scan of
> the thread group's children and tracees.
>
> This patch adds a special-case when waiting on a pid to skip these scans
> and instead
On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
> in the beginning of the function.
OK.
What you should do is to explain what it does and why it's needed.
>
> Signed-off-by: Yu-cheng Yu
> Cc: Andy Lutomirski
>
Hi Christophe,
> Powerpc is the only architecture having _inatomic variants of
> __get_user() and __put_user() accessors. They were introduced
> by commit e68c825bb016 ("[POWERPC] Add inatomic versions of __get_user
> and __put_user").
>
> Those variants expand to the _nosleep macros instead of
On 3/10/21 4:23 PM, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 1103e2826a9f ("xen/events: don't unmask an event channel when an eoi is
> pending")
>
> Fixes tag
>
> Fixes: 54c9de89895e0a36047 ("xen/events: add a new late EOI evtchn
> framework")
>
> has these problem(s):
>
> -
On Thu, Mar 11, 2021 at 12:12:17AM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 11, 2021 at 12:10:56AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Mar 11, 2021 at 09:36:15AM +1300, Kai Huang wrote:
> > > On Wed, 2021-03-10 at 17:11 +0200, Jarkko Sakkinen wrote:
> > > > On Wed, Mar 03, 2021 at
Defining one macro instead of two for tcpc_presenting_*_rd.
This is a follow up of the comment left by Heikki Krogerus.
https://patchwork.kernel.org/project/linux-usb/patch/
20210304070931.1947316-1-bad...@google.com/
Signed-off-by: Badhri Jagan Sridharan
---
drivers/usb/typec/tcpm/tcpci.c |
On 3/10/2021 5:25 PM, Ricardo Neri wrote:
On Wed, Mar 10, 2021 at 09:01:47PM +0100, Borislav Petkov wrote:
On Wed, Mar 10, 2021 at 11:46:44AM -0800, Ricardo Neri wrote:
But this series provides the use case, right? Kan's patches handle PMU counters
that may differ cross types of CPUs. In
Hi Christophe,
> This patch converts emulate_spe() to using user_access_being
s/being/begin/ :)
> logic.
>
> Since commit 662bbcb2747c ("mm, sched: Allow uaccess in atomic with
> pagefault_disable()"), might_fault() doesn't fire when called from
> sections where pagefaults are disabled, which
Both add_slot_store() and remove_slot_store() try to fix up the drc_name
copied from the store buffer by placing a NULL terminator at nbyte + 1
or in place of a '\n' if present. However, the static buffer that we
copy the drc_name data into is not zeored and can contain anything past
the n-th
On 2021-03-10, Arnd Bergmann wrote:
On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada wrote:
On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
> Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
masahiro@oscar:~/ref/linux$ echo 'void this_func_is_unused(void) {}'
>>
Hi Fabio,
> I am sorry, I fear I don't understand, checkpatch.sh script says the patch is
> ok.
> Where have I to add a ' ' (a blank?)?
>
> thank you,
>
> fabio
>
I'm only responding to this because this email is doing a very good job
of avoiding my filters somehow :) I think what Greg means
On Wed, 2021-03-10 at 21:56 +0200, Jarkko Sakkinen wrote:
[...]
> I also need to apply
>
> https://lore.kernel.org/linux-integrity/20210127190617.17564-1-james.bottom...@hansenpartnership.com/
>
> and I would like to do both while I'm at it.
>
> James, there was one patch that needed fixing
fix the following checkpatch warnings:
WARNING: Block comments use * on subsequent lines
+ /*
+ AMPDU_para [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k
--
WARNING: Block comments use * on subsequent lines
+/*
+op_mode
Signed-off-by: Fabio Aiuto
---
On Wed, Mar 10, 2021 at 09:01:47PM +0100, Borislav Petkov wrote:
> On Wed, Mar 10, 2021 at 11:46:44AM -0800, Ricardo Neri wrote:
> > But this series provides the use case, right? Kan's patches handle PMU
> > counters
> > that may differ cross types of CPUs. In patch 2, get_hybrid_params()
> >
On 21-03-03 10:31:19, Abel Vesa wrote:
> On 21-03-02 13:03:04, Adam Ford wrote:
> > On Mon, Feb 15, 2021 at 7:06 AM Abel Vesa wrote:
> > >
> > > On 21-02-13 08:44:28, Adam Ford wrote:
> > > > On Wed, Feb 3, 2021 at 3:22 PM Adam Ford wrote:
> > > > >
> > > > > On Thu, Jan 21, 2021 at 4:24 AM Abel
On Wed, Mar 10, 2021 at 1:14 PM Sean Christopherson wrote:
>
> On Wed, Mar 10, 2021, Paolo Bonzini wrote:
> > On 10/03/21 01:30, Sean Christopherson wrote:
> > > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > > index 50ef757c5586..f0c99fa04ef2 100644
> > > ---
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
UFFD_FEATURE_THREAD_ID is supported in Linux 4.14.
Signed-off-by: Peter Xu
---
man2/ioctl_userfaultfd.2 | 5 +
1 file changed, 5 insertions(+)
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index 47ae5f473..d4a8375b8 100644
--- a/man2/ioctl_userfaultfd.2
+++
Userfaultfd write-protect mode is supported starting from Linux 5.7.
Signed-off-by: Peter Xu
---
man2/ioctl_userfaultfd.2 | 81 ++--
1 file changed, 78 insertions(+), 3 deletions(-)
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index
Write-protect mode is supported starting from Linux 5.7.
Signed-off-by: Peter Xu
---
man2/userfaultfd.2 | 103 -
1 file changed, 101 insertions(+), 2 deletions(-)
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 555e37409..d1f9aad24 100644
v3:
- Don't use "Currently", instead add "(since x.y)" mark where proper [Alex]
- Always use semantic newlines across the whole patchset [Alex]
- Use quote when possible, rather than escapes [Alex]
- Fix one missing replacement of ".BR" -> ".B" [Alex]
- Some other trivial rephrases here and there
UFFD_FEATURE_THREAD_ID is supported since Linux 4.14.
Signed-off-by: Peter Xu
---
man2/userfaultfd.2 | 13 +
1 file changed, 13 insertions(+)
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index e7dc9f813..555e37409 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@
When tpm_read_log_efi is called multiple times, which happens when
one loads and unloads a TPM2 driver multiple times, then the global
variable efi_tpm_final_log_size will at some point become a negative
number due to the subtraction of final_events_preboot_size occurring
each time. Use a local
Check the eventlog signature before using it. This avoids using an
empty log, as may be the case when QEMU created the ACPI tables,
rather than probing the EFI log next. This resolves an issue where
the EFI log was empty since an empty ACPI log was used.
Fixes: 85467f63a05c ("tpm: Add support for
Avoid allocating memory and reading the host log when a virtual device
is used since this log is of no use to that driver. A virtual
device can be identified through the flag TPM_CHIP_FLAG_VIRTUAL, which
is only set for the tpm_vtpm_proxy driver.
Fixes: 6f99612e2500 ("tpm: Proxy driver for
This series of patches fixes a couple of issues related to TPM2
event logs, such as the disappearance of the TPM2 log on QEMU machines
running with UEFI (my fault) and a kernel fault due to an integer under-
flow when reading the TPM 2 log multiple times.
Regards,
Stefan
v1->v2:
- Revised
On Wed, Mar 10, 2021 at 11:22:57PM +0300, Dmitry Osipenko wrote:
> 10.03.2021 22:13, Dmitry Osipenko пишет:
> > I found that this patch introduced a serious regression on Tegra30 using
> > today's linux-next. Tegra30 has two 3d h/w blocks connected in SLI and
> > only one of the blocks is now
Similar to commit 92696286f3bb37ba50e4bd8d1beb24afb759a799 ("net:
bcmgenet: Set phydev->dev_flags only for internal PHYs") we need to
qualify the phydev->dev_flags based on whether the port is connected to
an internal or external PHY otherwise we risk having a flags collision
with a completely
On Tue, Mar 02, 2021 at 05:24:56PM -0800, Paul E. McKenney wrote:
> On Tue, Feb 23, 2021 at 01:10:08AM +0100, Frederic Weisbecker wrote:
> > A NOCB-gp wake up can safely delete the nocb_bypass_timer. nocb_gp_wait()
> > is going to check again the bypass state and rearm the bypass timer if
> >
Instead of strcpy'ing into a stack buffer, just let additional_notice
point to a string literal living in .rodata. This is better in a few
ways:
- Smaller .text - instead of gcc compiling the strcpys as a bunch of
immediate stores (effectively encoding the string literal in the
instruction
On 2021-03-09 11:50 a.m., Felix Kuehling wrote:
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
phydev::dev_flags contains a bitmask of configuration bits requested by
the consumer of a PHY device (Ethernet MAC or switch) towards the PHY
driver. Since these flags are often used for requesting LED or other
type of configuration being able to quickly audit them without
instrumenting the kernel
Oleg Nesterov writes:
> On 03/10, Eric W. Biederman wrote:
>>
>> /* If global init has exited,
>> * panic immediately to get a useable coredump.
>> */
>> if (unlikely(is_global_init(tsk) &&
>> (thread_group_empty(tsk) ||
>> (tsk->signal->flags &
On Thu, Mar 11, 2021 at 12:10:56AM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 11, 2021 at 09:36:15AM +1300, Kai Huang wrote:
> > On Wed, 2021-03-10 at 17:11 +0200, Jarkko Sakkinen wrote:
> > > On Wed, Mar 03, 2021 at 08:59:17AM -0800, Dave Hansen wrote:
> > > > On 3/3/21 7:03 AM, Jarkko Sakkinen
On Thu, Mar 11, 2021 at 09:36:15AM +1300, Kai Huang wrote:
> On Wed, 2021-03-10 at 17:11 +0200, Jarkko Sakkinen wrote:
> > On Wed, Mar 03, 2021 at 08:59:17AM -0800, Dave Hansen wrote:
> > > On 3/3/21 7:03 AM, Jarkko Sakkinen wrote:
> > > > diff --git a/arch/x86/kernel/cpu/sgx/main.c
> > > >
On 3/10/21 1:49 PM, Paul E. McKenney wrote:
> On Wed, Mar 10, 2021 at 10:11:22PM +0100, Michal Hocko wrote:
>> On Wed 10-03-21 10:56:08, Mike Kravetz wrote:
>>> On 3/10/21 7:19 AM, Michal Hocko wrote:
On Mon 08-03-21 18:28:02, Muchun Song wrote:
[...]
> @@ -1447,7 +1486,7 @@ void
On Wed, Mar 10, 2021 at 11:38:47PM +0300, Dmitry Osipenko wrote:
> 10.03.2021 06:36, Nicolin Chen пишет:
> > This patch dumps all active mapping entries from pagetable
> > to a debugfs directory named "mappings".
> >
> > Ataching an example:
> >
> > SWGROUP: hc
> > ASID: 0
> > reg: 0x250
> >
On Wed, 10 Mar 2021, Nick Desaulniers wrote:
> On Wed, Mar 10, 2021 at 1:08 PM Arnd Bergmann wrote:
> >
> > On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada
> > wrote:
> > > On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
> > > > Excerpts from Arnd Bergmann's message of February 27,
On Tue, Mar 02, 2021 at 05:22:29PM -0800, Paul E. McKenney wrote:
> On Tue, Feb 23, 2021 at 01:10:09AM +0100, Frederic Weisbecker wrote:
> > No need to disarm the nocb_timer if rcu_nocb is polling because it
> > shouldn't be armed either.
> >
> > Signed-off-by: Frederic Weisbecker
> > Cc: Josh
On Wed, Mar 10, 2021 at 10:51 PM Andrii Nakryiko
wrote:
> On Wed, Mar 10, 2021 at 12:12 PM Andrii Nakryiko
> wrote:
> > On Wed, Mar 10, 2021 at 8:59 AM Yonghong Song wrote:
> > > On 3/10/21 3:48 AM, Florent Revest wrote:
> > > > On Wed, Mar 10, 2021 at 6:16 AM Yonghong Song wrote:
> > > >> On
x86_64 randconfig-a014-20210309
x86_64 randconfig-a011-20210309
x86_64 randconfig-a012-20210309
x86_64 randconfig-a011-20210310
x86_64 randconfig-a016-20210310
x86_64 randconfig-a013-20210310
x86_64
randconfig-a015-20210309
x86_64 randconfig-a014-20210309
x86_64 randconfig-a011-20210309
x86_64 randconfig-a012-20210309
x86_64 randconfig-a011-20210310
x86_64 randconfig-a016-20210310
x86_64 randconfig-a013
Hello Munchun,
On Tue, Mar 09, 2021 at 06:07:16PM +0800, Muchun Song wrote:
> @@ -6806,11 +6823,23 @@ static inline void uncharge_gather_clear(struct
> uncharge_gather *ug)
> static void uncharge_batch(const struct uncharge_gather *ug)
> {
> unsigned long flags;
> + unsigned long
From: "H.J. Lu"
When Indirect Branch Tracking (IBT) is enabled, vDSO functions may be
called indirectly, and must have ENDBR32 or ENDBR64 as the first
instruction. The compiler must support -fcf-protection=branch so that it
can be used to compile vDSO.
Signed-off-by: H.J. Lu
Signed-off-by:
When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
in the beginning of the function.
Signed-off-by: Yu-cheng Yu
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Jarkko Sakkinen
---
arch/x86/entry/vdso/vsgx.S | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: "H.J. Lu"
Update ARCH_X86_CET_STATUS and ARCH_X86_CET_DISABLE for Indirect Branch
Tracking.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/kernel/cet_prctl.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/cet_prctl.c
From: "H.J. Lu"
Add ENDBR32 to __kernel_vsyscall entry point.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
Acked-by: Andy Lutomirski
Reviewed-by: Kees Cook
---
arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
1 file changed, 3 insertions(+)
diff --git
Introduce user-mode Indirect Branch Tracking (IBT) support. Add routines
for the setup/disable of IBT.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cet.h | 3 +++
arch/x86/kernel/cet.c | 33 +
2 files changed, 36
An ELF file's .note.gnu.property indicates features the file supports.
The property is parsed at loading time and passed to arch_setup_elf_
property(). Update it for Indirect Branch Tracking.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/kernel/process_64.c | 8
1
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
This is the second part of CET and enables Indirect Branch Tracking (IBT).
It is built on top
When an indirect CALL/JMP instruction is executed and before it reaches
the target, it is in 'WAIT_ENDBR' status, which can be read from
MSR_IA32_U_CET. The status is part of a task's status before a signal is
raised and preserved in the signal frame. It is restored for sigreturn.
IBT state
Indirect branch tracking is a hardware security feature that verifies near
indirect call/jump instructions arrive at intended targets, which are
labeled by the compiler with ENDBR opcodes. If such instructions reach
unlabeled locations, the processor raises control-protection faults.
Check the
On Tue, Mar 02, 2021 at 05:15:57PM -0800, Paul E. McKenney wrote:
> The first question is of course: Did you try this with lockdep enabled? ;-)
Yep I always do. But I may miss some configs on my testings. I usually
test at least TREE01 on x86 and arm64.
> > @@ -1702,43 +1692,50 @@ bool
On Wed, Mar 10, 2021 at 1:08 PM Arnd Bergmann wrote:
>
> On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada wrote:
> > On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
> > > Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
>
> >
> > masahiro@oscar:~/ref/linux$ echo 'void
This exercices most of the format specifiers when things go well.
Signed-off-by: Florent Revest
---
.../selftests/bpf/prog_tests/snprintf.c | 71 +++
.../selftests/bpf/progs/test_snprintf.c | 71 +++
2 files changed, 142 insertions(+)
create mode
We have a usecase where we want to audit symbol names (if available) in
callback registration hooks. (ex: fentry/nf_register_net_hook)
A few months back, I proposed a bpf_kallsyms_lookup series but it was
decided in the reviews that a more generic helper, bpf_snprintf, would
be more useful.
This
When initializing the __param array with a one liner, if all args are
const, the initial array value will be placed in the rodata section but
because libbpf does not support relocation in the rodata section, any
pointer in this array will stay NULL.
This is a workaround, ideally the rodata
The implementation takes inspiration from the existing bpf_trace_printk
helper but there are a few differences:
To allow for a large number of format-specifiers, parameters are
provided in an array, like in bpf_seq_printf.
Because the output string takes two arguments and the array of
parameters
Similarly to BPF_SEQ_PRINTF, this macro turns variadic arguments into an
array of u64, making it more natural to call the bpf_snprintf helper.
Signed-off-by: Florent Revest
---
tools/lib/bpf/bpf_tracing.h | 15 +++
1 file changed, 15 insertions(+)
diff --git
This type provides the guarantee that an argument is going to be a const
pointer to somewhere in a read-only map value. It also checks that this
pointer is followed by a NULL character before the end of the map value.
Signed-off-by: Florent Revest
---
include/linux/bpf.h | 1 +
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel returns
the following information:
*args = shadow stack/IBT status
*(args + 1) = shadow stack base address
*(args + 2) = shadow stack size
To deliver a signal, create a shadow stack restore token and put the token
and the signal restorer address on the shadow stack. For sigreturn, verify
the token and restore from it the shadow stack pointer.
A shadow stack restore token marks a restore point of the shadow stack, and
the address in
To prepare changes to arch_calc_vm_prot_bits() in the next patch, and be
consistent with other architectures, move arch_vm_get_page_prot() and
arch_calc_vm_prot_bits() to arch/x86/include/asm/mman.h.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/mman.h | 30
The kernel allocates (and frees on thread exit) a new shadow stack for a
pthread child.
It is possible for the kernel to complete the clone syscall and set the
child's shadow stack pointer to NULL and let the child thread allocate
a shadow stack for itself. There are two issues in
An ELF file's .note.gnu.property indicates arch features supported by the
file. These features are extracted by arch_parse_elf_property() and stored
in 'arch_elf_state'.
Introduce x86 feature definitions and arch_setup_elf_property(), which
enables such features. The first use-case of this
There are three possible options to create a shadow stack allocation API:
an arch_prctl, a new syscall, or adding PROT_SHSTK to mmap()/mprotect().
Each has its advantages and compromises.
An arch_prctl() is the least intrusive. However, the existing x86
arch_prctl() takes only two parameters.
Introduce basic shadow stack enabling/disabling/allocation routines.
A task's shadow stack is allocated from memory with VM_SHSTK flag and has
a fixed size of min(RLIMIT_STACK, 4GB).
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cet.h | 28 ++
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function
do_mmap_pgoff()").
There is a new user now. Shadow stack allocation passes VM_SHSTK to
do_mmap(). Re-introduce
When serving a page fault, maybe_mkwrite() makes a PTE writable if it is in
a writable vma. A shadow stack vma is writable, but its PTEs need
_PAGE_DIRTY to be set to become writable. For this reason, maybe_mkwrite()
has been updated.
There are a few places that call pte_mkwrite() directly, but
A shadow stack PTE must be read-only and have _PAGE_DIRTY set. However,
read-only and Dirty PTEs also exist for copy-on-write (COW) pages. These
two cases are handled differently for page faults. Introduce VM_SHSTK to
track shadow stack VMAs.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
Shadow stack accesses are those that are performed by the CPU where it
expects to encounter a shadow stack mapping. These accesses are performed
implicitly by CALL/RET at the site of the shadow stack pointer. These
accesses are made explicitly by shadow stack management instructions like
WRUSSQ.
When serving a page fault, maybe_mkwrite() makes a PTE writable if its vma
has VM_WRITE.
A shadow stack vma has VM_SHSTK. Its PTEs have _PAGE_DIRTY, but not
_PAGE_WRITE. In fork(), _PAGE_DIRTY is cleared to effect copy-on-write,
and in page fault, _PAGE_DIRTY is restored and the shadow stack
On 3/10/21 6:25 AM, gre...@linuxfoundation.org wrote:
From: Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.261 release.
There are 7 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let
On 3/10/21 6:24 AM, gre...@linuxfoundation.org wrote:
From: Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.180 release.
There are 39 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
INCSSP(Q/D) increments shadow stack pointer and 'pops and discards' the
first and the last elements in the range, effectively touches those memory
areas.
The maximum moving distance by INCSSPQ is 255 * 8 = 2040 bytes and
255 * 4 = 1020 bytes by INCSSPD. Both ranges are far from PAGE_SIZE.
Thus,
Can_follow_write_pte() ensures a read-only page is COWed by checking the
FOLL_COW flag, and uses pte_dirty() to validate the flag is still valid.
Like a writable data page, a shadow stack page is writable, and becomes
read-only during copy-on-write, but it is always dirty. Thus, in the
Account shadow stack pages to stack memory.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/mm/pgtable.c | 7 +++
include/linux/pgtable.h | 11 +++
mm/mmap.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/arch/x86/mm/pgtable.c
After the introduction of _PAGE_COW, a modified page's PTE can have either
_PAGE_DIRTY or _PAGE_COW. Change _PAGE_DIRTY to _PAGE_DIRTY_BITS.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
Cc: David Airlie
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Zhenyu
In change_pte_range(), when a PTE is changed for prot_numa, _PAGE_RW is
preserved to avoid the additional write fault after the NUMA hinting fault.
However, pte_write() now includes both normal writable and shadow stack
(RW=0, Dirty=1) PTEs, but the latter does not have _PAGE_RW and has no need
to
The read-only and Dirty PTE has been used to indicate copy-on-write pages.
However, newer x86 processors also regard a read-only and Dirty PTE as a
shadow stack page. In order to separate the two, the software-defined
_PAGE_COW is created to replace _PAGE_DIRTY for the copy-on-write case, and
To prepare the introduction of _PAGE_COW, move pmd_write() and
pud_write() up in the file, so that they can be used by other
helpers below.
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/pgtable.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
Add CPU feature flags for Control-flow Enforcement Technology (CET).
CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect Branch Tracking
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cpufeatures.h | 2 ++
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent a new memory type (shadow stack) within the existing bits.
They chose to repurpose a lightly-used state: Write=0, Dirty=1.
The reason it's lightly
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as Dirty.
New processors that support Shadow Stack regard read-only and Dirty PTEs as
shadow stack pages. This
When Shadow Stack is introduced, [R/O + _PAGE_DIRTY] PTE is reserved for
shadow stack. Copy-on-write PTEs have [R/O + _PAGE_COW].
When a PTE goes from [R/W + _PAGE_DIRTY] to [R/O + _PAGE_COW], it could
become a transient shadow stack PTE in two cases:
The first case is that some processors can
Introduce a software-defined X86_FEATURE_CET, which indicates either Shadow
Stack or Indirect Branch Tracking (or both) is present. Also introduce
related cpu init/setup functions.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cpufeatures.h | 2 +-
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level
401 - 500 of 1854 matches
Mail list logo
