On Sat, 6 Oct 2018 10:51:54 +1000
Dave Chinner wrote:
> Can you let us know whether the CC-by-SA 4.0 license is acceptible
> or not? That's really the only thing that we need clarified at this
> point - if it's OK I'll to pull this into the XFS tree for the 4.20
> merge window. If not, we'll go b
On Thu, Oct 11, 2018 at 11:27:35AM -0600, Jonathan Corbet wrote:
> On Sat, 6 Oct 2018 10:51:54 +1000 Dave Chinner
> wrote:
>
> > Can you let us know whether the CC-by-SA 4.0 license is
> > acceptible or not? That's really the only thing that we need
> > clarified at this point - if it's OK I'll t
On 11/10/2018 06:58, Mike Rapoport wrote:
> From: Mike Rapoport
>
> to allow additions of new documentation about memory hotplug under the same
> roof.
>
> Signed-off-by: Mike Rapoport
> ---
> Documentation/core-api/index.rst | 2 +-
> Documentation/core-api/memory-hotplug-n
On 11/10/2018 06:58, Mike Rapoport wrote:
> From: David Hildenbrand
>
> Let's document the magic a bit, especially why device_hotplug_lock is
> required when adding/removing memory and how it all play together with
> requests to online/offline memory from user space.
>
> [ rppt: moved the text t
The handler for "%pN" falls back to printing the raw pointer value when
using a different format than the (sole supported) special format
"%pNF", potentially leaking sensitive information regarding the kernel
layout in memory.
Avoid this leak by printing the hashed address instead.
Note that there
On platforms using the Common Clock Framework, "%pC" prints the clock's
name. On legacy platforms, it prints the unhashed clock's address,
potentially leaking sensitive information regarding the kernel layout in
memory.
Avoid this leak by printing the hashed address instead. To distinguish
betwee
- Make the ptr argument const, to avoid adding casts in future
callers,
- Move the function and its dependencies up, so it can be called from
special pointer type formatting routines.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Get rid of the forward declaration for ptr_to_id().
---
Hi all,
There are still two format specifiers that print unhanced kernel
addresses, potentially leaking sensitive information regarding the
kernel layout in memory.
This patch series fixes this by printing hashed addresses instead.
Changes compared to v1:
- Get rid of the forward d
Hi Ganapatrao,
On 11/10/18 07:39, Ganapatrao Kulkarni wrote:
+
+/*
+ * We must NOT create groups containing events from multiple hardware PMUs,
+ * although mixing different software and hardware PMUs is allowed.
+ */
+static bool thunderx2_uncore_validate_event_group(struct perf_event *event)
+
On Wed, Oct 10, 2018 at 8:45 PM, James Morris wrote:
> On Wed, 10 Oct 2018, Kees Cook wrote:
>
>> v5:
>> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
>> - dropped various Reviewed-bys due to rather large refactoring
>
> Patches 1-10 applied to
> git://git.kernel.org/pub/
Look in .note.gnu.property of an ELF file and check if Shadow Stack needs
to be enabled for the task.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
---
arch/x86/Kconfig | 4 +
arch/x86/include/asm/elf.h | 5 +
arch/x86/include/uapi/asm/elf_property.
The shadow stack for clone/fork is handled as the following:
(1) If ((clone_flags & (CLONE_VFORK | CLONE_VM)) == CLONE_VM),
the kernel allocates (and frees on thread exit) a new SHSTK
for the child.
It is possible for the kernel to complete the clone syscall
and set the child's SH
arch_prctl(ARCH_X86_CET_STATUS, unsigned long *addr)
Return CET feature status.
The parameter 'addr' is a pointer to a user buffer.
On returning to the caller, the kernel fills the following
information:
*addr = SHSTK/IBT status
*(addr + 1) = SHSTK base address
*(addr
This patch implements THP shadow stack memory copying in the same
way as the previous patch for regular PTE.
In copy_huge_pmd(), we clear the dirty bit from the PMD. On the
next shadow stack access to the PMD, a page fault occurs. At
that time, the page is copied/re-used and the PMD is fixed.
S
Add the following shadow stack management instructions.
INCSSP:
Increment shadow stack pointer by the steps specified.
RDSSP:
Read SSP register into a GPR.
SAVEPREVSSP:
Use "prev ssp" token at top of current shadow stack to
create a "restore token" on previous shadow stack.
RSTO
When setting up a signal, the kernel creates a shadow stack
restore token at the current SHSTK address and then stores the
token's address in the signal frame, right after the FPU state.
Before restoring a signal, the kernel verifies and then uses the
restore token to set the SHSTK pointer.
Signed
When a task does fork(), its shadow stack must be duplicated for
the child. However, the child may not actually use all pages of
of the copied shadow stack. This patch implements a flow that
is similar to copy-on-write of an anonymous page, but for shadow
stack memory. A shadow stack PTE needs t
Add shadow stack pages to memory accounting.
Signed-off-by: Yu-cheng Yu
---
mm/mmap.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index b85292014ec9..fa581ced3f56 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1677,6 +1677,9 @@ static inline int accountable_mapping
Indirect branch tracking provides an optional legacy code bitmap
that indicates locations of non-IBT compatible code. When set,
each bit in the bitmap represents a page in the linear address is
legacy code.
We allocate the bitmap only when the application requests it.
Most applications do not nee
From: "H.J. Lu"
Add ENDBR64 to vsyscall entry points.
Signed-off-by: H.J. Lu
---
arch/x86/entry/vsyscall/vsyscall_emu_64.S | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/entry/vsyscall/vsyscall_emu_64.S
b/arch/x86/entry/vsyscall/vsyscall_emu_64.S
index c9596a9af159..085
From: "H.J. Lu"
Add ENDBR32 to vsyscall entry point.
Signed-off-by: H.J. Lu
---
arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/entry/vdso/vdso32/system_call.S
b/arch/x86/entry/vdso/vdso32/system_call.S
index 263d7433dea8..2fc8141fff4e
Add REGSET_CET64/REGSET_CET32 to get/set CET MSRs:
IA32_U_CET (user-mode CET settings),
IA32_PL3_SSP (user-mode shadow stack),
IA32_PL0_SSP (kernel-mode shadow stack),
IA32_PL1_SSP (ring-1 shadow stack),
IA32_PL2_SSP (ring-2 shadow stack).
Signed-off-by: Yu-cheng Yu
---
arch
The user-mode indirect branch tracking support is done mostly by
GCC to insert ENDBR64/ENDBR32 instructions at branch targets.
The kernel provides CPUID enumeration, feature MSR setup and
the allocation of legacy bitmap.
Signed-off-by: Yu-cheng Yu
---
arch/x86/Kconfig | 16
arc
Update ARCH_X86_CET_STATUS and ARCH_X86_CET_DISABLE to include
Indirect Branch Tracking features.
Introduce:
arch_prctl(ARCH_X86_CET_GET_LEGACY_BITMAP, unsigned long *addr)
Enable the Indirect Branch Tracking legacy code bitmap.
Allocate the bitmap if the task does not have one.
The
Add user-mode indirect branch tracking enabling/disabling
and supporting routines.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/cet.h | 8 ++
arch/x86/include/asm/disabled-features.h | 8 +-
arch/x86/kernel/cet.c| 31
When Shadow Stack is enabled, the [R/O + PAGE_DIRTY_HW] setting is
reserved only for the Shadow Stack. For non-Shadow Stack R/O PTEs,
we use [R/O + PAGE_DIRTY_SW].
When a PTE goes from [R/W + PAGE_DIRTY_HW] to [R/O + PAGE_DIRTY_SW],
it could become a transient Shadow Stack PTE in two cases.
The
From: "H.J. Lu"
When Intel indirect branch tracking is enabled, functions in vDSO which
may be called indirectly must have endbr32 or endbr64 as the first
instruction. Compiler must support -fcf-protection=branch so that it
can be used to compile vDSO.
Signed-off-by: H.J. Lu
---
arch/x86/entr
This patch adds basic shadow stack enabling/disabling routines.
A task's shadow stack is allocated from memory with VM_SHSTK
flag set and read-only protection. The shadow stack is
allocated to a fixed size of RLIMIT_STACK.
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/cet.h
A RO and dirty PTE exists in the following cases:
(a) A page is modified and then shared with a fork()'ed child;
(b) A R/O page that has been COW'ed;
(c) A SHSTK page.
The processor does not read the dirty bit for (a) and (b), but
checks the dirty bit for (c). To prevent the use of non-SHSTK
mem
Look in .note.gnu.property of an ELF file and check if Indirect
Branch Tracking needs to be enabled for the task.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/uapi/asm/elf_property.h | 1 +
arch/x86/kernel/elf.c| 5 +
2 files changed, 6 insertio
There are a few places that need do_mmap() with mm->mmap_sem held.
Create an in-line function for that.
Signed-off-by: Yu-cheng Yu
---
include/linux/mm.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f658923e76ad..de55f36785
Add control transfer terminating instructions:
ENDBR64/ENDBR32:
Mark a valid 64/32-bit control transfer endpoint.
Signed-off-by: Yu-cheng Yu
---
arch/x86/lib/x86-opcode-map.txt | 13 +++--
tools/objtool/arch/x86/lib/x86-opcode-map.txt | 13 +++--
2 files change
WRUSS is a new kernel-mode instruction but writes directly to user
shadow stack memory. This is used to construct a return address on
the shadow stack for the signal handler.
This instruction can fault if the user shadow stack is invalid shadow
stack memory. In that case, the kernel does a fixup
The indirect branch tracking legacy bitmap takes a large address
space. This causes may_expand_vm() failure on the address limit
check. For a IBT-enabled task, add the bitmap size to the
address limit.
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/mmu_context.h | 7 +++
mm/mmap.c
can_follow_write_pte/pmd look for the (RO & DIRTY) PTE/PMD to
verify an exclusive RO page still exists after a broken COW.
A shadow stack PTE is RO & PAGE_DIRTY_SW when it is shared,
otherwise RO & PAGE_DIRTY_HW.
Introduce pte_exclusive() and pmd_exclusive() to also verify a
shadow stack PTE is e
The previous version of CET Branch Tracking/PTRACE patches is at the following
link:
https://lkml.org/lkml/2018/9/21/773
Summary of changes from v4:
Add ENDBR32/ENDBR64 to vsyscall assembly code.
Small cleanups.
Small fixes in IBT bitmap allocation.
From the discussion of IBT bitmap s
We are going to create _PAGE_DIRTY_SW for non-hardware, memory
management purposes. Rename _PAGE_DIRTY to _PAGE_DIRTY_HW and
_PAGE_BIT_DIRTY to _PAGE_BIT_DIRTY_HW to make these PTE dirty
bits more clear. There are no functional changes in this
patch.
Signed-off-by: Yu-cheng Yu
---
arch/x86/inc
VM_SHSTK indicates a shadow stack memory area.
The shadow stack is implemented only for the 64-bit kernel.
Signed-off-by: Yu-cheng Yu
---
fs/proc/task_mmu.c | 3 +++
include/linux/mm.h | 8
2 files changed, 11 insertions(+)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 5ea
Create a guard area between VMAs to detect memory corruption.
Signed-off-by: Yu-cheng Yu
---
include/linux/mm.h | 30 --
mm/Kconfig | 7 +++
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 041
Control Flow Enforcement (CET) MSRs are XSAVES system/supervisor
states. To support CET, we introduce XSAVES system states first.
XSAVES is a "supervisor" instruction and, comparing to XSAVE, saves
additional "supervisor" states that can be modified only from CPL 0.
However, these states are per-
Explain how CET works and the no_cet_shstk/no_cet_ibt kernel
parameters.
Signed-off-by: Yu-cheng Yu
---
.../admin-guide/kernel-parameters.txt | 6 +
Documentation/index.rst | 1 +
Documentation/x86/index.rst | 11 +
Documentation/x86/intel_cet
Update _PAGE_DIRTY to _PAGE_DIRTY_BITS in split_2MB_gtt_entry().
In order to support Control Flow Enforcement (CET), _PAGE_DIRTY
is now _PAGE_DIRTY_HW or _PAGE_DIRTY_SW.
Signed-off-by: Yu-cheng Yu
---
drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
If a page fault is triggered by a shadow stack access (e.g.
call/ret) or shadow stack management instructions (e.g.
wrussq), then bit[6] of the page fault error code is set.
In access_error(), we check if a shadow stack page fault
is within a shadow stack memory area.
Signed-off-by: Yu-cheng Yu
Introduce Kconfig option X86_INTEL_SHADOW_STACK_USER.
An application has shadow stack protection when all the following are
true:
(1) The kernel has X86_INTEL_SHADOW_STACK_USER enabled,
(2) The running processor supports the shadow stack,
(3) The application is built with shadow stack enabl
A control protection exception is triggered when a control flow transfer
attempt violated shadow stack or indirect branch tracking constraints.
For example, the return address for a RET instruction differs from the
safe copy on the shadow stack; or a JMP instruction arrives at a non-
ENDBR instruct
Control Flow Enforcement (CET) MSRs are XSAVES system states. To
support CET, we introduce XSAVES system states first.
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/fpu/internal.h | 3 +-
arch/x86/include/asm/fpu/xstate.h | 4 +-
arch/x86/kernel/fpu/core.c | 6 +-
arch/x86/k
To prevent function call/return spills into the next shadow stack
area, we do not merge shadow stack areas.
Signed-off-by: Yu-cheng Yu
---
mm/mmap.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 5f2b2b184c60..b85292014ec9 100644
--- a/mm/mmap.c
+++ b/mm/mm
Intel Control-flow Enforcement Technology (CET) introduces the
following MSRs into the XSAVES system states.
IA32_U_CET (user-mode CET settings),
IA32_PL3_SSP (user-mode shadow stack),
IA32_PL0_SSP (kernel-mode shadow stack),
IA32_PL1_SSP (ring-1 shadow stack),
IA32_PL2_SSP (ri
The previous version of CET Shadow Stack patches is at the following
link:
https://lkml.org/lkml/2018/9/21/776
Summary of changes from v4:
Clean up XSAVES system states patches.
Update control protection fault handler to provide error code to user.
Add CONFIG_VM_AREA_GUARD.
Clean up ar
Add CPUIDs 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
---
arch/x86/include/asm/cpufeatures.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/include
On Wed, Oct 10, 2018 at 10:56:32PM +0800, John Garry wrote:
> This patch fixes a couple of punctuation nits which can make the document
> more correct and readable.
>
> Also missing "()" are added to some function references for consistency.
While there's nothing wrong here, any chance you want t
On Thu, 11 Oct 2018, Kees Cook wrote:
> On Wed, Oct 10, 2018 at 8:45 PM, James Morris wrote:
> > On Wed, 10 Oct 2018, Kees Cook wrote:
> >
> >> v5:
> >> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> >> - dropped various Reviewed-bys due to rather large refactoring
> >
On Thu, Oct 11, 2018 at 08:29:10AM -0700, Matthew Wilcox wrote:
> On Wed, Oct 10, 2018 at 10:56:32PM +0800, John Garry wrote:
> > This patch fixes a couple of punctuation nits which can make the document
> > more correct and readable.
> >
> > Also missing "()" are added to some function references
On Thu, Oct 11, 2018 at 2:43 PM Suzuki K Poulose wrote:
>
> Hi Ganapatrao,
>
> On 11/10/18 07:39, Ganapatrao Kulkarni wrote:
> >>> +
> >>> +/*
> >>> + * We must NOT create groups containing events from multiple hardware
> >>> PMUs,
> >>> + * although mixing different software and hardware PMUs is
[+cc Jon Mason]
On Wed, Oct 10, 2018 at 10:42:55PM +0800, Wesley Sheng wrote:
> From: Wesley Yung
>
> The ntb_hw_switchtec driver has requirements on kernel configuration
> so we add these notes to the documentation and also clean up a few
> other sentences in the documentation.
>
> Signed-off
On 2018-10-11 10:27 a.m., Bjorn Helgaas wrote:
> I'm not sure who should really own this file:
>
> $ ./scripts/get_maintainer.pl -f Documentation/switchtec.txt
> Kurt Schwemmer (maintainer:PCI DRIVER FOR
> MICROSEMI SWITCHTEC)
> Logan Gunthorpe (maintainer:PCI DRIVER FOR MICROSEMI
> S
On Thu, Oct 11, 2018 at 08:14:57AM -0700, Yu-cheng Yu wrote:
> Add CPUIDs for Control Flow Enforcement Technology (CET).
This is not "CPUIDs" but feature flags. Fix the subject too pls.
> CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
> CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect branch tracking
>
> S
On Thu, 2018-10-11 at 18:43 +0200, Borislav Petkov wrote:
> On Thu, Oct 11, 2018 at 08:14:57AM -0700, Yu-cheng Yu wrote:
> > Add CPUIDs for Control Flow Enforcement Technology (CET).
>
> This is not "CPUIDs" but feature flags. Fix the subject too pls.
I will fix it.
Thanks,
Yu-cheng
On Thu, Oct 11, 2018 at 10:42:46AM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> There are still two format specifiers that print unhanced kernel
> addresses, potentially leaking sensitive information regarding the
> kernel layout in memory.
>
> This patch series fixes this by printing has
Hi Ganpatrao,
On 11/10/18 17:06, Ganapatrao Kulkarni wrote:
On Thu, Oct 11, 2018 at 2:43 PM Suzuki K Poulose wrote:
Hi Ganapatrao,
On 11/10/18 07:39, Ganapatrao Kulkarni wrote:
+
+/*
+ * We must NOT create groups containing events from multiple hardware PMUs,
+ * although mixing different s
On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook wrote:
> v5:
> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> - dropped various Reviewed-bys due to rather large refactoring
Here's a tl;dr of the behavioral changes...
Right now, we have:
- hard-coded special LSM: capability
On Thu, 11 Oct 2018, Peter Zijlstra wrote:
> On Thu, Oct 11, 2018 at 08:29:10AM -0700, Matthew Wilcox wrote:
>> On Wed, Oct 10, 2018 at 10:56:32PM +0800, John Garry wrote:
>> > This patch fixes a couple of punctuation nits which can make the document
>> > more correct and readable.
>> >
>> > Also
On 10/11/2018 08:14 AM, Yu-cheng Yu wrote:
> The previous version of CET Shadow Stack patches is at the following
> link:
>
> https://lkml.org/lkml/2018/9/21/776
Why are you posting these? Do you want more review? Do you simply want
the series applied?
On Wed, Oct 10, 2018 at 05:24:12PM -0700, Nicolin Chen wrote:
> Hi Guenter,
>
> On Wed, Oct 10, 2018 at 04:43:00PM -0700, Guenter Roeck wrote:
> > > > The effort to do all this using CPU cycles would in most if not all
> > > > cases
> > > > outweigh any perceived power savings. As such, I just do
On Thu, 2018-10-11 at 12:21 -0700, Dave Hansen wrote:
> On 10/11/2018 08:14 AM, Yu-cheng Yu wrote:
> > The previous version of CET Shadow Stack patches is at the following
> > link:
> >
> > https://lkml.org/lkml/2018/9/21/776
>
> Why are you posting these? Do you want more review? Do you simp
On Thu, Oct 11, 2018 at 12:31:52PM -0700, Guenter Roeck wrote:
> > One more question here, and this might sound a bit abuse of using
> > the existing hwmon ABI: would it sound plausible to you that the
> > driver powers down the chip when all three channels get disabled
> > via in[123]_enable node
Hi Nicolin,
On Thu, Oct 11, 2018 at 12:36:59PM -0700, Nicolin Chen wrote:
> On Thu, Oct 11, 2018 at 12:31:52PM -0700, Guenter Roeck wrote:
>
> > > One more question here, and this might sound a bit abuse of using
> > > the existing hwmon ABI: would it sound plausible to you that the
> > > driver
On Thu, Oct 11, 2018 at 12:50:25PM -0700, Guenter Roeck wrote:
> Hi Nicolin,
>
> On Thu, Oct 11, 2018 at 12:36:59PM -0700, Nicolin Chen wrote:
> > On Thu, Oct 11, 2018 at 12:31:52PM -0700, Guenter Roeck wrote:
> >
> > > > One more question here, and this might sound a bit abuse of using
> > > > t
On Thu, Oct 11, 2018 at 5:20 PM Yu-cheng Yu wrote:
> Create a guard area between VMAs to detect memory corruption.
[...]
> +config VM_AREA_GUARD
> + bool "VM area guard"
> + default n
> + help
> + Create a guard area between VM areas so that access beyond
> + limi
On 10/11/2018 08:15 AM, Yu-cheng Yu wrote:
> Create a guard area between VMAs to detect memory corruption.
This is a pretty major change that has a bunch of end-user implications.
It's not dependent on any debugging options and can't be turned on/off
by individual apps, at runtime, or even at boo
On Thu, 2018-10-11 at 22:39 +0200, Jann Horn wrote:
> On Thu, Oct 11, 2018 at 5:20 PM Yu-cheng Yu wrote:
> > Create a guard area between VMAs to detect memory corruption.
>
> [...]
> > +config VM_AREA_GUARD
> > + bool "VM area guard"
> > + default n
> > + help
> > + Crea
On Thu, Oct 11, 2018 at 1:39 PM Jann Horn wrote:
>
> On Thu, Oct 11, 2018 at 5:20 PM Yu-cheng Yu wrote:
> > Create a guard area between VMAs to detect memory corruption.
> [...]
> > +config VM_AREA_GUARD
> > + bool "VM area guard"
> > + default n
> > + help
> > + Create
‐‐‐ Original Message ‐‐‐
On Thursday, October 11, 2018 7:57 PM, Kees Cook wrote:
> On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook keesc...@chromium.org wrote:
>
> > v5:
> >
> > - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> > - dropped various Reviewed-bys due t
On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
wrote:
> On Thursday, October 11, 2018 7:57 PM, Kees Cook
> wrote:
>> To switch to SELinux at boot time with
>> "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>> work:
>>
>> selinux=1 security=selinux
>>
>>
On 10/11/2018 04:09 PM, Kees Cook wrote:
> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
> wrote:
>> On Thursday, October 11, 2018 7:57 PM, Kees Cook
>> wrote:
>>> To switch to SELinux at boot time with
>>> "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>>> w
‐‐‐ Original Message ‐‐‐
On Friday, October 12, 2018 1:09 AM, Kees Cook wrote:
> We've had things sort of like this proposed, but if you can convince
> James and others, I'm all for it. I think the standing objection from
> James and John about this is that the results of booting with
> "
‐‐‐ Original Message ‐‐‐
On Friday, October 12, 2018 1:48 AM, John Johansen
wrote:
> On 10/11/2018 04:09 PM, Kees Cook wrote:
>
> > On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
> > golden_mille...@protonmail.ch wrote:
> >
> > > On Thursday, October 11, 2018 7:57 PM, Kees Cook keesc...@
On 10/11/2018 04:53 PM, Jordan Glover wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 1:09 AM, Kees Cook wrote:
>
>> We've had things sort of like this proposed, but if you can convince
>> James and others, I'm all for it. I think the standing objection from
>> James and J
On 10/11/2018 05:11 PM, Jordan Glover wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 1:48 AM, John Johansen
> wrote:
>
>> On 10/11/2018 04:09 PM, Kees Cook wrote:
>>
>>> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
>>> golden_mille...@protonmail.ch wrote:
>>>
On T
79 matches
Mail list logo
