What would a "malicious application of hypervisor" look like?
How would that be different from a "malicious application of hardware"?
Generally speaking, we're talking "grey boxes" here, I imagine. And, I
guess, I'd expect either unwanted internet traffic or unwanted radio
traffic. Detection of e
>>Returning back to the discussion where I suggested it would be nice to
>>build OS kernels that would fail deliberately when virtualized to close
>>off that class of malware, especially on the new Intel Skylake chips
>>that have fixed so many virtualization bugs that they can (reportedly)
>>run VT
On 24 December 2015 08:00:01 GMT+00:00, Dragos Ruiu wrote:
>Returning back to the discussion where I suggested it would be nice to
>build
>OS kernels that would fail deliberately when virtualized to close off
>that
>class of malware, especially on the new Intel Skylake chips that have
>fixed
>so m
Read, James C' ; 'Theo de Raadt'
; 'OpenBSD general usage list' ;
owner-m...@openbsd.org
Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback]
>On 2015-12-23 10:04, Dragos Ruiu wrote:
>> Ok let me short circuit this meta discussion by saying tha
>On 2015-12-23 10:04, Dragos Ruiu wrote:
>> Ok let me short circuit this meta discussion by saying that AFAIK now
>> that the new Intel Skylake chips fixed many virtualization bugs
>
>Curious, where can I read about this, URL?
The canonical reference is still (and I looked for better summaries bu
On 2015-12-23 18:14, Dragos Ruiu wrote:
Sure you could spend the rest of your life checking all the firmware
and
trying to design separate specialized tools for the myriad of devices
in a
modern PC - and there is a lot more than your simple list, see the
presentation Mickey Shkatov and Jesse Mi
On 2015-12-23 10:04, Dragos Ruiu wrote:
Ok let me short circuit this meta discussion by saying that AFAIK now
that
the new Intel Skylake chips fixed many virtualization bugs
Curious, where can I read about this, URL?
and it's possible
to efficiently nest VMs there might not be a way to disco
> But I get it, it's hard, so you can throw up your hands and give up by
> saying that's not our problem, not an OS issue.
As coders, it is very much not our problem.
We just happen to run on some vendor hardware, often poorly documented
and inconsistant generation to generation (even when it is
On Wed, Dec 23, 2015 at 5:14 AM, Dragos Ruiu wrote:
> If you aren't paranoid enough to worry about it, then you've already lost.
What did you lose?
--
Raul
enbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Peter Kay
Sent: December 23, 2015 12:37 AM
To: Dragos Ruiu ; 'Read, James C' ; 'Theo de
Raadt' ; Dragos Ruiu ; 'Read, James C'
; 'Theo de Raadt'
Cc: 'OpenBSD general usage list' ; 'OpenBSD general us
On 23 December 2015 02:04:01 GMT+00:00, Dragos Ruiu wrote:
>I would be interested in any code that can knowingly break inside a VM
>to
>verify unvirtualized status, esp. on Skylake. Older processors can
>probably
>use the virtualization bugs in the hardware for this function.
Who cares? Yes, ther
mes C
Sent: December 22, 2015 9:51 AM
To: Theo de Raadt
Cc: OpenBSD general usage list
Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback]
>> a security consideration, as far as I can see the bootloader loads
>> using
INT
>> 13h calls. How can the kernel be sure it
>> a security consideration, as far as I can see the bootloader loads using
INT
>> 13h calls. How can the kernel be sure it is really operating in ring 0 and
not
>> in some VM given that this is the case?
>Hey, it looks like you are just trying to be a dick.
On the assumption that you are not sug
> >> a security consideration, as far as I can see the bootloader loads using=
> INT
> >> 13h calls. How can the kernel be sure it is really operating in ring 0 a=
> nd not
> >> in some VM given that this is the case?
>
> >Hey, it looks like you are just trying to be a dick.
>
> On the assumptio
> >The OpenBSD process is quite well understood. Use the best methods,
> >doubt what you do, refractor. Simple in concept, but it takes a lot
> >of time.
>
> >Therefore I am looking forward to seeing what you and James can do.
>
> >How long do you think it will take you? Can we expect to see w
>The OpenBSD process is quite well understood. Use the best methods,
>doubt what you do, refractor. Simple in concept, but it takes a lot
>of time.
>Therefore I am looking forward to seeing what you and James can do.
>How long do you think it will take you? Can we expect to see working
>code i
> a security consideration, as far as I can see the bootloader loads using INT
> 13h calls. How can the kernel be sure it is really operating in ring 0 and not
> in some VM given that this is the case?
Hey, it looks like you are just trying to be a dick.
Does your mother know?
Hi,
a security consideration, as far as I can see the bootloader loads using INT
13h calls. How can the kernel be sure it is really operating in ring 0 and not
in some VM given that this is the case?
On Tue, Dec 22, 2015 at 11:19:01AM +, Read, James C wrote:
I guess in the absence of a seriously thought out wish list such a project
could be open ended. >The more care spent in hardware design choices I guess
the more likely we could avoid the mess >that various legacies have caused.
Here
On Tue, Dec 22, 2015 at 11:19:01AM +, Read, James C wrote:
I guess in the absence of a seriously thought out wish list such a project
could be open ended. >The more care spent in hardware design choices I guess
the more likely we could avoid the mess >that various legacies have caused.
Here
>I guess in the absence of a seriously thought out wish list such a project
could be open ended. >The more care spent in hardware design choices I guess
the more likely we could avoid the mess >that various legacies have caused.
Here's a suggestion for a community that is base around the claim of
Oh, don't get me wrong - that was just an idle thinking out loud "what if?"
Rather than a serious proposal.
On 22 Dec 2015 2:05 am, "Theo de Raadt" wrote:
>
> > To be fair, i'd love to see the OpenBSD approach to software development
> > applied to BIOS/EFI firmware.
> >
> > For a start, it would
On Mon, 21 Dec 2015 23:41:18 +
"Read, James C" wrote:
> > Well there you go. Get to it. See you in 10 years.
>
> Seriously, though. The thought must have crossed your mind at least
> once during all these years of mopping up the mess that MS/Intel seem
> to have concocted over the years.
> To be fair, i'd love to see the OpenBSD approach to software development
> applied to BIOS/EFI firmware.
>
> For a start, it wouldn't have the nightmare that is Intel AMT sitting below
> the OS and offering a massive security hole.
Gareth,
The OpenBSD process is quite well understood. Use the
To be fair, i'd love to see the OpenBSD approach to software development
applied to BIOS/EFI firmware.
For a start, it wouldn't have the nightmare that is Intel AMT sitting below
the OS and offering a massive security hole.
On Tue, Dec 22, 2015 at 1:36 AM, Theo de Raadt
wrote:
> > Seriously, th
> Seriously, though. The thought must have crossed your mind at least once
> during all these years of mopping up the mess that MS/Intel seem to have
> concocted over the years.
>
> I wonder what a hardware system designed by BSD bootloader, kernel and driver
> hackers would look like. I should exp
> Well there you go. Get to it. See you in 10 years.
Seriously, though. The thought must have crossed your mind at least once
during all these years of mopping up the mess that MS/Intel seem to have
concocted over the years.
I wonder what a hardware system designed by BSD bootloader, kernel and
Read, James C wrote:
> >Also, BIOS functions are traditionally coded only powerful enough bootup
> style operation.
>
> I'm not sure what you mean by 'powerful enough'. Somebody who installs OpenBSD
> and cannot access the internet now has a double problem 1) he can't access the
> internet 2) he t
On Mon, Dec 21, 2015 at 11:19 AM, Read, James C wrote:
> I'm not sure what you mean by 'powerful enough'. Somebody who installs OpenBSD
> and cannot access the internet now has a double problem 1) he can't access the
> internet 2) he therefore can't search online for information about how to fix
>
> Somebody who installs OpenBSD and cannot access the internet now has a
> double problem 1) he can't access the internet 2) he therefore can't
> search online for information about how to fix the problem.
IF you're installing a new and unknown OS on your only Internet-capable
device - you are *as
On Mon, Dec 21, 2015 at 04:19:38PM +, Read, James C wrote:
The more I look into this the more I start to think that I wasn't being
extreme enough when I decided it would be easier to build my OS than play
around with everyone else's. It now seems what I should have decided was to
build my own
> >Because the kernel cannot know what memory it should leave untouched,
> >to use such BIOS functions.
>
> Why not? I understand that there is some degree of variance amongst BIOS
> uaage of memory but the upper bounds seem to be clearly defined (if I am not
> misinformed). And surely it would be
>Because the kernel cannot know what memory it should leave untouched,
>to use such BIOS functions.
Why not? I understand that there is some degree of variance amongst BIOS usage
of memory but the upper bounds seem to be clearly defined (if I am not
misinformed). And surely it would be possible to
> Given that most OS mailing lists/forums seem to be dominated with hardware
> problems my basic question is does OpenBSD have a fallback option to just use
> BIOS routines to get hardware working if even slower than feasible but at
> least working?
No.
> And if not why not?
Because the kernel c
Hi,
forgive my ignorance and lack of knowledge on OS fundamentals. As my signature
suggests I am a complete beginner with 0x00 knowledge of the subject.
Regardless of that fact here comes my rather naive question:
Given that most OS mailing lists/forums seem to be dominated with hardware
proble
35 matches
Mail list logo
