On Thu, May 06, 2021 at 11:47:47AM -0700, James Bottomley wrote:
> On Thu, 2021-05-06 at 10:33 -0700, Kees Cook wrote:
> > On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
> [...]
> > > > I think that a very complete description of the threats which
> &
this in the first
bullet point (i.e. "cross-process secret userspace memory exposures,
even in the face of privileged processes")?
>3. enhanced protection (in conjunction with all the other in-kernel
> attack prevention systems) against ROP attacks.
Same h
; > +#define TAINT_FLAGS_COUNT 19
> > #define TAINT_FLAGS_MAX((1UL << TAINT_FLAGS_COUNT)
> > - 1)
> >
> > struct taint_flag {
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index 332736a72a58..dff22bd80eaf 100644
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -386,6 +386,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT]
> > = {
> > [ TAINT_LIVEPATCH ] = { 'K', ' ', true },
> > [ TAINT_AUX ] = { 'X', ' ', true },
> > [ TAINT_RANDSTRUCT ]= { 'T', ' ', true },
> > + [ TAINT_RAW_PASSTHROUGH ] = { 'H', ' ', true },
> > };
> >
> > /**
> > --
> > 2.30.0
> >
--
Kees Cook
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
y things that actually manipulate these areas
should gain temporary PK access):
- Page Tables themselves
- Identity mapping
- The "read-only at rest" stuff, though it'll need special plumbing to
make it work with the slab allocator, etc (more like the later "static
allocat
; >
> > instance = kzalloc(struct_size(instance, mapping, count), GFP_KERNEL);
> >
> > This code was detected with the help of Coccinelle.
> >
> > Signed-off-by: Gustavo A. R. Silva
FWIW,
Reviewed-by: Kees Cook
-Kees
> > ---
> > drivers/nv
On Fri, May 17, 2019 at 10:28:48AM -0700, Dan Williams wrote:
> On Fri, May 17, 2019 at 8:57 AM Kees Cook wrote:
> >
> > On Fri, May 17, 2019 at 08:08:27AM -0700, Dan Williams wrote:
> > > As far as I can see it's mostly check_heap_object() that is the
> > >
On Fri, May 17, 2019 at 04:14:03PM +, David Laight wrote:
> From: Kees Cook
> > Sent: 17 May 2019 16:54
> ...
> > > I've changed some of our code to use __get_user() to avoid
> > > these stupid overheads.
> >
> > __get_user() skips even access_o
ees, please advise.
The intention is mainly for copies that haven't had explicit bounds
checking already performed on them, yes. Is there something getting
checked out of the slab, or is it literally just the overhead of doing
the "is this sla
size()
that is globally applicable, sure, let's do it.
I'm still not clear from this thread about the case that is getting
tripped/slowed? If you're already doing bounds checks somewhere else
and there isn't a chance for the pointer or size to change, then yeah,
it seems safe to s
gt; > This would be technically conforming with TAP13 and is consistent with
> > what some kselftests have done.
This is what I fixed kselftest to actually do (it wasn't doing correct
TAP13), and Shuah is testing the series now:
https://git.kernel.org/pub/scm/linux/
On Tue, Jan 8, 2019 at 3:54 PM Dan Williams wrote:
>
> On Tue, Jan 8, 2019 at 3:34 PM Kees Cook wrote:
> >
> > On Tue, Jan 8, 2019 at 3:28 PM Dan Williams
> > wrote:
> > > Ah, thanks for the report! The key difference is that you don't define
> > >
vdimm->sec.ops->freeze || nvdimm->sec.ops->disable
Okay, cool. I wasn't sure if that test needed a deeper check. :)
Fixes: 37833fb7989a9 ("acpi/nfit, libnvdimm: Add freeze security
support to Intel nvdimm")
Tested-by: Kees Cook
Thanks!
--
Kees Cook
___
9 ("acpi/nfit, libnvdimm: Add freeze security
support to Intel nvdimm") was where it started, but I didn't actually
bisect.
--
Kees Cook
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Mon, Apr 10, 2017 at 11:22 AM, Jeff Moyer wrote:
> Kees Cook writes:
>
>> On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
>>> Kees Cook writes:
>>>
>>>> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>>>>> Hi,
>>>
On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
> Kees Cook writes:
>
>> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>>> Hi,
>>>
>>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>>> regions") caus
I know nothing about pmem (yet), I bet there is
some oversight in what's happening with how KASLR scans for available
memory areas. I'll carve out some time next week to look into this.
-Kees
--
Kees Cook
Pixel Security
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
e those regions from the set of valid address range to insert
> the uncompressed kernel image. The nn@ss ranges will be skipped by the
> mem_avoid set since it indicates memory useable.
>
> Signed-off-by: Dave Jiang
Thanks for the updates!
Acked-by: Kees Cook
-Kees
> ---
>
long image_size)
{
int i;
unsigned long addr;
/* Check if we had too many memmaps. */
if (memmap_too_large) {
debug_putstr("Aborted e820 scan (more than 4 memmap=
arguments)!\n");
return 0;
}
On Tue, Nov 22, 2016 at 11:01 AM, Dan Williams wrote:
> On Tue, Nov 22, 2016 at 10:54 AM, Kees Cook wrote:
>> On Tue, Nov 22, 2016 at 9:26 AM, Dan Williams
>> wrote:
>>> [ replying for Dave since he's offline today and tomorrow ]
>>>
>>> On Tu
>>> char *ptr;
>>> + char arg[38];
>>
>> Where does the magic '38' come from?
>>
>>> + unsigned long long memmap_start, memmap_size;
>>>
>>> /*
>>>* Avoid the region that is unsafe to overlap during
>>> @@ -195,6 +230,16 @@ static void mem_avoid_init(unsigned long input,
>>> unsigned long input_size,
>>> add_identity_map(mem_avoid[MEM_AVOID_BOOTPARAMS].start,
>>>mem_avoid[MEM_AVOID_BOOTPARAMS].size);
>>>
>>> + /* see if we have any memmap areas */
>>> + if (cmdline_find_option("memmap", arg, sizeof(arg)) > 0) {
>>> + int rc = parse_memmap(arg, &memmap_start, &memmap_size);
>>> +
>>> + if (!rc) {
>>> + mem_avoid[MEM_AVOID_MEMMAP].start = memmap_start;
>>> + mem_avoid[MEM_AVOID_MEMMAP].size = memmap_size;
>>> + }
>>> + }
>>> +
>>
>> This only handles a single (first) memmap argument, is that sufficient?
>
> No, you're right, we need to handle multiple ranges. Since the
> mem_avoid array is statically allocated perhaps we can handle up to 4
> memmap= entries, but past that point disable kaslr for that boot?
Yeah, that seems fine to me. I assume it's rare to have 4?
-Kees
--
Kees Cook
Nexus Security
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
20 matches
Mail list logo
