> On May 28, 2020, at 10:40 AM, Don Porter <por...@cs.unc.edu> wrote:
>
> Hi Thomas,
>
> On 5/28/20 6:29 AM, Thomas Gleixner wrote:
>>> Until recently, we were doing proof-of-concept research, not product
>>> development, and there are limited hours in the day. I also hasten to
>>> say that the product of research is an article, the software artifact
>>> serves as documentation of the experiment. In contrast, the product of
>>> software development is software. It takes significant time and effort
>>> to convert one to the other. Upstreaming code is of little scientific
>>> interest. But things have changed for our project; we had no users in
>>> 2015 and we are now un-cutting corners that are appropriate for research
>>> but inappropriate for production. For a research artifact with an
>>> audience that knew the risks, we shipped a module because it was easier
>>> to maintain and install than a kernel patch.
>> I understand that and with a big fat warning and documentation from
>> start I wouldn't have complained so vehemently.
>
> This is a fair point. We will fix this ASAP, and I will be more careful
> about this going forward.
>
>>
>> Sorry for that innuendo. Now that my anger and general frustration about
>> this whole disaster have calmed down, I surely would not write that
>> again.
>
> I appreciate you saying so. Thank you.
>
> I can also understand how frustrating the history was with this feature, and
> we missed an opportunity to help sooner. There is a lot I still don't
> understand about the process of merging and testing patches in this
> community, but if it makes sense for us to help now, we would be willing.
>
>
With my x86 hat on, I have no particular expectation that you would be familiar
with the particular problems wi TV FSGSBASE. One sequence that will kill the
kernel is to use WRGSBASE to load a negative value (e.g. ~0), then set
EFLAGS.TF and do SYSENTER. I’m adding a test like this to the x86 selftests.
One useful test for the actual kernel patches would be to run your SGX workload
on a loaded core. That is, do
something like taskset -c 0 graphene_thing and, simultaneously, write a trivial
infinite loop program and run that under taskset -c 0 as well. For good
measure, you could have perf top or perf record running at the same time. Look
for kernel errors, but also look for any evidence of your workload
malfunctioning.
—Andy
