On 09/22/2013 04:07 PM, Roy Franz wrote:
On Sun, Sep 22, 2013 at 3:54 PM, H. Peter Anvin h...@zytor.com wrote:
Sorry this version is broken and doesn't even compile due to remaining
options_size references.
I compiled and tested this series on both x86_64 (using OVMF) and on
the ARM
A general note:
In multiline comments like:
/* Relocate a kernel image, either compressed or uncompressed.
* In the ARM64 case, all kernel images are currently
* uncompressed, and as such when we relocate it we need to
* allocate additional space for the BSS segment. Any low
* memory that
, of course.
-hpa
From 7d6cf630c1adbb9787a24c2994230373c2b20a8f Mon Sep 17 00:00:00 2001
From: H. Peter Anvin h...@linux.intel.com
Date: Fri, 20 Sep 2013 09:55:39 -0500
Subject: [PATCH] efi: Handle arbitrary Unicode characters
Instead of truncating UTF-16 assuming all characters is ASCII
On 09/18/2013 10:44 PM, Adam Borowski wrote:
In fact, these days it's 8-bit encodings that are more likely to be Unicode
than 16-bit ones: UTF-8 is ubiquitous, while you usually get UCS2 at most.
In either case, though, we have here is a 7-bit charset encoded as either
8-bit or 16-bit units.
On 09/13/2013 08:37 AM, Arend van Spriel wrote:
I need to obtain a uefi variable so I went looking at the API in
include/linux/efi.h. I found the following definition:
But according to the specs the variable I need to obtain is 2k bytes.
Should I expect trouble :-p
efivarfs doesn't have
On 09/10/2013 11:26 AM, Matthew Garrett wrote:
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to the
On 09/10/2013 12:17 PM, David Lang wrote:
In theory these blobs are traceable to a manufacturer. It's not really
an indication that it's safe more than it's an indication that it
hasn't been changed. But I haven't chased this very hard yet because
of below...
well, not if you are trying to
On 09/10/2013 04:55 PM, Mimi Zohar wrote:
What would the deliverables be from the hardware vendor and what tools
would you expect them to need on their end?
The package installer needs to not only install files, but file metadata
as well. Elena Reshetova (Intel) has already added rpm hooks
On 09/09/2013 09:30 AM, Matthew Garrett wrote:
On Mon, 2013-09-09 at 09:27 -0700, H. Peter Anvin wrote:
This will break or have to be redefined once you have signed kexec.
Yeah. I wasn't really sure how to define it based on an implementation
that isn't there yet - saying kexec_load
On 09/09/2013 08:49 AM, Matthew Garrett wrote:
Provide a coarse-grained runtime configuration option for restricting
userspace's ability to modify the running kernel.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
Documentation/security/securelevel.txt | 23 +++
I.e. capabilities ;)
Circles. All I see here are circles.
Having lived an entire release with a capabilities based mechanism for
this in Fedora, please no.
And if you are talking about non-POSIX capabilities as you mentioned
earlier, that seems to be no different than having
On 09/09/2013 12:58 PM, Josh Boyer wrote:
This is the term capability in the general sense, not the POSIX
implementation thereof.
See the whole last paragraph. Particularly the last sentence.
Yes. I disagree with not being able to use standard terminology.
-hpa
--
To
On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote:
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
Given that we know that people want signed binaries without
blocking kexec, you should have '1' just enforce module signing
and '2' (or higher) implement a full lockdown including
Sigh. That capability really is fscked up.
Matthew Garrett matthew.garr...@nebula.com wrote:
On Wed, 2013-09-04 at 20:52 -0700, H. Peter Anvin wrote:
On 09/03/2013 04:50 PM, Matthew Garrett wrote:
IO port access would permit users to gain access to PCI
configuration
registers, which in turn
On 09/03/2013 04:50 PM, Matthew Garrett wrote:
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down by default.
On 08/29/2013 11:37 AM, Josh Boyer wrote:
setup_efi_pci(boot_params);
diff --git a/arch/x86/include/uapi/asm/bootparam.h
b/arch/x86/include/uapi/asm/bootparam.h
index c15ddaf..d35da96 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@
On 08/29/2013 11:35 AM, Matthew Garrett wrote:
On Thu, 2013-08-29 at 11:22 -0700, H. Peter Anvin wrote:
On 08/19/2013 09:10 AM, Matthew Garrett wrote:
+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
Stale bits?
Yeah. Did I manage to send out the old copy
On 08/29/2013 11:49 AM, Matthew Garrett wrote:
No, you mixed and matched in a single patch...
Right, but I'd fixed that in V2 (which I see I *did* send correctly, and
you're just replying to the old one :))
Well, I'm responding to the one that was sent 31 minutes ago.
-hpa
--
On 08/09/2013 08:38 AM, H. Peter Anvin wrote:
On 08/09/2013 08:32 AM, James Bottomley wrote:
On Fri, 2013-08-09 at 08:23 -0700, H. Peter Anvin wrote:
I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB
to y. There is little reason to omit this since EFI now
On 08/13/2013 11:43 AM, James Bottomley wrote:
James, does this address your concerns?
You mean for globally enabling CONFIG_EFI on x86? not really for 32
bit, you say above it's pretty much unusable; I'd prefer just to enable
it for 64 bit. As you said in your original post since EFI now
On 08/13/2013 12:02 PM, James Bottomley wrote:
On Tue, 2013-08-13 at 11:52 -0700, H. Peter Anvin wrote:
On 08/13/2013 11:43 AM, James Bottomley wrote:
Can we actually boot a 32 bit kernel on an EFI64 system? The last time
I tried on my Secure Boot SDV it wouldn't work; the problem is getting
I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB
to y. There is little reason to omit this since EFI now is a
significant percentage of all systems.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to
On 08/05/2013 06:02 AM, Matt Fleming wrote:
On Tue, 30 Jul, at 08:52:12PM, Ingo Molnar wrote:
Pulled into tip:x86/urgent, thanks Matt!
Thanks Ingo.
Any chance we can get this to Linus for -rc5? The ARM EFI boot stub
patches depend on the bug fix in this pull request.
Yes, we should
On 08/05/2013 11:12 AM, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 08:50:17AM -0700, Andrew Fish wrote:
AFAICT EFI pre-dates kexec merge into mainline by a number of years as
SetVirtualaddressMap() was part of EFI 1.0 (previous millennium)
Ok, fair enough.
The EFI to UEFI conversion
On 08/05/2013 02:41 PM, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 02:37:08PM -0700, H. Peter Anvin wrote:
All of this would be a non-problem if there weren't buggy
implementations which can't run *without* SetVirtualAddressMap().
Oh, you mean, if we were to call the runtime services
On 07/10/2013 04:39 AM, Fleming, Matt wrote:
On 10 July 2013 12:34, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Hey,
It seems that in the merge window my macbook pro stopped working at some
point. I looked for suspicious
efi related commits, and found that reverting commit
On 07/08/2013 10:29 AM, Luck, Tony wrote:
Tony Luck (1):
[IA64] sim: Add casts to avoid assignment warnings
arch/ia64/hp/sim/boot/fw-emu.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
I
On 06/26/2013 07:38 AM, James Bottomley wrote:
On Wed, 2013-06-26 at 14:59 +0100, Matt Fleming wrote:
On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote:
It's completely feasible, but we'd need to use a different method to do
the boot services call with a 1:1 mapping (idmap support is not
20, 2013 at 03:35:24PM -0700, H. Peter Anvin wrote:
On 06/20/2013 11:47 AM, Borislav Petkov wrote:
I guess we can do a top-down allocation, starting from the highest
virtual addresses:
EFI_HIGHEST_ADDRESS
|
| size1
|
-- region1
|
| size2
|
-- region2
The 0xa restriction applies to BIOS really...
m...@console-pimps.org m...@console-pimps.org wrote:
On Tue, 18 Jun, at 10:12:22PM, Zachary Bobroff wrote:
Okay, I'm fine with that aspect then. Let's hope everyone plays by
that rule.
This is all according to specification, so if they are
On 06/19/2013 08:02 AM, Borislav Petkov wrote:
And yet there are the Macs which reportedly cannot stomach this.
No, the reports are that if you use the 1:1 map as the primary address
on Macs the drivers fail... not that you can't have a 1:1 map.
-hpa
--
To unsubscribe from this
On 06/19/2013 12:37 PM, Borislav Petkov wrote:
On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote:
On 06/19/2013 08:02 AM, Borislav Petkov wrote:
And yet there are the Macs which reportedly cannot stomach this.
No, the reports are that if you use the 1:1 map as the primary
On 06/06/2013 08:58 AM, Borislav Petkov wrote:
--
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 654be4ae3047..7a6129afdff1 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1021,6 +1021,9 @@ __do_page_fault(struct pt_regs *regs, unsigned long
error_code)
On 06/05/2013 08:59 AM, Matt Fleming wrote:
+ * There still isn't enough room, so return an error
+ */
+ if (remaining_size - size 5120)
+ return EFI_OUT_OF_RESOURCES;
+ }
Please don't open-code the constant 5120 in this case.
On 05/29/2013 01:16 PM, Russ Anderson wrote:
To be more specific (now that I've dug through the code), grub2 (used
by rhel7) uses EFI boot stubs. grub and elilo apparently do not use
EFI boot stubs, so they don't hit the problem (at least on my test
systems).
Grub2 *can* use the EFI boot
Nope, just a vehicle for experiments.
Greg KH gre...@linuxfoundation.org wrote:
On Thu, Apr 18, 2013 at 11:00:27PM -0700, H. Peter Anvin wrote:
The only real use for command line options is to be able to get users
to test something during troubleshooting.
Ok, but the option shouldn't be used
On 04/19/2013 10:38 AM, Matt Fleming wrote:
Hi guys,
There's a few bug fixes sitting in the EFI urgent branch. Please
consider pulling.
We are *post -rc7* and days away from release.
I can't push this to Linus without a detailed description of what this
is and why we need it now.
Yes, I
On 04/19/2013 10:38 AM, Matt Fleming wrote:
Richard Weinberger (2):
x86,efi: Check max_size only if it is non-zero.
x86,efi: Implement efi_no_storage_paranoia parameter
OK, I'll pull this for now, but this *really* need to be an automatic
quirk of some sort, especially when
On 04/18/2013 09:33 AM, Josh Triplett wrote:
On Thu, Apr 18, 2013 at 12:00:26PM +0100, Matt Fleming wrote:
No, no - we *don't* have a BGRT object at all.
We have a completely clean memory map - but the BGRT code is causing the
is_ram() failure.
You assume that mapping of the Boot Services
On 04/18/2013 01:17 PM, Darren Hart wrote:
Ah, well then I've misunderstood the nature of the problem a bit. Will
have to spend some time understanding this better.
Way, way too many people misunderstand HIGHMEM.
-hpa
--
To unsubscribe from this list: send the line unsubscribe
parameter for what?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
in the process. Sure, it has to
be mapped before you can copy it out, but that usually isn't a big deal.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line unsubscribe linux-efi
On 04/04/2013 05:18 AM, Matt Fleming wrote:
From: Matt Fleming matt.flem...@intel.com
drivers/firmware/efivars.c has grown pretty large and is ~2K lines.
Hi Matt,
Are you expecting me or Matt G. to take this one?
-hpa
--
To unsubscribe from this list: send the line unsubscribe
CAP_SYS_RAWIO is definitely inappropriate there.
Matthew Garrett matthew.garr...@nebula.com wrote:
On Tue, 2013-03-19 at 18:02 -0700, H. Peter Anvin wrote:
Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the
possibility
of compromising the kernel, because they let device drivers
On 03/20/2013 08:14 AM, Matthew Garrett wrote:
On Wed, 2013-03-20 at 08:03 -0700, H. Peter Anvin wrote:
CAP_SYS_RAWIO is definitely inappropriate there.
Ok. How do we fix that without breaking userspace that expects
CAP_SYS_RAWIO to be sufficient?
I don't think we can to some way, because
On 03/18/2013 02:32 PM, Matthew Garrett wrote:
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down by default.
.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
their head over where to sprinkle this.
Apart from that, I like the idea, especially when it's wired up to MAC
security.
The wiring up to MAC security is a nice touch.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf
On 03/19/2013 06:02 PM, H. Peter Anvin wrote:
Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility
of compromising the kernel, because they let device drivers be bypassed,
which means arbitrary DMA, which means you have everything.
Well, *unless* you have an iommu
On 03/19/2013 06:07 PM, Matthew Garrett wrote:
Yeah, I'd like the option of relaxing restrictions when drivers explicitly
opt in based on iommu support.
When drivers opt in they can provide an interface. The interesting case
becomes non-drivers.
-hpa
--
H. Peter Anvin, Intel Open
On 03/19/2013 08:18 PM, Alex Williamson wrote:
The pinning process needs to involve a call to the kernel to process
the page for DMA (pinning the page and opening it in the iommu) and
return a transaction address, of course.
I think we have the interface for that in vfio, but I haven't
On 03/18/2013 11:04 AM, Matt Fleming wrote:
On 03/18/2013 03:32 PM, David Woodhouse wrote:
On Mon, 2013-03-18 at 15:16 +, Matt Fleming wrote:
See,
commit 53b87cf0 (x86, mm: Include the entire kernel memory map in
trampoline_pgd),
commit 185034e7 (x86, efi: 1:1 pagetable mapping
as an additional patch.
That way it can be enabled if needed, without the user having to build
their own kernel.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line unsubscribe linux
On 03/01/2013 02:53 PM, Borislav Petkov wrote:
Adding a few more people.
This has been a big topic, and yes, we have a problem.
We seem to have a few options:
1. We could always map 1:1, with the EFI mappings being in the user
part of the virtual address space. This MAY be what Windows
On 03/01/2013 03:39 PM, Borislav Petkov wrote:
Just commenting on this one for now, the rest tomorrow cuz I'm half
asleep.
On Fri, Mar 01, 2013 at 11:30:25PM +, David Woodhouse wrote:
The other option, for the long term, is to fix the damn firmware to
allow SetVirtualAddressMap to be
On 03/01/2013 03:07 PM, Borislav Petkov wrote:
Hmm, yeah, that's nasty. This also means option #2 can go too because
of the fixed addresses. Option #1 is also kinda polluting user address
space so maybe the most elegant one would be #4, AFAICT.
No, it doesn't pollute the user address
such a thread.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Yes, but way before... not a problem. It isn't a thread in the scheduler sense.
David Woodhouse dw...@infradead.org wrote:
On Fri, 2013-03-01 at 17:11 -0800, H. Peter Anvin wrote:
On 03/01/2013 03:30 PM, David Woodhouse wrote:
On Sat, 2013-03-02 at 00:07 +0100, Borislav Petkov wrote:
Hmm
On 02/13/2013 12:27 AM, Paolo Bonzini wrote:
On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially
when coupled with file DAC.
File DAC?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe
On 02/13/2013 11:55 AM, Paolo Bonzini wrote:
Il 13/02/2013 18:22, H. Peter Anvin ha scritto:
On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially
when coupled with file DAC.
Discretionary Access Control.
Either way, I think you are at best deluded and more like you just
On 02/13/2013 05:04 PM, Matthew Garrett wrote:
On Wed, 2013-02-13 at 16:44 -0800, Casey Schaufler wrote:
If you want that sort of granularity throw yourself on the SELinux
bandwagon. Fine grained capabilities are insane and unmanageable
and will only lead to tears. Security is despised
, 2013 at 11:42 AM, H. Peter Anvin h...@zytor.com wrote:
On 02/08/2013 11:18 AM, Kees Cook wrote:
No. CAP_RAWIO is for reading. Writing needs a much stronger check.
If so, I suspect we need to do this for *all* raw I/O... but I keep
wondering how much more sensitive writing really is than reading
On 02/08/2013 01:02 PM, Kees Cook wrote:
On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett
matthew.garr...@nebula.com wrote:
On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote:
Maybe a capability isn't the right way to go, I'm not sure. I'll leave
that to Matthew. Whatever the flag, it should
On 01/19/2013 03:40 PM, Ellwood Blues wrote:
Hi.
I've had this problem for so long that today after compiling kernel
3.7.3 and not getting any improvements I decided to let you know that
some of us still only able to use our GPT 3TB hard disks only on
Windows.
On linux only hdparm and
Well, *I* am confused as heck. They look like bitmasks, we normally use
decimal numbers for bit numbers as a matter of style.
Matt Fleming m...@console-pimps.org wrote:
On Fri, 2013-01-04 at 08:08 -0700, Tim Gardner wrote:
On 01/03/2013 06:18 AM, Matt Fleming wrote:
From: Matt Fleming
On 01/02/2013 09:43 AM, Matthew Garrett wrote:
On Wed, Jan 02, 2013 at 08:26:29AM -0500, Shea Levy wrote:
Hm, ok. Does the boot stub have access to CONFIG_CMDLINE? Or could
another compile-time setting be added so that distros can ship livecds
that automatically use a config file found at
On 01/02/2013 09:21 AM, Nathan Zimmer wrote:
I am getting an early boot problem. It only happens on the larger of the
machines I haven't seen it crop up on machines with more then 512 GB of ram.
It shows in the latest linus kernel too.
I am (wildly) guessing that what is happening is that
On 01/01/2013 07:55 AM, Shea Levy wrote:
Hi all,
In March last year, I submitted a patch to enable the EFI boot stub to
read its config arguments from a file on the ESP, both to help with
booting from livecds and to avoid having to use efibootmgr every time
you change your boottime
On 12/26/2012 12:00 AM, Borislav Petkov wrote:
On Sat, Dec 22, 2012 at 11:23:25AM +0100, Stefan Hasko wrote:
Fixed different size cast warnings in function setup_efi_pci
Signed-off-by: Stefan Hasko hasko.st...@gmail.com
You might want to add the actual compiler warnings to the commit
On 12/28/2012 11:17 AM, Matthew Garrett wrote:
On Fri, 2012-12-28 at 11:07 -0800, H. Peter Anvin wrote:
We do have such machines, which is why this change has been reverted twice
already. I believe we should stick to the priority scheme I proposed a few
weeks ago.
I seem to have missed
On 12/28/2012 12:49 PM, Matthew Garrett wrote:
On Fri, 2012-12-28 at 12:40 -0800, H. Peter Anvin wrote:
I suspect that what we *should* do looks like:
1. If ACPI exports a Time and Alarm Device (ACPI000E) the use it;
2. If ACPI exports an PC/AT device (PNP0B00/1/2) then use it(*);
3. If we
On 12/28/2012 05:00 PM, joeyli wrote:
於 五，2012-12-28 於 17:43 +，Matthew Garrett 提到：
On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime()
are also
supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
-#ifndef CONFIG_DEBUG_BOOT_PARAMS
-struct boot_params __initdata boot_params;
-#else
struct boot_params boot_params;
-#endif
No, that is not a right fix
We should only cache pointer to setup_data.
at the same time we should export
On 12/05/2012 04:30 PM, Yinghai Lu wrote:
On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/05/2012 04:18 PM, Matthew Garrett wrote:
Because it also needs to modify it. Right now kexec userspace
synthesizes struct boot_params from scratch, and does so incorrectly
On 12/05/2012 05:13 PM, Matthew Garrett wrote:
H. Peter Anvin h...@zytor.com wrote:
And that presumably would be something that cannot be exposed to root?
If so we may want to use one of the bits in the setup_data type field
as
a security flag, perhaps...
Yeah, it needs to be hidden from
On 12/03/2012 07:18 PM, joeyli wrote:
於 二，2012-09-04 於 11:43 -0700，H. Peter Anvin 提到：
On 08/28/2012 08:48 PM, joeyli wrote:
Hi all experts,
I tried the EFI_STUB on v3.6-rc1 kernel on Intel DQ57TM board with B.11
BIOS that's the only one sample board on my hand. I found it can't boot
success
On 11/13/2012 02:00 PM, Matt Fleming wrote:
Hi guys,
The following changes since commit 5189c2a7c7769ee9d037d76c1a7b8550ccf3481c:
x86: efi: Turn off efi_enabled after setup on mixed fw/kernel (2012-10-25
19:09:40 +0100)
are available in the git repository at:
On 11/07/2012 10:54 PM, Matthew Garrett wrote:
Is there a case where modifying MSRs or EC registers can cause arbitrary
code execution?
It definitely can't be ruled out.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to
On 11/07/2012 10:54 PM, Matthew Garrett wrote:
Is there a case where modifying MSRs or EC registers can cause arbitrary
code execution?
For MSRs we could have a whitelist of permitted MSRs, but allowing
general MSR access... no.
-hpa
--
To unsubscribe from this list: send the line
On 11/05/2012 07:14 AM, Eric W. Biederman wrote:
In any case the notion that unattended install with no user interaction
on any uefi machine in any state is complete and total rubbish. It
can't be done. You need power and you need boot media.
That is a hugely different thing from needing
101 - 180 of 180 matches
Mail list logo
