Neste artigo vou descrever os erros nos laptops BIOS / UEFI que tinham que trabalhar, e para o qual tiveram de se adaptar carregadores. Em primeiro lugar, será sobre os erros que não são visíveis para o usuário, mas que pode interferir com o bootloader, mesmo no pressuposto de que tudo foi feito corretamente. Erros foram encontrados nas interfaces dos respectivos ambientes de execução, e na modalidade de código processadores SMM Intel. o material conduzido com base na experiência, que é esticada a uma suficientemente grande período de tempo. Portanto, no momento da escrita, perdeu-se uma lista de modelos específicos. No entanto, eu mantenho uma lista de fabricantes, em laptops que têm problemas. Erros será descrito sequencialmente a partir do simples ao mais complexo. Também nas descrições dos cursos será dada uma forma de contorná-los.

Antes de começar

Para torná-lo um completo entendimento das circunstâncias em que teve de lidar com os problemas descritos, vou dizer-lhe brevemente que tipo de trabalho tem de realizar. Existe um produto que criptografa a unidade do sistema. Portanto, na fase de iniciar o PC é necessária para descriptografar as unidades para que o sistema operacional pode ser executado. Portanto, o carregador de inicialização foi desenvolvido, que executa essa função. Depois de instalar todos os seus interceptores as transferências carregador controle para o carregador SO original. Além disso, o termo “boot loader” na descrição é usado para descrever o nosso bootloader. E o termo “boot loader” é usado para se referir ao carregador de boot, que substituímos.

problemas de inicialização bootloader (Lenovo, UEFI)

Sabe-se que UEFI implementa variáveis ​​globais. Em particular, existem variáveis ​​globais, cada um dos quais descreve uma forma de lançar o PC (entrada opção de carregamento). Há também um BootOrder variável global, que descreve como chamar essas opções. Assim, o carregador foi gravado na partição do sistema UEFI, e um novo registo, quando BootOrder este carregador foi colocada em primeiro lugar na fila foi criada por ele. No entanto, quando você inicia o seu PC que chama de carregador de inicialização do Windows.Descobriu-se que o UEFI ignorou completamente o BootOrder importância e sempre baixado o Windows, se for encontrado o seu recorde.

O problema era dar a volta por substituição do próprio carregador do Windows. Isto, naturalmente, contribui para o trabalho, porque Agora, um arquivo de substituição deve ser protegido no próprio sistema operacional.

Problemas com comandos de envio de USB (HP, UEFI)

O carregador funciona com dispositivos USB. Ou seja, um CCID-leitores. Para trabalhar com dispositivos USB usados ​​para este protocolo efeitos previstos – EFI_USB_IO_PROTOCOL. O problema era que executar o gerenciador de não especificar qualquer dispositivo USB quando em outros PCs no mesmo carregador definido eles. À primeira vista pode parecer que é completamente não-funcionamento do driver USB, mas eu não conseguia no trabalho com um laptop ignorar o fato de que o laptop é lançado com sucesso a partir da unidade flash. Além disso, tornou-se claro que o problema ocorre quando o envio de comandos atrav de um canal de controlo (tubo de transferência de controlo) quando se utiliza a ferramenta protocolo UsbControlTransfer EFI_USB_IO_PROTOCOL. O protótipo função é mostrado abaixo.

typedef EFI_STATUS (EFIAPI *EFI_USB_IO_CONTROL_TRANSFER) ( IN EFI_USB_IO_PROTOCOL* This, IN EFI_USB_DEVICE_REQUEST* Request, IN EFI_USB_DATA_DIRECTION Direction, IN UINT32 Timeout, IN OUT VOID* Data OPTIONAL, IN UINTN DataLength OPTIONAL, OUT UINT32* Status );

Função sempre retorna um EFI_USB_ERR_TIMEOUT erro. Descobriu-se que o tipo de EFI_USB_DATA_DIRECTION foi implementada por desenvolvedores não de acordo com a especificação UEFI.Determinação do tipo da especificação abaixo.

typedef enum { EfiUsbDataIn, EfiUsbDataOut, EfiUsbNoData } EFI_USB_DATA_DIRECTION;

O erro na implementação do tipo foi o fato de que no laptop correspondente EfiUsbDataIn e EfiUsbDataOut foram misturados. Consequentemente, quando o carregador chama a função UsbControlTransfer do terceiro parâmetro igual EfiUsbDataOut, o que realmente acontece não é uma entrada no dispositivo e ler a partir dele. E vice-versa. Desde código do aplicativo EfiUsbDataOut se encontra com o primeiro lugar, verifica-se que o controlador USB tenta ler dados a partir do dispositivo, que envia um pedido quando não pode haver.Por conseguinte, a função terminou com um tempo limite.

A solução é extremamente feio. Ao iniciar as verificações carregador se a estrutura de campo de linha FirmwareRevision EFI_SYSTEM_TABLE «HPQ», e, em caso afirmativo, verifica que continham FirmwareRevision valor do campo 0x10000001. Se estiverem preenchidas as duas condições, então quando você chamar as funções apropriadas, pretendemos alterar os valores e EfiUsbDataIn EfiUsbDataOut revertida.

Problemas para obter USB-respostas (Fujitsu LifeBook E743, UEFI)

Externamente, um problema conhecido é que nem todos os dispositivos no carregador CCID-operado. mais velho da família trabalhou sem problemas, o novo não. Descobriu-se que o problema ocorre quando você chamar a função de protocolo UsbBulkTransfer EFI_USB_IO_PROTOCOL. A função sempre retorna um EFI_DEVICE_ERROR erro.

Sabe-se que o controlador USB hospedeiro comunica com as unidades de pacotes de comprimento fixo.desenvolvedores USB também permitiu que o dispositivo pode retornar um pacote curto. Neste caso, o controlador de host irá retornar o status de conclusão de transmissão não é “Sucesso” e “Short Packet”. E USB Driver Essa resposta foi interpretado como um erro. Ou seja, função UsbBulkTransfer sempre retorna EFI_DEVICE_ERROR se o dispositivo respondeu em rajadas curtas.

E assim aconteceu que o velho CCID família sempre respondeu o tamanho do pacote quando novo – curta. O problema estava a contornar por meio da análise da memória intermédia de saída. A figura seguinte mostra o formato de CCID dispositivos pacotes RDR_to_PC_DataBlock. Este dispositivo pacote de volta para um comando como PC_to_RDR_IccPowerOn, PC_to_RDR_Secure e PC_to_RDR_XfrBlock.

#pragma pack( push, 1 ) struct RDR_to_PC_DataBlock { UINT8 bMessageType; UINT32 dwLength; UINT8 bSlot; UINT8 bSeq; UINT8 bStatus; UINT8 bError; UINT8 bChainParameter; UINT8* abData[0]; }; #pragma pack( pop )

campo bMessageType identifica o tipo de pacote e de pacotes RDR_to_PC_DataBlock é sempre igual a 0x80.Portanto, antes de receber uma resposta a partir dos dispositivos do tampão, este campo anteriormente zerada. Se a função UsbBulkTransfer retorna um erro, então ele verifica o valor deste campo, e se ele é igual a 0x80, em seguida, assumiu-se que o dispositivo está realmente respondidas corretamente. Neste caso campo dwLength usada para calcular o tamanho de resposta, e este tamanho já é devolvido ao solicitante original.

Problemas com cartão de memória (Toshiba Satellite U200, BIOS)

Externamente, um problema conhecido é que o carregador se recusou a trabalhar porque Eu não consegui encontrar um pedaço de memória na qual ele poderia acomodar. A análise revelou problemas durante a digitalização de cartões de memória. Durante esta parte do intervalo de varrimento é ignorada e não submetidas a análise.

Estamos falando de uma interrupção int 15h serviço 0xe820. porque downloader deixou parte do código residente, necessário para alocar memória e colocar o código nesta área. Por sua vez, levou um modificações cartão de memória para o sistema operacional no momento do seu lançamento, nós não usar um site dedicado. Assim, durante o lançamento de todo o cartão foi lido corretamente modificado e foi substituído pelo 15h interceptação int.

O seguinte são os parâmetros de entrada e de saída da função de receber o cartão.

  • parâmetros de entrada:
    • EAX – código de função é sempre 0xe820;
    • EBX – continuou, em primeira convocação deve ser igual ao valor 0, com valor subseqüente deve ser igual ao valor retornado pela chamada função depois. Este registo especifica as funções que a gravação continuar a receber o cartão de memória;
    • ES: DI – ponteiro para o tampão, que retorna uma entrada descreve uma gama particular de memória;
    • ECX – tamanho do buffer deve ser pelo menos 20, tal como função primeira de auditoria que devolvido o tamanho da gravação de 20 bytes. Nos sistemas modernos, o tamanho do registro é de 24 bytes;
    • EDX – uma assinatura é sempre ‘SMAP’. Usado para verificar o solicitante.
  • Parâmetros de saída:
    • CF – Avaria Se 0, então não há nenhum erro;
    • EAX – assinatura é sempre ‘SMAP’. Usado para verificar o BIOS;
    • ES: DI – ponteiro para o tampão, a mesma que na entrada;
    • ECX – gravação tamanho que é retornado pela função;
    • EBX – um valor que deve ser aplicada para a função de entrada para obter o próximo registro.Além disso, não fazer suposições sobre o valor devido isso pode ser compensado, índice ou qualquer outra entidade na representação interna da função.

Com esta função, o carregador de inicialização no ciclo revisa o cartão de memória inteiro. E o carregador foi desenvolvido de tal forma a garantir a compatibilidade para a frente com futuras versões do BIOS. Ou seja,Entrada ECX registo continha 64. Como se segue a partir da descrição da função, a função no registo ECX retorna o tamanho da ficha que foi registado na memória tampão. Porque no momento em que o tamanho máximo de registro de 24, então mais do que este valor, o registo pode não ser. Além disso, a função deve retornar sempre exatamente uma entrada.

No entanto, em um laptop específico descobriu-se que a função interpreta o valor de ECX pouco diferentes.Ou seja, ele não é usado para determinar o tamanho do registro, que é apoiado pelo interrogador, e para determinar como a função pode retornar todos os registros em uma única chamada. Assim aconteceu que quando a função não é loader lê uma entrada e dois. E, por isso, um deles é sempre ignorado pelo carregador. Isto levou ao fato de que o carregador não é possível encontrar a localização de memória, no qual ele poderia colocar um código residente.

O problema foi resolvido pela transmissão dos valores em ECX 24. Ou seja, a compatibilidade para a frente ideia teve de ser abandonado. Estava pensando sobre como determinar o tamanho do disco, mas, percebendo a estabilidade de diferentes versões da BIOS, há um risco de que o algoritmo porque ele também não vai funcionar de forma estável.

Problemas ao parar e re-inicializar 3,0 controladores PIC USB (HP, BIOS)

Visualmente, o problema ficou assim: depois que o usuário se conectou com sucesso o cartão inteligente e entrou no PIN, a tela escureceu, uma mensagem indicando que o sistema operacional está carregando, e todas as paradas sobre este relatório. PC congela duro.

Desde o carregador de inicialização do BIOS é projetado com base em um RTOS, muito corridas shell de usuário em modo protegido, o processador, o que, naturalmente, exigem re-inicialização do controlador PIC clássico. Assim, durante a transmissão do processador de controlo do carregador OS retorna para o modo real. E este, por sua vez, exigiu o PIC retorna ao seu estado original.

A análise preliminar revelou que o processador é devolvido para o modo real, mas Além disso, há trava ou PC. Além disso, descobriu-se que o problema só surge se o bootloader inicializa os controladores de host USB.Antes de voltar para o modo real e antes da PIC redefinir e parar os controladores de host USB.

Controlador USB 3.0 host pode ter um USBLEGSUP registo. Este registo permite o controlo do BIOS do controlador de transmissão para o sistema operacional, e vice-versa. Em primeiro lugar, pode ser necessário, por exemplo, para emular o teclado clássico portas I / O, a fim de garantir a compatibilidade com programas antigos. Ou seja, quando se refere a estas portas será um SMI, e tudo o mais tem que fazer o manipulador de interrupção. Mas em máquinas modernas única todos USB teclado são usados ​​com mais frequência.registar formato é descrito abaixo.

  • ID Capability (bits 0-7) – recurso ID. Para um determinado campo de registo 1 igual a
  • Próxima Pointer Capability (bits 8-15) – ponteiro para o próximo capacidade de registo
  • HC BIOS Propriedade semáforo (bit 16) – se definir, isso significa BIOS controla o controlador hospedeiro
  • Reservado (bits 17-23)
  • HC OS Propriedade semáforo (bit 24) – antes de usar controlador hospedeiro sistema operativo deve definir este bit, em resposta a este bit repõe o BIOS 16 então pode usar o controlador hospedeiro
  • Reservado (bits 25-31)

RTOS quando parar o controlador de host 24 também redefine o bit USBLEGSUP registo. Assim, ele devolve o controlo do mesmo para o BIOS. Próxima RTOS executa retornos controlador PIC para seu estado original.Sabe-se também que o hardware do controlador PIC já não existe e ele também emulado para significa SMM-mode. Portanto, quando o controlador PIC retorna ao seu estado original quando se regista com a interrupção SMI ocorreu. A análise revelou que, como RTOS não espera para a criação de 16 bits no registo USBLEGSUP e desde que imediatamente após o bit 24 deste registo são devolvidos controlador PIC ao seu estado original, um código de modo para o SMM controle de retorno sobre o controlador de host e controlador PIC, o que, de fato, gerado SMI interrupção não é processado em tudo. Uma vez que a inicialização PIC é realizada em várias etapas, o controlador de estado foi parcialmente neproinitsializirovannom. Devido a isso, ele quebrou a entrega de interrupção. Imediatamente após o retorno da CPU em modo real na primeira interrupção do CPU subiu para um vector inválida, razão pela qual ele começou a executar um fluxo sem sentido de instruções.

O problema era para ignorar através do bit de espera para 16 no registo USBLEGSUP PIC antes de retornar ao estado inicial.

problemas de entrega a partir do controlador de interrupção PIC (Dell Latitude E7240, BIOS)

Externamente, o problema ficou assim: quando o carregador já começou e levou a um convite para a conexão de cartão inteligente, o carregador pendurado com força. Quando este problema ocorreu apenas quando você reiniciar o computador quando você ligá-lo funcionou bem.

A análise preliminar revelou que o processador é despejado em uma falha de página. Um estudo subsequente do problema mostrou que para cada SOTR interrompe utiliza pilhas separadas, que são muito pequenas em tamanho (256 bytes). Todas estas pilhas estão localizadas de modo adjacente, como reflectido na figura abaixo.

Além disso, descobrimos que a falha de página ocorreu na página de memória, que se seguiu imediatamente na primeira página com pilhas interrupções. Portanto, uma análise mais aprofundada foi realizada já neste nível.

RTOS quando a inicialização do controlador host USB também inclui a entrega com a linha PIC interrupção no qual o controlador está localizado. Ao chamar o manipulador de interrupção permite todas as interrupções na CPU, e em seguida, faz sequencialmente manipuladores registrados para esta linha. Depois de invocar todos os manipuladores para o manipulador de interrupção envia uma completa controlador PIC comando de interrupção (EOI).

Sabe-se que um registo ISR controlador PIC. Este registo é usado para determinar quais interrupção está processando o processador, e que não são. E se o processador processa uma interrupção específica, mesmo que a linha correspondente está presente inquérito, não vai ser entregue. Enquanto o processador não dará comando EOI para o PIC, em seguida, o PIC retomará o fornecimento da interrupção.

A análise posterior revelou que no curso de tratadores de chamada para o controlador PIC interrupção entregue repetidamente, apesar do fato de que o comando EOI ainda não foi enviado ao PIC. Claro, isso emulação de erro do controlador PIC. Isto levou ao fato de que o primeiro sobrecarregada pilha correspondente interrupção, então estragar outra pilha de interrupção, e, finalmente, o acesso é feito a página de memória não-display. E isso levou à falha de página, que o condutor pára o carregador.

O problema era para contornar através da proibição de entrega de interrupções no controlador PIC correspondente para os manipuladores para chamar e sua resolução após a sua chamada.

conclusão

Esta lista de correções está longe de terminar. Ele descreve apenas os casos que poderia se lembrar. Pior de tudo, até agora não conseguiram chegar a uma solução radical para o problema da estabilidade. Só conseguiu alcançar a estabilidade apenas em alguns momentos. Ainda nos deparamos com casos de erros que tenham sofrido desenvolvedores inventar. E pior ainda, passar três dias na análise e eliminação do problema. E alguns casos estão longe de ser fácil. Três dias para corrigir o problema, é claro, não tanto, mas quando problemas com uma dúzia, isso é bom batidas do horário de trabalho.

Compreender a realidade forçado a engenharia reversa do Windows bootloader a fim de compreender quais os mecanismos que ele usa. Para mim, isso significa que eu também pode usá-los com segurança. Se você desviar-se estas regras, então o trabalho do carregador não pode ser garantida.

Depois de mais alguns problemas USB em UEFI Eu vim para o fato de que no carregador para colocar o driver de controlador de host. Para isso temos de parar os motoristas que trabalham no UEFI-, e carregar a sua própria. Adicionar os chamados “picos” Eu nunca fiquei impressionado. Além disso, o seguinte código irá eventualmente tornar-se difícil desenvolver por causa da pilha.

E, como para os seus condutores, em que há um monte de sentido, porque Modo lá fastboot, o que não garante o carregamento de USB-motorista. Não é um bug, mas uma pedra na direção da UEFI como um padrão, que não oferece motoristas descarregadas mecanismo de recarga.

No final da descrição dos problemas que eu gostaria de observar o seguinte: há uma impressão de que o atual BIOS / UEFI desenvolvidas isoladamente a partir da compreensão completa dos princípios de funcionamento desses sistemas, ou teste não é realizado corretamente. De acordo com a experiência, tanto ocorrendo. É suficiente que produziu no PC para executar o Windows e Linux. Tudo o resto – o custo de produção. E quem vai culpar o cliente, eu acho que não é necessário dizer.

Com base na experiência, BIOS e UEFI são os ambientes de execução mais instáveis. Em particular, EFI MacBook é uma exceção especial, e para trabalhar com ele o mais difícil. Mas isso é outra história.

Anúncios