Messages in this thread | | | Date | Wed, 30 Nov 2022 22:40:40 +0900 | From | asmadeus@codewrec ... | Subject | Re: [PATCH] 9p: fix crash when transaction killed |
| |
Christian Schoenebeck wrote on Wed, Nov 30, 2022 at 02:25:59PM +0100: > > I'm also not convinced it'd fix anything here, we're not talking about a > > real server but about a potential attacker -- if a reply comes in with > > the next tag while we're allocating it, we'll get the exact same problem > > as we have right now. > > Frankly, 9p has no security at all so I'm not sure this is something we > > really need to worry about, but bugs are bugs so we might as well fix > > them if someone has the time for that... > > > > Anyway, I can appreciate that logs will definitely be easier to read, so > > an option to voluntarily switch to cyclic allocation would be more than > > welcome as a first step and shouldn't be too hard to do... > > I would actually do it the other way around: generating continuous sequential > tags by default and only reverting back to dense tags if requested by mount > option. > > Is there any server implementation known to rely on current dense tag > generation?
No, I thought ganesha did when we discussed it last time, but checked just now and it appears to be correct.
I had a quick look at other servers I have around (diod uses a plain list, libixp uses a bucket list like ganesha...), but there are so many 9p servers out here that I'm far from keeping track...
Happy to give it a try and see who complains...
> If there is really some exotic server somewhere that uses e.g. a simple > constant size array to lookup tags and nobody is able to replace that array by > a hash table or something for whatever reason, then I am pretty sure that > server is limited at other ends as well (e.g. small 'msize'). So what we could > do is adjusting the default behaviour according to the other side and allow to > explicitly set both sequential and dense tags by mount option (i.e. not just > a boolean mount option).
Well, TVERSION doesn't have much negotiation capability aside of msize, not sure what to suggest here...
| |