On Tue, Apr 4, 2017 at 5:22 PM, Linus Torvalds
wrote:
> On Tue, Apr 4, 2017 at 3:55 PM, Linus Torvalds
> wrote:
>>
>> I already explained what the likely fix is: make devmem_is_allowed()
>> return a ternary value, so that those things that *do* read the BIOS
>> area can just continue to do so, bu
On Tue, Apr 4, 2017 at 3:55 PM, Linus Torvalds
wrote:
>
> I already explained what the likely fix is: make devmem_is_allowed()
> return a ternary value, so that those things that *do* read the BIOS
> area can just continue to do so, but they see zeroes for the parts
> that the kernel has taken ove
On Tue, Apr 4, 2017 at 3:55 PM, Linus Torvalds
wrote:
> On Tue, Apr 4, 2017 at 3:37 PM, Kees Cook wrote:
>>
>> For one of my systems, I see something like this:
>>
>> -0fff : reserved
>> 1000-0008efff : System RAM
>> 0008f000-0008 : reserved
>> 0009-0009f7ff : System RAM
>
On Tue, Apr 4, 2017 at 3:37 PM, Kees Cook wrote:
>
> For one of my systems, I see something like this:
>
> -0fff : reserved
> 1000-0008efff : System RAM
> 0008f000-0008 : reserved
> 0009-0009f7ff : System RAM
> 0009f800-0009 : reserved
That's fairly normal.
> I note t
On Fri, Mar 31, 2017 at 12:32 PM, Tommi Rantala
wrote:
> On 31.03.2017 21:26, Linus Torvalds wrote:
>>
>> Hmm. Thinking more about this, we do allow access to the first 1MB of
>> physical memory unconditionally (see devmem_is_allowed() in
>> arch/x86/mm/init.c). And I think we only _reserve_ the f
On Fri, Mar 31, 2017 at 11:26 AM, Linus Torvalds
wrote:
> On Fri, Mar 31, 2017 at 10:32 AM, Kees Cook wrote:
>>
>> How is 8809 both in the direct mapping and a slab object?
>
> I think this is just very regular /dev/mem behavior, that is hidden by
> the fact that the *normal* case for
On 31.03.2017 21:26, Linus Torvalds wrote:
Hmm. Thinking more about this, we do allow access to the first 1MB of
physical memory unconditionally (see devmem_is_allowed() in
arch/x86/mm/init.c). And I think we only _reserve_ the first 64kB or
something. So I guess even STRICT_DEVMEM isn't actually
On Fri, Mar 31, 2017 at 11:03 AM, Dave Jones wrote:
> On Fri, Mar 31, 2017 at 10:32:04AM -0700, Kees Cook wrote:
>
> > > > > > > Full dmesg output here: https://pastebin.com/raw/Kur2mpZq
> > > > > > >
> > > > > > > [ 51.418954] usercopy: kernel memory exposure attempt
> detected from
>
On Fri, Mar 31, 2017 at 10:32 AM, Kees Cook wrote:
>
> How is 8809 both in the direct mapping and a slab object?
I think this is just very regular /dev/mem behavior, that is hidden by
the fact that the *normal* case for /dev/mem is all to reserved RAM,
which will never be a slab objec
On Fri, Mar 31, 2017 at 10:32:04AM -0700, Kees Cook wrote:
> > > > > > Full dmesg output here: https://pastebin.com/raw/Kur2mpZq
> > > > > >
> > > > > > [ 51.418954] usercopy: kernel memory exposure attempt detected
> > from
> > > > > > 8809 (dma-kmalloc-256) (4096 byt
On Fri, Mar 31, 2017 at 10:17 AM, Dave Jones wrote:
> On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
> > On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones
> wrote:
> > > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> > > > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
> On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones wrote:
> > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> > > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> > > wrote:
> > > > Hi,
> > > >
> > > > Running:
> >
On 31.03.2017 08:40, Tommi Rantala wrote:
The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely. Tommi, can you put strace of x86info
-mp somewhere?
That will confirm/deny whether we're at least asking the kernel to do
sane things.
Indeed the bug ha
On 30.03.2017 20:44, Laura Abbott wrote:
On 03/30/2017 10:37 AM, Kees Cook wrote:
Reads out of /dev/mem should be restricted to non-RAM on Fedora, yes?
Tommi, do your kernels have CONFIG_STRICT_DEVMEM=y ?
-Kees
CONFIG_STRICT_DEVMEM should be on in all Fedora kernels.
Yes, the fedora kern
On 30.03.2017 23:01, Dave Jones wrote:
On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
> On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones wrote:
> > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> > > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> > > wrote:
> >
On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
> On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones wrote:
> > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> > > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> > > wrote:
> > > > Hi,
> > > >
> > > > Running:
> >
On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones wrote:
> On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> > wrote:
> > > Hi,
> > >
> > > Running:
> > >
> > > $ sudo x86info -a
> > >
> > > On this HP ZBook 15 G3 laptop kills t
On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> wrote:
> > Hi,
> >
> > Running:
> >
> > $ sudo x86info -a
> >
> > On this HP ZBook 15 G3 laptop kills the x86info process with segfault and
> > produces the following kernel B
On 03/30/2017 10:37 AM, Kees Cook wrote:
> On Thu, Mar 30, 2017 at 10:27 AM, Laura Abbott wrote:
>> On 03/30/2017 09:45 AM, Kees Cook wrote:
>>> On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
>>> wrote:
Hi,
Running:
$ sudo x86info -a
On this HP ZBook 15 G3 la
On Thu, Mar 30, 2017 at 10:27 AM, Laura Abbott wrote:
> On 03/30/2017 09:45 AM, Kees Cook wrote:
>> On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
>> wrote:
>>> Hi,
>>>
>>> Running:
>>>
>>> $ sudo x86info -a
>>>
>>> On this HP ZBook 15 G3 laptop kills the x86info process with segfault and
>>>
On 03/30/2017 09:45 AM, Kees Cook wrote:
> On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> wrote:
>> Hi,
>>
>> Running:
>>
>> $ sudo x86info -a
>>
>> On this HP ZBook 15 G3 laptop kills the x86info process with segfault and
>> produces the following kernel BUG.
>>
>> $ git describe
>> v4.1
On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> wrote:
> > Hi,
> >
> > Running:
> >
> > $ sudo x86info -a
> >
> > On this HP ZBook 15 G3 laptop kills the x86info process with segfault and
> > produces the following kernel BUG.
> >
>
On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
wrote:
> Hi,
>
> Running:
>
> $ sudo x86info -a
>
> On this HP ZBook 15 G3 laptop kills the x86info process with segfault and
> produces the following kernel BUG.
>
> $ git describe
> v4.11-rc4-40-gfe82203
>
> It is also reproducible with the f
Hi,
Running:
$ sudo x86info -a
On this HP ZBook 15 G3 laptop kills the x86info process with segfault
and produces the following kernel BUG.
$ git describe
v4.11-rc4-40-gfe82203
It is also reproducible with the fedora kernel: 4.9.14-200.fc25.x86_64
Full dmesg output here: https://past
24 matches
Mail list logo