R: Re: R: Re: R: Re: CAN BIOS/UEFI DO WRITING OPERATIONS ON ATTACHED DRIVES BY MEANS OF INT 13 H INTERRUPT ?
Dear Colin, You has been very clear about the GRUB design. Please, let me pose another question, because i see you have a solid experience and you are precise. Do you know if the Ubuntu kernel uses BIOS services, in particular the INT 13H interrupt, or if it is BIOS indipendent ? In this last case in which a way Ubuntu treats the low-level disk services ? If I well understood Ubuntu should intercept the call and passes it to the operating system's native disk I/O mechanism, bypassing BIOS routines for the low-level disk reading/writing access. Thanks in advance. Your tips are welcome. Best Regards. Vincenzo. Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo Messaggio originale Da: cjwat...@ubuntu.com Data: 18-lug-2017 13.28 A: "ingegneriafore...@alice.it" Cc: Ogg: Re: R: Re: R: Re: CAN GRUB DO WRITING OPERATIONS ON ATTACHED DRIVES ? On Tue, Jul 18, 2017 at 12:38:33PM +0200, ingegneriafore...@alice.it wrote: > I've read with interest your reply and i gave a look at the grub code. > > You wrote an important assertion: "GRUB intentionally has no filesystem > writing support". > > So, the writing operations that grub can do, only be sent to a pre-allocated > memory regions of the disk different in any case from that allocated by the > OS for the filesystem, where the user data are stored. > > This means that grub never can corrupt the user data. > > Please, can you confirm if this my conclusion is right ? Because is this > the crucial question i need to solve. I would never want to rule out the possibility of strange bugs, but that is certainly the design. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: R: Re: R: Re: R: Re: CAN BIOS/UEFI DO WRITING OPERATIONS ON ATTACHED DRIVES BY MEANS OF INT 13 H INTERRUPT ?
On Mon, Jul 24, 2017 at 11:25:31AM +0200, ingegneriafore...@alice.it wrote: > You has been very clear about the GRUB design. > > Please, let me pose another question, because i see you have a solid > experience and you are precise. > > Do you know if the Ubuntu kernel uses BIOS services, in particular the INT > 13H interrupt, or if it is BIOS indipendent ? In this last case in which a > way Ubuntu treats the low-level disk services ? > > If I well understood Ubuntu should intercept the call and passes it to the > operating system's native disk I/O mechanism, bypassing BIOS routines for the > low-level disk reading/writing access. I'm afraid that I'm not a kernel developer and can't answer this with any authority. My understanding is that the Linux kernel typically doesn't use BIOS services for disk I/O since it's running in protected mode, but it's possible that there are some edge cases where this isn't true. You'd need to find an actual kernel developer to be authoritative about this, though. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] Core TPM support
On Wed, Jul 05, 2017 at 02:19:57PM -0700, Matthew Garrett wrote:
> Add support for performing basic TPM measurements. Right now this only
> supports extending PCRs statically and only on UEFI.
> ---
> grub-core/Makefile.core.def| 7 +
> grub-core/commands/efi/tpm.c | 282
> +
> grub-core/commands/tpm.c | 87 +
> grub-core/kern/i386/efi/init.c | 1 +
> include/grub/efi/tpm.h | 153 ++
> include/grub/tpm.h | 74 +++
> 6 files changed, 604 insertions(+)
> create mode 100644 grub-core/commands/efi/tpm.c
> create mode 100644 grub-core/commands/tpm.c
> create mode 100644 include/grub/efi/tpm.h
> create mode 100644 include/grub/tpm.h
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 16c4d0ea5..ca1caa1fe 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -2375,6 +2375,13 @@ module = {
>common = commands/testspeed.c;
> };
>
> +module = {
> + name = tpm;
> + common = commands/tpm.c;
> + efi = commands/efi/tpm.c;
> + enable = efi;
> +};
> +
> module = {
>name = tr;
>common = commands/tr.c;
> diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
> new file mode 100644
> index 0..c9fb3c133
> --- /dev/null
> +++ b/grub-core/commands/efi/tpm.c
> @@ -0,0 +1,282 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static grub_efi_guid_t tpm_guid = EFI_TPM_GUID;
> +static grub_efi_guid_t tpm2_guid = EFI_TPM2_GUID;
> +
> +static grub_efi_boolean_t grub_tpm_present(grub_efi_tpm_protocol_t *tpm)
> +{
> + grub_efi_status_t status;
> + TCG_EFI_BOOT_SERVICE_CAPABILITY caps;
> + grub_uint32_t flags;
> + grub_efi_physical_address_t eventlog, lastevent;
> +
> + caps.Size = (grub_uint8_t)sizeof(caps);
> +
> + status = efi_call_5(tpm->status_check, tpm, &caps, &flags, &eventlog,
> + &lastevent);
> +
> + if (status != GRUB_EFI_SUCCESS || caps.TPMDeactivatedFlag
> + || !caps.TPMPresentFlag)
> +return 0;
> +
> + return 1;
> +}
> +
> +static grub_efi_boolean_t grub_tpm2_present(grub_efi_tpm2_protocol_t *tpm)
> +{
> + grub_efi_status_t status;
> + EFI_TCG2_BOOT_SERVICE_CAPABILITY caps;
> +
> + caps.Size = (grub_uint8_t)sizeof(caps);
> +
> + status = efi_call_2(tpm->get_capability, tpm, &caps);
> +
> + if (status != GRUB_EFI_SUCCESS || !caps.TPMPresentFlag)
> +return 0;
> +
> + return 1;
> +}
> +
> +static grub_efi_boolean_t grub_tpm_handle_find(grub_efi_handle_t *tpm_handle,
> +grub_efi_uint8_t
> *protocol_version)
> +{
> + grub_efi_handle_t *handles;
> + grub_efi_uintn_t num_handles;
> +
> + handles = grub_efi_locate_handle (GRUB_EFI_BY_PROTOCOL, &tpm_guid, NULL,
> + &num_handles);
> + if (handles && num_handles > 0) {
> +*tpm_handle = handles[0];
> +*protocol_version = 1;
> +return 1;
> + }
> +
> + handles = grub_efi_locate_handle (GRUB_EFI_BY_PROTOCOL, &tpm2_guid, NULL,
> + &num_handles);
> + if (handles && num_handles > 0) {
> +*tpm_handle = handles[0];
> +*protocol_version = 2;
> +return 1;
> + }
> +
> + return 0;
> +}
> +
> +static grub_err_t
> +grub_tpm1_execute(grub_efi_handle_t tpm_handle,
> + PassThroughToTPM_InputParamBlock *inbuf,
> + PassThroughToTPM_OutputParamBlock *outbuf)
> +{
> + grub_efi_status_t status;
> + grub_efi_tpm_protocol_t *tpm;
> + grub_uint32_t inhdrsize = sizeof(*inbuf) - sizeof(inbuf->TPMOperandIn);
> + grub_uint32_t outhdrsize = sizeof(*outbuf) - sizeof(outbuf->TPMOperandOut);
> +
> + tpm = grub_efi_open_protocol (tpm_handle, &tpm_guid,
> + GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> +
> + if (!grub_tpm_present(tpm))
> +return 0;
> +
> + /* UEFI TPM protocol takes the raw operand block, no param block header */
> + status = efi_call_5 (tpm->pass_through_to_tpm, tpm,
> +inbuf->IPBLength - inhdrsize, inbuf->TPMOperandIn,
> +outbuf->OPBLength - outhdrsize, outbuf->TPMOperandOut);
> +
> + switch (status) {
> + case GRUB_EFI_SUCCESS:
> +return 0;
> + case GRUB_EFI_DEVICE_ERROR:
> +return grub_error (GRUB_ERR_IO, N_("Command failed"));
> + case GRUB_EFI_INVALID_PARAMETER:
> +return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("Invalid parameter"));
> + case GRUB_EFI_BUFFER_TOO_SMALL:
> +return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("Output buffer too small"));
> + case GRUB_EFI_NOT_FOUND:
> +return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("TPM unavailable"));
> + default:
> +return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("Unknown TPM error"));
> + }
> +}
> +
> +static grub_err_t
> +grub_tpm2_execute(grub_efi_handle_t tpm_handle,
> + PassThroughToTPM_InputParamBlock *inbuf,
> + PassThr
Re: [PATCH 1/2] Verify commands executed by grub
On Sat, Jul 22, 2017, 00:13 Matthew Garrett wrote: > On Fri, Jul 21, 2017 at 7:39 AM, Vladimir 'phcoder' Serbinenko > wrote: > > This omits all separators. So it considers e.g. ab and a b to be the > same. > > Can we have a better array serialization? I.a. following 3 need to be > > distinguished: > > ab > > a b > > "a b" > > It inserts a space after each argv, so I think ab and a b are already > distinguishable in the output? "a b" isn't, however, and that's > certainly a problem. I can see a few approaches to this: > > 1) Delimit with \0. That makes parsing the result more annoying, but > avoids any ambiguity. > I like this possibility. I'll change string hashing to a byte array hashing in verifiers API > 2) Add quotes back in for any arguments that contain spaces > 3) Do the verification before any parsing. Downside is that we don't > get any variable expansion, which doesn't really matter for the TPM > case but might not work for other use cases? > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] Core TPM support
Thanks, fixed those up. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
