On Thu, Jul 08, 2021 at 04:39:58PM +0200, Juergen Gross wrote:

On 08.07.21 16:22, Konrad Rzeszutek Wilk wrote:

quoted

On Thu, Jul 08, 2021 at 02:43:42PM +0200, Juergen Gross wrote:

quoted

Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but it shouldn't be able to e.g. crash a guest by
other means or cause a privilege escalation in the guest).

Unfortunately blkfront in the Linux kernel is fully trusting its
backend. This series is fixing blkfront in this regard.

It was discussed to handle this as a security problem, but the topic
was discussed in public before, so it isn't a real secret.

Wow. This looks like what Marek did .. in 2018!

https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02336.html

Yes, seems to have been a similar goal.

quoted

Would it be worth crediting Marek?

I'm fine mentioning his patches, but I didn't know of his patches until
having sent out V1 of my series.

Some email issue likely? You were on explicit CC in that series.

I'd be interested in learning why his patches haven't been taken back
then.

Mostly it was waiting in limbo on "public: add RING_COPY_RESPONSE()"[1] patch
to the Xen tree, to be then synchronized back to Linux headers. That patch
was finally committed in March this year. I should've followed up on it,
earlier than 3 years later...

[1] https://lore.kernel.org/xen-devel/20180430215436.21062-1-marmarek@invisiblethingslab.com/T/#u (local)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab