| Message ID | 20210708124345.10173-1-jgross@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | xen: harden blkfront against malicious backends | expand |
On Thu, Jul 08, 2021 at 02:43:42PM +0200, Juergen Gross wrote: > 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 Would it be worth crediting Marek? > > Changes in V2: > - put blkfront patches into own series > - some minor comments addressed > > Juergen Gross (3): > xen/blkfront: read response from backend only once > xen/blkfront: don't take local copy of a request from the ring page > xen/blkfront: don't trust the backend response data blindly > > drivers/block/xen-blkfront.c | 122 +++++++++++++++++++++++------------ > 1 file changed, 80 insertions(+), 42 deletions(-) > > -- > 2.26.2 >
On 08.07.21 16:22, Konrad Rzeszutek Wilk wrote: > On Thu, Jul 08, 2021 at 02:43:42PM +0200, Juergen Gross wrote: >> 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. > 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. I'd be interested in learning why his patches haven't been taken back then. Juergen
On Thu, Jul 08, 2021 at 04:39:58PM +0200, Juergen Gross wrote: > On 08.07.21 16:22, Konrad Rzeszutek Wilk wrote: > > On Thu, Jul 08, 2021 at 02:43:42PM +0200, Juergen Gross wrote: > > > 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. > > > 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