On Wed, Apr 17, 2019 at 5:00 PM Linus Torvalds
wrote:
>
> On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote:
> >
> > On Wed, 17 Apr 2019, Linus Torvalds wrote:
> >
> > > With SMEP, user space pages are always NX.
> >
> > We talk past each other. The user space page in the ring3 valid virtual
On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote:
>
> On Wed, 17 Apr 2019, Linus Torvalds wrote:
>
> > With SMEP, user space pages are always NX.
>
> We talk past each other. The user space page in the ring3 valid virtual
> address space (non negative) is of course protected by SMEP.
>
> The
On Wed, 17 Apr 2019, Linus Torvalds wrote:
> On Wed, Apr 17, 2019, 14:20 Thomas Gleixner wrote:
>
> >
> > It's not necessarily a W+X issue. The user space text is mapped in the
> > kernel as well and even if it is mapped RX then this can happen. So any
> > kernel mappings of user space text
On Wed, Apr 17, 2019, 14:20 Thomas Gleixner wrote:
>
> It's not necessarily a W+X issue. The user space text is mapped in the
> kernel as well and even if it is mapped RX then this can happen. So any
> kernel mappings of user space text need to be mapped NX!
With SMEP, user space pages are
David Gibson writes:
> On Sat, Mar 23, 2019 at 05:01:35PM -0400, Michael S. Tsirkin wrote:
>> On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote:
>> > Michael S. Tsirkin writes:
> [snip]
>> > >> > Is there any justification to doing that beyond someone putting
>> > >> > out
Michael S. Tsirkin writes:
> On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote:
>>
>> Michael S. Tsirkin writes:
>>
>> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote:
>> >> >From what I understand of the ACCESS_PLATFORM definition, the host will
>>
On Wed, 17 Apr 2019, Nadav Amit wrote:
> > On Apr 17, 2019, at 10:26 AM, Ingo Molnar wrote:
> >> As I was curious, I looked at the paper. Here is a quote from it:
> >>
> >> "In x86-64, however, the permissions of physmap are not in sane state.
> >> Kernels up to v3.8.13 violate the W^X property
hey,
I'm seeing an issue on a couple of arm64 systems[*] where they spew
~10K "cma: cma_alloc: alloc failed" messages at boot. The errors are
non-fatal, and bumping up cma to a large enough size (~128M) gets rid
of them - but that seems suboptimal. Bisection shows that this started
after commit
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 prevent execution
> of direct kernel mappings. Is this
On Wed, Apr 17, 2019 at 12:49:04PM -0700, Andy Lutomirski wrote:
> I also proposed using a gcc plugin (or upstream gcc feature) to add
> some instrumentation to any code that pops RSP to verify that the
> resulting (unsigned) change in RSP is between 0 and THREAD_SIZE bytes.
> This will make ROP
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 prevent execution
> >>> of direct kernel mappings. Is this motivation still present if those
> >>>
On Wed, Apr 17, 2019 at 07:24:41PM +0100, Jean-Philippe Brucker wrote:
> Currently pci_ats_disabled() is only defined when CONFIG_PCI is enabled.
> Since we're about to use the function in the Arm SMMUv3 driver, which
> could be built with CONFIG_PCI disabled, add a definition of
>
On Wed, Apr 17, 2019 at 07:24:40PM +0100, Jean-Philippe Brucker wrote:
> At the moment, the ATS functions are only defined when CONFIG_PCI is
> enabled. Since we're about to use them in the Arm SMMUv3 driver, which
> could be built with CONFIG_PCI disabled, and they are already guarded by
>
The ARM architecture has a "Top Byte Ignore" (TBI) option that makes the
MMU mask out bits [63:56] of an address, allowing a userspace application
to store data in its pointers. This option is incompatible with PCI ATS.
If TBI is enabled in the SMMU and userspace triggers DMA transactions on
PCIe devices can implement their own TLB, named Address Translation Cache
(ATC). Enable Address Translation Service (ATS) for devices that support
it and send them invalidation requests whenever we invalidate the IOTLBs.
ATC invalidation is allowed to take up to 90 seconds, according to the
PCIe
Root complex node in IORT has a bit telling whether it supports ATS or
not. Store this bit in the IOMMU fwspec when setting up a device, so it
can be accessed later by an IOMMU driver. In the future we'll probably
want to store this bit at the host bridge or SMMU rather than in each
endpoint.
This series enables PCI ATS in SMMUv3. Changes since v2 [1]:
* Fix build failure when building arm-smmu-v3 without CONFIG_PCI
Patches 1 and 2 are new.
* Only enable ATS if the root complex supports it. For the moment, only
IORT provides this information. I have patches for devicetree but
When removing a mapping from a domain, we need to send an invalidation to
all devices that might have stored it in their Address Translation Cache
(ATC). In addition when updating the context descriptor of a live domain,
we'll need to send invalidations for all devices attached to it.
Maintain a
Simplify the attach/detach code a bit by keeping a pointer to the stream
IDs in the master structure. Although not completely obvious here, it does
make the subsequent support for ATS, PRI and PASID a bit simpler.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 30
As we're going to track domain-master links more closely for ATS and CD
invalidation, add pointer to the attached domain in struct
arm_smmu_master. As a result, arm_smmu_strtab_ent is redundant and can be
removed.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 92
The arm_smmu_master_data structure already represents more than just the
firmware data associated to a master, and will be used extensively to
represent a device's state when implementing more SMMU features. Rename
the structure to arm_smmu_master.
Signed-off-by: Jean-Philippe Brucker
---
Currently pci_ats_disabled() is only defined when CONFIG_PCI is enabled.
Since we're about to use the function in the Arm SMMUv3 driver, which
could be built with CONFIG_PCI disabled, add a definition of
pci_ats_disabled() for !CONFIG_PCI.
Signed-off-by: Jean-Philippe Brucker
---
At the moment, the ATS functions are only defined when CONFIG_PCI is
enabled. Since we're about to use them in the Arm SMMUv3 driver, which
could be built with CONFIG_PCI disabled, and they are already guarded by
CONFIG_PCI_ATS which depends on CONFIG_PCI, move the definitions outside
of
> On Apr 17, 2019, at 10:26 AM, Ingo Molnar wrote:
>
>
> * Nadav Amit wrote:
>
>>> On Apr 17, 2019, at 10: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
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?
>>>
>>> (Sorry if this has been asked and
* Nadav Amit wrote:
> > On Apr 17, 2019, at 10: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
> On Apr 17, 2019, at 10: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?
>>>
>>> (Sorry if this has
* 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?
> >
> > (Sorry if this has been asked and answered in previous discussions.)
>
> Hi
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 infrastructure for XPFO which protects
>>
[ 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 infrastructure for XPFO which protects
> against 'ret2dir' kernel attacks. The basic idea is to
> The call to of_parse_phandle returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
Can a splitting of this information into two sentences help?
> 581 static int mtk_iommu_probe(struct platform_device *pdev)
> 582 {
> ...
I
> The call to of_parse_phandle returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
Can a splitting of this information into two sentences help?
> 581 static int mtk_iommu_probe(struct platform_device *pdev)
> 582 {
> ...
I
On 17/04/2019 07:33, Christoph Hellwig wrote:
On Wed, Apr 10, 2019 at 08:11:57AM +0200, Christoph Hellwig wrote:
On Tue, Apr 09, 2019 at 06:59:32PM +0100, Robin Murphy wrote:
On 27/03/2019 08:04, Christoph Hellwig wrote:
This keeps the code together and will simplify compiling the code
out on
The use count of svm->mm is incremented by mmget_not_zero. However, it
is not dropped when the address is not canonical. This patch fixes the
bug.
Fixes: 9d8c3af31607("iommu/vt-d: IOMMU Page Request needs to check if
address is canonical.")
Signed-off-by: Pan Bian
---
drivers/iommu/intel-svm.c
On 17/04/2019 04:41, Wen Yang wrote:
> The call to of_parse_phandle returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> 581 static int mtk_iommu_probe(struct platform_device *pdev)
> 582 {
> ...
> 626 for (i = 0; i <
On Wed, Apr 10, 2019 at 08:11:57AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 09, 2019 at 06:59:32PM +0100, Robin Murphy wrote:
> > On 27/03/2019 08:04, Christoph Hellwig wrote:
> >> This keeps the code together and will simplify compiling the code
> >> out on architectures that are always dma
36 matches
Mail list logo
