[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] net: ne2000: check ring buffer control register
From: |
Jason Wang |
Subject: |
Re: [Qemu-devel] [PATCH] net: ne2000: check ring buffer control registers |
Date: |
Tue, 23 Feb 2016 11:27:43 +0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
On 02/09/2016 02:47 PM, P J P wrote:
> Hello Jason,
>
> +-- On Fri, 5 Feb 2016, Jason Wang wrote --+
> | I suspect this could even work. Consider after realizing, s->stop is
> | zero, any attempt to set STARTPG will fail?
>
> Ie after 'pci_ne2000_realize'? It does not seem to set or reset s->stop
> register.
I mean with your patch, driver will only be allowed to set EN0_STOPPG
before EN0_STARTPG. So if a driver want to set STARTPG first, the check
+ if (v < NE2000_PMEM_END && v < s->stop) {
will prevent the driver from working correctly since s->stop is zero here.
>
> | This may not be sufficient, consider:
> |
> | set start to 1
> | set stop to 100
> | set boundary to 50
> | then set stop to 10
>
> I think any attempts to define the ring buffer limits should reset
> 'boundary' and 'curpag' registers to s->start(STARTPG). I wonder if a driver
> should be allowed to fiddle with the ring buffers location inside
> contorller's
> memory. It does not seem right.
Well, I think we could not assume the behavior of a driver, especially
consider it may be malicious.
>
> | I'm thinking maybe we need check during receiving like what we did in
> | dd793a74882477ca38d49e191110c17dfee51dcc?
>
> Check if (s->start == s->stop) at each receive call?
Or in ne2000_buffer_full()?
>
> --
> - P J P
> 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
>