On 1/14/21 10:46 AM, Borislav Petkov wrote:
> On Thu, Jan 14, 2021 at 08:27:43AM -0800, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> Defining DEBUG should only be done in development.
>> So remove DEBUG.
>>
>> Signed-off-by: Tom Rix
>> ---
>&
On Thu, Jan 14, 2021 at 08:27:43AM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> Defining DEBUG should only be done in development.
> So remove DEBUG.
>
> Signed-off-by: Tom Rix
> ---
> arch/x86/kernel/cpu/mtrr/generic.c | 1 -
> 1 file changed, 1 deletion(-)
From: Tom Rix
Defining DEBUG should only be done in development.
So remove DEBUG.
Signed-off-by: Tom Rix
---
arch/x86/kernel/cpu/mtrr/generic.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index a29997e6cf9e
From: Ying-Tsun Huang
commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream.
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is returned. These condition checks are for ensuring the input memory
From: Ying-Tsun Huang
commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream.
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is returned. These condition checks are for ensuring the input memory
From: Ying-Tsun Huang
commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream.
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is returned. These condition checks are for ensuring the input memory
From: Ying-Tsun Huang
commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream.
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is returned. These condition checks are for ensuring the input memory
From: Ying-Tsun Huang
commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream.
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is returned. These condition checks are for ensuring the input memory
From: Ying-Tsun Huang
commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream.
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is returned. These condition checks are for ensuring the input memory
Committer: Borislav Petkov
CommitterDate: Wed, 06 Jan 2021 13:01:13 +01:00
x86/mtrr: Correct the range check before performing MTRR type lookups
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is
Committer: Borislav Petkov
CommitterDate: Wed, 30 Dec 2020 08:56:35 +01:00
x86/mtrr: Convert comma to semicolon
Replace a comma between expression statements with a semicolon.
Signed-off-by: Zheng Yongjun
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/20201216131159.14393-1
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c
b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 5bd011737272
In mtrr_type_lookup, if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, write-back attribute
is returned. These condition checks are for ensuring the input memory
address region is mapped to the physical memory actually.
However, if the end address is
On Fri, 11 Dec 2020, Borislav Petkov wrote:
> [CAUTION: External Email]
>
> On Mon, Dec 07, 2020 at 02:12:26PM +0800, Ying-Tsun Huang wrote:
> > In mtrr_type_lookup, if the input memory address region is not in the
> > MTRR, over 4GB, and not over the top of memory,
On Mon, Dec 07, 2020 at 02:12:26PM +0800, Ying-Tsun Huang wrote:
> In mtrr_type_lookup, if the input memory address region is not in the
> MTRR, over 4GB, and not over the top of memory, write-back attribute
> is returned. These condition checks are for ensuring the input memory
> ad
In mtrr_type_lookup, if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, write-back attribute
is returned. These condition checks are for ensuring the input memory
address region is mapped to the physical memory actually.
However, if the end address is
:00
Committer: Borislav Petkov
CommitterDate: Mon, 02 Nov 2020 19:58:53 +01:00
x86/mtrr: Fix a kernel-doc markup
Kernel-doc markup should use this format:
identifier - description
Fix it.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Borislav Petkov
Link:
https
Kernel-doc markup should use this format:
identifier - description
Signed-off-by: Mauro Carvalho Chehab
---
arch/x86/kernel/cpu/mtrr/mtrr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
index
:25PM -0600, Tuowen Zhao wrote:
> > > > > Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> > > > > in MTRR. This will cause the system to hang during boot. If possible,
> > > > > this bug could be corrected with a firmware update.
e-combining BAR for intel-lpss-pci
> > > > in MTRR. This will cause the system to hang during boot. If possible,
> > > > this bug could be corrected with a firmware update.
> > > >
> > > > Previous version: https://lkml.org/lkml/2019/10/14/575
> >
On Thu, Oct 17, 2019 at 08:31:16AM +0100, Lee Jones wrote:
> On Thu, 17 Oct 2019, Andy Shevchenko wrote:
> > On Wed, Oct 16, 2019 at 03:06:25PM -0600, Tuowen Zhao wrote:
> > > Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> > > in MTRR. This wi
On Thu, 17 Oct 2019, Andy Shevchenko wrote:
> On Wed, Oct 16, 2019 at 03:06:25PM -0600, Tuowen Zhao wrote:
> > Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> > in MTRR. This will cause the system to hang during boot. If possible,
> > this bug coul
On Wed, Oct 16, 2019 at 03:06:25PM -0600, Tuowen Zhao wrote:
> Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> in MTRR. This will cause the system to hang during boot. If possible,
> this bug could be corrected with a firmware update.
>
> Previous
Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
in MTRR. This will cause the system to hang during boot. If possible,
this bug could be corrected with a firmware update.
Previous version: https://lkml.org/lkml/2019/10/14/575
Changes from previous version:
* implement
xtra permissions bits. This supports the KVM XO feature.
> >
> > TODO: Since MTRR is emulated using EPT permissions, the XO version of
> > the gpa range will not inherrit the MTRR type with this implementation.
> > There shouldn't be any legacy use of KVM XO,
On Thu, Oct 03, 2019 at 02:23:48PM -0700, Rick Edgecombe wrote:
> Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
> guests view of gfn is used when high bits of the physical memory are
> used as extra permissions bits. This supports the KVM XO feature.
>
> TODO
Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
guests view of gfn is used when high bits of the physical memory are
used as extra permissions bits. This supports the KVM XO feature.
TODO: Since MTRR is emulated using EPT permissions, the XO version of
the gpa range will not
; > > > Make PAT(Page Attribute Table) independent from
> > > > MTRR(Memory Type Range Register).
> > > > Some environments (mainly virtual ones) support only PAT, but not MTRR
> > > > because PAT replaces MTRR.
> > > > It's tricky and
On Tue, Aug 13, 2019 at 12:49:20AM -0700, Isaku Yamahata wrote:
> In addition to Xen, KVM+qemu can enable/disable MTRR, PAT independently.
> So user may want to disable MTRR to reduce attack surface.
No, no "user may want" etc vague formulations. Just because some virt
thin
On Fri, Aug 09, 2019 at 07:51:17PM +,
"Kani, Toshi" wrote:
> On Fri, 2019-08-09 at 09:06 +0200, Borislav Petkov wrote:
> > On Thu, Aug 08, 2019 at 08:54:17PM -0700, Isaku Yamahata wrote:
> > > Make PAT(Page Attribute Table) independent from
> > > MTRR(Me
On Fri, 2019-08-09 at 09:06 +0200, Borislav Petkov wrote:
> On Thu, Aug 08, 2019 at 08:54:17PM -0700, Isaku Yamahata wrote:
> > Make PAT(Page Attribute Table) independent from
> > MTRR(Memory Type Range Register).
> > Some environments (mainly virtual ones) support o
On Thu, Aug 08, 2019 at 08:54:17PM -0700, Isaku Yamahata wrote:
> Make PAT(Page Attribute Table) independent from
> MTRR(Memory Type Range Register).
> Some environments (mainly virtual ones) support only PAT, but not MTRR
> because PAT replaces MTRR.
> It's tricky and no gain
Make PAT(Page Attribute Table) independent from
MTRR(Memory Type Range Register).
Some environments (mainly virtual ones) support only PAT, but not MTRR
because PAT replaces MTRR.
It's tricky and no gain to support both MTRR and PAT except compatibility.
So some VM technologies don't su
This is a preparation for make PAT(Page Attribute Table) independent
from MTRR(Memory Type Range Register).
It renames prefix of common functions in mtrr/generic.c from mtrr_ to
mtrr_pat_ which are commonly used by both MTRR and PAT and moves out
them from mtrr/generic.c to rendezvous.c.
Only
This patch makes PAT(Page Attribute Table) independent from
MTRR(Memory Type Range Register)
Some environments (mainly virtual ones) support only PAT, not MTRR.
It's tricky and no gain to support both MTRR and PAT at the
same time except compatibility because PAT replaces MTRR.
So so
This is a preparation for make PAT(Page Attribute Table) independent
from MTRR(Memory Type Range Register).
It renames prefix of common functions in mtrr.c from mtrr_ to
mtrr_pat_ which are commonly used by both MTRR and PAT and moves out
them from mtrr.c to rendezvous.c.
Only prefix rename and
Commit-ID: 7468a4eae541ce5aff65595aa502aa0a4def6615
Gitweb: https://git.kernel.org/tip/7468a4eae541ce5aff65595aa502aa0a4def6615
Author: Gustavo A. R. Silva
AuthorDate: Mon, 5 Aug 2019 15:17:12 -0500
Committer: Thomas Gleixner
CommitDate: Wed, 7 Aug 2019 15:12:01 +0200
x86: mtrr: cyrix
On Mon, Aug 05, 2019 at 03:17:12PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> Fix the following warning (Building: i386_defconfig i386):
>
> arch/x86/kernel/cpu/mtrr/cyrix.c:99:6: warning: this statement may fall
> t
Commit-ID: fd329f276ecaad7a371d6f91b9bbea031d0c3440
Gitweb: https://git.kernel.org/tip/fd329f276ecaad7a371d6f91b9bbea031d0c3440
Author: Ricardo Neri
AuthorDate: Thu, 27 Jun 2019 19:35:37 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 07:21:00 +0200
x86/mtrr: Skip cache
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also involves flushing
caches and TLBs twice. As a result, the process may take a considerable
amount
This is the second iteration of this patchset. The first iteration can be
viewed here [1].
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also
On Thu, 27 Jun 2019, Ricardo Neri wrote:
> By measuring the execution time of mtrr_aps_init() (from which MTRRs
> in all CPUs are programmed in lock-step at boot), I find savings in the
> time required to program MTRRs as follows:
>
> Platform time-with-wbinvd(ms) time-no-wbin
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also involves flushing
caches and TLBs twice. As a result, the process may take a considerable
amount
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also involves flushing
caches and TLBs twice. As a result, the process may take a considerable
amount
n't), but this fixes
that.
Signed-off-by: Alexandru Ardelean
---
arch/x86/kernel/cpu/mtrr/if.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index 4ec7a5f7b94c..e67820a044cc 100644
--- a/arch/x86/kerne
Commit-ID: c81cd5c08d676483bb09f4809660d2a1abea0062
Gitweb: https://git.kernel.org/tip/c81cd5c08d676483bb09f4809660d2a1abea0062
Author: Bo Yu
AuthorDate: Fri, 8 Feb 2019 07:53:43 -0500
Committer: Thomas Gleixner
CommitDate: Fri, 8 Feb 2019 14:32:33 +0100
x86/mtrr: Remove unused
From: Bo Yu
There is a warning if enable W=1 when compile kernel:
arch/x86/kernel/cpu/mtrr/cleanup.c:299:16: warning: variable ‘second_basek’ set
but not used [-Wunused-but-set-variable]
unsigned long second_basek, second_sizek;
Signed-off-by: Bo Yu
---
arch/x86/kernel/cpu/mtrr/cleanup.c
userspace.
Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use
userspace.
Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use
userspace.
Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use
userspace.
Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use
userspace.
Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use
userspace.
Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use
piler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit
ioctls")
Signed-off-by: Colin Ian King
Signe
piler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit
ioctls")
Signed-off-by: Colin Ian King
Signe
piler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit
ioctls")
Signed-off-by: Colin Ian King
Signe
piler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit
ioctls")
Signed-off-by: Colin Ian King
Signe
piler added padding fields that may be in struct (currently there are
none).
Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit
ioctls")
Signed-off-by: Colin Ian King
Signe
Commit-ID: 32043fa065b51e0b1433e48d118821c71b5cd65d
Gitweb: https://git.kernel.org/tip/32043fa065b51e0b1433e48d118821c71b5cd65d
Author: Colin Ian King
AuthorDate: Tue, 18 Dec 2018 17:29:56 +
Committer: Thomas Gleixner
CommitDate: Wed, 19 Dec 2018 00:00:16 +0100
x86/mtrr: Don&#
Commit-ID: 39dc6f154dac134e4612827cb5283934c1862cb8
Gitweb: https://git.kernel.org/tip/39dc6f154dac134e4612827cb5283934c1862cb8
Author: Pu Wen
AuthorDate: Sun, 23 Sep 2018 17:34:16 +0800
Committer: Borislav Petkov
CommitDate: Thu, 27 Sep 2018 18:28:57 +0200
x86/cpu/mtrr: Support
v Petkov
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
arch/x86/kernel/cpu/mtrr/mtrr.c| 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c
b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 765afd5..3668c5d 100644
--- a/arch/x86/kernel/cpu/mtrr/c
v Petkov
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
arch/x86/kernel/cpu/mtrr/mtrr.c| 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c
b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 765afd5..3668c5d 100644
--- a/arch/x86/kernel/cpu/mtrr/c
On 2018/9/11 2:06, Borislav Petkov wrote:
On Mon, Sep 10, 2018 at 09:16:03PM +0800, Pu Wen wrote:
The Hygon Dhyana CPU have a special magic MSR way to force WB for
From the last review round:
Also, it is "The ... CPU has a special..."
Please take your time and incorporate *all* review feedb
new revision out and drop review feedback.
> memory >4GB, and support TOP_MEM2. Therefore, it is necessary to
> add Hygon Dhyana support in amd_special_default_mtrr().
>
> The number of variable MTRRs for Hygon is 2 as AMD's.
>
> Signed-off-by: Pu Wen
> ---
> ar
The Hygon Dhyana CPU have a special magic MSR way to force WB for
memory >4GB, and support TOP_MEM2. Therefore, it is necessary to
add Hygon Dhyana support in amd_special_default_mtrr().
The number of variable MTRRs for Hygon is 2 as AMD's.
Signed-off-by: Pu Wen
---
arch/x86/kernel/
On 2018/9/4 16:02, Borislav Petkov wrote:
shows only old mails so I'm going to assume this got fixed, finally! And
you probably have received a *fixed* BIOS even, allegedly.
So what's up?
I tested the function on Hygon Dhyana platforms with the latest BIOS,
found that this problem is indeed fi
initialization of the fixed MTRRs, then cleared to 0 for
operation.
Is your BIOS already broken?
Searching the net for
pr_err(FW_WARN "MTRR: CPU %u: SYSCFG[MtrrFixDramModEn]"
" not cleared by BIOS, clearing this bit\n",
shows
On 2018/9/4 3:04, Borislav Petkov wrote:
It was "Hygon Dhyana" before now "Hygon" only. Can we agree on the
naming nomenclature and stick with it.
OK, agree on it.
...
- if (!((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
- (boot_cpu_data.x86 >= 0x0f)))
+ if (!((boo
n.
>
> The number of variable MTRRs for Hygon is 2 as AMD's.
>
> Signed-off-by: Pu Wen
> ---
> arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
> arch/x86/kernel/cpu/mtrr/generic.c | 5 +++--
> arch/x86/kernel/cpu/mtrr/mtrr.c| 2 +-
> 3 files changed, 6 insertions(+)
hen cleared to 0 for
operation.
The number of variable MTRRs for Hygon is 2 as AMD's.
Signed-off-by: Pu Wen
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
arch/x86/kernel/cpu/mtrr/generic.c | 5 +++--
arch/x86/kernel/cpu/mtrr/mtrr.c| 2 +-
3 files changed, 6 insertions(+), 4 deletions(
hen cleared to 0 for
operation.
The number of variable MTRRs for Hygon is 2 as AMD's.
Signed-off-by: Pu Wen
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
arch/x86/kernel/cpu/mtrr/generic.c | 5 +++--
arch/x86/kernel/cpu/mtrr/mtrr.c| 2 +-
3 files changed, 6 insertions(+), 4 deletions(
hen cleared to 0 for
operation.
The number of variable MTRRs for Hygon is 2 as AMD's.
Signed-off-by: Pu Wen
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
arch/x86/kernel/cpu/mtrr/generic.c | 5 +++--
arch/x86/kernel/cpu/mtrr/mtrr.c| 2 +-
3 files changed, 6 insertions(+), 4 deletions(
On Mon, Jul 16, 2018 at 12:03:39AM +0200, Ingo Molnar wrote:
>
> * Jann Horn wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > be something normal, like a proper file or a pipe) then ca
On Sun, Jul 15, 2018 at 6:33 PM Jann Horn wrote:
>
> +Linus, Andy, Al from the other thread
>
> On Mon, Jul 16, 2018 at 12:03 AM Ingo Molnar wrote:
> >
> > BTW., a naive question: would it make sense to simply disallow 'special'
> > fds to be passed to setuid binaries, and fix any user-space that
+Linus, Andy, Al from the other thread
On Mon, Jul 16, 2018 at 12:03 AM Ingo Molnar wrote:
> * Jann Horn wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > be something normal, like a pr
* Jann Horn wrote:
> - A malicious user can pass an arbitrary file to a setuid binary as
> stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> be something normal, like a proper file or a pipe) then calls read(0,
> , ), if the kernel disregards the length argument and writ
t; this happens, *the address limit checks are disabled*, allowing the
> ->read() or ->write() handler to read and write *kernel memory* using
> copy_from_user()/copy_to_user() and other "userspace" accessor
> functions. The easiest way to trigger this behavior from userspace is
&
en
this happens, *the address limit checks are disabled*, allowing the
->read() or ->write() handler to read and write *kernel memory* using
copy_from_user()/copy_to_user() and other "userspace" accessor
functions. The easiest way to trigger this behavior from userspace is
to use sys
this change?
Only few places in the kernel do this way and I would like to understand
why in most of the cases it's okay to supply maximum available length
and here is not the one.
> Fixes: 7f8ec5a4f01a ("x86/mtrr: Convert to use strncpy_from_user()
> helper")
> Signed-
Commit-ID: 15279df6f26cf2013d713904b4a0c957ae8abb96
Gitweb: https://git.kernel.org/tip/15279df6f26cf2013d713904b4a0c957ae8abb96
Author: Jann Horn
AuthorDate: Fri, 6 Jul 2018 23:50:03 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 7 Jul 2018 18:58:41 +0200
x86/mtrr: Don't cop
Don't access the provided buffer out of bounds - this can cause a kernel
out-of-bounds read when invoked through sys_splice() or other things that
use kernel_write()/__kernel_write().
Fixes: 7f8ec5a4f01a ("x86/mtrr: Convert to use strncpy_from_user() helper")
Signed-off-by: Jann
make ARCH=i386
>
> All errors (new ones prefixed by >>):
Problems with !SMP, which I am beating up on...
Thanx, Paul
>arch/x86/kernel/cpu/mtrr/main.o: In function `mtrr_ap_init':
> >> arch/x86/kernel/cpu/m
)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 354238a30982b817262fe6f9d00f808451694366
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
arch/x86/kernel/cpu/mtrr/main.o: In function `mtrr_a
Commit-ID: 7f8ec5a4f01aa7d03e94a3d99d7b5f9c02d7fe5a
Gitweb: https://git.kernel.org/tip/7f8ec5a4f01aa7d03e94a3d99d7b5f9c02d7fe5a
Author: Andy Shevchenko
AuthorDate: Tue, 15 May 2018 21:05:35 +0300
Committer: Ingo Molnar
CommitDate: Wed, 16 May 2018 09:47:23 +0200
x86/mtrr: Convert to
Commit-ID: 13a4db9d75ec5dbca4bd6229e149e061ef7a6bf0
Gitweb: https://git.kernel.org/tip/13a4db9d75ec5dbca4bd6229e149e061ef7a6bf0
Author: Andy Shevchenko
AuthorDate: Tue, 15 May 2018 20:57:59 +0300
Committer: Ingo Molnar
CommitDate: Wed, 16 May 2018 09:47:22 +0200
x86/mtrr: Convert to
Replace the open coded string fetch from the user.
Signed-off-by: Andy Shevchenko
---
arch/x86/kernel/cpu/mtrr/if.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index e4adad68b5e5..3cbae60663fa
The helper returns index of the matching string in an array.
Replace the open coded array lookup.
Signed-off-by: Andy Shevchenko
---
- reword commit message
arch/x86/kernel/cpu/mtrr/if.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/x86
On Sun, May 13, 2018 at 10:23 PM, Thomas Gleixner wrote:
> On Fri, 4 May 2018, Andy Shevchenko wrote:
>
>> The new helper returns index of the matching string in an array.
>
> new helper? match_string() is in tree for 2 years.
Old template.
>> We are going to use it here.
>
> Are we going to use
Commit-ID: e6d8c84a58380030457759ad6085f3792a76b2ce
Gitweb: https://git.kernel.org/tip/e6d8c84a58380030457759ad6085f3792a76b2ce
Author: Joe Perches
AuthorDate: Thu, 10 May 2018 08:45:31 -0700
Committer: Thomas Gleixner
CommitDate: Sun, 13 May 2018 21:25:18 +0200
x86/mtrr: Rename
On Fri, 4 May 2018, Andy Shevchenko wrote:
> The new helper returns index of the matching string in an array.
new helper? match_string() is in tree for 2 years.
> We are going to use it here.
Are we going to use it ? When?
"Replace the open coded array lookup." or something like that would be
On 09/05/18 17:11, Roger Pau Monné wrote:
> On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote:
>> On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote:
>>> On 09/05/18 11:21, Roger Pau Monne wrote:
>>> I'm not sure that setting the de
Kbuild uses the first file as the name for KBUILD_MODNAME.
mtrr uses main.c as its first file, so rename that file to mtrr.c
and fixup the Makefile.
Remove the now duplicate "mtrr: " prefixes from the logging calls.
Signed-off-by: Joe Perches
---
arch/x86/kernel/cpu/mtr
On Wed, May 09, 2018 at 04:11:39PM +0100, Roger Pau Monné wrote:
> On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote:
> > On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote:
> > > On 09/05/18 11:21, Roger Pau Monne wrote:
> > > I'm not su
On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote:
> On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote:
> > On 09/05/18 11:21, Roger Pau Monne wrote:
> > I'm not sure that setting the default MTRR type is going to be a
> > clever idea in hinds
On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote:
> On 09/05/18 11:21, Roger Pau Monne wrote:
> > On PVH MTRR is not initialized by the firmware (because there's no
> > firmware), so the kernel is started with MTRR disabled which means all
> > memory acces
On 09/05/18 11:21, Roger Pau Monne wrote:
> On PVH MTRR is not initialized by the firmware (because there's no
> firmware), so the kernel is started with MTRR disabled which means all
> memory accesses are UC.
>
> So far there have been no issues (ie: slowdowns) caused by thi
On PVH MTRR is not initialized by the firmware (because there's no
firmware), so the kernel is started with MTRR disabled which means all
memory accesses are UC.
So far there have been no issues (ie: slowdowns) caused by this
because PVH only supported DomU mode without passed-through device
The new helper returns index of the matching string in an array.
We are going to use it here.
Signed-off-by: Andy Shevchenko
---
arch/x86/kernel/cpu/mtrr/if.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86
On PVH MTRR is not initialized by the firmware (because there's no
firmware), so the kernel is started with MTRR disabled which means all
memory accesses are UC.
So far there have been no issues (ie: slowdowns) caused by this
because PVH only supported DomU mode without passed-through device
From: Chen Yu
Sometimes it is too late for the APs to adjust their MTRRs
to the valid ones saved before suspend - currently this
action is performed by set_mtrr_state() after all the APs
have been brought up. In some cases the BIOS might scribble
the MTRR across suspend, as a result we might get
1 - 100 of 1038 matches
Mail list logo
