On 14.10.2015 17:39, Seth Goldberg wrote: > > >> On Oct 14, 2015, at 4:08 AM, Daniel Kiper <daniel.ki...@oracle.com> wrote: >> >>> On Wed, Oct 14, 2015 at 05:19:32AM +0000, Ye, Ting wrote: >>> Hi all, >>> >>> If I understand the issue correctly, I don't quite agree that UEFI >>> spec is imprecise about SNP constraints described as following. >>> The "constraint" described here is that the grub should use attribute >>> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage >>> is clearly described in page 184, chapter 6.3 >>> EFI_BOOT_SERVICES.OpenProtocol(). >>> >>> EXCLUSIVE Used by applications to gain exclusive access to a >>> protocol interface. >>> If any drivers have the protocol interface opened with an >>> attribute of BY_DRIVER, >>> then an attempt will be made to remove them by calling the >>> driver's Stop() function. >>> >>> The grub code should not assume that the SNP is not occupied by other >>> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to >>> be more precise, use OpenProtocolInformation() to check whether SNP is >>> already opened by other driver, then decide whether need to use EXCLUSIVE >>> to disconnect the other drivers. This is the typical usage for all UEFI >>> protocol, not particular constraints to SNP protocol. >> >> Looks good! Great! However, it looks that we still have a problem if somebody >> opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to UEFI >> spec. >> Sadly we do not have a control on other stuff and one day our approach may >> fail >> because somebody decided to open SNP in EXCLUSIVE mode in e.g. a driver. Does >> it mean that migration to MNP is one sensible solution for our problems? As >> I know >> this is huge overhaul, so, we should think twice before choosing that way. > > > Then it is fortunate that when I wrote the MNP implementation that we ship > with Oracle Solaris 11.2, that I tested it on many thousands of systems as > well as on new UEFI implementations at the UEFI Plugfest ;). > Can you please point to the patch you used? I think the only sane solution judging from what I have read so far is to use MNP as far as possible and fallback to current code if MNP fails > --S > > > >> >> Daniel >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > . >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
