On Thu, Dec 12, 2024 at 11:56 AM Daniel P. Smith
wrote:
>
> Hey Luto!
>
> Let me try to address your concerns below.
>
> On 11/18/24 15:02, Andy Lutomirski wrote:
> > On Mon, Nov 18, 2024 at 11:12 AM James Bottomley
> > wrote:
> >>
> >> On Mon,
On Thu, Nov 21, 2024 at 12:54 PM Andy Lutomirski wrote:
>
> On Thu, Nov 21, 2024 at 12:11 PM wrote:
> >
> > On 11/18/24 12:02 PM, Andy Lutomirski wrote:
>
> > > If the vendor of an attestation-dependent thing trusts SM3 but *Linux*
> > > does not like SM3
On Thu, Nov 21, 2024 at 12:11 PM wrote:
>
> On 11/18/24 12:02 PM, Andy Lutomirski wrote:
> > If the vendor of an attestation-dependent thing trusts SM3 but *Linux*
> > does not like SM3, then the vendor's software should not become wildly
> > insecure because Linu
On Mon, Nov 18, 2024 at 11:12 AM James Bottomley
wrote:
>
> On Mon, 2024-11-18 at 10:43 -0800, Andy Lutomirski wrote:
> > Linux should not use TPM2_PCR_Extend *at all*. Instead, Linux should
> > exclusively use TPM2_PCR_Event. I would expect that passing, say,
> > th
On Mon, Nov 18, 2024 at 10:43 AM Andy Lutomirski wrote:
>
> Linux should not use TPM2_PCR_Extend *at all*. Instead, Linux should
> exclusively use TPM2_PCR_Event. I would expect that passing, say, the
> entire kernel image to TPM2_PCR_Event would be a big mistake, so
> inste
gt; >> to
> >> get an inquiry why I hadn't responded.
> >>
> >> On 9/21/24 18:40, Andy Lutomirski wrote:
> > [...]
> >>> I assumed that "deliberately cap" meant that there was an actual
> >>> feature where you write something
On Sat, Sep 21, 2024 at 11:37 AM Daniel P. Smith
wrote:
>
> On 9/13/24 23:57, Andy Lutomirski wrote:
> > On Thu, Sep 12, 2024 at 5:34 PM Daniel P. Smith
> > wrote:
> >>
> > What, exactly, is your patchset doing that requires hashing at all?
> > (I assume
On Thu, Sep 12, 2024 at 5:34 PM Daniel P. Smith
wrote:
>
> Hey again,
>
> On 9/4/24 21:01, Daniel P. Smith wrote:
> > Hi Luto.
> >
> > On 8/28/24 23:17, Andy Lutomirski wrote:
> >> On Thu, Aug 15, 2024 at 12:10 PM Thomas Gleixner
> >> wrote:
&g
On Wed, Aug 28, 2024 at 8:25 PM Matthew Garrett wrote:
>
> On Wed, Aug 28, 2024 at 08:17:05PM -0700, Andy Lutomirski wrote:
>
> > Ross et al, can you confirm that your code actually, at least by
> > default and with a monstrous warning to anyone who tries to change the
> &
On Thu, Aug 15, 2024 at 12:10 PM Thomas Gleixner wrote:
>
> On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
> > On 5/31/24 09:54, Eric W. Biederman wrote:
> >> Eric Biggers writes:
> >>> That paragraph is also phrased as a hypothetical, "Even if we'd prefer to
> >>> use
> >>> SHA-256-only".
On Wed, Sep 29, 2021, at 10:07 AM, Luck, Tony wrote:
> On Wed, Sep 29, 2021 at 09:58:22AM -0700, Andy Lutomirski wrote:
>> On 9/28/21 16:10, Luck, Tony wrote:
>> > Moving beyond pseudo-code and into compiles-but-probably-broken-code.
>> >
>> >
>> &
On Wed, Sep 29, 2021, at 10:41 AM, Luck, Tony wrote:
> On Wed, Sep 29, 2021 at 07:15:53PM +0200, Thomas Gleixner wrote:
>> On Wed, Sep 29 2021 at 09:59, Andy Lutomirski wrote:
>> > On 9/29/21 05:28, Thomas Gleixner wrote:
>> >> Looking at that patch again, none of
On 9/29/21 05:28, Thomas Gleixner wrote:
On Wed, Sep 29 2021 at 11:54, Peter Zijlstra wrote:
On Fri, Sep 24, 2021 at 04:03:53PM -0700, Andy Lutomirski wrote:
I think the perfect and the good are a bit confused here. If we go for
"good", then we have an mm owning a PASID for its entir
On 9/28/21 16:10, Luck, Tony wrote:
Moving beyond pseudo-code and into compiles-but-probably-broken-code.
The intent of the functions below is that Fenghua should be able to
do:
void fpu__pasid_write(u32 pasid)
{
u64 msr_val = pasid | MSR_IA32_PASID_VALID;
struct ia32_pasid_sta
On Fri, Sep 24, 2021, at 9:12 AM, Luck, Tony wrote:
> On Fri, Sep 24, 2021 at 03:18:12PM +0200, Thomas Gleixner wrote:
>> On Thu, Sep 23 2021 at 19:48, Thomas Gleixner wrote:
>> > On Thu, Sep 23 2021 at 09:40, Tony Luck wrote:
>> >
>> > fpu_write_task_pasid() can just grab the pasid from current
On Thu, Sep 23, 2021, at 4:22 PM, Luck, Tony wrote:
> On Thu, Sep 23, 2021 at 04:09:18PM -0700, Andy Lutomirski wrote:
>> On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
>
>> I think this is unnecessarily complicated because it's buying in to the
>> existing
On Thu, Sep 23, 2021, at 7:56 PM, Fenghua Yu wrote:
> Hi, Andy,
>
> On Thu, Sep 23, 2021 at 04:17:05PM -0700, Andy Lutomirski wrote:
>> On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
>> > ENQCMD requires the IA32_PASID MSR has a valid PASID value which was
>&
On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
> ENQCMD requires the IA32_PASID MSR has a valid PASID value which was
> allocated to the process during bind. The MSR could be populated eagerly
> by an IPI after the PASID is allocated in bind. But the method was
> disabled in commit 9bfecd0
On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
> PASIDs are fundamentally hardware resources in a shared address space.
> There is a limited number of them to use ENQCMD on shared workqueue.
> They must be shared and managed. They can not, for instance, be
> statically allocated to processes.
On Mon, Jun 21, 2021 at 10:51 AM Ross Philipson
wrote:
>
> On 6/18/21 2:32 PM, Robin Murphy wrote:
> > On 2021-06-18 17:12, Ross Philipson wrote:
> >> The IOMMU should always be set to default translated type after
> >> the PMRs are disabled to protect the MLE from DMA.
> >>
> >> Signed-off-by: Ro
On 6/9/21 10:32 AM, Luck, Tony wrote:
>>> I've told Fenghua to dig out the previous iteration of this patch where
>>> the plan was to lazily fix the PASID_MSR in other threads in the #GP
>>> handler.
>>
>> Blech. Also this won't work for other PASID-like features.
>>
>> I have a half-written patch
On 6/3/21 4:32 PM, Andi Kleen wrote:
>
>> We do not need an increasing pile of kludges
>
> Do you mean disabling features is a kludge?
>
> If yes I disagree with that characterization.
>
>
>> to make TDX and SEV “secure”. We need the actual loaded driver to be
>> secure. The virtio architect
On Thu, Jun 3, 2021, at 12:53 PM, Andi Kleen wrote:
>
> > Tell that to every crypto downgrade attack ever.
>
> That's exactly what this patch addresses.
>
> >
> > I see two credible solutions:
> >
> > 1. Actually harden the virtio driver.
> That's exactly what this patchkit, and the alternativ
On Thu, Jun 3, 2021, at 11:00 AM, Andi Kleen wrote:
>
> On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
> > On 6/2/21 5:41 PM, Andi Kleen wrote:
> >> Only allow split mode when in a protected guest. Followon
> >> patches harden the split mode code paths, and we don&#x
On 6/2/21 5:41 PM, Andi Kleen wrote:
> Only allow split mode when in a protected guest. Followon
> patches harden the split mode code paths, and we don't want
> an malicious host to force anything else. Also disallow
> indirect mode for similar reasons.
I read this as "the virtio driver is buggy.
On 6/2/21 1:37 PM, Luck, Tony wrote:
>>> ... so on a PASID system, your trivial reproducer would theoretically
>>> fire the same way and corrupt FPU state just as well.
>>
>> This is worse and you can't selftest it because the IPI can just hit in
>> the middle of _any_ FPU state operation and corru
> On Feb 7, 2021, at 12:31 AM, Zhou Wang wrote:
>
> SVA(share virtual address) offers a way for device to share process virtual
> address space safely, which makes more convenient for user space device
> driver coding. However, IO page faults may happen when doing DMA
> operations. As the late
> On Aug 3, 2020, at 10:34 AM, Dave Hansen wrote:
>
> On 8/3/20 10:16 AM, Andy Lutomirski wrote:
>> - TILE: genuinely per-thread, but it's expensive so it's
>> lazy-loadable. But the lazy-load mechanism reuses #NM, and it's not
>> fully disambigua
On Mon, Aug 3, 2020 at 9:37 AM Dave Hansen wrote:
>
> On 8/3/20 8:12 AM, Andy Lutomirski wrote:
> > I could easily be convinced that the PASID fixup is so trivial and so
> > obviously free of misfiring in a way that causes an infinite loop that
> > this code is fine. But
On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
>
> On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> >> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
> >> without a valid PASID value programmed. #GP error codes are 16 bits and all
> >>
On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
>
> The PASID state has to be cleared on forks, since the child has a
> different address space. The PASID is also cleared for thread clone. While
> it would be correct to inherit the PASID in this case, it is unknown
> whether the new task will us
On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
>
> A #GP fault is generated when ENQCMD instruction is executed without
> a valid PASID value programmed in the current thread's PASID MSR. The
> #GP fault handler will initialize the MSR if a PASID has been allocated
> for this process.
Let's ta
On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
>
> A #GP fault is generated when ENQCMD instruction is executed without
> a valid PASID value programmed in the current thread's PASID MSR. The
> #GP fault handler will initialize the MSR if a PASID has been allocated
> for this process.
>
> Decod
On Wed, Jun 17, 2020 at 12:39 PM Luck, Tony wrote:
>
> > Is PASID in the uapi at all?
>
>
> $ grep pasid include/uapi/linux/iommu.h
> * @pasid: Process Address Space ID
> __u32 pasid;
> * @pasid: Process Address Space ID
> __u32 pasid;
> * @pasid: Process Address Space ID
>
On Wed, Jun 17, 2020 at 11:24 AM Fenghua Yu wrote:
>
> PASID is defined as a few different types in iommu including "int",
> "u32", and "unsigned int". To be consistent and to match with ioasid's
> type, define PASID and its variations (e.g. max PASID) as "unsigned int".
>
> No PASID type change i
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu wrote:
>
> Hi, Peter,
>
>> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
>>> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>>>
>>> Or do you suggest to add a random new flag in struct thread_info instead
>>> of a TIF fl
> On Jun 15, 2020, at 1:56 PM, Luck, Tony wrote:
>
>
>>
>> Are we planning to keep PASID live once a task has used it once or are we
>> going to swap it lazily? If the latter, a percpu variable might be better.
>
> Current plan is "touch it once and the task owns it until exit(2)"
>
> Ma
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 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
> >>> mapping
> On Apr 5, 2019, at 9:56 AM, Tycho Andersen wrote:
>
>> On Fri, Apr 05, 2019 at 09:24:50AM -0600, Andy Lutomirski wrote:
>>
>>
>>> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>>>
>>> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>>&
> On Apr 5, 2019, at 10:01 AM, Dave Hansen wrote:
>
> On 4/5/19 8:24 AM, Andy Lutomirski wrote:
>>> Sounds like we need a mechanism that will do the deferred XPFO TLB
>>> flushes whenever the kernel is entered, and not _just_ at context
>>> switch
> 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 acceptable trade-off? April 1st was a few days ago.
>
>>> On Apr 4, 2019, at 4:55 PM, Khalid Aziz wrote:
>>>
>>> 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
>
> On Apr 4, 2019, at 10:28 AM, Thomas Gleixner wrote:
>
>> On Thu, 4 Apr 2019, Tycho Andersen wrote:
>>leaq-PTREGS_SIZE(%rax), %rsp
>>UNWIND_HINT_FUNC sp_offset=PTREGS_SIZE
>>
>> +/*
>> + * If we oopsed in an interrupt handler, interrupts may be off. Let's
>> turn
>> +
On Wed, Apr 3, 2019 at 6:42 PM Tycho Andersen wrote:
>
> On Wed, Apr 03, 2019 at 05:12:56PM -0700, Andy Lutomirski wrote:
> > On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
> > >
> > > From: Tycho Andersen
> > >
> > > Oopsing might kill th
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 each core allocating pages causes a
> flood of IPI messages to all other cores
On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>
> From: Tycho Andersen
>
> Oopsing might kill the task, via rewind_stack_do_exit() at the bottom, and
> that might sleep:
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 9d5c75f02295..7891add0913f 100644
> --- a/arch/x86/mm
On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote:
> The cr3 register entry can contain the SME encryption mask that indicates
> the PGD is encrypted. The encryption mask should not be used when
> creating a virtual address from the cr3 register, so remove the SME
> encryption mask in the read
On Thu, Jun 8, 2017 at 3:38 PM, Tom Lendacky wrote:
> On 6/8/2017 1:05 AM, Andy Lutomirski wrote:
>>
>> On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky
>> wrote:
>>>
>>> The cr3 register entry can contain the SME encryption bit that indicates
>>>
On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky wrote:
> The cr3 register entry can contain the SME encryption bit that indicates
> the PGD is encrypted. The encryption bit should not be used when creating
> a virtual address for the PGD table.
>
> Create a new function, read_cr3_pa(), that will ex
On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote:
>
> BOOT data (such as EFI related data) is not encyrpted when the system is
> booted and needs to be accessed as non-encrypted. Add support to the
> early_memremap API to identify the type of data being accessed so that
> the proper encryption attri
On Aug 30, 2016 6:34 AM, "Tom Lendacky" wrote:
>
> On 08/25/2016 08:04 AM, Thomas Gleixner wrote:
> > On Mon, 22 Aug 2016, Tom Lendacky wrote:
> >
> >> Provide support for Secure Memory Encryption (SME). This initial support
> >> defines the memory encryption mask as a variable for quick access an
On Wed, Apr 27, 2016 at 1:10 PM, Tom Lendacky wrote:
> On 04/27/2016 09:39 AM, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky
>> wrote:
>>> This RFC patch series provides support for AMD's new Secure Memory
>>> Encryption (SME) fe
On Wed, Apr 27, 2016 at 8:31 AM, Borislav Petkov wrote:
> On Wed, Apr 27, 2016 at 08:12:56AM -0700, Andy Lutomirski wrote:
>> I think there are some errata
>
> Isn't that addressed by the first branch of the if-test in pat_init():
>
> if ((c->x
On Wed, Apr 27, 2016 at 8:05 AM, Tom Lendacky wrote:
> On 04/27/2016 09:47 AM, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky
>> wrote:
>>> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>>>> On Tue, Apr 26, 2016 at 3:56 PM, Tom
On Wed, Apr 27, 2016 at 7:54 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote:
>> > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote:
>> >> O
On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote:
>> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
>> >> One
On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky wrote:
> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky
>> wrote:
>>> For AMD processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP)
On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
>
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be aut
On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky wrote:
> For AMD processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
What's the purpose of using the WP memory type?
--Andy
_
On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote:
> On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
>> One correction: it's a feature of the device in the system.
>> There could be a mix of devices bypassing and not
>> bypassing the IOMMU.
>
> No, it really is not. A device
On Mon, Oct 13, 2014 at 6:09 AM, Antonios Motakis
wrote:
> We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
> and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
> This way the user can control whether the XN flag will be set on the
> requested mappings. T
62 matches
Mail list logo
