On Mon, Nov 9, 2015 at 12:11 PM, Jan Beulich <jbeul...@suse.com> wrote:
> >>> On 06.11.15 at 18:22, <joa...@invisiblethingslab.com> wrote:
> > 1. First of all, I wish Xen was somehow more defensively coded. To
> provide
> > some
> > examples:
> >
> > a. In XSA-109 [5] there was a problem with the hypervisor dereferencing a
> > NULL
> > pointer. The problem was fixed by the Xen Security Team by applying a
> patch
> > which (hopefully) made sure the execution path that lead to this NULL
> > pointer
> > dereferencing code was never taken. Back then I suggested (on the Xen
> > pre-disclosure list) to make this patch more explicit though:
> >
> >> On Wed, Jan 21, 2015 at 02:31:51PM +0100, Joanna Rutkowska wrote:
> >
> >> (...)
> >>>
> >>> Wouldn't it be prudent to also check if:
> >>>
> >>> (v->arch.paging.mode>{write_guest_entry,cmpxchg_guest_entry} != NULL)
> >>>
> >>> ... in the two affected functions, just before derefing these function
> >>> pointers?
> >>>
> >>> Going even a step further: how about replacing all
> >>> function-pointer-based calls with macros that first validates the
> >>> pointer before derefing it? At least when the system doesn't have SMEP?
> >>>
> > ...to which I got a reply from one of the Xen Security Team engineers
> that
> > the
> > above might perhaps be justified in debug builds only, followed by a
> > standard:
> > "feel free to contribute a patch".
>
> And you know what - I can only repeat this now. Indeed, the points
> you make are all quite reasonable from a technical perspective (and
> especially the code quality aspect is something that I also have been
> complaining _but also trying to do something_ about repeatedly), but
> the attitude behind the way you present them bothers me quite a lot:
> I get the impression that you (a) expect others to do work that you
> neither pay for, nor are at the slightest willing to help with and (b)
> de-value all our efforts during the last so many years to move the
> code base from a research project to a production usable one.
>
> Yes, the work item you mention above has been on our virtual,
> combined todo list, but with all the other work that needs to be done
> it seems like no-one actually found the time to actually carry this out.
> A good example that just pointing out issues is nice and easy, but
> actually finding time to do the work is quite a bit harder.
>
> > b. The XSA-123 [6] was another critical security bug in Xen, this time
> > resulting
> > from one of the hypervisor developer's fetish to use an absolutely
> confusing
> > construct in order to save a few modest bytes in a structure which might
> > have
> > been allocated by the system maybe a few tens of times at best. Even more
> > worrying was the way how Xen Security Team decided to fix the bug: again
> by
> > modifying some condition in the code further up the execution path, with
> the
> > hopes that this time they would ensure this puzzling construct would
> always
> > be
> > used properly. We wrote more about this in our QSB #18 [7].
>
> I suppose you already know what my response here would be?
>
> > c. Finally, the way how Xen fixed the recent XSA-148 looks also very
> reactive,
> > IMHO. With a bug of this calibre, I would expect Xen to carefully review
> and
> > augment all its PV memory virtualization code with additional checks
> (ASSERTs),
> > ensuring certain invariants are always satisfied. Such as e.g. that none
> of the
> > pages containing PDEs or PTEs are becoming writeable by the VM.
>
> Perhaps I'm overlooking something, but I cannot see what kinds of
> ASSERT()s could have helped avoid that problem. The only things I
> can see that would have helped here are
> - better thinking through of all cases by the original developer
> - better review before things going in
> - regular code audits
> None of which, according to what you write further down, you're
> willing to help with.
>
> > I can't help but have a feeling that some of the Xen developers seem to
> be
> > overconfident in their belief they can fully understand all the possible
> > execution paths in their code. Well, the XSAs quoted above are an
> > indisputable
> > prove that this is not quite always the case. Realizing that, each
> developer
> > by
> > themselves, might be a great step towards a more secure hypervisor...
>
> I think we need to find a reasonable balance here. Taking your
> statement to the extreme, we might end up with code having more
> ASSERT()s in it than anything else. Surely that can't be the goal,
> as this would severely hamper maintainability. It simply doesn't
> make sense for every function to mistrust its callers in all aspects.
>
> > 2. Another security-related aspect of the Xen project is how it totally
> > ignores
> > problems related to the build process security. Those who don't believe
> me
> > should grep the sources for wget, which is now disguised as "FETCHER"
> shell
> > variable... (so grep for "FETCHER" string)
> >
> > I feel embarrassed that I need to explain, at the end of 2015, why the
> build
> > process of any serious software project should not blindly download
> unsigned
> > components (sources) from the Internet, especially if it is about to
> execute
> > Makefiles from these components a moment later... Come on, guys!
> >
> > (Of course we have been forced to get around this gapping security whole
> in
> > Qubes OS [8] ourselves, sadly with a method that is not well suited for
> > upstreaming).
>
> To be honest, for a purely development oriented build environment
> this might by fine. No-one is required to use that, or even run their
> builds outside of sandboxes. Even in my local build environment
> (used for just my own purposes) I avoid any such downloads, albeit
> perhaps more for performance than security reasons. But what this
> tells us is that avoiding to build on this "convenience" is quite simple.
>
> > 3. Another thing is, of course: stop adding features to the core
> hypervisor. We
> > really need Xen to finally mature, stabilize, and for its development
> process to
> > be slowing down over time (just the bug fixes). We need a
> long-term-supported
> > hypervisor, which doesn't change with subsonic speed. This would allow
> this core
> > code to be widely audited by many experts. If some users want features,
> these
> > should perhaps be maintained as additional modules (no, I don't mean
> dynamically
> > loaded modules, just compile-time included), preferably in separate
> repos.
>
> I admit that, especially during the last couple of months, I have
> wished the ratio between feature addition patches and bug fixes
> would shift towards the latter (and that without hoping for there
> to be more bugs to be fixed - in fact the opposite has seemed to
> be the case in the more recent past), albeit for other reasons than
> yours.
>
> But is not adding new features realistic? I don't think so. People
> want a secure _and_ functionally complete _and_ performant
> hypervisor, and the latter two require making use of new
> hardware features as they become available (and occasionally
> introduce pure software features too, see the xSplice work
> underway).
>
> > Admittedly, some of the features are a result of hardware evolution,
> such as
> > e.g. UEFI support. But many are not. Again, maintaining these as
> optional code
> > (in separate repos) would be a great step into getting the hypervisor
> maturing,
> > finally.
>
> This, afaict, would quickly become unwieldy and unmaintainable.
>
> > 4. Finally, I've been really surprised by the line of reasoning Ian
> > expressed in
> > the above-mentioned blog post. TL;DR: "we're still doing pretty great,
> > compared
> > to other projects, because: 1) we have smaller number of publicly
> disclosed
> > bugs, and 2) we actually publicly disclose these bugs which we are aware
> > of".
> >
> > The attitude presented in the blog post is so wrong, that I'm not even
> sure
> > where to start commenting on this...
> >
> > With a single bug like the XSA-148 which, let me repeat that one more
> time: had
> > been present in the hypervisor for the last 7 years, so with a bug like
> this it
> > really doesn't matter how many (i.e. what number) of critical bugs does
> the
> > competition have.
>
> And let me repeat - it doesn't matter for how long the bug has been
> there without anyone noticing. Had you noticed it 7 years ago, and
> had we both rejected your fixes and not taken steps to fix it
> ourselves, I could see you being upset. But you having done nothing
> (Out of the now around 150 security issues in Xen, how many did you
> discover, btw?), what gives you the right to complain about a bug (no
> matter how severe) having been there for an admittedly rather long
> time? If you weren't able to spot it, how can you demand someone
> else to be able to? It is the nature of bugs that at times they hide
> rather well.
>
> > Can we, the Qubes OS project, or myself personally, help with
> implementing the
> > above suggestions? Sadly, no. While some of us do contribute occasional
> patches
> > to Xen (specifically Marek Marczykowski-Górecki), we really work for a
> different
> > project and have different tasks and responsibilities.
>
> But you seem to forget that many if not most of us too are not
> employed by their employers to look after Xen as their sole or
> primary task. I.e. if everyone reasoned this way, we could simply
> bin the entire project.
>
> So bottom line - _constructive_ criticism is welcome, but
> accusations, especially without any intent to help changing things
> (other than demanding others to do the necessary work), aren't.
>
> (Please note that all of the above are my personal views, i.e. I'm
> explicitly not speaking on behalf of the project.)
>
>
It seems positions are antithetic with no possible compromise in view.
Sadly this is a general problem of FOSS software: developers tend to do
what they like and not what users request. And who can blame developers for
that? After all they are working as volunteers so they deserve to do what
they like. No possible compromise.
Perhaps a way out of this impasse is to put bounties on Xen security tasks
identified by Joanna and properly advertise these bounties to Xen users. I
would give particular attention to the companies that use Xen. I imagine
there are many of them. Some of them may already be giving money to Xen. If
some of you knows who are these companies and how is the proper way to set
up a bounty, I offer to write the copywriting letter, already have some
clear ideas how to do that.
Best
Fran
> Jan
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/56409B7702000078000B3018%40prv-mh.provo.novell.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
