On 01/08/19 14:27, Ard Biesheuvel wrote:
> On Tue, 8 Jan 2019 at 02:11, Laszlo Ersek <ler...@redhat.com> wrote:
>>
>> On 01/07/19 20:37, Ard Biesheuvel wrote:
>>> On Mon, 7 Jan 2019 at 20:21, Achin Gupta <achin.gu...@arm.com> wrote:
>>
>>>> Could you please explain the need for End of DXE signalling and
>>>> the traditional SMM IPL. It is not obvious to me :o(
>>>>
>>>
>>> The point is that there are PI specified events that we are currently
>>> not signalling in standalone MM, so in that sense, we are not
>>> implementing the PI spec fully.
>>>
>>> Note that EndOfDxe is security sensitive - it is used as a trigger to
>>> lock down and/or secure stuff, and if it never get signalled,
>>> standalone MM drivers may falsely assume that the context is more
>>> secure than it is.
>>
>> Yes, see PI 1.6, Vol2 ("DXE"), 5.1.2.1 "End of DXE Event".
>>
>> (I won't quote the spec here, as I could quote the entire section; all
>> of it is relevant here.)
>>
>> In my interpretation anyway, the MM infrastructure basically "trusts"
>> DXE until End-of-DXE is signaled. See also:
>> - 5.6 "DXE MM Ready to Lock Protocol",
>> - 4.6 "MM Ready to Lock Protocol",
>> in Vol4.
>>
>> The kind of "early distrust" that Achin describes up-thread may be
>> well-founded, and it might obviate the above event groups. I'm not sure.
>
> I disagree. The whole point of standalone MM is to have parity with
> x86 in terms of having a separate execution context where platform
> specific services can reside. Even though DXE_SMM_DRIVER and
> MM_STANDALONE modules are dispatched in different ways, they should be
> able to be built from a shared source, and not signalling the EndOfDxe
> event is highly likely to cause more problems that it solves.
>
> And actually, I think it is a valid security model to distinguish
> between before and after EndOfDxe, since EndOfDxe will be signalled
> before loading any third-party drivers, and so whatever has executed
> up to that point can be held to higher standards in terms of trust.
What you describe is absolutely *easier* to understand and to agree
with, so I'm naturally drawn to it.
I'm just pointing out -- sort of reasoning against myself! -- that Achin
wrote up-thread,
> The idea behind MM Standalone mode was to sandbox MM code in self
> sufficient execution context. This was a step to avoid some of the
> vulnerabilities in traditional SMM due to code and data sharing with
> DXE.
Through this, Achin seemed to imply that some SMM vulnerabilities had
occurred due to SMM being *capable* of reading *any* RAM (and MMIO too)
outside of SMRAM ("data sharing"); hence invalid pointer dereferences
(even just reads) could lead to really bad problems.
Then, I tried to fill the term "sandbox" with meaning -- i.e. MM would
be prevented from reading any DXE data (anything outside of MMRAM). This
looked sort of consistent with the extra restriction that standalone MM
code couldn't consume UEFI protocols even at init time.
And then I extrapolated: if MM can't trust DXE *at all*, then MM needs
no notification that, due to BDS reaching a specific point, MM can trust
DXE even *less* than before. There is no "less" than "not at all".
In short, I agree with you, I'm just trying to comprehend the "threat
model" (is that the right term?) behind Achin's story (AIUI).
Thanks!
Laszlo
>> The concept is novel to me (after having struggled for months in ~2015
>> to wrap my brain around traditional SMM in the first place), so I'm
>> having trouble at reasoning about standalone MM.
>>
>
> I think that applies to all of us :-)
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
