On Mon, Oct 18, 2021 at 02:15:47PM +0200, Greg KH wrote:
> On Mon, Oct 11, 2021 at 07:59:17AM -0400, Michael S. Tsirkin wrote:
> > On Sun, Oct 10, 2021 at 03:22:39PM -0700, Andi Kleen wrote:
> > >
> > > > To which Andi replied
> > > > One problem with removing the ioremap opt-in is that
>
On Mon, Oct 11, 2021 at 07:59:17AM -0400, Michael S. Tsirkin wrote:
> On Sun, Oct 10, 2021 at 03:22:39PM -0700, Andi Kleen wrote:
> >
> > > To which Andi replied
> > > One problem with removing the ioremap opt-in is that
> > > it's still possible for drivers to get at devices without going
On Tue, Oct 12, 2021 at 11:35:04AM -0700, Andi Kleen wrote:
> > I'd rather see more concerted efforts focused/limited core changes
> > rather than leaf driver changes until there is a clearer definition of
> > hardened.
>
> A hardened driver is a driver that
Ah, you do define this, thank you!
>
On Sun, Oct 10, 2021 at 03:11:23PM -0700, Andi Kleen wrote:
>
> On 10/9/2021 1:39 PM, Dan Williams wrote:
> > On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote:
> > > On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan
> > > wrote:
> > > > From: Andi Kleen
> > > >
> > >
On Mon, Oct 18 2021 at 02:55, Thomas Gleixner wrote:
> On Sun, Oct 10 2021 at 15:11, Andi Kleen wrote:
>> The 5.15 tree has something like ~2.4k IO accesses (including MMIO and
>> others) in init functions that also register drivers (thanks Elena for
>> the number)
>
> These numbers are
Andi,
On Sun, Oct 10 2021 at 15:11, Andi Kleen wrote:
> On 10/9/2021 1:39 PM, Dan Williams wrote:
>> I agree with you and Greg here. If a driver is accessing hardware
>> resources outside of the bind lifetime of one of the devices it
>> supports, and in a way that neither modrobe-policy nor
>>
On Thu, Oct 14, 2021 at 12:33:49PM +, Reshetova, Elena wrote:
> > On Thu, Oct 14, 2021 at 07:27:42AM +, Reshetova, Elena wrote:
> > > > On Thu, Oct 14, 2021 at 06:32:32AM +, Reshetova, Elena wrote:
> > > > > > On Tue, Oct 12, 2021 at 06:36:16PM +, Reshetova, Elena wrote:
> > > > >
Elena,
On Thu, Oct 14 2021 at 06:32, Elena Reshetova wrote:
>> On Tue, Oct 12, 2021 at 06:36:16PM +, Reshetova, Elena wrote:
> It does not make any difference really for the content of the /drivers/*:
> gives 408 __init style functions doing IO (.probe & builtin/module_
>> >
On Thu, Oct 14, 2021 at 07:27:42AM +, Reshetova, Elena wrote:
> > On Thu, Oct 14, 2021 at 06:32:32AM +, Reshetova, Elena wrote:
> > > > On Tue, Oct 12, 2021 at 06:36:16PM +, Reshetova, Elena wrote:
> > > > > > The 5.15 tree has something like ~2.4k IO accesses (including MMIO
> > > >
On Thu, Oct 14, 2021 at 07:27:42AM +, Reshetova, Elena wrote:
> > On Thu, Oct 14, 2021 at 06:32:32AM +, Reshetova, Elena wrote:
> > > > On Tue, Oct 12, 2021 at 06:36:16PM +, Reshetova, Elena wrote:
> > > > > > The 5.15 tree has something like ~2.4k IO accesses (including MMIO
> > > >
On Thu, Oct 14, 2021 at 06:32:32AM +, Reshetova, Elena wrote:
> > On Tue, Oct 12, 2021 at 06:36:16PM +, Reshetova, Elena wrote:
> > > > The 5.15 tree has something like ~2.4k IO accesses (including MMIO and
> > > > others) in init functions that also register drivers (thanks Elena for
> >
On Tue, Oct 12, 2021 at 2:28 PM Andi Kleen wrote:
[..]
> >> But how do you debug the kernel then? Making early undebuggable seems
> >> just bad policy to me.
> > I am not proposing making the early undebuggable.
>
>
> That's the implication of moving the policy into initrd.
>
>
> If only initrd
But that was due to performance problems in hot paths. Nothing of this
applies here.
It applies because a new API that individual driver authors is being
proposed and that's an ongoing maintenance burden that might be
mitigated by hiding that implementation detail from leaf drivers.
Right
On 10/12/2021 2:18 PM, Michael S. Tsirkin wrote:
On Tue, Oct 12, 2021 at 02:14:44PM -0700, Dan Williams wrote:
Especially in this case where the virtio use case being
opted-in is *already* in a path that has been authorized by the
device-filter policy engine.
That's a good point. Andi, how
On Tue, Oct 12, 2021 at 02:14:44PM -0700, Dan Williams wrote:
> Especially in this case where the virtio use case being
> opted-in is *already* in a path that has been authorized by the
> device-filter policy engine.
That's a good point. Andi, how about setting a per-device flag
if its ID has
On Tue, Oct 12, 2021 at 11:35 AM Andi Kleen wrote:
>
>
> > The "better safe-than-sorry" argument is hard to build consensus
> > around. The spectre mitigations ran into similar problems where the
> > community rightly wanted to see the details and instrument the
> > problematic paths rather than
On Tue, Oct 12, 2021 at 06:36:16PM +, Reshetova, Elena wrote:
> > The 5.15 tree has something like ~2.4k IO accesses (including MMIO and
> > others) in init functions that also register drivers (thanks Elena for
> > the number)
>
> To provide more numbers on this. What I can see so far from a
On 10/12/2021 12:13 PM, Dan Williams wrote:
On Tue, Oct 12, 2021 at 11:57 AM Reshetova, Elena
wrote:
I suspect the true number is even higher because that doesn't include IO
inside calls to other modules and indirect pointers, correct?
Actually everything should be included. Smatch has
On Tue, Oct 12, 2021 at 11:57 AM Reshetova, Elena
wrote:
>
>
> > I suspect the true number is even higher because that doesn't include IO
> > inside calls to other modules and indirect pointers, correct?
>
> Actually everything should be included. Smatch has cross-function db and
> I am using it
On 10/12/2021 11:36 AM, Reshetova, Elena wrote:
The 5.15 tree has something like ~2.4k IO accesses (including MMIO and
others) in init functions that also register drivers (thanks Elena for
the number)
To provide more numbers on this. What I can see so far from a smatch-based
analysis, we
On 10/11/2021 10:31 PM, Christoph Hellwig wrote:
On Mon, Oct 11, 2021 at 03:09:09PM -0400, Michael S. Tsirkin wrote:
The reason we have trouble is that it's not clear what does the API mean
outside the realm of TDX.
If we really, truly want an API that says "ioremap and it's a hardened
The "better safe-than-sorry" argument is hard to build consensus
around. The spectre mitigations ran into similar problems where the
community rightly wanted to see the details and instrument the
problematic paths rather than blanket sprinkle lfence "just to be
safe".
But that was due to
On Sun, Oct 10, 2021 at 3:11 PM Andi Kleen wrote:
>
>
> On 10/9/2021 1:39 PM, Dan Williams wrote:
> > On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote:
> >> On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote:
> >>> From: Andi Kleen
> >>>
> >>> For Confidential VM
On Mon, Oct 11, 2021 at 03:09:09PM -0400, Michael S. Tsirkin wrote:
> The reason we have trouble is that it's not clear what does the API mean
> outside the realm of TDX.
> If we really, truly want an API that says "ioremap and it's a hardened
> driver" then I guess ioremap_hardened_driver is what
On Mon, Oct 11, 2021 at 10:23:00AM -0700, Andi Kleen wrote:
>
> On 10/11/2021 12:58 AM, Christoph Hellwig wrote:
> > Just as last time: This does not make any sense. ioremap is shared
> > by definition.
>
> It's not necessarily shared with the host for confidential computing: for
> example
On Mon, Oct 11, 2021 at 10:32:23AM -0700, Andi Kleen wrote:
>
> > Because it does not end with I/O operations, that's a trivial example.
> > module unloading is famous for being racy: I just re-read that part of
> > virtio drivers and sure enough we have bugs there, this is after
> > they have
Because it does not end with I/O operations, that's a trivial example.
module unloading is famous for being racy: I just re-read that part of
virtio drivers and sure enough we have bugs there, this is after
they have presumably been audited, so a TDX guest is better off
just disabling
On 10/11/2021 12:58 AM, Christoph Hellwig wrote:
Just as last time: This does not make any sense. ioremap is shared
by definition.
It's not necessarily shared with the host for confidential computing:
for example BIOS mappings definitely should not be shared, but they're
using ioremap
On Sun, Oct 10, 2021 at 03:22:39PM -0700, Andi Kleen wrote:
>
> > To which Andi replied
> > One problem with removing the ioremap opt-in is that
> > it's still possible for drivers to get at devices without going through
> > probe.
> >
> > To which Greg replied:
> >
Just as last time: This does not make any sense. ioremap is shared
by definition.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
To which Andi replied
One problem with removing the ioremap opt-in is that
it's still possible for drivers to get at devices without going through
probe.
To which Greg replied:
https://lore.kernel.org/all/yvxbnj431yiww...@kroah.com/
If there are in-kernel PCI drivers
On 10/9/2021 1:39 PM, Dan Williams wrote:
On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote:
On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote:
From: Andi Kleen
For Confidential VM guests like TDX, the host is untrusted and hence
the devices emulated by the
On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote:
>
> On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > From: Andi Kleen
> >
> > For Confidential VM guests like TDX, the host is untrusted and hence
> > the devices emulated by the host or any data coming from
On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote:
> From: Andi Kleen
>
> For Confidential VM guests like TDX, the host is untrusted and hence
> the devices emulated by the host or any data coming from the host
> cannot be trusted. So the drivers that interact with the
34 matches
Mail list logo
