en a fault is in kernel space which has been triggered by XPFO.
Signed-off-by: Tycho Andersen
CC: x...@kernel.org
Tested-by: Khalid Aziz
Cc: Khalid Aziz
---
arch/x86/mm/fault.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9d
mm, xpfo: temporarily map dcache regions
Julian Stecklina (1):
xpfo, mm: optimize spinlock usage in xpfo_kunmap
Khalid Aziz (2):
xpfo, mm: Defer TLB flushes for non-current CPUs (x86 only)
xpfo, mm: Optimize XPFO TLB flushes by batching them together
Tycho Andersen (4):
mm: add MAP_HUGETLB
.de: encode all XPFO info in struct page]
Signed-off-by: Julian Stecklina
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
---
v9: * Do not use page extensions. Encode all xpfo information in struct
page (Julian Stecklina).
* Split architecture specific code into its own separate patch
;t be used accidentally by other
CPUs.
Signed-off-by: Juerg Haefliger
Signed-off-by: Tycho Andersen
Tested-by: Marco Benatto
[jstec...@amazon.de: rebased from v4.13 to v4.19]
Signed-off-by: Julian Stecklina
Tested-by: Khalid Aziz
Cc: Khalid Aziz
---
drivers/misc/lkdtm/Makefile | 1 +
dr
4.20+XPFO+Deferred flush803.989s1.32x
This same code should be implemented for other architectures as
well once finalized.
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
---
arch/x86/include/asm/tlbflush.h | 1 +
arch/x86/mm/tlb.c | 52 +
-by: Khalid Aziz
Cc: Khalid Aziz
---
include/linux/xpfo.h | 21 +
mm/xpfo.c| 30 ++
2 files changed, 51 insertions(+)
diff --git a/include/linux/xpfo.h b/include/linux/xpfo.h
index 5d8d06e4b796..2318c7eb5fb7 100644
--- a/include/linux
From: Juerg Haefliger
XPFO can unmap a bounce buffer. Check for this and map it back in if
needed.
Signed-off-by: Juerg Haefliger
Signed-off-by: Tycho Andersen
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
Reviewed-by: Konrad Rzeszutek Wilk
---
v9: * Added a generic check for whether a page
From: Juerg Haefliger
If the page is unmapped by XPFO, a data cache flush results in a fatal
page fault, so let's temporarily map the region, flush the cache, and then
unmap it.
CC: linux-arm-ker...@lists.infradead.org
Signed-off-by: Juerg Haefliger
Signed-off-by: Tycho Andersen
---
v6: actual
table.
Model-checked with up to 4 concurrent callers with Spin.
Signed-off-by: Julian Stecklina
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
Cc: x...@kernel.org
Cc: kernel-harden...@lists.openwall.com
Cc: Vasileios P. Kemerlis
Cc: Juerg Haefliger
Cc: Tycho Andersen
Cc: Marco Benatto
Cc
Andersen
Signed-off-by: Marco Benatto
Signed-off-by: Julian Stecklina
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
---
.../admin-guide/kernel-parameters.txt | 10 +-
arch/x86/Kconfig | 1 +
arch/x86/include/asm/pgtable.h| 26
arch
Signed-off-by: Tycho Andersen
Tested-by: Marco Benatto
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
---
v7: * make user_virt_to_phys a GPL symbol
v6: * add a definition of user_virt_to_phys in the !CONFIG_XPFO case
arch/x86/mm/xpfo.c | 57
include/li
From: Tycho Andersen
vm_mmap is exported, which means kernel modules can use it. In particular,
for testing XPFO support, we want to use it with the MAP_HUGETLB flag, so
let's support it via vm_mmap.
Signed-off-by: Tycho Andersen
Tested-by: Marco Benatto
Tested-by: Khalid Aziz
Cc: K
turned on.
Thanks to Laura Abbot for the simplification from v5, and Mark Rutland
for pointing out we need NO_CONT_MAPPINGS too.
CC: linux-arm-ker...@lists.infradead.org
Signed-off-by: Juerg Haefliger
Signed-off-by: Tycho Andersen
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
---
.../admin-gu
make -j4 all
5.0 610.642s
5.0+XPFO+Deferred flush+Batch update773.075s1.27x
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
Signed-off-by: Tycho Andersen
---
v9:
- Do not map a page freed by userspace back into kernel. Mark
it as
On 4/4/19 1:43 AM, Peter Zijlstra wrote:
>
> You must be so glad I no longer use kmap_atomic from NMI context :-)
>
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
>> +static inline void xpfo_kmap(void *kaddr, struct page *page)
>> +{
>> +unsign
[trimmed To: and Cc: It was too large]
On 4/4/19 1:52 AM, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:05AM -0600, Khalid Aziz wrote:
>> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
>> index 2779ace16d23..5c0e1581fa56 100644
>> --- a
On 4/4/19 1:56 AM, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:12AM -0600, Khalid Aziz wrote:
>> From: Julian Stecklina
>>
>> Only the xpfo_kunmap call that needs to actually unmap the page
>> needs to be serialized. We need to be careful to handle the case
On 4/3/19 10:10 PM, Andy Lutomirski wrote:
> On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>>
>> XPFO flushes kernel space TLB entries for pages that are now mapped
>> in userspace on not only the current CPU but also all other CPUs
>> synchronously. Processes on
On 4/5/19 8:44 AM, Dave Hansen wrote:
> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>>> process. Is that an acceptable trade-off?
>> You are not seriously asking whether creating a user controllable ret2dir
>> attack window is a acceptable trade-off? April 1st was a few days ago.
>
> Well, let's no
On 4/5/19 9:24 AM, Andy Lutomirski wrote:
>
>
>> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>>
>> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
process. Is that an acceptable trade-off?
>>> You are not seriously asking whether creating a user controllable ret2dir
>>> attack window is a acc
On 4/5/19 10:27 AM, Andy Lutomirski wrote:
> At the risk of asking stupid questions: we already have a mechanism for this:
> highmem. Can we enable highmem on x86_64, maybe with some heuristics to make
> it work well?
>
I proposed using highmem infrastructure for xpfo in my cover letter as
wel
On 4/17/19 10:15 AM, Ingo Molnar wrote:
>
> [ Sorry, had to trim the Cc: list from hell. Tried to keep all the
> mailing lists and all x86 developers. ]
>
> * Khalid Aziz wrote:
>
>> From: Juerg Haefliger
>>
>> This patch adds basic support in
On 4/17/19 11:09 AM, Ingo Molnar wrote:
>
> * Khalid Aziz wrote:
>
>>> I.e. the original motivation of the XPFO patches was to prevent execution
>>> of direct kernel mappings. Is this motivation still present if those
>>> mappings are non-executable?
>&
On 4/17/19 1:49 PM, Andy Lutomirski wrote:
> On Wed, Apr 17, 2019 at 10:33 AM Khalid Aziz wrote:
>>
>> On 4/17/19 11:09 AM, Ingo Molnar wrote:
>>>
>>> * Khalid Aziz wrote:
>>>
>>>>> I.e. the original motivation of the XPFO patches was to p
On 4/17/19 11:41 PM, Kees Cook wrote:
> On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
>> I don't think this type of NX goof was ever the argument for XPFO.
>> The main argument I've heard is that a malicious user program writes a
>> ROP payload into user memory (regular anonymous user me
On 4/18/19 8:34 AM, Khalid Aziz wrote:
> On 4/17/19 11:41 PM, Kees Cook wrote:
>> On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
>>> I don't think this type of NX goof was ever the argument for XPFO.
>>> The main argument I've heard is that a ma
On 5/1/19 8:49 AM, Waiman Long wrote:
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
>
>> index 858b6c0b9a15..9b36da94760e 100644
>> ---
Rozycki
Cc: Matt Wang
Cc: Khalid Aziz
Signed-off-by: Arnd Bergmann
---
Documentation/scsi/BusLogic.rst | 581 ---
Documentation/scsi/FlashPoint.rst | 176 -
MAINTAINERS |7 -
drivers/scsi/BusLogic.c | 3727 --
drivers/scsi/BusLogic.h
about the lack of a bus_to_virt()
replacement. A better fix would likely involve changing out the entire
descriptor allocation for a simpler one, but that would be much
more invasive.
Cc: Maciej W. Rozycki
Cc: Matt Wang
Cc: Khalid Aziz
Signed-off-by: Arnd Bergmann
---
drivers/
On 6/23/22 08:47, Arnd Bergmann wrote:
Can you test it again with this patch on top?
diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index d057abfcdd5c..9e67f2ee25ee 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2554,8 +2554,14 @@ static void blogic_scan
about the lack of a bus_to_virt()
replacement. A better fix would likely involve changing out the entire
descriptor allocation for a simpler one, but that would be much
more invasive.
Cc: Maciej W. Rozycki
Cc: Matt Wang
Tested-by: Khalid Aziz
Reviewed-by: Robin Murphy
Reviewed-by: Hannes Reinecke
31 matches
Mail list logo
